aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2017-10-10drm/i915: Pass crtc state to i9xx_enable_pll()Ville Syrjälä1-4/+5
Pass the crtc state to i9xx_enable_pll() and use it rather than crtc->config. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170913140900.6972-5-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-10-10drm/i915: Parametrize CBR_DPLLBMD_PIPE definesVille Syrjälä2-3/+2
Apply a bit of polish by parametrizing the CBR_DPLLBMD_PIPE defines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170913140900.6972-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-10-10drm/i915: Use enum pipe for PCH transcodersVille Syrjälä1-3/+3
One more place where we've failed to switch to enum pipe when talking about PCH transcoders. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010125556.25086-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-10-10drm/i915: Increase atomic update vblank evasion time with lockdepDaniel Vetter1-0/+6
All our mmio writes take forever with lockdep due to the constant lock acquire&dropping we do. Ville has some patches to only acquire the mmio spinlocks once instead for every single mmio, but those aren't ready yet. As an interim solution just extend our budget slightly when lockdep is enabled, to avoid the rare and sporadic noise in CI. v2: I forgot to add the FIXME comment ... Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=103169 References: https://bugs.freedesktop.org/show_bug.cgi?id=103124 References: https://bugs.freedesktop.org/show_bug.cgi?id=102403 References: https://bugs.freedesktop.org/show_bug.cgi?id=103020 References: https://bugs.freedesktop.org/show_bug.cgi?id=103019 References: https://bugs.freedesktop.org/show_bug.cgi?id=102723 References: https://bugs.freedesktop.org/show_bug.cgi?id=102544 References: https://bugs.freedesktop.org/show_bug.cgi?id=103180 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171010091816.26898-1-daniel.vetter@ffwll.ch
2017-10-10drm/i915: Use execlists_num_ports instead of size of arrayMika Kuoppala2-2/+2
There is function to tell how many ports we have, so use it. We still have direct relationship with array size and port count, so no harm was done. Fixes: 76e70087d360 ("drm/i915: Make execlist port count variable") Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010114857.13108-1-mika.kuoppala@intel.com
2017-10-10drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlockDaniel Vetter1-15/+23
4.14-rc1 gained the fancy new cross-release support in lockdep, which seems to have uncovered a few more rules about what is allowed and isn't. This one here seems to indicate that allocating a work-queue while holding mmap_sem is a no-go, so let's try to preallocate it. Of course another way to break this chain would be somewhere in the cpu hotplug code, since this isn't the only trace we're finding now which goes through msr_create_device. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 4.14.0-rc1-CI-CI_DRM_3118+ #1 Tainted: G U ------------------------------------------------------ prime_mmap/1551 is trying to acquire lock: (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8109dbb7>] apply_workqueue_attrs+0x17/0x50 but task is already holding lock: (&dev_priv->mm_lock){+.+.}, at: [<ffffffffa01a7b2a>] i915_gem_userptr_init__mmu_notifier+0x14a/0x270 [i915] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #6 (&dev_priv->mm_lock){+.+.}: __lock_acquire+0x1420/0x15e0 lock_acquire+0xb0/0x200 __mutex_lock+0x86/0x9b0 mutex_lock_nested+0x1b/0x20 i915_gem_userptr_init__mmu_notifier+0x14a/0x270 [i915] i915_gem_userptr_ioctl+0x222/0x2c0 [i915] drm_ioctl_kernel+0x69/0xb0 drm_ioctl+0x2f9/0x3d0 do_vfs_ioctl+0x94/0x670 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 -> #5 (&mm->mmap_sem){++++}: __lock_acquire+0x1420/0x15e0 lock_acquire+0xb0/0x200 __might_fault+0x68/0x90 _copy_to_user+0x23/0x70 filldir+0xa5/0x120 dcache_readdir+0xf9/0x170 iterate_dir+0x69/0x1a0 SyS_getdents+0xa5/0x140 entry_SYSCALL_64_fastpath+0x1c/0xb1 -> #4 (&sb->s_type->i_mutex_key#5){++++}: down_write+0x3b/0x70 handle_create+0xcb/0x1e0 devtmpfsd+0x139/0x180 kthread+0x152/0x190 ret_from_fork+0x27/0x40 -> #3 ((complete)&req.done){+.+.}: __lock_acquire+0x1420/0x15e0 lock_acquire+0xb0/0x200 wait_for_common+0x58/0x210 wait_for_completion+0x1d/0x20 devtmpfs_create_node+0x13d/0x160 device_add+0x5eb/0x620 device_create_groups_vargs+0xe0/0xf0 device_create+0x3a/0x40 msr_device_create+0x2b/0x40 cpuhp_invoke_callback+0xa3/0x840 cpuhp_thread_fun+0x7a/0x150 smpboot_thread_fn+0x18a/0x280 kthread+0x152/0x190 ret_from_fork+0x27/0x40 -> #2 (cpuhp_state){+.+.}: __lock_acquire+0x1420/0x15e0 lock_acquire+0xb0/0x200 cpuhp_issue_call+0x10b/0x170 __cpuhp_setup_state_cpuslocked+0x134/0x2a0 __cpuhp_setup_state+0x46/0x60 page_writeback_init+0x43/0x67 pagecache_init+0x3d/0x42 start_kernel+0x3a8/0x3fc x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0x6d/0x70 verify_cpu+0x0/0xfb -> #1 (cpuhp_state_mutex){+.+.}: __lock_acquire+0x1420/0x15e0 lock_acquire+0xb0/0x200 __mutex_lock+0x86/0x9b0 mutex_lock_nested+0x1b/0x20 __cpuhp_setup_state_cpuslocked+0x52/0x2a0 __cpuhp_setup_state+0x46/0x60 page_alloc_init+0x28/0x30 start_kernel+0x145/0x3fc x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0x6d/0x70 verify_cpu+0x0/0xfb -> #0 (cpu_hotplug_lock.rw_sem){++++}: check_prev_add+0x430/0x840 __lock_acquire+0x1420/0x15e0 lock_acquire+0xb0/0x200 cpus_read_lock+0x3d/0xb0 apply_workqueue_attrs+0x17/0x50 __alloc_workqueue_key+0x1d8/0x4d9 i915_gem_userptr_init__mmu_notifier+0x1fb/0x270 [i915] i915_gem_userptr_ioctl+0x222/0x2c0 [i915] drm_ioctl_kernel+0x69/0xb0 drm_ioctl+0x2f9/0x3d0 do_vfs_ioctl+0x94/0x670 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 other info that might help us debug this: Chain exists of: cpu_hotplug_lock.rw_sem --> &mm->mmap_sem --> &dev_priv->mm_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev_priv->mm_lock); lock(&mm->mmap_sem); lock(&dev_priv->mm_lock); lock(cpu_hotplug_lock.rw_sem); *** DEADLOCK *** 2 locks held by prime_mmap/1551: #0: (&mm->mmap_sem){++++}, at: [<ffffffffa01a7b18>] i915_gem_userptr_init__mmu_notifier+0x138/0x270 [i915] #1: (&dev_priv->mm_lock){+.+.}, at: [<ffffffffa01a7b2a>] i915_gem_userptr_init__mmu_notifier+0x14a/0x270 [i915] stack backtrace: CPU: 4 PID: 1551 Comm: prime_mmap Tainted: G U 4.14.0-rc1-CI-CI_DRM_3118+ #1 Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 Call Trace: dump_stack+0x68/0x9f print_circular_bug+0x235/0x3c0 ? lockdep_init_map_crosslock+0x20/0x20 check_prev_add+0x430/0x840 __lock_acquire+0x1420/0x15e0 ? __lock_acquire+0x1420/0x15e0 ? lockdep_init_map_crosslock+0x20/0x20 lock_acquire+0xb0/0x200 ? apply_workqueue_attrs+0x17/0x50 cpus_read_lock+0x3d/0xb0 ? apply_workqueue_attrs+0x17/0x50 apply_workqueue_attrs+0x17/0x50 __alloc_workqueue_key+0x1d8/0x4d9 ? __lockdep_init_map+0x57/0x1c0 i915_gem_userptr_init__mmu_notifier+0x1fb/0x270 [i915] i915_gem_userptr_ioctl+0x222/0x2c0 [i915] ? i915_gem_userptr_release+0x140/0x140 [i915] drm_ioctl_kernel+0x69/0xb0 drm_ioctl+0x2f9/0x3d0 ? i915_gem_userptr_release+0x140/0x140 [i915] ? __do_page_fault+0x2a4/0x570 do_vfs_ioctl+0x94/0x670 ? entry_SYSCALL_64_fastpath+0x5/0xb1 ? __this_cpu_preempt_check+0x13/0x20 ? trace_hardirqs_on_caller+0xe3/0x1b0 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1c/0xb1 RIP: 0033:0x7fbb83c39587 RSP: 002b:00007fff188dc228 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: ffffffff81492963 RCX: 00007fbb83c39587 RDX: 00007fff188dc260 RSI: 00000000c0186473 RDI: 0000000000000003 RBP: ffffc90001487f88 R08: 0000000000000000 R09: 00007fff188dc2ac R10: 00007fbb83efcb58 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000003 R14: 00000000c0186473 R15: 00007fff188dc2ac ? __this_cpu_preempt_check+0x13/0x20 Note that this also has the minor benefit of slightly reducing the critical section where we hold mmap_sem. v2: Set ret correctly when we raced with another thread. v3: Use Chris' diff. Attach the right lockdep splat. v4: Repaint in Tvrtko's colors (aka don't report ENOMEM if we race and some other thread managed to not also get an ENOMEM and successfully install the mmu notifier. Note that the kernel guarantees that small allocations succeed, so this never actually happens). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Sasha Levin <alexander.levin@verizon.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Tejun Heo <tj@kernel.org> References: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3180/shard-hsw3/igt@prime_mmap@test_userptr.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102939 Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171009164401.16035-1-daniel.vetter@ffwll.ch
2017-10-10drm/etnaviv: remove unnecessary clock stabilization delayPhilipp Zabel1-3/+0
There is no reason to wait for clock stabilization here, as the clock framework guarantees that PLL clock sources are stable before clk_enable returns. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: reduce reset delayPhilipp Zabel1-1/+1
After reset assertion, we only have to wait for the reset signals to propagate through the GPU before deasserting the reset again. A few hundred clock cycles should be more than enough. Replace the msleep(1), which can actually take about 30 ms on i.MX6Q in some configurations, with an usleep_range of a few microseconds. If the delay was too short, the FE would not be idle afterwards, and the reset would be retried. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: remove unused function etnaviv_gem_newLucas Stach2-23/+0
We only ever do GEM object creation by handle, as there is no kernel internal use of GEM objects. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: remove stale commentLucas Stach1-7/+0
This comment is outdated as the driver is taking care about clock gating and the pulse eater for quite some time already. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2017-10-10drm/etnaviv: submit supports performance monitor requestsChristian Gmeiner1-1/+1
We increment the minor driver version so userspace can detect perfmon support. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: enable debug registers on demandChristian Gmeiner1-0/+10
Some performance register are debug register and they need to be enabled in order to be functional. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: need to disable clock gating when doing profilingChristian Gmeiner1-0/+13
As done by Vivante kernel driver. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add MC perf domainChristian Gmeiner1-0/+23
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add TX perf domainChristian Gmeiner1-0/+53
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add RA perf domainChristian Gmeiner1-0/+43
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add SE perf domainChristian Gmeiner1-0/+18
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add PA perf domainChristian Gmeiner1-0/+38
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add SH perf domainChristian Gmeiner1-0/+53
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add PE perf domainChristian Gmeiner1-0/+65
We need to iterate over all pixel pipelines to get overall value. Changes from v4 -> v5: - switch back to pixel pipe 0 to prevent GPU hang - PIXELS_RENDERED_2D is exposed for 2D pipe Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add HI perf domainChristian Gmeiner1-0/+55
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: use 'sync points' for performance monitor requestsChristian Gmeiner2-6/+70
With 'sync points' we can sample the reqeustes perform signals before and/or after the submited command buffer. Changes v2 -> v3: - fixed indentation and init nr_events to 1 Changes v4 -> v5: - simplify logic around fence handling. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: clear alloced eventChristian Gmeiner1-1/+1
Results in less code as the users do not set every struct member to 0/NULL. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add 'sync point' supportChristian Gmeiner4-0/+69
In order to support performance counters in a sane way we need to provide a method to sync the GPU with the CPU. The GPU can process multpile command buffers/events per irq. With the help of a 'sync point' we can trigger an event and stop the GPU/FE immediately. When the CPU is done with is processing it simply needs to restart the FE and the GPU will process the command stream. Changes from v1 -> v2: - process sync point with a work item to keep irq as fast as possible Changes from v4 -> v5: - renamed pmrs_* to sync_point_* - call event_free(..) in sync_point_worker(..) Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add performance monitor request processingChristian Gmeiner2-0/+20
Changes v4 -> v5 - make use of doms_meta array Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: copy pmrs from userspaceChristian Gmeiner1-2/+67
Changes from v1 -> v2: - renamed submit_perfmon_request() to submit_perfmon_validate() - extended flags validation - added comment about offset 0 - moved assigment of cmdbuf->nr_pmrs below the copy_from_user of the pmrs. Changes from v2 -> v3: - fixed flags validation Changes v4 -> v5 - pass cmdbuf->exec_state to etnaviv_pm_req_validate(..) Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add performance monitor request validationChristian Gmeiner2-0/+20
Check if the selected domain and signal combination exists. Changes from v4 to v5 - add exec_state parameter Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: extend etnaviv_gpu_cmdbuf_new(..) with nr_pmrsChristian Gmeiner4-4/+17
This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number of struct etnaviv_perfmon elements gets used. Changes from v1 -> v2: - make use of goto as requested by Lucas Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add internal representation of perfmon_requestChristian Gmeiner2-0/+16
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: add infrastructure to query perf counterChristian Gmeiner4-1/+183
Make it possible that userspace can query all performance domains and its signals. This information is needed to sample those signals via submit ioctl. At the moment no performance domain is available. Changes from v1 -> v2: - use a 16 bit value for signals - fix padding issues - add id member to domain and signal struct Changes v4 -> v5 - provide for each pipe an own set of pm domains Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: make it possible to allocate multiple eventsChristian Gmeiner1-16/+31
This makes it possible to allocate multiple events under the event spinlock. This change is needed to support 'sync'-points. Changes v2 -> v3: - wait for the completion of all events - use 10sec timeout regardless of the number of events - removed validation if there are enough free events - fixed return value evaluation of event_alloc(..) in etnaviv_gpu_submit(..) Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: use bitmap to keep track of eventsChristian Gmeiner2-20/+17
This is prep work to be able to allocate multiple events in one go. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: rework clock initializationLucas Stach1-5/+10
The reset path wants to initialize the clock control register regardless of the DYNAMIC_FREQUENCY_SCALING feature, so don't call clock update, but explicitly load the register. Also disabling of the debug registers is moved into the reset function, so we always get to the same state after a GPU reset. This means the clock update function should not touch the bits already set in the clock control register, but instead only update the scaling bits. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2017-10-10drm/etnaviv: remove IOMMU dependencyLucas Stach7-157/+158
Using the IOMMU API to manage the internal GPU MMU has been an historical accident and it keeps getting in the way, as well as entangling the driver with the inner workings of the IOMMU subsystem. Clean this up by removing the usage of iommu_domain, which is the last piece linking etnaviv to the IOMMU subsystem. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2017-10-10drm/etnaviv: mmu: mark local functions staticLucas Stach2-11/+5
And clean up the header file a bit. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/etnaviv: mmu: stop using iommu map/unmap functionsLucas Stach2-14/+62
This is a preparation to remove the etnaviv dependency on the IOMMU subsystem by importing the relevant parts of the iommu map/unamp functions into the driver. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/etnaviv: iommuv1: remove map_lockLucas Stach1-7/+0
It wasn't protecting anything, as the single word writes used to set up or tear down a translation are already inherently atomic, so the spinlock is pure overhead. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/etnaviv: iommuv1: fold pgtable_write into callersLucas Stach1-12/+4
A function doing a single assignment is not really helping the code flow. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/etnaviv: iommuv1: fold pagetable alloc and free into callerLucas Stach1-21/+10
Those functions are simple enough to fold them into the calling function. This also fixes a correctness issue, as the alloc/free functions didn't specifiy the device the memory was allocated for. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/etnaviv: remove iova_to_phys iommu opsLucas Stach2-35/+0
They are not used in any way, so can go away. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/etnaviv: remove iommu fault handlerLucas Stach1-9/+0
The handler has never been used, so it's really just dead code. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
2017-10-10drm/bridge/synopsys: dsi :remove is_panel_bridgebenjamin.gaignard@linaro.org1-4/+1
When using drm_of_panel_bridge_remove() we can simplify the code and remove is_panel_bridge from dw_mipi_dsi structure. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/1506936888-23844-6-git-send-email-benjamin.gaignard@linaro.org
2017-10-10drm/vc4: remove bridge from driver internal structurebenjamin.gaignard@linaro.org1-11/+6
With a call to drm_of_panel_bridge_remove() we could remove the bridge without store it in vc4_dpi internal driver structure. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1506936888-23844-5-git-send-email-benjamin.gaignard@linaro.org
2017-10-10drm/stm: ltdc: remove bridge from driver internal structurebenjamin.gaignard@linaro.org2-13/+5
With a call to drm_of_panel_bridge_remove() we could remove the bridge without store it in ldtc internal driver structure. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/1506936888-23844-4-git-send-email-benjamin.gaignard@linaro.org
2017-10-10drm/drm_of: add drm_of_panel_bridge_remove functionbenjamin.gaignard@linaro.org1-0/+33
This function is the pendant of drm_of_find_panel_or_bridge() to remove a previously allocated panel_bridge. Given a specific port and endpoint it remove the panel bridge. Since drm_panel_bridge_remove() will check that bridge parameter is not NULL and is a real drm_panel_bridge and no a simple bridge it is safe to call it directly. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/1506936888-23844-3-git-send-email-benjamin.gaignard@linaro.org
2017-10-10drm/bridge: make drm_panel_bridge_remove more robustbenjamin.gaignard@linaro.org1-1/+9
Make sure that bridge parameter is not NULL and can be safely cast into a panel_bridge structure. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/1506936755-23625-2-git-send-email-benjamin.gaignard@linaro.org
2017-10-10drm/i915/bios: don't pass bdb to parsers that don't parse VBT directlyJani Nikula1-11/+9
Hint that you're not supposed to look at VBT in these functions. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b82c326be8c796a70bdc2bd1c479bbb6159f5cb0.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: parse SDVO device mapping from pre-parsed child devicesJani Nikula1-27/+12
We parse and store the child devices in parse_general_definitions(). There is no need to parse the VBT block again for SDVO device mapping. Do the same as we do in parse_ddi_ports(). We no longer have access to child device size at this stage, but we also don't need to worry about reading past the child device anymore. Instead of a child device size check, do a mild optimization by limiting the parsing to gens 3 through 7. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c918d4173dd38a165295f1270cb16c2c01bd8cd1.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: merge parse_device_mapping() into parse_general_definitions()Jani Nikula1-32/+16
They're both parsing the same block, and there's no need for them to be split. The former also benefits from the range checks in the latter. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/64a292606ecbb0b8602e6c5523c5746573ec3944.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: cleanup comments and useless returnJani Nikula1-7/+2
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4a95fb9d23d980830e3158d3c57258e6539965ce.1506586821.git.jani.nikula@intel.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.