aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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 <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Marta Lofstedt <[email protected]> Cc: Tejun Heo <[email protected]> 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 <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]>
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 <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]>
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 <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add MC perf domainChristian Gmeiner1-0/+23
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add TX perf domainChristian Gmeiner1-0/+53
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add RA perf domainChristian Gmeiner1-0/+43
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add SE perf domainChristian Gmeiner1-0/+18
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add PA perf domainChristian Gmeiner1-0/+38
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add SH perf domainChristian Gmeiner1-0/+53
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add HI perf domainChristian Gmeiner1-0/+55
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add internal representation of perfmon_requestChristian Gmeiner2-0/+16
Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add uapi for perfmon featureChristian Gmeiner1-0/+16
Sadly we can not read any registers via command stream so we need to extend the drm_etnaviv_gem_submit struct with performance monitor requests. Those requests gets process before or after the actual submitted command stream. The Vivante kernel driver has a special ioctl to read all perfmon registers at once and return it. Changes from v1 -> v2: - use a 16 bit value for signals - fix padding issues Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2017-10-10drm/etnaviv: add infrastructure to query perf counterChristian Gmeiner5-2/+209
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
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 <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]>
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 <[email protected]>
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 <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
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 <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
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 <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
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 <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
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 <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
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 <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
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 <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Reviewed-By: Wladimir J. van der Laan <[email protected]>
2017-10-10drm/bridge/synopsys: dsi :remove is_panel_bridge[email protected]1-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 <[email protected]> Reviewed-by: Philippe Cornu <[email protected]> Tested-by: Philippe Cornu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-10-10drm/vc4: remove bridge from driver internal structure[email protected]1-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 <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-10-10drm/stm: ltdc: remove bridge from driver internal structure[email protected]2-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 <[email protected]> Reviewed-by: Philippe Cornu <[email protected]> Tested-by: Philippe Cornu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-10-10drm/drm_of: add drm_of_panel_bridge_remove function[email protected]2-0/+41
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 <[email protected]> Reviewed-by: Philippe Cornu <[email protected]> Tested-by: Philippe Cornu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-10-10drm/bridge: make drm_panel_bridge_remove more robust[email protected]1-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 <[email protected]> Reviewed-by: Philippe Cornu <[email protected]> Tested-by: Philippe Cornu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
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ä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> 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ä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> 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ä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> 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ä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4a95fb9d23d980830e3158d3c57258e6539965ce.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: remove an unnecessary temp variableJani Nikula1-5/+2
Prepare for merging parse_device_mapping() into parse_general_definitions(). No functional changes. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f1c3621e2622f4debdfb4a2f5c1959845754ac04.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: don't initialize fields based on vbt versionJani Nikula1-13/+0
In theory, these might clobber information for older VBT versions. We might have to store the BDB version for later parsing, but currently all code accessing these fields will only use them on newer platforms with new enough BDB versions. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/0232d9cb258e8f83c4180cdb8aad1459a312ec2a.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: refactor parse general definitionsJani Nikula1-14/+20
Early return on failures. Rename the variable for later merging with parse_device_mappings(). Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/785abb904a572752fec68d90d34efeb67774dc1f.1506586821.git.jani.nikula@intel.com
2017-10-10drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channelJani Nikula1-1/+1
While technically CHV isn't DDI, we do look at the VBT based DDI port info for HDMI DDC pin and DP AUX channel. (We call these "alternate", but they're really just something that aren't platform defaults.) In commit e4ab73a13291 ("drm/i915: Respect alternate_ddc_pin for all DDI ports") Ville writes, "IIRC there may be CHV system that might actually need this." I'm not sure why there couldn't be even more platforms that need this, but start conservative, and parse the info for CHV in addition to DDI. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100553 Reported-by: Marek Wilczewski <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d0815082cb98487618429b62414854137049b888.1506586821.git.jani.nikula@intel.com
Powered by cgit, Gruvboxed by Blaster4385.