[Nouveau] [PATCH v3 1/4] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

2019-02-01 Thread Lyude Paul
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the passed port if we successfully
allocated VCPI to it.

As a result, if drm_dp_mst_allocate_vcpi() fails during a modeset and
another successive modeset calls drm_dp_mst_deallocate_vcpi() we will
end up dropping someone else's malloc reference to the port. Example:

[  962.309260] 
==
[  962.309290] BUG: KASAN: use-after-free in 
drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309296] Read of size 4 at addr 888416c30004 by task kworker/0:1H/500

[  962.309308] CPU: 0 PID: 500 Comm: kworker/0:1H Tainted: GW  O  
5.0.0-rc2Lyude-Test+ #1
[  962.309313] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 
) 04/09/2018
[  962.309428] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
[  962.309434] Call Trace:
[  962.309452]  dump_stack+0xad/0x150
[  962.309462]  ? dump_stack_print_info.cold.0+0x1b/0x1b
[  962.309472]  ? kmsg_dump_rewind_nolock+0xd9/0xd9
[  962.309504]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309515]  print_address_description+0x6c/0x23c
[  962.309542]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309568]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309577]  kasan_report.cold.3+0x1a/0x32
[  962.309605]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309631]  drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309658]  ? drm_dp_mst_put_mstb_malloc+0x180/0x180 [drm_kms_helper]
[  962.309687]  drm_dp_mst_destroy_state+0xcd/0x120 [drm_kms_helper]
[  962.309745]  drm_atomic_state_default_clear+0x6ee/0xcc0 [drm]
[  962.309864]  intel_atomic_state_clear+0xe/0x80 [i915]
[  962.309928]  __drm_atomic_state_free+0x35/0xd0 [drm]
[  962.310044]  intel_atomic_cleanup_work+0x56/0x70 [i915]
[  962.310057]  process_one_work+0x884/0x1400
[  962.310067]  ? drain_workqueue+0x5a0/0x5a0
[  962.310075]  ? __schedule+0x87f/0x1e80
[  962.310086]  ? __sched_text_start+0x8/0x8
[  962.310095]  ? run_rebalance_domains+0x400/0x400
[  962.310110]  ? deref_stack_reg+0xb4/0x120
[  962.310117]  ? __read_once_size_nocheck.constprop.7+0x10/0x10
[  962.310124]  ? worker_enter_idle+0x47f/0x6a0
[  962.310134]  ? schedule+0xd7/0x2e0
[  962.310141]  ? __schedule+0x1e80/0x1e80
[  962.310148]  ? _raw_spin_lock_irq+0x9f/0x130
[  962.310155]  ? _raw_write_unlock_irqrestore+0x110/0x110
[  962.310164]  worker_thread+0x196/0x11e0
[  962.310175]  ? set_load_weight+0x2e0/0x2e0
[  962.310181]  ? __switch_to_asm+0x34/0x70
[  962.310187]  ? __switch_to_asm+0x40/0x70
[  962.310194]  ? process_one_work+0x1400/0x1400
[  962.310199]  ? __switch_to_asm+0x40/0x70
[  962.310205]  ? __switch_to_asm+0x34/0x70
[  962.310211]  ? __switch_to_asm+0x34/0x70
[  962.310216]  ? __switch_to_asm+0x40/0x70
[  962.310221]  ? __switch_to_asm+0x34/0x70
[  962.310226]  ? __switch_to_asm+0x40/0x70
[  962.310231]  ? __switch_to_asm+0x34/0x70
[  962.310236]  ? __switch_to_asm+0x40/0x70
[  962.310242]  ? syscall_return_via_sysret+0xf/0x7f
[  962.310248]  ? __switch_to_asm+0x34/0x70
[  962.310253]  ? __switch_to_asm+0x40/0x70
[  962.310258]  ? __switch_to_asm+0x34/0x70
[  962.310263]  ? __switch_to_asm+0x40/0x70
[  962.310268]  ? __switch_to_asm+0x34/0x70
[  962.310273]  ? __switch_to_asm+0x40/0x70
[  962.310281]  ? __schedule+0x87f/0x1e80
[  962.310292]  ? __sched_text_start+0x8/0x8
[  962.310300]  ? save_stack+0x8c/0xb0
[  962.310308]  ? __kasan_kmalloc.constprop.6+0xc6/0xd0
[  962.310313]  ? kthread+0x98/0x3a0
[  962.310318]  ? ret_from_fork+0x35/0x40
[  962.310334]  ? __wake_up_common+0x178/0x6f0
[  962.310343]  ? _raw_spin_lock_irqsave+0xa4/0x140
[  962.310349]  ? __lock_text_start+0x8/0x8
[  962.310355]  ? _raw_write_lock_irqsave+0x70/0x130
[  962.310360]  ? __lock_text_start+0x8/0x8
[  962.310371]  ? process_one_work+0x1400/0x1400
[  962.310376]  kthread+0x2e2/0x3a0
[  962.310383]  ? kthread_create_on_node+0xc0/0xc0
[  962.310389]  ret_from_fork+0x35/0x40

[  962.310401] Allocated by task 1462:
[  962.310410]  __kasan_kmalloc.constprop.6+0xc6/0xd0
[  962.310437]  drm_dp_add_port+0xd60/0x1960 [drm_kms_helper]
[  962.310464]  drm_dp_send_link_address+0x4b0/0x770 [drm_kms_helper]
[  962.310491]  drm_dp_check_and_send_link_address+0x197/0x1f0 [drm_kms_helper]
[  962.310515]  drm_dp_mst_link_probe_work+0x2b6/0x330 [drm_kms_helper]
[  962.310522]  process_one_work+0x884/0x1400
[  962.310529]  worker_thread+0x196/0x11e0
[  962.310533]  kthread+0x2e2/0x3a0
[  962.310538]  ret_from_fork+0x35/0x40

[  962.310543] Freed by task 500:
[  962.310550]  __kasan_slab_free+0x133/0x180
[  962.310555]  kfree+0x92/0x1a0
[  962.310581]  drm_dp_mst_put_port_malloc+0x14d/0x180 [drm_kms_helper]
[  

[Nouveau] [PATCH v3 0/4] drm/dp_mst: Fix regressions from new atomic VCPI helpers

2019-02-01 Thread Lyude Paul
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.

This time around, we use a slightly different but much less complicated
approach for fixing said issues.

Cc: Daniel Vetter 

Lyude Paul (4):
  drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
  drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()
  drm/atomic: Add drm_atomic_state->duplicated
  drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

 drivers/gpu/drm/drm_atomic_helper.c | 10 +++-
 drivers/gpu/drm/drm_dp_mst_topology.c   | 32 +
 drivers/gpu/drm/i915/intel_dp_mst.c | 17 +
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 +
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 31 ++--
 drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
 include/drm/drm_atomic.h|  9 +++
 7 files changed, 66 insertions(+), 40 deletions(-)

-- 
2.20.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH v3 3/4] drm/atomic: Add drm_atomic_state->duplicated

2019-02-01 Thread Lyude Paul
Since

commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")

We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a connector is
unregistered before we attempt to restore the atomic state, something we
end up failing the atomic check that happens when trying to restore the
state during resume.

Normally this would be OK: we try our best to make sure that the atomic
state pre-suspend can be restored post-suspend, but failures at that
point usually don't cause problems. That is of course, until we
introduced the new atomic MST VCPI helpers:

[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] active 
changed
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for 
[CONNECTOR:123:DP-5]
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling 
[CONNECTOR:123:DP-5]
[drm:drm_atomic_get_private_obj_state [drm]] Added new private object 
25844636 state 9fd2899a to 3a13d7b8
WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 
drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl 
x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) 
crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt 
snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer 
mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi 
thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video tpm 
acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci 
nvme_core xhci_hcd
CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  
5.0.0-rc2Lyude-Test+ #1
Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 
85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 b3 
a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
RSP: 0018:88841235f268 EFLAGS: 00010246
RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
RDX: dc00 RSI:  RDI: ed108246bde0
RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
R13: 8883bc499100 R14: 88841bf12ab8 R15: 
FS:  7f16fbd4cd00() GS:88841ed8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
 ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
 ? __printk_safe_exit+0x10/0x10
 ? save_stack+0x8c/0xb0
 ? vprintk_func+0x96/0x1bf
 ? __printk_safe_exit+0x10/0x10
 intel_atomic_check+0x234/0x4750 [i915]
 ? printk+0x9f/0xc5
 ? kmsg_dump_rewind_nolock+0xd9/0xd9
 ? _raw_spin_lock_irqsave+0xa4/0x140
 ? drm_atomic_check_only+0xb1/0x28b0 [drm]
 ? drm_dbg+0x186/0x1b0 [drm]
 ? drm_dev_dbg+0x200/0x200 [drm]
 ? intel_link_compute_m_n+0xb0/0xb0 [i915]
 ? drm_mode_put_tile_group+0x20/0x20 [drm]
 ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
 ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
 drm_atomic_check_only+0x13c4/0x28b0 [drm]
 ? drm_state_info+0x220/0x220 [drm]
 ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
 ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
 ? kasan_unpoison_shadow+0x35/0x40
 drm_atomic_commit+0x3b/0x100 [drm]
 drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
 drm_mode_setcrtc+0x636/0x1660 [drm]
 ? vprintk_func+0x96/0x1bf
 ? drm_dev_dbg+0x200/0x200 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? printk+0x9f/0xc5
 ? mutex_unlock+0x1d/0x40
 ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
 ? rcu_sync_dtor+0x2e0/0x2e0
 ? drm_dbg+0x186/0x1b0 [drm]
 ? set_page_dirty+0x271/0x4d0
 drm_ioctl_kernel+0x203/0x290 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? drm_setversion+0x7f0/0x7f0 [drm]
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x34/0x70
 drm_ioctl+0x445/0x950 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? drm_getunique+0x220/0x220 [drm]
 ? expand_files.part.10+0x920/0x920
 do_vfs_ioctl+0x1a1/0x13d0
 ? ioctl_preallocate+0x2b0/0x2b0
 ? __fget_light+0x2d6/0x390
 ? schedule+0xd7/0x2e0
 ? fget_raw+0x10/0x10
 ? apic_timer_interrupt+0xa/0x20
 ? apic_timer_interrupt+0xa/0x20
 ? rcu_cleanup_dead_rnp+0x2c0/0x2c0
 ksys_ioctl+0x60/0x90
 __x64_sys_ioctl+0x6f/0xb0
 do_syscall_64+0x136/0x440
 ? 

[Nouveau] [PATCH v3 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

2019-02-01 Thread Lyude Paul
Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in order to ensure that when committing an artificially
duplicated state (like during system resume), that we reuse the PBN of
that state to perform VCPI allocations and don't recalculate a different
value from the drm connector's reported bpc.

Also, move the VCPI slot allocations while we're at it as well. With
this, removing a topology in suspend while using nouveau no longer
causes the new atomic VCPI helpers to complain.

Signed-off-by: Lyude Paul 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Cc: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 ++
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 +++--
 drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index a194990d2b0d..b5fae5ab3fa8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -116,6 +116,12 @@ struct nv50_head_atom {
u8 depth:4;
} or;
 
+   /* Currently only used for MST */
+   struct {
+   int pbn;
+   u8 tu:6;
+   } dp;
+
union nv50_head_atom_mask {
struct {
bool olut:1;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 60d858c2f2ce..e8bb35f6d015 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -659,8 +659,6 @@ struct nv50_mstc {
 
struct drm_display_mode *native;
struct edid *edid;
-
-   int pbn;
 };
 
 struct nv50_msto {
@@ -765,17 +763,26 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_connector *connector = conn_state->connector;
struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
-   int bpp = connector->display_info.bpc * 3;
+   struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
int slots;
 
-   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
-bpp);
+   /* When restoring duplicated states, we need to make sure that the
+* bw remains the same and avoid recalculating it, as the connector's
+* bpc may have changed after the state was duplicated
+*/
+   if (!state->duplicated)
+   asyh->dp.pbn =
+   drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+connector->display_info.bpc * 3);
 
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
- mstc->port, mstc->pbn);
+ mstc->port,
+ asyh->dp.pbn);
if (slots < 0)
return slots;
+
+   asyh->dp.tu = slots;
}
 
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
@@ -786,13 +793,13 @@ static void
 nv50_msto_enable(struct drm_encoder *encoder)
 {
struct nv50_head *head = nv50_head(encoder->crtc);
+   struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
struct nv50_msto *msto = nv50_msto(encoder);
struct nv50_mstc *mstc = NULL;
struct nv50_mstm *mstm = NULL;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
u8 proto, depth;
-   int slots;
bool r;
 
drm_connector_list_iter_begin(encoder->dev, _iter);
@@ -808,8 +815,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
if (WARN_ON(!mstc))
return;
 
-   slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
-   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn, slots);
+   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, armh->dp.pbn,
+armh->dp.tu);
WARN_ON(!r);
 
if (!mstm->links++)
@@ -827,8 +834,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
default: depth = 0x6; break;
}
 
-   mstm->outp->update(mstm->outp, head->base.index,
-  nv50_head_atom(head->base.base.state), proto, depth);
+   mstm->outp->update(mstm->outp, head->base.index, armh, proto, depth);
 
msto->head = head;
msto->mstc = mstc;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index ac97ebce5b35..2e7a0c347ddb 100644
--- 

[Nouveau] [PATCH v3 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

2019-02-01 Thread Lyude Paul
Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new displays on unregistered connectors in
update_connector_routing() in drm_atomic_check_modeset(). All it does is
cause us to have to make weird special exceptions in our atomic
modesetting code. So, get rid of it entirely.

Signed-off-by: Lyude Paul 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c   | 12 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  3 +--
 3 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index abb0ea8ba9d9..4325e1518286 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3117,10 +3117,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
drm_atomic_state *state,
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
-   port = drm_dp_mst_topology_get_port_validated(mgr, port);
-   if (port == NULL)
-   return -EINVAL;
-
/* Find the current allocation for this port, if any */
list_for_each_entry(pos, _state->vcpis, next) {
if (pos->port == port) {
@@ -3153,10 +3149,8 @@ int drm_dp_atomic_find_vcpi_slots(struct 
drm_atomic_state *state,
/* Add the new allocation to the state */
if (!vcpi) {
vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
-   if (!vcpi) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (!vcpi)
+   return -ENOMEM;
 
drm_dp_mst_get_port_malloc(port);
vcpi->port = port;
@@ -3165,8 +3159,6 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state 
*state,
vcpi->vcpi = req_slots;
 
ret = req_slots;
-out:
-   drm_dp_mst_topology_put_port(port);
return ret;
 }
 EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index cdb83d294cdd..fb67cd931117 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -80,17 +80,12 @@ static int intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
 
-   /* Zombie connectors can't have VCPI slots */
-   if (!drm_connector_is_unregistered(connector)) {
-   slots = drm_dp_atomic_find_vcpi_slots(state,
- _dp->mst_mgr,
- port,
- mst_pbn);
-   if (slots < 0) {
-   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
- slots);
-   return slots;
-   }
+   slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr, port,
+ mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+   return slots;
}
 
intel_link_compute_m_n(bpp, lane_count,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 2e8a5fd9b262..60d858c2f2ce 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -771,8 +771,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
 bpp);
 
-   if (drm_atomic_crtc_needs_modeset(crtc_state) &&
-   !drm_connector_is_unregistered(connector)) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
  mstc->port, mstc->pbn);
if (slots < 0)
-- 
2.20.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

2019-02-01 Thread Lyude Paul
Important! below

On Fri, 2019-02-01 at 18:57 +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote:
> > Since
> > 
> > commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> > connectors harder")
> > 
> > We've been failing atomic checks if they try to enable new displays on
> > unregistered connectors. This is fine except for the one situation that
> > breaks atomic assumptions: suspend/resume. If a connector is
> > unregistered before we attempt to restore the atomic state, something we
> > end up failing the atomic check that happens when trying to restore the
> > state during resume.
> > 
> > Normally this would be OK: we try our best to make sure that the atomic
> > state pre-suspend can be restored post-suspend, but failures at that
> > point usually don't cause problems. That is of course, until we
> > introduced the new atomic MST VCPI helpers:
> > 
> > [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B]
> > active changed
> > [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing
> > for [CONNECTOR:123:DP-5]
> > [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling
> > [CONNECTOR:123:DP-5]
> > [drm:drm_atomic_get_private_obj_state [drm]] Added new private object
> > 25844636 state 9fd2899a to 3a13d7b8
> > WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153
> > drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> > Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek
> > snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb
> > btrtl x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit
> > drm_kms_helper(O) crc32_pclmul snd_hda_intel syscopyarea sysfillrect
> > snd_hda_codec sysimgblt snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr
> > drm(O) psmouse snd_timer mei_me ecdh_generic i2c_i801 mei i2c_core
> > ucsi_acpi typec_ucsi typec wmi thinkpad_acpi ledtrig_audio snd soundcore
> > tpm_tis rfkill tpm_tis_core video tpm acpi_pad pcc_cpufreq uas usb_storage
> > crc32c_intel nvme serio_raw xhci_pci nvme_core xhci_hcd
> > CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  5.0.0-
> > rc2Lyude-Test+ #1
> > Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 )
> > 04/09/2018
> > RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> > Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00
> > 0f 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7
> > c0 78 b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
> > RSP: 0018:88841235f268 EFLAGS: 00010246
> > RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
> > RDX: dc00 RSI:  RDI: ed108246bde0
> > RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
> > R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
> > R13: 8883bc499100 R14: 88841bf12ab8 R15: 
> > FS:  7f16fbd4cd00() GS:88841ed8()
> > knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
> > DR0:  DR1:  DR2: 
> > DR3:  DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >  drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
> >  ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
> >  ? __printk_safe_exit+0x10/0x10
> >  ? save_stack+0x8c/0xb0
> >  ? vprintk_func+0x96/0x1bf
> >  ? __printk_safe_exit+0x10/0x10
> >  intel_atomic_check+0x234/0x4750 [i915]
> >  ? printk+0x9f/0xc5
> >  ? kmsg_dump_rewind_nolock+0xd9/0xd9
> >  ? _raw_spin_lock_irqsave+0xa4/0x140
> >  ? drm_atomic_check_only+0xb1/0x28b0 [drm]
> >  ? drm_dbg+0x186/0x1b0 [drm]
> >  ? drm_dev_dbg+0x200/0x200 [drm]
> >  ? intel_link_compute_m_n+0xb0/0xb0 [i915]
> >  ? drm_mode_put_tile_group+0x20/0x20 [drm]
> >  ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
> >  ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
> >  drm_atomic_check_only+0x13c4/0x28b0 [drm]
> >  ? drm_state_info+0x220/0x220 [drm]
> >  ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
> >  ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
> >  ? kasan_unpoison_shadow+0x35/0x40
> >  drm_atomic_commit+0x3b/0x100 [drm]
> >  drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
> >  drm_mode_setcrtc+0x636/0x1660 [drm]
> >  ? vprintk_func+0x96/0x1bf
> >  ? drm_dev_dbg+0x200/0x200 [drm]
> >  ? drm_mode_getcrtc+0x790/0x790 [drm]
> >  ? printk+0x9f/0xc5
> >  ? mutex_unlock+0x1d/0x40
> >  ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
> >  ? rcu_sync_dtor+0x2e0/0x2e0
> >  ? drm_dbg+0x186/0x1b0 [drm]
> >  ? set_page_dirty+0x271/0x4d0
> >  drm_ioctl_kernel+0x203/0x290 [drm]
> >  ? drm_mode_getcrtc+0x790/0x790 [drm]
> >  ? drm_setversion+0x7f0/0x7f0 [drm]
> >  ? 

Re: [Nouveau] Render Targets and Pitch Linear Textures in Maxwell/Pascal Question

2019-02-01 Thread Ilia Mirkin
Miptree layout for linear textures:

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_miptree.c#n238

Setting for RTs:

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n224

Follow the !nouveau_bo_memtype path (and not BUFFER).

Hope this helps,

  -ilia

On Fri, Feb 1, 2019 at 5:25 PM Fernando Sahmkow  wrote:
>
> So I have been going on over the documentation trying to figure out the exact 
> layout of Pitch Linear Textures and find some missing values.
>
> First Question: What's the correct layout of pitch linear textures in memory? 
> Is padding of the pitch added at start or at the end? Do they have some kind 
> of header? Currently I see them as a normal texture matrix with just pitch at 
> the end of each row but If I send the game this values, they go into an 
> ternal loop.
>
> Second Question: Pitch Value in Render Targets. In the registers in 
> https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L282
>  the pitch does not appear anywhere, where is it stored for Render Targets.
>
> Thanks in advance and I hope you guys can provide me some info.
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] Render Targets and Pitch Linear Textures in Maxwell/Pascal Question

2019-02-01 Thread Fernando Sahmkow
So I have been going on over the documentation trying to figure out the
exact layout of Pitch Linear Textures and find some missing values.

First Question: What's the correct layout of pitch linear textures in
memory? Is padding of the pitch added at start or at the end? Do they have
some kind of header? Currently I see them as a normal texture matrix with
just pitch at the end of each row but If I send the game this values, they
go into an ternal loop.

Second Question: Pitch Value in Render Targets. In the registers in
https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L282
the pitch does not appear anywhere, where is it stored for Render Targets.

Thanks in advance and I hope you guys can provide me some info.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 109529] [NV46] unable to handle kernel paging request

2019-02-01 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109529

--- Comment #1 from dfloger...@gmail.com ---
I made it lock-up using 4.19.18 with mesa-git.

However, there may be two separate issues going on.  This time, I did not get
anything in dmesg after the event.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

2019-02-01 Thread Daniel Vetter
On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote:
> Since
> 
> commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> connectors harder")
> 
> We've been failing atomic checks if they try to enable new displays on
> unregistered connectors. This is fine except for the one situation that
> breaks atomic assumptions: suspend/resume. If a connector is
> unregistered before we attempt to restore the atomic state, something we
> end up failing the atomic check that happens when trying to restore the
> state during resume.
> 
> Normally this would be OK: we try our best to make sure that the atomic
> state pre-suspend can be restored post-suspend, but failures at that
> point usually don't cause problems. That is of course, until we
> introduced the new atomic MST VCPI helpers:
> 
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] 
> active changed
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for 
> [CONNECTOR:123:DP-5]
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling 
> [CONNECTOR:123:DP-5]
> [drm:drm_atomic_get_private_obj_state [drm]] Added new private object 
> 25844636 state 9fd2899a to 3a13d7b8
> WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 
> drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl 
> x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) 
> crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt 
> snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer 
> mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi 
> thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video 
> tpm acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci 
> nvme_core xhci_hcd
> CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  
> 5.0.0-rc2Lyude-Test+ #1
> Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
> RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 
> 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 
> b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
> RSP: 0018:88841235f268 EFLAGS: 00010246
> RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
> RDX: dc00 RSI:  RDI: ed108246bde0
> RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
> R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
> R13: 8883bc499100 R14: 88841bf12ab8 R15: 
> FS:  7f16fbd4cd00() GS:88841ed8() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
>  ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
>  ? __printk_safe_exit+0x10/0x10
>  ? save_stack+0x8c/0xb0
>  ? vprintk_func+0x96/0x1bf
>  ? __printk_safe_exit+0x10/0x10
>  intel_atomic_check+0x234/0x4750 [i915]
>  ? printk+0x9f/0xc5
>  ? kmsg_dump_rewind_nolock+0xd9/0xd9
>  ? _raw_spin_lock_irqsave+0xa4/0x140
>  ? drm_atomic_check_only+0xb1/0x28b0 [drm]
>  ? drm_dbg+0x186/0x1b0 [drm]
>  ? drm_dev_dbg+0x200/0x200 [drm]
>  ? intel_link_compute_m_n+0xb0/0xb0 [i915]
>  ? drm_mode_put_tile_group+0x20/0x20 [drm]
>  ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
>  ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
>  drm_atomic_check_only+0x13c4/0x28b0 [drm]
>  ? drm_state_info+0x220/0x220 [drm]
>  ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
>  ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
>  ? kasan_unpoison_shadow+0x35/0x40
>  drm_atomic_commit+0x3b/0x100 [drm]
>  drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
>  drm_mode_setcrtc+0x636/0x1660 [drm]
>  ? vprintk_func+0x96/0x1bf
>  ? drm_dev_dbg+0x200/0x200 [drm]
>  ? drm_mode_getcrtc+0x790/0x790 [drm]
>  ? printk+0x9f/0xc5
>  ? mutex_unlock+0x1d/0x40
>  ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
>  ? rcu_sync_dtor+0x2e0/0x2e0
>  ? drm_dbg+0x186/0x1b0 [drm]
>  ? set_page_dirty+0x271/0x4d0
>  drm_ioctl_kernel+0x203/0x290 [drm]
>  ? drm_mode_getcrtc+0x790/0x790 [drm]
>  ? drm_setversion+0x7f0/0x7f0 [drm]
>  ? __switch_to_asm+0x34/0x70
>  ? __switch_to_asm+0x34/0x70
>  drm_ioctl+0x445/0x950 [drm]
>  ? drm_mode_getcrtc+0x790/0x790 [drm]
>  ? drm_getunique+0x220/0x220 [drm]
>  ? expand_files.part.10+0x920/0x920
>  do_vfs_ioctl+0x1a1/0x13d0
>  ? ioctl_preallocate+0x2b0/0x2b0
>  ? 

Re: [Nouveau] [PATCH v2 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

2019-02-01 Thread Daniel Vetter
On Thu, Jan 31, 2019 at 08:14:49PM -0500, Lyude Paul wrote:
> Since we now have an easy way of refcounting drm_dp_mst_port structs and
> safely accessing their contents, there isn't any good reason to keep
> validating ports here. It doesn't prevent us from performing modesets on
> branch devices that have been removed either, and we already disallow
> enabling new displays on unregistered connectors in
> update_connector_routing() in drm_atomic_check_modeset(). All it does is
> cause us to have to make weird special exceptions in our atomic
> modesetting code. So, get rid of it entirely.
> 
> Signed-off-by: Lyude Paul 
> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c   | 12 ++--
>  drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c |  3 +--
>  3 files changed, 9 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index abb0ea8ba9d9..4325e1518286 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3117,10 +3117,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   if (IS_ERR(topology_state))
>   return PTR_ERR(topology_state);
>  
> - port = drm_dp_mst_topology_get_port_validated(mgr, port);
> - if (port == NULL)
> - return -EINVAL;
> -
>   /* Find the current allocation for this port, if any */
>   list_for_each_entry(pos, _state->vcpis, next) {
>   if (pos->port == port) {

Also noticed that the WARN_ON() return -EINVAL; here gets fixed with this
patch.

Reviewed-by: Daniel Vetter 

> @@ -3153,10 +3149,8 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   /* Add the new allocation to the state */
>   if (!vcpi) {
>   vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
> - if (!vcpi) {
> - ret = -ENOMEM;
> - goto out;
> - }
> + if (!vcpi)
> + return -ENOMEM;
>  
>   drm_dp_mst_get_port_malloc(port);
>   vcpi->port = port;
> @@ -3165,8 +3159,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   vcpi->vcpi = req_slots;
>  
>   ret = req_slots;
> -out:
> - drm_dp_mst_topology_put_port(port);
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index cdb83d294cdd..fb67cd931117 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -80,17 +80,12 @@ static int intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
>   pipe_config->pbn = mst_pbn;
>  
> - /* Zombie connectors can't have VCPI slots */
> - if (!drm_connector_is_unregistered(connector)) {
> - slots = drm_dp_atomic_find_vcpi_slots(state,
> -   _dp->mst_mgr,
> -   port,
> -   mst_pbn);
> - if (slots < 0) {
> - DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
> -   slots);
> - return slots;
> - }
> + slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr, port,
> +   mst_pbn);
> + if (slots < 0) {
> + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
> +   slots);
> + return slots;
>   }
>  
>   intel_link_compute_m_n(bpp, lane_count,
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 2e8a5fd9b262..60d858c2f2ce 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -771,8 +771,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
>   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
>bpp);
>  
> - if (drm_atomic_crtc_needs_modeset(crtc_state) &&
> - !drm_connector_is_unregistered(connector)) {
> + if (drm_atomic_crtc_needs_modeset(crtc_state)) {
>   slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
> mstc->port, mstc->pbn);
>   if (slots < 0)
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [PATCH] drm: prefix header search paths with $(srctree)/

2019-02-01 Thread Masahiro Yamada
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].

To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.

Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").

[1]: https://patchwork.kernel.org/patch/9632347/

Signed-off-by: Masahiro Yamada 
---

I put all gpu/drm changes into a single patch because
they are trivial conversion.

Please let me know if I need to split this into per-driver patches.


 drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
 drivers/gpu/drm/amd/lib/Makefile| 2 +-
 drivers/gpu/drm/i915/gvt/Makefile   | 2 +-
 drivers/gpu/drm/msm/Makefile| 6 +++---
 drivers/gpu/drm/nouveau/Kbuild  | 8 
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index f76bcb9..b21ebb0 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -23,7 +23,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-FULL_AMD_PATH=$(src)/..
+FULL_AMD_PATH=$(srctree)/$(src)/..
 DISPLAY_FOLDER_NAME=display
 FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
 
diff --git a/drivers/gpu/drm/amd/lib/Makefile b/drivers/gpu/drm/amd/lib/Makefile
index 6902430..d534992 100644
--- a/drivers/gpu/drm/amd/lib/Makefile
+++ b/drivers/gpu/drm/amd/lib/Makefile
@@ -27,6 +27,6 @@
 # driver components or later moved to kernel/lib for sharing with
 # other drivers.
 
-ccflags-y := -I$(src)/../include
+ccflags-y := -I $(srctree)/$(src)/../include
 
 obj-$(CONFIG_CHASH) += chash.o
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc7..a4a5a96 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,6 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
 
-ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
+ccflags-y  += -I $(srctree)/$(src) -I 
$(srctree)/$(src)/$(GVT_DIR)/
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
 obj-$(CONFIG_DRM_I915_GVT_KVMGT)   += $(GVT_DIR)/kvmgt.o
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 56a70c7..b7b1ebd 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/gpu/drm/msm
-ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
-ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
+ccflags-y := -I $(srctree)/$(src)
+ccflags-y += -I $(srctree)/$(src)/disp/dpu1
+ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
 
 msm-y := \
adreno/adreno_device.o \
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index b17843d..b4bc88ad 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -1,7 +1,7 @@
-ccflags-y += -I$(src)/include
-ccflags-y += -I$(src)/include/nvkm
-ccflags-y += -I$(src)/nvkm
-ccflags-y += -I$(src)
+ccflags-y += -I $(srctree)/$(src)/include
+ccflags-y += -I $(srctree)/$(src)/include/nvkm
+ccflags-y += -I $(srctree)/$(src)/nvkm
+ccflags-y += -I $(srctree)/$(src)
 
 # NVKM - HW resource manager
 #- code also used by various userspace tools/tests
-- 
2.7.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT

2019-02-01 Thread Daniel Vetter
On Fri, Jan 25, 2019 at 03:02:46PM +, Emil Velikov wrote:
> On Thu, 24 Jan 2019 at 17:00, Daniel Vetter  wrote:
> >
> > It's 0.
> >
> I'd add a bit more information here. Feel free to reuse as much/little
> of the following:
> 
> Both macros evaluate to 0. At the same time flag is already set to
> zero since the struct is kzalloc'd in framebuffer_alloc().
> As called by drm_fb_helper_alloc_fbi() in the DRM drivers.

Added, thanks for your review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [PATCH -next] drm/nouveau: fix copy-paste error in nouveau_fence_wait_uevent_handler

2019-02-01 Thread Pierre Moreau
Friendly ping, Ben.
I see that in `nouveau_fence_done()` there is a check on `chan` not being NULL
prior to passing it to `nouveau_fence_update()`. Would something similar be
needed here?

Pierre

On 2018-11-15 — 12:14, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/nouveau/nouveau_fence.c: In function 
> 'nouveau_fence_wait_uevent_handler':
> drivers/gpu/drm/nouveau/nouveau_fence.c:156:27: warning:
>  variable 'chan' set but not used [-Wunused-but-set-variable]
> 
> nouveau_fence_update should use rcu protected 'chan'
> rather than 'fence->channel'
> 
> Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and 
> protect with rcu")
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
> b/drivers/gpu/drm/nouveau/nouveau_fence.c
> index d4964f3..91286d0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> @@ -157,7 +157,7 @@
>  
>   fence = list_entry(fctx->pending.next, typeof(*fence), head);
>   chan = rcu_dereference_protected(fence->channel, 
> lockdep_is_held(>lock));
> - if (nouveau_fence_update(fence->channel, fctx))
> + if (nouveau_fence_update(chan, fctx))
>   ret = NVIF_NOTIFY_DROP;
>   }
>   spin_unlock_irqrestore(>lock, flags);
> 
> 
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau