Age | Commit message (Collapse) | Author |
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We only need to flush the HDP here, not invalidate the TLB.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Separate tlb invalidation and hdp flushing and move the HDP
flush to the caller.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Needed to flush and invalidate the HDP block using the CPU.
v2: use preferred register on soc15.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Samuel Li <Samuel.Li@amd.com> (v1)
|
|
Needed to flush and invalidate the HDP block using the CPU.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Samuel Li <Samuel.Li@amd.com>
|
|
Needed to flush and invalidate the HDP block using the CPU.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Samuel Li <Samuel.Li@amd.com>
|
|
Needed to flush and invalidate the HDP block using the CPU.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Samuel Li <Samuel.Li@amd.com>
|
|
Needed to properly flush the HDP cache with the CPU from rather
than the GPU.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Samuel Li <Samuel.Li@amd.com>
|
|
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We follow the same approach as gfx8. The only changes are register
access macros.
Tested on vega10. The execution latency results fall within the expected
ranges from the polaris10 data.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
V2: reuse the SMUThermal structure defined in pp_thermal.h
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
V2: move the SMU7Thermal structure to newly created header file
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
V2: new header file to hold the common SMU7Thermal structure
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Populate the hwmon temp range as part of thermal controller setup.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
thermal range
Added a new callback for asic specific backends to specify the temperature ranges.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This will be used by powerplay to update the dpm temp range structure
used to interface with hwmon.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
values are part of the valid range
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
better name for
other parameter
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Unused.
v2: squash in warning fix (Harry)
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
printk format strings accepting a single subsequent argument
are shorter thus easier to read.
Instead of having format strings accepting 3 different arguments
pointing to first 3 bytes of the same buffer rewrite the format
string to accept only one argument - the buffer - with "%3ph"
specifier.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
PP_ASSERT_WITH_CODE prints a newline at the end of the message string,
so the message string does not need to include a newline explicitly.
Done using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219145708.23523-1-daniel.vetter@ffwll.ch
|
|
The compiler is not automatically caching the i915->regs address inside
a register and emitting a load for every mmio access. For simple
functions like gen8_gt_irq_handler that are already using the raw
accessors, we can open-code them for substantial savings:
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-83 (-83)
Function old new delta
gen8_gt_irq_handler 290 266 -24
gen8_gt_irq_ack 181 122 -59
Total: Before=954637, After=954554, chg -0.01%
v2: Add raw_reg_read/raw_reg_write.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219100926.16554-1-chris@chris-wilson.co.uk
|
|
Keep the master iir and use it to reduce the number of reads and writes
to the GT iir array, i.e. only the bits marked as set by the master iir
are valid inside GT iir array and will be handled during the interrupt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215073713.26985-1-chris@chris-wilson.co.uk
|
|
As the driver is called to handle circumstances beyond it's control, we
cannot assume that the pm_runtime core is happy to see us. For example,
if we are called from shrink_slab to free up our pages during suspend,
rpm may be disabled and pm_runtime_if_in_use() decides to fail with
-EINVAL rather than simply say no. This is expected to happen, so don't
warn. For example,
[ 217.429228] Suspending console(s) (use no_console_suspend to debug)
[ 217.557179] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 217.559399] sd 0:0:0:0: [sda] Stopping disk
[ 218.661567] i915 0000:00:02.0: Resetting chip after gpu hang
[ 219.523879] ------------[ cut here ]------------
[ 219.524474] pm_runtime_get_if_in_use() failed: -22
[ 219.524817] WARNING: CPU: 1 PID: 14 at drivers/gpu/drm/i915/intel_runtime_pm.c:3351 intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915]
[ 219.524836] Modules linked in: vgem i915 snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec r8169 lpc_ich snd_hwdep mii snd_hda_core snd_pcm prime_numbers
[ 219.525054] CPU: 1 PID: 14 Comm: cpuhp/1 Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1
[ 219.525070] Hardware name: /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010
[ 219.525294] RIP: 0010:intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915]
[ 219.525313] RSP: 0018:ffff880018f5edf8 EFLAGS: 00010286
[ 219.525344] RAX: dffffc0000000008 RBX: ffff880007fc0000 RCX: 0000000000000000
[ 219.525361] RDX: 0000000000000001 RSI: ffffffff850609c0 RDI: ffffffff872992a0
[ 219.525377] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 219.525394] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880007fc0000
[ 219.525411] R13: ffff880018f5f0f8 R14: ffff880007fc8de8 R15: ffff880018f5f0f0
[ 219.525429] FS: 0000000000000000(0000) GS:ffff880019c80000(0000) knlGS:0000000000000000
[ 219.525446] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 219.525463] CR2: 0000564df7897e86 CR3: 0000000000d7c000 CR4: 00000000000006e0
[ 219.525478] Call Trace:
[ 219.525734] i915_gem_shrink+0x841/0xb50 [i915]
[ 219.525802] ? debug_check_no_locks_freed+0x2a0/0x2a0
[ 219.525842] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 219.526083] ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915]
[ 219.526131] ? lock_acquire+0x138/0x3c0
[ 219.526157] ? lock_acquire+0x138/0x3c0
[ 219.526391] ? shrinker_lock+0x49/0x210 [i915]
[ 219.526465] ? mutex_trylock+0x15c/0x1a0
[ 219.526694] ? shrinker_lock+0x49/0x210 [i915]
[ 219.526969] ? i915_gem_shrinker_scan+0xc4/0x320 [i915]
[ 219.527200] i915_gem_shrinker_scan+0xc4/0x320 [i915]
[ 219.527448] ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915]
[ 219.527533] shrink_slab.part.18+0x2d0/0x8d0
[ 219.527613] ? unregister_shrinker+0x1f0/0x1f0
[ 219.527668] ? mem_cgroup_iter+0x37d/0xc50
[ 219.527728] shrink_node+0x882/0xbe0
[ 219.527847] ? shrink_node_memcg+0x11c0/0x11c0
[ 219.527882] ? mark_held_locks+0xa8/0xf0
[ 219.527931] ? trace_hardirqs_on_caller+0x33f/0x590
[ 219.527961] ? ktime_get+0xad/0x140
[ 219.528015] do_try_to_free_pages+0x2d3/0xd70
[ 219.528099] ? allow_direct_reclaim.part.23+0x1d0/0x1d0
[ 219.528132] ? shrink_node+0xbe0/0xbe0
[ 219.528213] try_to_free_pages+0x1cd/0x570
[ 219.528257] ? do_try_to_free_pages+0xd70/0xd70
[ 219.528355] __alloc_pages_nodemask+0xadf/0x2110
[ 219.528423] ? unwind_next_frame+0x870/0x1970
[ 219.528465] ? deref_stack_reg+0x97/0xc0
[ 219.528503] ? gfp_pfmemalloc_allowed+0x150/0x150
[ 219.528539] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.528588] ? unwind_next_frame+0x138/0x1970
[ 219.528619] ? kthread+0x30a/0x3d0
[ 219.528677] ? __read_once_size_nocheck.constprop.4+0x10/0x10
[ 219.528698] ? deref_stack_reg+0xc0/0xc0
[ 219.528762] ? __save_stack_trace+0x6e/0xd0
[ 219.528822] depot_save_stack+0x3bc/0x430
[ 219.528870] kasan_kmalloc+0x142/0x170
[ 219.528912] ? __kmalloc+0xf7/0x340
[ 219.528935] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.528957] ? partition_sched_domains+0x4d4/0x840
[ 219.528978] ? sched_cpu_deactivate+0x11b/0x150
[ 219.529001] ? cpuhp_invoke_callback+0x160/0x15f0
[ 219.529023] ? cpuhp_thread_fun+0x35e/0x710
[ 219.529044] ? smpboot_thread_fn+0x50a/0x7f0
[ 219.529065] ? kthread+0x30a/0x3d0
[ 219.529086] ? ret_from_fork+0x24/0x50
[ 219.529141] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.529169] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.529198] ? set_track+0x87/0x100
[ 219.529225] ? init_object+0x6e/0x80
[ 219.529275] ? ___slab_alloc.constprop.36+0x232/0x3e0
[ 219.529303] ? ___slab_alloc.constprop.36+0x232/0x3e0
[ 219.529325] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.529410] ? mark_held_locks+0xa8/0xf0
[ 219.529453] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.529479] ? trace_hardirqs_on_caller+0x33f/0x590
[ 219.529532] __kmalloc+0xf7/0x340
[ 219.529557] ? register_sched_domain_sysctl+0x23a/0x1b90
[ 219.529604] register_sched_domain_sysctl+0x23a/0x1b90
[ 219.529684] ? sched_debug_show+0x20/0x20
[ 219.529713] ? debug_object_activate+0x530/0x530
[ 219.529771] ? rcu_lockdep_current_cpu_online+0xdc/0x130
[ 219.529802] ? partition_sched_domains+0x4ae/0x840
[ 219.529825] ? rcu_read_lock_sched_held+0x10f/0x130
[ 219.529875] partition_sched_domains+0x4d4/0x840
[ 219.529955] ? sched_init_domains+0x110/0x110
[ 219.529981] ? __wait_rcu_gp+0x24f/0x390
[ 219.530054] sched_cpu_deactivate+0x11b/0x150
[ 219.530086] ? sched_cpu_activate+0x1e0/0x1e0
[ 219.530112] ? __call_rcu.constprop.53+0x680/0x680
[ 219.530132] ? call_rcu_bh+0x10/0x10
[ 219.530166] ? debug_check_no_locks_freed+0x2a0/0x2a0
[ 219.530201] ? trace_raw_output_rcu_utilization+0xa0/0xa0
[ 219.530267] ? trace_raw_output_rcu_utilization+0xa0/0xa0
[ 219.530337] ? rcu_lockdep_current_cpu_online+0xdc/0x130
[ 219.530370] ? sched_cpu_activate+0x1e0/0x1e0
[ 219.530397] cpuhp_invoke_callback+0x160/0x15f0
[ 219.530424] ? lock_acquire+0x138/0x3c0
[ 219.530445] ? lock_acquire+0x138/0x3c0
[ 219.530471] ? cpuhp_thread_fun+0xaf/0x710
[ 219.530507] ? pci_mmcfg_check_reserved+0x100/0x100
[ 219.530565] cpuhp_thread_fun+0x35e/0x710
[ 219.530618] ? cpuhp_complete_idle_dead+0x10/0x10
[ 219.530639] smpboot_thread_fn+0x50a/0x7f0
[ 219.530678] ? sort_range+0x20/0x20
[ 219.530709] ? __kthread_parkme+0xba/0x1f0
[ 219.530739] ? schedule+0x84/0x1a0
[ 219.530768] ? __kthread_parkme+0xbf/0x1f0
[ 219.530805] ? sort_range+0x20/0x20
[ 219.530831] kthread+0x30a/0x3d0
[ 219.530859] ? _kthread_create_on_node+0xb0/0xb0
[ 219.530900] ret_from_fork+0x24/0x50
[ 219.530999] Code: 01 00 00 00 85 c0 74 4a 89 e8 5b 5d c3 80 3d 48 37 4e 00 00 75 f2 89 c6 48 c7 c7 40 f0 61 c0 c6 05 36 37 4e 00 01 e8 ed 2a e1 c2 <0f> ff eb d9 80 3d 3f 37 4e 00 00 75 94 48 c7 c7 60 e8 61 c0 c6
[ 219.531880] ---[ end trace 18ec0139488ea0c8 ]---
[ 219.607967] IRQ 16: no longer affine to CPU1
[ 219.670291] IRQ 24: no longer affine to CPU2
[ 219.701489] IRQ 8: no longer affine to CPU3
[ 219.701529] IRQ 9: no longer affine to CPU3
[ 219.701582] IRQ 18: no longer affine to CPU3
[ 219.701640] IRQ 25: no longer affine to CPU3
[ 219.743857] cache: parent cpu1 should not be sleeping
[ 219.784549] cache: parent cpu2 should not be sleeping
[ 219.816041] cache: parent cpu3 should not be sleeping
v2: Add Returns: information to intel_runtime_pm_get_if_in_use() kerneldoc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219125046.19363-1-chris@chris-wilson.co.uk
|
|
Use the new idr_init_base() function to create an IDR that knows id==0
is never allocated as it maps to an invalid identifier. By knowing that
id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
of having to start each lookup from the zeroth leaf as id==0 is always
unused (and thus the tree-of-bitmaps indicate that is the first
available).
References: 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Christian Konig <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com> as well.
Link: https://patchwork.freedesktop.org/patch/msgid/20180212145533.30046-1-chris@chris-wilson.co.uk
|
|
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL. A check for this added right after
the call to drm_cvt_mode() in this particular area of code.
Signed-off-by: Joe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-4-joe.moriarty@oracle.com
|
|
The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.
- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.
Signed-off-by: Joe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.moriarty@oracle.com
|
|
The in-lined comments for channel.port doesn't follow the syntax
described at kernel-doc document, causing the following warning:
$ ./scripts/kernel-doc -none drivers/gpu/drm/i915/intel_dpio_phy.c
drivers/gpu/drm/i915/intel_dpio_phy.c:154: warning: Function parameter or member 'channel.port' not described in 'bxt_ddi_phy_info'
While the best would be for the Kernel to deduce that from the
context, supporting it is not trivial. So, let's just stick with
the existing syntax.
[Jani: depends on "scripts: kernel-doc: support in-line comments on
nested structs/unions" to actually fix the warning.]
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9ba9ac773f4f9e60770bd9169b0e46ac974d858a.1518788761.git.mchehab@s-opensource.com
|
|
drivers/dma-buf/sw_sync.c:248: warning: No description found for parameter 'obj'
drivers/dma-buf/sw_sync.c:248: warning: No description found for parameter 'value'
drivers/dma-buf/sw_sync.c:248: warning: Excess function parameter 'parent' description in 'sync_pt_create'
drivers/dma-buf/sw_sync.c:248: warning: Excess function parameter 'inc' description in 'sync_pt_create'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208113816.8288-1-chris@chris-wilson.co.uk
|
|
drivers/gpu/drm/drm_lease.c:56: warning: No description found for parameter 'lessee_id'
drivers/gpu/drm/drm_lease.c:56: warning: Excess function parameter 'id' description in '_drm_find_lessee'
drivers/gpu/drm/drm_lease.c:114: warning: No description found for parameter 'file_priv'
drivers/gpu/drm/drm_lease.c:114: warning: Excess function parameter 'master' description in '_drm_lease_held'
drivers/gpu/drm/drm_lease.c:134: warning: No description found for parameter 'file_priv'
drivers/gpu/drm/drm_lease.c:134: warning: Excess function parameter 'master' description in 'drm_lease_held'
drivers/gpu/drm/drm_lease.c:158: warning: No description found for parameter 'crtcs_in'
drivers/gpu/drm/drm_lease.c:158: warning: Excess function parameter 'crtcs' description in 'drm_lease_filter_crtcs'
drivers/gpu/drm/drm_lease.c:311: warning: No description found for parameter 'top'
drivers/gpu/drm/drm_lease.c:311: warning: Excess function parameter 'master' description in '_drm_lease_revoke'
drivers/gpu/drm/drm_lease.c:494: warning: No description found for parameter 'lessor_priv'
drivers/gpu/drm/drm_lease.c:494: warning: Excess function parameter 'file_priv' description in 'drm_mode_create_lease_ioctl'
drivers/gpu/drm/drm_lease.c:672: warning: No description found for parameter 'lessee_priv'
drivers/gpu/drm/drm_lease.c:672: warning: Excess function parameter 'file_priv' description in 'drm_mode_get_lease_ioctl'
drivers/gpu/drm/drm_lease.c:733: warning: No description found for parameter 'lessor_priv'
drivers/gpu/drm/drm_lease.c:733: warning: Excess function parameter 'file_priv' description in 'drm_mode_revoke_lease_ioctl'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208110817.30057-1-chris@chris-wilson.co.uk
|
|
The structure bochs_bo_driver is local to the source and does not need to
be in global scope, so make it static.
Cleans up sparse warning:
drivers/gpu/drm/bochs/bochs_mm.c:197:22: warning: symbol 'bochs_bo_driver'
was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207111353.30261-1-colin.king@canonical.com
|
|
Hitting the failure path through check_digital_port_conflicts triggers:
================================================
WARNING: lock held when returning to user space!
4.16.0-rc1-CI-kasan_1+ #1 Tainted: G W
------------------------------------------------
kms_3d/1439 is leaving the kernel with locks still held!
1 lock held by kms_3d/1439:
#0: (drm_connector_list_iter){.+.+}, at: [<000000003745d183>] intel_atomic_check+0x1d9d/0x3ff0 [i915]
Rearrange the code to have a single exit path through the unlock.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215091425.42364-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.
This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.
Cc: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Ørjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-4-thierry.escande@collabora.com
|
|
The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).
Signed-off-by: Haixia Shi <hshi@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-3-thierry.escande@collabora.com
|
|
This patch removes unused fields from vop structure.
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-2-thierry.escande@collabora.com
|
|
devm_ioremap_resource() already checks if the resource is NULL, so
remove the unnecessary platform_get_resource() error check.
Cc: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1513602150-7542-4-git-send-email-festevam@gmail.com
|
|
devm_ioremap_resource() already checks if the resource is NULL, so
remove the unnecessary platform_get_resource() error check.
Cc: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1513602150-7542-3-git-send-email-festevam@gmail.com
|
|
Backmerge 4.15 and hdcp topic branch
Signed-off-by: Sean Paul <seanpaul@chromium.org>
|
|
Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.
Invert their settings of IO_POL register.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1518717288-123578-1-git-send-email-giulio.benetti@micronovasrl.com
|
|
Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
broke the build with one build error and one warning. Fix both.
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180216154412.22876-1-maxime.ripard@bootlin.com
|
|
We can't assert that the execlists are active before we set the flag. So
perform the assert after we are expected to have marked the execlists
active.
Fixes: 339ccd35b42c ("drm/i915: Assert that we always complete a submission to guc/execlists")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180216153210.30551-1-chris@chris-wilson.co.uk
|
|
The continual resubmission model for execlists (and emulated over guc)
requires that we keep feeding requests into the HW in order to generate
more CS interrupts to drain the rest of the queue. Add a couple of
asserts to ensure that we don't skip a cycle and come to a grinding
halt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180215162553.23348-1-chris@chris-wilson.co.uk
|
|
i915 is the only driver using those fields in the drm_gem_object
structure, so they only waste memory for all other drivers.
Move the fields into drm_i915_gem_object instead and patch the i915 code
with the following sed commands:
sed -i "s/obj->base.read_domains/obj->read_domains/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c
sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c
Change is only compile tested.
v2: move fields around as suggested by Chris.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180216124338.9087-1-christian.koenig@amd.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.
Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-11-jernej.skrabec@siol.net
|
|
It supports 1 VI and 1 UI plane and HW scaling on both planes.
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-10-jernej.skrabec@siol.net
|
|
This TCON is connected to HDMI encoder.
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-9-jernej.skrabec@siol.net
|
|
Some TCONs on newer SoCs doesn't support channel 0, since they are meant
to be used only with TV or HDMI encoder.
Prepare support for them with adding has_channel_0 quirk.
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-8-jernej.skrabec@siol.net
|