[Bug 196379] Laptop loses performance at random bootups.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=196379

Chen Yu (yu.c.c...@intel.com) changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||yu.c.c...@intel.com
  Component|Other   |Video(DRI - non Intel)
   Assignee|r...@rjwysocki.net   |drivers_video-dri@kernel-bu
   ||gs.osdl.org
Product|Power Management|Drivers

--- Comment #1 from Chen Yu (yu.c.c...@intel.com) ---
I could not find the coolsense kernel module you mentioned above, maybe it is a
an BIOS option, could you point to me the reddit link?
Besides, the web/music/comping are working well, which means the cpu frequency
should not be throttled, and this is what the thermal management would  touch
when the temperature is too high, but this should not the case per your
description.  I suspect there might be a adjustment in the graphic card.
BTW, you can always check with latest upstream kernel(not the distribution
kernel).
And you can try running the latest 'turbostat' both when running in
normal/abnormal cases, let's make a double check if the cpufreq has been
throttled or not.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99353

--- Comment #12 from Vedran Miletić  ---
Interestingly enough, not exactly the same result, amdgpu again:

[39371/39371] skip: 3231, pass: 15458, warn: 13, fail: 20668, crash: 1

Then on the next try:

[39371/39371] skip: 3231, pass: 15456, warn: 13, fail: 20670, crash: 1

I can check what the diff is, but doubt it's important.

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

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101739

--- Comment #1 from Roland Scheidegger  ---
My naive conclusion from the description would be that the hw is doing earlyz
optimizations when it shouldn't (so, the depth updates happen before the final
sample mask modified by the alpha value is known).
The driver doesn't set if early z is enabled directly, since it just sets
EARLY_Z_THEN_LATE_Z most of the time, and the hw should figure out if early z
is possible (taking into account all state), otherwise use late z.
If that's the case, then overriding the Z_ORDER to LATE_Z for the
db_shader_control value might be necessary in this case.
But that's just a guess, I could be completely wrong here - I've got only a
very rough idea of radeonsi hw and driver...

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99353

--- Comment #11 from Vedran Miletić  ---
dmesg with radeon:

[ 1443.752932] show_signal_msg: 8 callbacks suppressed
[ 1443.752936] glslparsertest[31344]: segfault at 20 ip 7f10f2a45a25 sp
7ffd7c7b4ea0 error 4 in radeonsi_dri.so[7f10f2713000+a7f000]
[ 1453.316958] [TTM] Out of kernel memory
[ 1453.317022] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (65536, 6, 4096, -12)
[ 1453.326439] [TTM] Out of kernel memory
[ 1453.326501] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (65536, 6, 4096, -12)
[ 1453.326672] glslparsertest[32001]: segfault at 0 ip   (null) sp
7ffd440e3e68 error 14 in glslparsertest[40+3000]
[ 1453.446181] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 2, 4096, -12)
[ 1454.292472] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 2, 4096, -12)
[ 1470.746846] [TTM] Out of kernel memory
[ 1470.746919] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (65536, 2, 4096, -12)
[ 1470.747217] [TTM] Out of kernel memory
[ 1470.747252] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (65536, 2, 4096, -12)
[ 1470.796559] [TTM] Out of kernel memory
[ 1470.796626] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (131072, 6, 16384, -12)
[ 1470.797251] [TTM] Out of kernel memory
[ 1470.797283] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (131072, 6, 16384, -12)
[ 1471.951962] [TTM] Out of kernel memory
[ 1471.952038] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (4096, 2, 4096, -12)
[ 1471.952099] [TTM] Out of kernel memory
[ 1471.952126] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (4096, 2, 4096, -12)
[ 1471.952453] [TTM] Out of kernel memory
[ 1471.952491] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (131072, 6, 4096, -12)
[ 1471.952543] [TTM] Out of kernel memory
[ 1471.952571] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (131072, 6, 4096, -12)
[ 1471.952820] [TTM] Out of kernel memory
[ 1471.952857] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (131072, 6, 4096, -12)
[ 1514.410139] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -12!
[ 1519.145813] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -12!
[ 1549.734495] abrt-action-ana[2377]: segfault at 20 ip 559ddb8a74f3 sp
7fff5b29c650 error 4 in abrt-action-analyze-c[559ddb8a6000+2000]
[ 1840.953467] glslparsertest[10334]: segfault at 20 ip 7f4e7a1b5a25 sp
7ffc99dcd3c0 error 4 in radeonsi_dri.so[7f4e79e83000+a7f000]
[ 1853.794208] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.794598] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.805828] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.806023] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.806233] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.806299] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.806370] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1853.806431] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1073741824, 6, 16384, -12)
[ 1953.982528] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (65536, 2, 4096, -12)
[ 1953.982937] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (65536, 2, 4096, -12)
[ 1953.986720] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1048576, 2, 4096, -12)
[ 1953.986838] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (1048576, 2, 4096, -12)
[ 1953.987165] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (258048, 2, 4096, -12)
[ 1953.987661] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
allocate GEM object (258048, 2, 4096, -12)
[ 2003.316542] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -12!
[ 2003.324763] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -12!
[ 2003.695833] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -12!
[ 2003.784308] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse
relocation -12!
[ 2003.844831] [TTM] Out of kernel memory
[ 2003.844892] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to
alloc

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99353

--- Comment #10 from Vedran Miletić  ---
Fedora does not enable AMDGPU CIK, but I rebuilt the kernel manually. Same
story with Xorg/Wayland with the amdgpu kernel driver.

As for piglit, managed to run till the end this time (with radeon):
[39371/39371] skip: 3237, pass: 14626, warn: 8, fail: 21498, crash: 2

Will retest with amdgpu.

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

Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

[Ilia Mirkin]

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith  wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 
> 8600 GT] [10de:0402] (rev a1)
>
> abreviated dmesg:
> ...
> [3.720990] fb: switching to nouveaufb from VESA VGA
> [3.744489] Console: switching to colour dummy device 80x25
> [3.744966] nouveau :01:00.0: NVIDIA G84 (084200a2)
> ...
> [3.846963] usbcore: registered new interface driver uas
> [3.849938] nouveau :01:00.0: bios: version 60.84.6e.00.12
> [  321.450262] nouveau :01:00.0: DRM: suspending console...
> [  321.450265] nouveau :01:00.0: DRM: suspending display...
> [  321.450462] e1000e: EEE TX LPI TIMER: 
> [  321.450501] br0: port 1(eth0) entered disabled state
> [  321.473838] [ cut here ]
> [  321.473863] WARNING: CPU: 1 PID: 4786 at drivers/gpu/drm/drm_vblank.c:608 
> drm_calc_vbltimestamp_from_scanoutpos+0x14f/0x330 [drm]
> [  321.473864] Modules linked in: ebtable_filter(E) ebtables(E) fuse(E) 
> rpcsec_gss_krb5(E) nfsv4(E) dns_resolver(E) nfs(E) fscache(E) af_packet(E) 
> bridge(E) stp(E) llc(E) iscsi_ibft(E) iscsi_boot_sysfs(E) ip6t_REJECT(E) 
> xt_tcpudp(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) ip6table_raw(E) 
> ipt_REJECT(E) iptable_raw(E) iptable_filter(E) ip6table_mangle(E) 
> nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
> nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) 
> ip6table_filter(E) ip6_tables(E) x_tables(E) saa7134_alsa(E) tda1004x(E) 
> saa7134_dvb(E) videobuf2_dvb(E) dvb_core(E) arc4(E) rt2800usb(E) rt2x00usb(E) 
> rt2800lib(E) crc_ccitt(E) rt2x00lib(E) mac80211(E) cfg80211(E) 
> rc_medion_x10_or2x(E) rfkill(E) ati_remote(E) tda827x(E) tda8290(E) tuner(E) 
> snd_hda_codec_realtek(E) saa7134(E)
> [  321.473905]  snd_hda_codec_generic(E) snd_hda_intel(E) snd_hda_codec(E) 
> snd_hwdep(E) tveeprom(E) coretemp(E) videobuf2_dma_sg(E) videobuf2_memops(E) 
> snd_hda_core(E) videobuf2_v4l2(E) kvm_intel(E) snd_pcm(E) kvm(E) 
> videobuf2_core(E) snd_timer(E) rc_core(E) v4l2_common(E) snd(E) videodev(E) 
> iTCO_wdt(E) media(E) e1000e(E) iTCO_vendor_support(E) ptp(E) pps_core(E) 
> shpchp(E) soundcore(E) i2c_i801(E) lpc_ich(E) mfd_core(E) irqbypass(E) 
> pcspkr(E) thermal(E) acpi_cpufreq(E) fan(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) 
> lockd(E) grace(E) sunrpc(E) ext4(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) 
> sr_mod(E) cdrom(E) sd_mod(E) uas(E) usb_storage(E) hid_generic(E) usbhid(E) 
> nouveau(E) wmi(E) video(E) i2c_algo_bit(E) ahci(E) drm_kms_helper(E) 
> syscopyarea(E) sysfillrect(E) libahci(E) sysimgblt(E) fb_sys_fops(E) 
> firewire_ohci(E)
> [  321.473950]  libata(E) firewire_core(E) crc_itu_t(E) ehci_pci(E) 
> serio_raw(E) ttm(E) button(E) drm(E) uhci_hcd(E) ehci_hcd(E) usbcore(E) sg(E) 
> dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) 
> scsi_mod(E) autofs4(E)
> [  321.473966] CPU: 1 PID: 4786 Comm: kworker/u8:17 Tainted: GW   E   
> 4.12.0.gccd5d1b-master #186
> [  321.473968] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 
> 12/26/2007
> [  321.473972] Workqueue: events_unbound async_run_entry_fn
> [  321.473974] task: 8801daf93d40 task.stack: c90003edc000
> [  321.473990] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x14f/0x330 
> [drm]
> [  321.473992] RSP: 0018:c90003edfb00 EFLAGS: 00010082
> [  321.473994] RAX: a03e6100 RBX: 88021114 RCX: 
> 0001
> [  321.473995] RDX: a01dd8c8 RSI: 0001 RDI: 
> a01c8023
> [  321.473996] RBP: c90003edfb80 R08:  R09: 
> a01b0920
> [  321.473998] R10: a0376e60 R11: 8802131399f8 R12: 
> 0001
> [  321.473999] R13: 880213139800 R14: c90003edfb94 R15: 
> c90003edfbd0
> [  321.474001] FS:  () GS:88022fc8() 
> knlGS:
> [  321.474003] CS:  0010 DS:  ES:  CR0: 80050033
> [  321.474004] CR2: 7fdd82e8f810 CR3: 000214683000 CR4: 
> 06e0
> [  321.474005] Call Trace:
> [  321.474068]  ? nv50_head_vblank_put+0x22/0x50 [nouveau]
> [  321.474085]  drm_get_last_vbltimestamp+0x41/0x70 [drm]
> [  321.474102]  drm_update_vblank_count+0x61/0x230 [drm]
> [  321.474118]  drm_vblank_disable_and_save+0x59/0xc0 [drm]
> [  321.474134]  drm_crtc_vblank_off+0x1d5/0x210 [drm]
> [  321.474152]  ? drm_modeset_drop_locks+0x4e/0x60 [drm]
> [  321.474203]  nouveau_display_fini+0x56/0xd0 [nouveau]
> [  321.474254]  nouveau_display_suspend+0x4f/0x110 [nouveau]
> [  321.474304]  nouveau_do_suspend+0x7c/0x1e0 [nouveau]
> [  321.474355]  nouveau_pmops_suspend+0x2d/0x70 [nouveau]
> [  321.474358]  pci_pm_suspend+0x70/0x130
> [  321.474360]  ? pci_pm_resume+0x90/0x90
> [  321.474364]  dpm_run_callback+0x4d/0x150
> [  32

Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

[Ilia Mirkin]

On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin  wrote:
> On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith  wrote:
>> Greetings,
>>
>> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
>> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>>
>> lspci -nn -d 10de:
>> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 
>> 8600 GT] [10de:0402] (rev a1)
>>
>> abreviated dmesg:
>> ...
>> [3.720990] fb: switching to nouveaufb from VESA VGA
>> [3.744489] Console: switching to colour dummy device 80x25
>> [3.744966] nouveau :01:00.0: NVIDIA G84 (084200a2)
>> ...
>> [3.846963] usbcore: registered new interface driver uas
>> [3.849938] nouveau :01:00.0: bios: version 60.84.6e.00.12
>> [3.870769] hid-generic 0003:04CA:002B.0002: input,hidraw1: USB HID v1.11 
>> Keyboard [Liteon Wireless keyboard and mouse] on usb-:00:1d.0-1/input0
>> [3.870773] nouveau :01:00.0: bios: M0203T not found
>> [3.870774] nouveau :01:00.0: bios: M0203E not matched!
>> [3.870777] nouveau :01:00.0: fb: 256 MiB DDR2
>> [3.871168] input: Liteon Wireless keyboard and mouse as 
>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.1/0003:04CA:002B.0003/input/input7
>> [3.896090] usb 3-2: new low-speed USB device number 3 using uhci_hcd
>> [3.919101] [TTM] Zone  kernel: Available graphics memory: 3881208 kiB
>> [3.919106] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
>> [3.919110] [TTM] Initializing pool allocator
>> [3.919120] [TTM] Initializing DMA pool allocator
>> [3.919141] nouveau :01:00.0: DRM: VRAM: 256 MiB
>> [3.919146] nouveau :01:00.0: DRM: GART: 1048576 MiB
>> [3.919152] nouveau :01:00.0: DRM: TMDS table version 2.0
>> [3.919157] nouveau :01:00.0: DRM: DCB version 4.0
>> [3.919162] nouveau :01:00.0: DRM: DCB outp 00: 04000310 0028
>> [3.919167] nouveau :01:00.0: DRM: DCB outp 01: 02011300 0028
>> [3.919171] nouveau :01:00.0: DRM: DCB outp 02: 01011302 0030
>> [3.919176] nouveau :01:00.0: DRM: DCB outp 03: 02022322 00020010
>> [3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083
>> [3.919185] nouveau :01:00.0: DRM: DCB conn 00: 
>> [3.919189] nouveau :01:00.0: DRM: DCB conn 01: 1130
>> [3.919194] nouveau :01:00.0: DRM: DCB conn 02: 2261
>> [3.919198] nouveau :01:00.0: DRM: DCB conn 03: 0310
>> [3.919202] nouveau :01:00.0: DRM: DCB conn 04: 0311
>> [3.919206] nouveau :01:00.0: DRM: DCB conn 05: 0313
>> [3.919258] [ cut here ]
>> [3.919316] WARNING: CPU: 3 PID: 224 at 
>> drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c:83 
>> nvkm_outp_xlat.isra.0+0x26/0x80 [nouveau]
>
> The code in question is
>
> static enum nvkm_ior_proto
> nvkm_outp_xlat(struct nvkm_outp *outp, enum nvkm_ior_type *type)
> {
> switch (outp->info.location) {
> case 0:
> switch (outp->info.type) {
> case DCB_OUTPUT_ANALOG: *type = DAC; return  CRT;
> case DCB_OUTPUT_TMDS  : *type = SOR; return TMDS;
> case DCB_OUTPUT_LVDS  : *type = SOR; return LVDS;
> case DCB_OUTPUT_DP: *type = SOR; return   DP;
> default:
> break;
> }
> break;
> case 1:
> switch (outp->info.type) {
> case DCB_OUTPUT_TMDS: *type = PIOR; return TMDS;
> case DCB_OUTPUT_DP  : *type = PIOR; return TMDS; /* not a bug 
> */
> default:
> break;
> }
> break;
> default:
> break;
> }
> WARN_ON(1);
> return UNKNOWN;
> }
>
> Looks like someone forgot about TV S-Video/Composite outputs (which
> existed up until the GT21x's).
>
>> [3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083
>
> And there ya go (the type is the lowest nibble of the first dword). We
> don't support TV outputs on nv50+, so you could just add a
>
> case DCB_OUTPUT_TV: return UNKNOWN;
>
> in the location == 0 case.
>
> I don't think that's related to the issue you're seeing on suspend
> though, as the TV connector isn't created anyways, it's just an
> "annoyance" warn, and you were also seeing it on your GM20x which has
> no such thing.

Actually while this may fix things for you in the short term, this is
all generic code, not chip-specific, and we do support TV outputs on
pre-nv50 chips, so it needs to be fixed for real.

Ben - I'm very weak on all these concepts of OR/etc - is the right
move to add a new nvkm_ior_proto/type for TV? (There's also a
DCB_OUTPUT_EOL type, no clue what that is.) I guess it should get type
= DAC and add a new nvkm_ior_proto for TV?

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

[Ilia Mirkin]

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith  wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 
> 8600 GT] [10de:0402] (rev a1)
>
> abreviated dmesg:
> ...
> [3.720990] fb: switching to nouveaufb from VESA VGA
> [3.744489] Console: switching to colour dummy device 80x25
> [3.744966] nouveau :01:00.0: NVIDIA G84 (084200a2)
> ...
> [3.846963] usbcore: registered new interface driver uas
> [3.849938] nouveau :01:00.0: bios: version 60.84.6e.00.12
> [3.870769] hid-generic 0003:04CA:002B.0002: input,hidraw1: USB HID v1.11 
> Keyboard [Liteon Wireless keyboard and mouse] on usb-:00:1d.0-1/input0
> [3.870773] nouveau :01:00.0: bios: M0203T not found
> [3.870774] nouveau :01:00.0: bios: M0203E not matched!
> [3.870777] nouveau :01:00.0: fb: 256 MiB DDR2
> [3.871168] input: Liteon Wireless keyboard and mouse as 
> /devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.1/0003:04CA:002B.0003/input/input7
> [3.896090] usb 3-2: new low-speed USB device number 3 using uhci_hcd
> [3.919101] [TTM] Zone  kernel: Available graphics memory: 3881208 kiB
> [3.919106] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [3.919110] [TTM] Initializing pool allocator
> [3.919120] [TTM] Initializing DMA pool allocator
> [3.919141] nouveau :01:00.0: DRM: VRAM: 256 MiB
> [3.919146] nouveau :01:00.0: DRM: GART: 1048576 MiB
> [3.919152] nouveau :01:00.0: DRM: TMDS table version 2.0
> [3.919157] nouveau :01:00.0: DRM: DCB version 4.0
> [3.919162] nouveau :01:00.0: DRM: DCB outp 00: 04000310 0028
> [3.919167] nouveau :01:00.0: DRM: DCB outp 01: 02011300 0028
> [3.919171] nouveau :01:00.0: DRM: DCB outp 02: 01011302 0030
> [3.919176] nouveau :01:00.0: DRM: DCB outp 03: 02022322 00020010
> [3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083
> [3.919185] nouveau :01:00.0: DRM: DCB conn 00: 
> [3.919189] nouveau :01:00.0: DRM: DCB conn 01: 1130
> [3.919194] nouveau :01:00.0: DRM: DCB conn 02: 2261
> [3.919198] nouveau :01:00.0: DRM: DCB conn 03: 0310
> [3.919202] nouveau :01:00.0: DRM: DCB conn 04: 0311
> [3.919206] nouveau :01:00.0: DRM: DCB conn 05: 0313
> [3.919258] [ cut here ]
> [3.919316] WARNING: CPU: 3 PID: 224 at 
> drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c:83 
> nvkm_outp_xlat.isra.0+0x26/0x80 [nouveau]

The code in question is

static enum nvkm_ior_proto
nvkm_outp_xlat(struct nvkm_outp *outp, enum nvkm_ior_type *type)
{
switch (outp->info.location) {
case 0:
switch (outp->info.type) {
case DCB_OUTPUT_ANALOG: *type = DAC; return  CRT;
case DCB_OUTPUT_TMDS  : *type = SOR; return TMDS;
case DCB_OUTPUT_LVDS  : *type = SOR; return LVDS;
case DCB_OUTPUT_DP: *type = SOR; return   DP;
default:
break;
}
break;
case 1:
switch (outp->info.type) {
case DCB_OUTPUT_TMDS: *type = PIOR; return TMDS;
case DCB_OUTPUT_DP  : *type = PIOR; return TMDS; /* not a bug */
default:
break;
}
break;
default:
break;
}
WARN_ON(1);
return UNKNOWN;
}

Looks like someone forgot about TV S-Video/Composite outputs (which
existed up until the GT21x's).

> [3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083

And there ya go (the type is the lowest nibble of the first dword). We
don't support TV outputs on nv50+, so you could just add a

case DCB_OUTPUT_TV: return UNKNOWN;

in the location == 0 case.

I don't think that's related to the issue you're seeing on suspend
though, as the TV connector isn't created anyways, it's just an
"annoyance" warn, and you were also seeing it on your GM20x which has
no such thing.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm: radeon: constify pci_device_id.

[Christian König]

Am 15.07.2017 um 09:12 schrieb Arvind Yadav:

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
6560  23212  72   298447494 gpu/drm/radeon/radeon_drv.o

File size After adding 'const':
text   data bss dec hex filename
   28960812  72   298447494 gpu/drm/radeon/radeon_drv.o

Signed-off-by: Arvind Yadav 


Impressive result for such a simple change.

Patch is Reviewed-by: Christian König 

Are the PCI IDs already const in amdgpu or do we need a similar patch 
there as well? I only see patch 1 of 5 in my inbox.


Christian.


---
  drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index e25cb51..b079937 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -298,7 +298,7 @@ module_param_named(uvd, radeon_uvd, int, 0444);
  MODULE_PARM_DESC(vce, "vce enable/disable vce support (1 = enable, 0 = 
disable)");
  module_param_named(vce, radeon_vce, int, 0444);
  
-static struct pci_device_id pciidlist[] = {

+static const struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
  };
  



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

[Christian König]

Am 15.07.2017 um 05:32 schrieb Michel Dänzer:

On 15/07/17 04:47 AM, Felix Kuehling wrote:

On 17-07-13 11:26 PM, Michel Dänzer wrote:

On 14/07/17 06:08 AM, Felix Kuehling wrote:

Allows gdb to access contents of user mode mapped BOs. VRAM access
requires the driver to implement a new callback in ttm_bo_driver.

Thanks for doing this. Looks mostly good, but I still have some comments.

The shortlog prefix should be "drm/ttm:".



diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 9f53df9..0ef2eb9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -294,10 +294,74 @@ static void ttm_bo_vm_close(struct vm_area_struct *vma)
vma->vm_private_data = NULL;
  }
  
+static int ttm_bo_vm_access_kmap(struct ttm_buffer_object *bo,

+unsigned long offset,
+void *buf, int len, int write)
+{
+   unsigned long first_page = offset >> PAGE_SHIFT;
+   unsigned long last_page = (offset + len - 1) >> PAGE_SHIFT;
+   unsigned long num_pages = last_page - first_page + 1;
+   struct ttm_bo_kmap_obj map;
+   void *ptr;
+   bool is_iomem;
+   int ret;
+
+   ret = ttm_bo_kmap(bo, first_page, num_pages, &map);
+   if (ret)
+   return ret;

Could there be cases (e.g. on 32-bit) where mapping all pages at once
fails, but mapping one page at a time would work?

Maybe. I'm not really familiar with ttm_bo_kmap limitations on 32-bit. I
guess the the access would have to be really big. I think in practice
GDB doesn't do very big accesses. So I'm not sure it's worth the trouble.

Okay, I guess it can always be changed later if necessary.


It would still be better to do this page by page.

See the issue is that when you only map one page ttm_bo_kmap() is clever 
and returns a pointer to only that page.


But when you map at least two pages ttm_bo_kmap() needs to allocate 
virtual address space, map the pages and flush the TLBs (which is a very 
heavy operation) just to make those two pages look continuously to the CPU.


Not that I expect that this function is performance critical, but that 
is complexity I would try to avoid.






+   int (*access_vram)(struct ttm_buffer_object *bo, unsigned long offset,
+  void *buf, int len, int write);
  };

I suggest making the write parameter a bool.

I made this as similar as possible to the vm_ops->access API, where
write is also an integer.

I see, makes sense.


Yeah, agree as well. Please keep the style of the upstream interface here.

Christian.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote:
> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
> usage we could convert to WARN_ONCE?

Shooting the messenger is generally considered uncool :)

-Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Grant Grundler]

On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter  wrote:
> On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler  wrote:
>> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
>>  wrote:
>>> On Thu, 13 Jul 2017, Stéphane Marchesin  
>>> wrote:
 So, if you think this is wrong, can you fix this warning in a way that
 you'd like?
>>>
>>> As I replied previously [1], with more background, fixing the warnings
>>> properly, in a way that actually improves the code instead of making it
>>> worse, would mean a bunch of churn that's not just purely mechanical
>>> conversion.
>>
>> That's fair.
>>
>>> Unless you can point out a bug which is actually caused by mixing the
>>> types (which is mostly intentional, see the background) I have a hard
>>> time telling people this should be a priority.
>>
>> This feels like "can't see the forest because of the trees".
>>
>> The original patch was submitted in order to compile cleanly using
>> clang and the above suggests using clang is not important.  Using
>> clang is important to Matthias and the Chrome OS organization for many
>> good reasons - including better warnings.
>>
>> The original patch message was clear that clang was generating the
>> warning. This isn't the only patch mka has sent to kernel devs. What
>> one can infer is Chrome OS is trying to move to clang (like other
>> Google products _already_ have.)  My impression is all these products
>> are a priority to Intel - but it would be good to know otherwise.
>>
>>> Definitely something we'd
>>> like to do in the long run and pedantically correct (and I tend to
>>> prefer code that way) but we certainly have more important things to do.
>>
>> The long run is now. Everyone agrees the code should change and you
>> don't have to do it. Matthias submitted an unacceptable patch and
>> giving him some concrete guidance on what would be acceptable would
>> enable him to implement/test it (or anyone else could for that
>> matter).  Can you do that?
>>
>> Just give an example of what the "right" API looks like and see where it 
>> goes.
>
> We've replied and discussed on May 5th what that roughly should be,
> right when Matthias pinged us. The original submission unfortunately
> fell through the cracks (it happens, not much we can do with this
> flood). Matthias didn't seem to have any questions about the proposed
> solutions (we laid out both the minimal short-term fix to unconfuse
> things, and what might be done on top), I think a reasonable
> assumption was that it's all clear. Otherwise he should have asked.

Indeed!

After briefly chatting with Stephane and mka, it seems the difference
between short-term fix and "done on top" were not clear.

> Now, over 2 months later (and complete silence from your side) there's
> suddenly mass panic and multiple escalations on all available
> channels, which feels like a rather decent overreaction and not a
> terrible constructive way to collaborate on the upstream codebase.

I'm sorry - I'm not on the other channels and I didn't see any mass
panic. I agree that's not a collaborative. The previous answer in this
thread didn't seem particularly collaborative either though.

The silence was partly due to mka working on other "clang enablement" patches:

$ pwclient list -w m...@chromium.org
Patches submitted by Matthias Kaehlcke :
ID  StateName
--  -
9668095 Superseded   mac80211: Fix clang warning about constant
operand in logical operation
9668479 Accepted ath9k: Add cast to u8 to FREQ2FBIN macro
9668643 Accepted [v2] mac80211: Fix clang warning about constant
operand in logical operation
9679753 Accepted [v2] cfg80211: Fix array-bounds warning in fragment copy
9684547 Accepted mac80211: ibss: Fix channel type enum in
ieee80211_sta_join_ibss()
9684629 Accepted nl80211: Fix enum type of variable in
nl80211_put_sta_rate()

> Anyway, I've done the quick draft for the function declaration changes
> that would clear up the confusion, just needs a clang run to update
> all the parameters to match, and passed that on to Stéphane Marchesin.

Awesome - thanks! :)

> I expect you to follow up with the corresponding patch right away.

mka said "he would take a look at it". But knowing how he understates
things in a typical "German Engineer" way, I'm optimistic it will be
more than that. Thanks!

cheers,
grant

>
> Thanks a lot.
>
> Yours, Daniel
>
> For reference the diff, but probably whitespace mangled because the
> real machine is down already:
>
> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> index d484862cc7df..21c221b4ae57 100644
> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> @@ -313,7 +313,7 @@ bool intel_set_cpu_fifo_underrun_reporting(struct
> drm_i915_private *dev_priv,
>   * Returns the previous state of underrun reporting.
>   */
>  bool intel_set_pch_fifo_underrun_reporting(struct drm_i915_private *dev_priv,
> -   enum 

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Fri, 2017-07-14 at 14:42 -0500, Josh Poimboeuf wrote:
> 
> Does this fix it?

Yup, both READONLY __bug_table and "extra stern" warning are gone.

> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index 39e702d..aa6b202 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch/x86/include/asm/bug.h
> @@ -35,7 +35,7 @@
>  #define _BUG_FLAGS(ins, flags)   
> \
>  do { \
>   asm volatile("1:\t" ins "\n"\
> -  ".pushsection __bug_table,\"a\"\n" \
> +  ".pushsection __bug_table,\"aw\"\n"\
>"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"   \
>"\t"  __BUG_REL(%c0) "\t# bug_entry::file\n"   \
>"\t.word %c1""\t# bug_entry::line\n"   \
> @@ -52,7 +52,7 @@ do {
> \
>  #define _BUG_FLAGS(ins, flags)   
> \
>  do { \
>   asm volatile("1:\t" ins "\n"\
> -  ".pushsection __bug_table,\"a\"\n" \
> +  ".pushsection __bug_table,\"aw\"\n"\
>"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"   \
>"\t.word %c0""\t# bug_entry::flags\n"  \
>"\t.org 2b+%c1\n"  \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
> > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> 
> > > Urgh, is for some mysterious reason the __bug_table section of modules
> > > ending up in RO memory?
> > > 
> > > I forever get lost in that link magic :/
> > 
> > +1
> > 
> > drm.ko
> >  20 __bug_table   0630      0004bff3  
> > 2**0
> >   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> > vmlinux
> >  15 __bug_table   ba84  81af26c0  01af26c0  00cf26c0  
> > 2**0
> >   CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 
> > Danged if I know... um um RELOC business mucks things up?
> 
> Argh, it shouldn't be READONLY for vmlinux either, but apparently that
> is working for mysterious reasons.
> 
> Some architectures were in fact complaining that I broke that, and hence
> patch:
> 
> b5effd3815cc ("debug: Fix __bug_table[] in arch linker scripts")
> 
> I think we need professional help with this linking stuff, but who to
> ask?

Andy Lutomirski?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm: via: constify pci_device_id.

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
4931072   01565 61d drivers/gpu/drm/via/via_drv.o

File size After adding 'const':
   textdata bss dec hex filename
821 744   01565 61d drivers/gpu/drm/via/via_drv.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/via/via_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/via/via_drv.c b/drivers/gpu/drm/via/via_drv.c
index 9e0e539..f58a473 100644
--- a/drivers/gpu/drm/via/via_drv.c
+++ b/drivers/gpu/drm/via/via_drv.c
@@ -53,7 +53,7 @@ static void via_driver_postclose(struct drm_device *dev, 
struct drm_file *file)
kfree(file_priv);
 }
 
-static struct pci_device_id pciidlist[] = {
+static const struct pci_device_id pciidlist[] = {
viadrv_PCI_IDS
 };
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm: nouveau: constify pci_device_id.

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  12256 360 976   135923518 gpu/drm/nouveau/nouveau_drm.o

File size After adding 'const':
   textdata bss dec hex filename
  12360 256 976   135923518 gpu/drm/nouveau/nouveau_drm.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 15a13d0..07a1efb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1019,7 +1019,7 @@ driver_stub = {
.patchlevel = DRIVER_PATCHLEVEL,
 };
 
-static struct pci_device_id
+static const struct pci_device_id
 nouveau_drm_pci_table[] = {
{
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID),
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

The conversion is a nice catch, but i'd like to have a bit more context, 
see below!


With a better description:

Tobias Klausmann 


On 7/14/17 5:10 PM, Karol Herbst wrote:

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?

Reviewed-By: Karol Herbst 

On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann
 wrote:

On 7/14/17 3:41 PM, Mike Galbraith wrote:

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

   All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
   drivers/gpu/drm/drm_vblank.c |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
  */
 if (mode->crtc_clock == 0) {
 DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n",
pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report
me.\n",


"report me" seems a bit odd, maybe just uninitialized mode?



+ dev->driver->name);
 return false;
 }



Hey,

confirmed this helps saving the box, but we still have to find the root
cause! Backtrace with the above fix applied (and the one which came in with
the latest drm-fixes merge)!


[1] https://hastebin.com/uyoqifijed.http

Thanks,

Tobias
Reviewed-By: Karol Herbst 
___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Grant Grundler]

On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
 wrote:
> On Thu, 13 Jul 2017, Stéphane Marchesin  wrote:
>> So, if you think this is wrong, can you fix this warning in a way that
>> you'd like?
>
> As I replied previously [1], with more background, fixing the warnings
> properly, in a way that actually improves the code instead of making it
> worse, would mean a bunch of churn that's not just purely mechanical
> conversion.

That's fair.

> Unless you can point out a bug which is actually caused by mixing the
> types (which is mostly intentional, see the background) I have a hard
> time telling people this should be a priority.

This feels like "can't see the forest because of the trees".

The original patch was submitted in order to compile cleanly using
clang and the above suggests using clang is not important.  Using
clang is important to Matthias and the Chrome OS organization for many
good reasons - including better warnings.

The original patch message was clear that clang was generating the
warning. This isn't the only patch mka has sent to kernel devs. What
one can infer is Chrome OS is trying to move to clang (like other
Google products _already_ have.)  My impression is all these products
are a priority to Intel - but it would be good to know otherwise.

> Definitely something we'd
> like to do in the long run and pedantically correct (and I tend to
> prefer code that way) but we certainly have more important things to do.

The long run is now. Everyone agrees the code should change and you
don't have to do it. Matthias submitted an unacceptable patch and
giving him some concrete guidance on what would be acceptable would
enable him to implement/test it (or anyone else could for that
matter).  Can you do that?

Just give an example of what the "right" API looks like and see where it goes.

cheers,
grant

>
> BR,
> Jani.
>
> [1] http://mid.mail-archive.com/87wp9rahjy.fsf@intel.com
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: arcpgu: Fix mmap() callback

[Jose Abreu]

Now that ARC properly supports DMA mmapping we can use the
standard CMA helper to map dumb buffers. This makes ARC PGU
works with standard DRM consumer applications like, for
example, mpv via DRM.

This fixes the use of dumb buffers.

Signed-off-by: Jose Abreu 
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 1926b20..890bc87 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -48,18 +48,6 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
 }
 
-static int arcpgu_gem_mmap(struct file *filp, struct vm_area_struct *vma)
-{
-   int ret;
-
-   ret = drm_gem_mmap(filp, vma);
-   if (ret)
-   return ret;
-
-   vma->vm_page_prot = pgprot_noncached(vm_get_page_prot(vma->vm_flags));
-   return 0;
-}
-
 static const struct file_operations arcpgu_drm_ops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -69,7 +57,7 @@ static int arcpgu_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
.poll = drm_poll,
.read = drm_read,
.llseek = no_llseek,
-   .mmap = arcpgu_gem_mmap,
+   .mmap = drm_gem_cma_mmap,
 };
 
 static void arcpgu_lastclose(struct drm_device *drm)
-- 
1.9.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm: vmwgfx: constify pci_device_id.

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  13765 800  20   1458538f9 gpu/drm/vmwgfx/vmwgfx_drv.o

File size After adding 'const':
   textdata bss dec hex filename
  13829 736  20   1458538f9 gpu/drm/vmwgfx/vmwgfx_drv.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 4a64155..f5fe28f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -227,7 +227,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
  DRM_AUTH | DRM_RENDER_ALLOW),
 };
 
-static struct pci_device_id vmw_pci_id_list[] = {
+static const struct pci_device_id vmw_pci_id_list[] = {
{0x15ad, 0x0405, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VMWGFX_CHIP_SVGAII},
{0, 0, 0}
 };
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] constify drm pci_device_id

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Arvind Yadav (5):
  [PATCH 1/5] drm: radeon: constify pci_device_id.
  [PATCH 2/5] drm: vmwgfx: constify pci_device_id.
  [PATCH 3/5] drm: nouveau: constify pci_device_id.
  [PATCH 4/5] drm: via: constify pci_device_id.
  [PATCH 5/5] drm: hisilicon: constify pci_device_id.

 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 drivers/gpu/drm/via/via_drv.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Karol Herbst]

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?

Reviewed-By: Karol Herbst 

On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann
 wrote:
> On 7/14/17 3:41 PM, Mike Galbraith wrote:
>>
>> On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
>>>
>>>   All DRM did was to slip a
>>> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
>>> things no longer warn, they blow the box out of the water.
>>
>> BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
>> into a WARN_ONCE(), and all is peachy, you get the warning, box lives.
>>
>> ---
>>   drivers/gpu/drm/drm_vblank.c |3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> --- a/drivers/gpu/drm/drm_vblank.c
>> +++ b/drivers/gpu/drm/drm_vblank.c
>> @@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
>>  */
>> if (mode->crtc_clock == 0) {
>> DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n",
>> pipe);
>> -   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
>> +   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report
>> me.\n",
>> + dev->driver->name);
>> return false;
>> }
>
>
>
> Hey,
>
> confirmed this helps saving the box, but we still have to find the root
> cause! Backtrace with the above fix applied (and the one which came in with
> the latest drm-fixes merge)!
>
>
> [1] https://hastebin.com/uyoqifijed.http
>
> Thanks,
>
> Tobias
>Reviewed-By: Karol Herbst 
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] drm: radeon: constify pci_device_id.

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6560   23212  72   298447494 gpu/drm/radeon/radeon_drv.o

File size After adding 'const':
   textdata bss dec hex filename
  28960 812  72   298447494 gpu/drm/radeon/radeon_drv.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index e25cb51..b079937 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -298,7 +298,7 @@ module_param_named(uvd, radeon_uvd, int, 0444);
 MODULE_PARM_DESC(vce, "vce enable/disable vce support (1 = enable, 0 = 
disable)");
 module_param_named(vce, radeon_vce, int, 0444);
 
-static struct pci_device_id pciidlist[] = {
+static const struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
 };
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Fri, 2017-07-14 at 17:05 +0200, Tobias Klausmann wrote:
> On 7/14/17 3:41 PM, Mike Galbraith wrote:
> > On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
> >>   All DRM did was to slip a
> >> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> >> things no longer warn, they blow the box out of the water.
> > BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
> > into a WARN_ONCE(), and all is peachy, you get the warning, box lives.
> >
> > ---
> >   drivers/gpu/drm/drm_vblank.c |3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
> >  */
> > if (mode->crtc_clock == 0) {
> > DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
> > -   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
> > +   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report me.\n",
> > + dev->driver->name);
> >   
> > return false;
> > }
> 
> 
> Hey,
> 
> confirmed this helps saving the box, but we still have to find the root 
> cause! Backtrace with the above fix applied (and the one which came in 
> with the latest drm-fixes merge)!

Yeah, I'll be reporting some extra whining from my 8600 GT backup box.

-Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Consistently use enum pipe for PCH transcoders

[Matthias Kaehlcke]

The current code uses two different enum types for PCH transcoders and
performs implicit conversions between the two types. This is error prone
and causes clang to raise warnings like this:

drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
  from enumeration type 'enum pipe' to different enumeration type
  'enum transcoder' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);

Consistently use the type enum pipe for PCH transcoders.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/i915/i915_irq.c| 10 +-
 drivers/gpu/drm/i915/intel_display.c   | 24 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  6 +++---
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  6 +++---
 4 files changed, 21 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 190f6aa5d15e..7960d2170750 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2132,10 +2132,10 @@ static void ibx_irq_handler(struct drm_i915_private 
*dev_priv, u32 pch_iir)
DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
 
if (pch_iir & SDE_TRANSA_FIFO_UNDER)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
 
if (pch_iir & SDE_TRANSB_FIFO_UNDER)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
 }
 
 static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
@@ -2169,13 +2169,13 @@ static void cpt_serr_int_handler(struct 
drm_i915_private *dev_priv)
DRM_ERROR("PCH poison interrupt\n");
 
if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
 
if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
 
if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
-   intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
+   intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
 
I915_WRITE(SERR_INT, serr_int);
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9106ea32b048..21a8fea46ad9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1782,7 +1782,7 @@ static void lpt_enable_pch_transcoder(struct 
drm_i915_private *dev_priv,
 
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
-   assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
+   assert_fdi_rx_enabled(dev_priv, PIPE_A);
 
/* Workaround: set timing override bit. */
val = I915_READ(TRANS_CHICKEN2(PIPE_A));
@@ -1858,16 +1858,16 @@ void lpt_disable_pch_transcoder(struct drm_i915_private 
*dev_priv)
I915_WRITE(TRANS_CHICKEN2(PIPE_A), val);
 }
 
-enum transcoder intel_crtc_pch_transcoder(struct intel_crtc *crtc)
+enum pipe intel_crtc_pch_transcoder(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
WARN_ON(!crtc->config->has_pch_encoder);
 
if (HAS_PCH_LPT(dev_priv))
-   return TRANSCODER_A;
+   return PIPE_A;
else
-   return (enum transcoder) crtc->pipe;
+   return crtc->pipe;
 }
 
 /**
@@ -1906,7 +1906,7 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
if (crtc->config->has_pch_encoder) {
/* if driving the PCH, we need FDI enabled */
assert_fdi_rx_pll_enabled(dev_priv,
- (enum pipe) 
intel_crtc_pch_transcoder(crtc));
+ 
intel_crtc_pch_transcoder(crtc));
assert_fdi_tx_pll_enabled(dev_priv,
  (enum pipe) cpu_transcoder);
}
@@ -4573,7 +4573,7 @@ static void lpt_pch_enable(const struct intel_crtc_state 
*crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
 
-   assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
+   assert_pch_transcoder_disabled(dev_priv, PIPE_A);
 
lpt_program_iclkip(crtc);
 
@@ -5329,8 +5329,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
return;
 
if (intel_crtc->config->has_pch_encoder)
-   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
-  

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:
>  All DRM did was to slip a
> WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
 drivers/gpu/drm/drm_vblank.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
 */
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report me.\n",
+ dev->driver->name);
 
return false;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm: hisilicon: constify pci_device_id.

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   2704 808   03512 db8
gpu/drm/hisilicon/hibmc/hibmc_drm_drv.o

File size After adding 'const':
   textdata bss dec hex filename
   2768 744   03512 db8
gpu/drm/hisilicon/hibmc/hibmc_drm_drv.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 2ffdbf9..a8c8186 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -401,7 +401,7 @@ static void hibmc_pci_remove(struct pci_dev *pdev)
drm_dev_unref(dev);
 }
 
-static struct pci_device_id hibmc_pci_table[] = {
+static const struct pci_device_id hibmc_pci_table[] = {
{0x19e5, 0x1711, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{0,}
 };
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vgem: add compat_ioctl support

[Brian Norris]

DRM drivers should supply a compat version if they're going to provide
an ioctl implementation at all. This can confuse 32-bit user space on a
64-bit system.

Signed-off-by: Brian Norris 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 9fee38a942c4..3835656e2baf 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -220,6 +220,7 @@ static const struct file_operations vgem_driver_fops = {
.poll   = drm_poll,
.read   = drm_read,
.unlocked_ioctl = drm_ioctl,
+   .compat_ioctl   = drm_compat_ioctl,
.release= drm_release,
 };
 
-- 
2.13.2.932.g7449e964c-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:
> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith  wrote:
> > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:
> >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
> >> >
> >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not
> >> > too much trouble, a bisect would be pretty useful.
> >>
> >> Bisection seemingly went fine, but the result is odd.
> >>
> >> e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit
> >
> > But it really really is bad.  Looking at gitk fork in the road leading
> > to it...
> >
> > 52d9d38c183b drm/sti:fix spelling mistake: "compoment" -> "component" - good
> > e4e818cc2d7c drm: make drm_panel.h self-contained - good
> > 9cf8f5802f39 drm: add missing declaration to drm_blend.h  - good
> >
> > Before the git highway splits, all is well.  The lane with commits
> > works fine at both ends, but e98c58e55f68 is busted.  Merge arfifact?
> 
> Hmmm... that tree does not appear to have gotten a v4.12 backmerge at
> any point. The last backmerge from Linus as far as I can tell was
> v4.11-rc7. Could be an interaction with some out-of-tree change.

Ok, a network outage gave me time to go hunting.  Indeed it is a bad
interaction with the tree DRM merged into.  All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.  I made a
dinky testcase module (attached), and bisected to the real root

19d436268dde95389c616bb3819da73f0a8b28a8 is the first bad commit
commit 19d436268dde95389c616bb3819da73f0a8b28a8
Author: Peter Zijlstra 
Date:   Sat Feb 25 08:56:53 2017 +0100

debug: Add _ONCE() logic to report_bug()

Josh suggested moving the _ONCE logic inside the trap handler, using a
bit in the bug_entry::flags field, avoiding the need for the extra
variable.

Sadly this only works for WARN_ON_ONCE(), since the others have
printk() statements prior to triggering the trap.

Still, this saves a fair amount of text and some data:

  text data   filename
  10682460 4530992defconfig-build/vmlinux.orig
  10665111 4530096defconfig-build/vmlinux.patched

Suggested-by: Josh Poimboeuf 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar 

:04 04 9f47f66ec4c234f6ee8e2a09e991c95fe47cf2c1 
3e92aa9e77b39ed075ae2c3bdf041d92ef898f62 M  arch
:04 04 34f70b73d40c82533dd7df9b289106be69e2fa8d 
dd5d7248694a36b3e170f2dca5d9c4121535a990 M  include
:04 04 f6e627b0d378f0a00d2987fdd0c7b215306e6e3c 
b360d4ee2579744cce530184d7dab13493f73ee0 M  lib ---
 kernel/Makefile |2 ++
 kernel/foo.c|   15 +++
 2 files changed, 17 insertions(+)

--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -111,6 +111,8 @@ obj-$(CONFIG_MEMBARRIER) += membarrier.o
 
 obj-$(CONFIG_HAS_IOMEM) += memremap.o
 
+obj-m += foo.o
+
 $(obj)/configs.o: $(obj)/config_data.h
 
 targets += config_data.gz
--- /dev/null
+++ b/kernel/foo.c
@@ -0,0 +1,15 @@
+#include 
+#include 
+
+static int __init foo_init(void)
+{
+	printk(KERN_INFO "foo: module loaded\n");
+	WARN_ON_ONCE(1);
+	return 0;
+}
+
+static void __exit foo_exit(void) { }
+
+module_init(foo_init);
+module_exit(foo_exit);
+MODULE_LICENSE("GPL");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] constify drm pci_device_id

[Arvind Yadav]

pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Arvind Yadav (5):
  [PATCH 1/5] drm: radeon: constify pci_device_id.
  [PATCH 2/5] drm: vmwgfx: constify pci_device_id.
  [PATCH 3/5] drm: nouveau: constify pci_device_id.
  [PATCH 4/5] drm: via: constify pci_device_id.
  [PATCH 5/5] drm: hisilicon: constify pci_device_id.

 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 drivers/gpu/drm/via/via_drv.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

On 7/14/17 3:41 PM, Mike Galbraith wrote:

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

  All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
  drivers/gpu/drm/drm_vblank.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
 */
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report me.\n",
+ dev->driver->name);
  
  		return false;

}



Hey,

confirmed this helps saving the box, but we still have to find the root 
cause! Backtrace with the above fix applied (and the one which came in 
with the latest drm-fixes merge)!



[1] https://hastebin.com/uyoqifijed.http

Thanks,

Tobias

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Mike Galbraith]

On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote:
> > Ok, a network outage gave me time to go hunting.  Indeed it is a bad
> > interaction with the tree DRM merged into.  All DRM did was to slip a
> > WARN_ON_ONCE() that nouveau triggers into a kernel module where such
> > things no longer warn, they blow the box out of the water.  I made a
> > dinky testcase module (attached), and bisected to the real root
> > 
> > 19d436268dde95389c616bb3819da73f0a8b28a8 is the first bad commit
> > commit 19d436268dde95389c616bb3819da73f0a8b28a8
> > Author: Peter Zijlstra 
> > Date:   Sat Feb 25 08:56:53 2017 +0100
> > 
> > debug: Add _ONCE() logic to report_bug()
> 
> Urgh, is for some mysterious reason the __bug_table section of modules
> ending up in RO memory?
> 
> I forever get lost in that link magic :/

+1

drm.ko
 20 __bug_table   0630      0004bff3  2**0
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
vmlinux
 15 __bug_table   ba84  81af26c0  01af26c0  00cf26c0  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA

Danged if I know... um um RELOC business mucks things up?

-Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Matthias Kaehlcke]

El Fri, Jul 14, 2017 at 03:43:35PM -0700 Grant Grundler ha dit:

> On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter  wrote:
> > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler  
> > wrote:
> >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
> >>  wrote:
> >>> On Thu, 13 Jul 2017, Stéphane Marchesin  
> >>> wrote:
>  So, if you think this is wrong, can you fix this warning in a way that
>  you'd like?
> >>>
> >>> As I replied previously [1], with more background, fixing the warnings
> >>> properly, in a way that actually improves the code instead of making it
> >>> worse, would mean a bunch of churn that's not just purely mechanical
> >>> conversion.
> >>
> >> That's fair.
> >>
> >>> Unless you can point out a bug which is actually caused by mixing the
> >>> types (which is mostly intentional, see the background) I have a hard
> >>> time telling people this should be a priority.
> >>
> >> This feels like "can't see the forest because of the trees".
> >>
> >> The original patch was submitted in order to compile cleanly using
> >> clang and the above suggests using clang is not important.  Using
> >> clang is important to Matthias and the Chrome OS organization for many
> >> good reasons - including better warnings.
> >>
> >> The original patch message was clear that clang was generating the
> >> warning. This isn't the only patch mka has sent to kernel devs. What
> >> one can infer is Chrome OS is trying to move to clang (like other
> >> Google products _already_ have.)  My impression is all these products
> >> are a priority to Intel - but it would be good to know otherwise.
> >>
> >>> Definitely something we'd
> >>> like to do in the long run and pedantically correct (and I tend to
> >>> prefer code that way) but we certainly have more important things to do.
> >>
> >> The long run is now. Everyone agrees the code should change and you
> >> don't have to do it. Matthias submitted an unacceptable patch and
> >> giving him some concrete guidance on what would be acceptable would
> >> enable him to implement/test it (or anyone else could for that
> >> matter).  Can you do that?
> >>
> >> Just give an example of what the "right" API looks like and see where it 
> >> goes.
> >
> > We've replied and discussed on May 5th what that roughly should be,
> > right when Matthias pinged us. The original submission unfortunately
> > fell through the cracks (it happens, not much we can do with this
> > flood). Matthias didn't seem to have any questions about the proposed
> > solutions (we laid out both the minimal short-term fix to unconfuse
> > things, and what might be done on top), I think a reasonable
> > assumption was that it's all clear. Otherwise he should have asked.
> 
> Indeed!
> 
> After briefly chatting with Stephane and mka, it seems the difference
> between short-term fix and "done on top" were not clear.
> 
> > Now, over 2 months later (and complete silence from your side) there's
> > suddenly mass panic and multiple escalations on all available
> > channels, which feels like a rather decent overreaction and not a
> > terrible constructive way to collaborate on the upstream codebase.
> 
> I'm sorry - I'm not on the other channels and I didn't see any mass
> panic. I agree that's not a collaborative. The previous answer in this
> thread didn't seem particularly collaborative either though.
> 
> The silence was partly due to mka working on other "clang enablement" patches:

Yes, sorry for the silence :(

With my lack of expertise with this driver and graphics in general I
wasn't sure if I'd take up the "done on top" solution and shifted my
attention to other clang related issues.

> $ pwclient list -w m...@chromium.org
> Patches submitted by Matthias Kaehlcke :
> ID  StateName
> --  -
> 9668095 Superseded   mac80211: Fix clang warning about constant
> operand in logical operation
> 9668479 Accepted ath9k: Add cast to u8 to FREQ2FBIN macro
> 9668643 Accepted [v2] mac80211: Fix clang warning about constant
> operand in logical operation
> 9679753 Accepted [v2] cfg80211: Fix array-bounds warning in fragment copy
> 9684547 Accepted mac80211: ibss: Fix channel type enum in
> ieee80211_sta_join_ibss()
> 9684629 Accepted nl80211: Fix enum type of variable in
> nl80211_put_sta_rate()
> 
> > Anyway, I've done the quick draft for the function declaration changes
> > that would clear up the confusion, just needs a clang run to update
> > all the parameters to match, and passed that on to Stéphane Marchesin.

Thanks, that is helpful!

> Awesome - thanks! :)
> 
> > I expect you to follow up with the corresponding patch right away.
> 
> mka said "he would take a look at it". But knowing how he understates
> things in a typical "German Engineer" way, I'm optimistic it will be
> more than that. Thanks!
> 
> cheers,
> grant
> 
> >
> > Thanks a lot.
> >
> > Yours, Daniel
> >
> > For reference the diff, but probably whitespace mangled because the
> > real machine is down 

Re: [PATCH] drm/etnaviv: select CMA and DMA_CMA if available

[Joshua Clayton]

On Friday, July 14, 2017 7:38:01 AM PDT Lucas Stach wrote:
> While this is no build dependency, etnaviv will only work correctly on most
> systems if CMA and DMA_CMA are enabled. Select both options if available to
> avoid users ending up with a non-working GPU due to a lacking kernel config.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig
> b/drivers/gpu/drm/etnaviv/Kconfig index 71cee4e9fefb..38b477b5fbf9 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -10,6 +10,8 @@ config DRM_ETNAVIV
>   select IOMMU_API
>   select IOMMU_SUPPORT
>   select WANT_DEV_COREDUMP
> + select CMA if HAVE_DMA_CONTIGUOUS
> + select DMA_CMA if HAVE_DMA_CONTIGUOUS
>   help
> DRM driver for Vivante GPUs.
IIRC, This at least half solves it.
Does the user of systems with > 2 GiB  need to explicitly specify cma size for 
it to work?

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm/nouveau] GeForce 8600 GT boot/suspend grumbling

[Mike Galbraith]

Greetings,

box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
kernel: master.today (v4.12-11690-gccd5d1b91f22)

lspci -nn -d 10de:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600 
GT] [10de:0402] (rev a1)

abreviated dmesg:
...
[3.720990] fb: switching to nouveaufb from VESA VGA
[3.744489] Console: switching to colour dummy device 80x25
[3.744966] nouveau :01:00.0: NVIDIA G84 (084200a2)
...
[3.846963] usbcore: registered new interface driver uas
[3.849938] nouveau :01:00.0: bios: version 60.84.6e.00.12
[3.870769] hid-generic 0003:04CA:002B.0002: input,hidraw1: USB HID v1.11 
Keyboard [Liteon Wireless keyboard and mouse] on usb-:00:1d.0-1/input0
[3.870773] nouveau :01:00.0: bios: M0203T not found
[3.870774] nouveau :01:00.0: bios: M0203E not matched!
[3.870777] nouveau :01:00.0: fb: 256 MiB DDR2
[3.871168] input: Liteon Wireless keyboard and mouse as 
/devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.1/0003:04CA:002B.0003/input/input7
[3.896090] usb 3-2: new low-speed USB device number 3 using uhci_hcd
[3.919101] [TTM] Zone  kernel: Available graphics memory: 3881208 kiB
[3.919106] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[3.919110] [TTM] Initializing pool allocator
[3.919120] [TTM] Initializing DMA pool allocator
[3.919141] nouveau :01:00.0: DRM: VRAM: 256 MiB
[3.919146] nouveau :01:00.0: DRM: GART: 1048576 MiB
[3.919152] nouveau :01:00.0: DRM: TMDS table version 2.0
[3.919157] nouveau :01:00.0: DRM: DCB version 4.0
[3.919162] nouveau :01:00.0: DRM: DCB outp 00: 04000310 0028
[3.919167] nouveau :01:00.0: DRM: DCB outp 01: 02011300 0028
[3.919171] nouveau :01:00.0: DRM: DCB outp 02: 01011302 0030
[3.919176] nouveau :01:00.0: DRM: DCB outp 03: 02022322 00020010
[3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083
[3.919185] nouveau :01:00.0: DRM: DCB conn 00: 
[3.919189] nouveau :01:00.0: DRM: DCB conn 01: 1130
[3.919194] nouveau :01:00.0: DRM: DCB conn 02: 2261
[3.919198] nouveau :01:00.0: DRM: DCB conn 03: 0310
[3.919202] nouveau :01:00.0: DRM: DCB conn 04: 0311
[3.919206] nouveau :01:00.0: DRM: DCB conn 05: 0313
[3.919258] [ cut here ]
[3.919316] WARNING: CPU: 3 PID: 224 at 
drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c:83 
nvkm_outp_xlat.isra.0+0x26/0x80 [nouveau]
[3.919322] Modules linked in: uas(E) usb_storage(E) hid_generic(E+) 
usbhid(E) nouveau(E+) wmi(E) video(E) i2c_algo_bit(E) ahci(E+) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) libahci(E) sysimgblt(E) 
fb_sys_fops(E) firewire_ohci(E) libata(E) firewire_core(E) crc_itu_t(E) 
ehci_pci(E+) serio_raw(E) ttm(E) button(E) drm(E) uhci_hcd(E) ehci_hcd(E) 
usbcore(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) 
scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[3.919360] CPU: 3 PID: 224 Comm: systemd-udevd Tainted: GE   
4.12.0.gccd5d1b-master #186
[3.919366] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007
[3.919370] task: 880211cd3d40 task.stack: c9714000
[3.919412] RIP: 0010:nvkm_outp_xlat.isra.0+0x26/0x80 [nouveau]
[3.919417] RSP: 0018:c97177b0 EFLAGS: 00010202
[3.919421] RAX: 88021128fc08 RBX: 880211c0aa80 RCX: c9717870
[3.919425] RDX: c97177fc RSI:  RDI: 0001
[3.919429] RBP: 88021128fc10 R08: 880211c0aa80 R09: 880211c0aa80
[3.919433] R10:  R11: ea00084cf980 R12: 8802130f5500
[3.919437] R13: 880211c0a9d0 R14: 0003 R15: 0004
[3.919442] FS:  7fe2035b68c0() GS:88022fd8() 
knlGS:
[3.919448] CS:  0010 DS:  ES:  CR0: 80050033
[3.919452] CR2: 7fe203586000 CR3: 0002133e3000 CR4: 06e0
[3.919456] Call Trace:
[3.919500]  nvkm_outp_ctor+0x105/0x130 [nouveau]
[3.919508]  ? kmem_cache_alloc_trace+0x135/0x140
[3.919550]  nvkm_disp_oneinit+0x132/0x510 [nouveau]
[3.919583]  nvkm_engine_init+0x74/0x1d0 [nouveau]
[3.919617]  nvkm_subdev_init+0xaf/0x200 [nouveau]
[3.919648]  nvkm_engine_ref+0x4a/0x70 [nouveau]
[3.919681]  nvkm_ioctl_new+0x118/0x280 [nouveau]
[3.919705]  ? drm_property_create+0x100/0x150 [drm]
[3.919746]  ? nvkm_udevice_map+0x40/0x40 [nouveau]
[3.919779]  nvkm_ioctl+0x13c/0x230 [nouveau]
[3.919785]  ? try_to_grab_pending+0xa7/0x130
[3.919816]  nvif_object_init+0xc0/0x130 [nouveau]
[3.919859]  nouveau_display_create+0x13e/0x630 [nouveau]
[3.919903]  nouveau_drm_load+0x1e2/0x8d0 [nouveau]
[3.919910]  ? sysfs_do_create_link_sd.isra.2+0x6b/0xb0
[3.919924]  drm_dev_register+0x139/0x1d0 [drm]
[3.919930]  ? pci_read_config_word.part.9+0x47/0x60
[3.91994

[PATCH 3/4] tegra-cec: add Tegra HDMI CEC driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for the Tegra CEC IP. It is based on the
NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel.

This has been converted to the CEC framework and cleaned up.

Tested with my Jetson TK1 board. It has also been tested with the
Tegra X1 in an embedded product.

Note of warning for the Tegra X2: this SoC supports two HDMI outputs,
but only one CEC adapter and the CEC bus is shared between the
two outputs. This is a design mistake and the CEC adapter can
control only one HDMI output. Never hook up both HDMI outputs
to the CEC bus in a hardware design: this is illegal as per the
CEC specification.

The CEC bus can be shared between multiple inputs and zero or one
outputs, but not between multiple outputs.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS  |   8 +
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/tegra-cec/Makefile|   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c | 506 +++
 drivers/media/platform/tegra-cec/tegra_cec.h | 127 +++
 6 files changed, 655 insertions(+)
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d9bd4a041af..35b393feac52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1917,6 +1917,14 @@ M:   Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
+ARM/TEGRA HDMI CEC SUBSYSTEM SUPPORT
+M: Hans Verkuil 
+L: linux-te...@vger.kernel.org
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/tegra-cec/
+F: Documentation/devicetree/bindings/media/tegra-cec.txt
+
 ARM/TETON BGA MACHINE SUPPORT
 M: "Mark F. Brown" 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd533436..31f54cbdf2e2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -570,6 +570,17 @@ config VIDEO_STM32_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_TEGRA_HDMI_CEC
+   tristate "Tegra HDMI CEC driver"
+   depends on ARCH_TEGRA || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for the Tegra HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
 
 menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..9da73532e556 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra-cec/
+
 obj-y  += stm32/
 
 obj-y   += blackfin/
diff --git a/drivers/media/platform/tegra-cec/Makefile 
b/drivers/media/platform/tegra-cec/Makefile
new file mode 100644
index ..f3d81127589f
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra_cec.o
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c 
b/drivers/media/platform/tegra-cec/tegra_cec.c
new file mode 100644
index ..346586c3ad6d
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -0,0 +1,506 @@
+/*
+ * Tegra CEC implementation
+ *
+ * The original 3.10 CEC driver using a custom API:
+ *
+ * Copyright (c) 2012-2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Conversion to the CEC framework and to the mainline kernel:
+ *
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+

[PATCH 4/4] drm/tegra: add cec-notifier support

[Hans Verkuil]

From: Hans Verkuil 

In order to support CEC the HDMI driver has to inform the CEC driver
whenever the physical address changes. So when the EDID is read the
CEC driver has to be informed and whenever the hotplug detect goes
away.

This is done through the cec-notifier framework.

The link between the HDMI driver and the CEC driver is done through
the hdmi_phandle in the tegra-cec node in the device tree.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/tegra/drm.h| 3 +++
 drivers/gpu/drm/tegra/hdmi.c   | 9 +
 drivers/gpu/drm/tegra/output.c | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6d6da01282f3..c0a18b60caf1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
   struct clk *clk, unsigned long pclk,
   unsigned int div);
 
+struct cec_notifier;
+
 struct tegra_output {
struct device_node *of_node;
struct device *dev;
@@ -219,6 +221,7 @@ struct tegra_output {
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
+   struct cec_notifier *notifier;
unsigned int hpd_irq;
int hpd_gpio;
enum of_gpio_flags hpd_gpio_flags;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index cda0491ed6bf..fbf14e1efd0e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #include "hdmi.h"
 #include "drm.h"
 #include "dc.h"
@@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->vdd);
}
 
+   hdmi->output.notifier = cec_notifier_get(&pdev->dev);
+   if (hdmi->output.notifier == NULL)
+   return -ENOMEM;
+
hdmi->output.dev = &pdev->dev;
 
err = tegra_output_probe(&hdmi->output);
@@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device *pdev)
 
tegra_output_remove(&hdmi->output);
 
+   if (hdmi->output.notifier)
+   cec_notifier_put(hdmi->output.notifier);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 595d1ec3e02e..57c052521a44 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -11,6 +11,8 @@
 #include 
 #include "drm.h"
 
+#include 
+
 int tegra_output_connector_get_modes(struct drm_connector *connector)
 {
struct tegra_output *output = connector_to_output(connector);
@@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
*connector)
edid = drm_get_edid(connector, output->ddc);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
 
if (edid) {
err = drm_add_edid_modes(connector, edid);
@@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
*connector, bool force)
status = connector_status_connected;
}
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(output->notifier);
+
return status;
 }
 
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] ARM: tegra: add CEC support to tegra124.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
Jetson TK1.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 
 arch/arm/boot/dts/tegra124.dtsi   | 12 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 7bacb2954f58..c22c0e6dc3d9 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -67,6 +67,10 @@
};
};
 
+   tegra_cec {
+   status = "okay";
+   };
+
gpu@0,5700 {
/*
 * Node left disabled on purpose - the bootloader will enable
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 1b10b14a6abd..df7e9e2925f5 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -123,7 +123,7 @@
nvidia,head = <1>;
};
 
-   hdmi@5428 {
+   hdmi: hdmi@5428 {
compatible = "nvidia,tegra124-hdmi";
reg = <0x0 0x5428 0x0 0x0004>;
interrupts = ;
@@ -851,6 +851,16 @@
status = "disabled";
};
 
+   tegra_cec {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+   hdmi-phandle = <&hdmi>;
+   status = "disabled";
+   };
+
soctherm: thermal-sensor@700e2000 {
compatible = "nvidia,tegra124-soctherm";
reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] dt-bindings: document the tegra CEC bindings

[Hans Verkuil]

From: Hans Verkuil 

This documents the binding for the Tegra CEC module.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/tegra-cec.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt

diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
b/Documentation/devicetree/bindings/media/tegra-cec.txt
new file mode 100644
index ..ba0b6071acaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
@@ -0,0 +1,26 @@
+* Tegra HDMI CEC driver
+
+The HDMI CEC module is present in Tegra SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be one of the following:
+   "nvidia,tegra114-cec"
+   "nvidia,tegra124-cec"
+   "nvidia,tegra210-cec"
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "cec",
+ corresponding to ithe entry in the clocks property.
+  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
+
+Example:
+
+tegra_cec {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] tegra-cec: add Tegra HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the Tegra CEC functionality.

It has two prerequisites:

this cec-notifier patch: https://patchwork.linuxtv.org/patch/42521/

and this workaround: http://www.spinics.net/lists/dri-devel/msg147038.html

A proper fix needs to be found for that workaround, but it is good
enough for testing this patch series.

The first patch documents the CEC bindings, the second adds support
for this to tegra124.dtsi and enables it for the Jetson TK1.

The third patch adds the CEC driver itself and the final patch adds
the cec notifier support to the drm/tegra driver in order to notify
the CEC driver whenever the physical address changes.

I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
other Tegra SoCs, but I can only test this with my Jetson TK1 board.

The dt-bindings and the tegra-cec driver would go in through the media
subsystem, the drm/tegra part through the drm subsystem and the dts
changes through (I guess) the linux-tegra developers. Luckily they are
all independent of one another.

To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.

To build this:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh; ./configure
make
sudo make install   # optional, you really only need utils/cec*

To test:

cec-ctl --playback  # configure as playback device
cec-ctl -S  # detect all connected CEC devices

See here for the public CEC API:

https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html

Regards,

Hans

Hans Verkuil (4):
  dt-bindings: document the tegra CEC bindings
  ARM: tegra: add CEC support to tegra124.dtsi
  tegra-cec: add Tegra HDMI CEC driver
  drm/tegra: add cec-notifier support

 .../devicetree/bindings/media/tegra-cec.txt|  26 ++
 MAINTAINERS|   8 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
 arch/arm/boot/dts/tegra124.dtsi|  12 +-
 drivers/gpu/drm/tegra/drm.h|   3 +
 drivers/gpu/drm/tegra/hdmi.c   |   9 +
 drivers/gpu/drm/tegra/output.c |   6 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/tegra-cec/Makefile  |   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c   | 506 +
 drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
 12 files changed, 714 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

[Daniel Vetter]

On Sat, Jul 15, 2017 at 11:10:07AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-07-14 23:46:54)
> > @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> > drm_atomic_state *state,
> > struct drm_connector_state *new_conn_state;
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *new_crtc_state;
> > +   struct drm_device *dev = state->dev;
> > +   int ret;
> >  
> > state->acquire_ctx = ctx;
> >  
> > @@ -2914,7 +2921,10 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> > drm_atomic_state *state,
> > for_each_new_connector_in_state(state, connector, new_conn_state, i)
> > state->connectors[i].old_state = connector->state;
> >  
> > -   return drm_atomic_commit(state);
> > +   ret = drm_atomic_commit(state);
> > +   drm_atomic_clean_old_fb(dev, ~0U, ret);
> 
> I have no idea what the rules should be here. Or how it should interact
> with error. Should we just try the "drm: Track framebuffer references at
> the point of assignment" approach to simplify the rules (at least from
> my perspective)? The problem with that patch is sorting out the state
> duplication done in a couple of drivers and figuring out if they are
> transferring ownership or not.

Yeah this is a decent mess. I think a first incremental step would be to
move the ->old_fb and ->fb refcount updating into drm_atomic_commit -
clean_old_fb is a superbly misnamed function, what it really does is
update the legacy framebuffer pointer refcounts. The kernel-doc it has
also just serves to increase the confusion :-/

The only problem is that for an drm_atomic_commit in one of the legacy
callbacks we must _not_ do that, because the core already takes care fo
that. But having a drm_atomic_commit_legacy for that would be a lot
cleaner I think.

Once we have that I guess we could try and figure out what to do with the
refcounting of the legacy pointers at large.

Meanwhile the rules are:
- If you do an atomic commit, you must call clean_old_fb. Everywhere. We
  got away in a few cases because we've made nice symmetric commits (like
  suspend/resume) or commits where we know the fb doesn't get updated.

- Exception: When called from ->plane_update/disable, ->set_config or
  ->page_flip, the core does it for you.

It's a mess, but I'd like to decouple fixing that mess from fixing the
unload bug we have. I'll try to type up the drm_atomic_commit/_legacy
patch next week.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

[Chris Wilson]

Quoting Daniel Vetter (2017-07-15 10:53:28)
> For modern drivers the DRM core doesn't use struct_mutex at all, which
> means it's defacto a driver-private lock. But since we still need it
> for legacy drivers we can't initialize it in drivers, which means all
> the different instances share one lockdep key. Despite that they might
> be placed in totally different places in the locking hierarchy.
> 
> This results in a lot of bogus lockdep splats when running stuff on
> systems with multiple gpus. Partially remedy the situation by only
> doing might_lock checks on drivers that do use struct_mutex still for
> gem locking.
> 
> A more complete solution would be to do the mutex_init in the drm core
> only for legacy drivers, plus add it to each modern driver that still
> needs it, which would also give each its own lockdep key. Trying to do
> that dynamically doesn't work, because lockdep requires it's keys to
> be statically allocated.
> 
> Cc: Hans de Goede 
> Cc: Ben Skeggs 
> Cc: Jiri Slaby 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Signed-off-by: Daniel Vetter 

But fwiw, the patch isn't wrong and fixes a false positive, so
Reviewed-by: Chris Wilson 

>  drivers/gpu/drm/drm_gem.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 8dc11064253d..9663a79dd363 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -826,13 +826,15 @@ drm_gem_object_put_unlocked(struct drm_gem_object *obj)
> return;
>  
> dev = obj->dev;
> -   might_lock(&dev->struct_mutex);
>  
> if (dev->driver->gem_free_object_unlocked)

coding-style nit, if one branch needs {} they all need {}.
(The real reason why I didn't want to move might_lock around in this
function ;)

> kref_put(&obj->refcount, drm_gem_object_free);
> -   else if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
> +   else {
> +   might_lock(&dev->struct_mutex);
> +   if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
> &dev->struct_mutex))
> -   mutex_unlock(&dev->struct_mutex);
> +   mutex_unlock(&dev->struct_mutex);
> +   }
>  }
>  EXPORT_SYMBOL(drm_gem_object_put_unlocked);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: cdn-dp: send audio infoframe to sink

[Chris Zhong]

Some DP/HDMI sink need to receive the audio infoframe to play sound,
especially some multi-channel AV receiver, they need the
channel_allocation from infoframe to config the speakers. Send the
audio infoframe via SDP will make them work properly.

Signed-off-by: Chris Zhong 
---

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 20 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 19 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.h  |  6 ++
 3 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9b0b058..e59ca47 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -802,6 +802,7 @@ static int cdn_dp_audio_hw_params(struct device *dev,  void 
*data,
.sample_rate = params->sample_rate,
.channels = params->channels,
};
+   u8 buffer[14];
int ret;
 
mutex_lock(&dp->lock);
@@ -823,6 +824,25 @@ static int cdn_dp_audio_hw_params(struct device *dev,  
void *data,
goto out;
}
 
+   memset(buffer, 0, sizeof(buffer));
+
+   ret = hdmi_audio_infoframe_pack(¶ms->cea, buffer, sizeof(buffer));
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev, "Failed to pack audio infoframe: %d\n", ret);
+   goto out;
+   }
+
+   /*
+* Change the infoframe header to SDP header per DP 1.3 spec, Table
+* 2-98.
+*/
+   buffer[0] = 0;
+   buffer[1] = HDMI_INFOFRAME_TYPE_AUDIO;
+   buffer[2] = 0x1b;
+   buffer[3] = 0x48;
+
+   cdn_dp_sdp_write(dp, 0, buffer, sizeof(buffer));
+
ret = cdn_dp_audio_config(dp, &audio);
if (!ret)
dp->audio_info = audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index b14d211..8907db0 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -951,6 +951,25 @@ static void cdn_dp_audio_config_spdif(struct cdn_dp_device 
*dp)
clk_set_rate(dp->spdif_clk, CDN_DP_SPDIF_CLK);
 }
 
+void cdn_dp_sdp_write(struct cdn_dp_device *dp, int entry_id, u8 *buf, u32 len)
+{
+   int idx;
+   u32 *packet = (u32 *)buf;
+   u32 length = len / 4;
+   u8 type = buf[1];
+
+   for (idx = 0; idx < length; idx++)
+   writel(cpu_to_le32(*packet++), dp->regs + SOURCE_PIF_DATA_WR);
+
+   writel(entry_id, dp->regs + SOURCE_PIF_WR_ADDR);
+
+   writel(F_HOST_WR, dp->regs + SOURCE_PIF_WR_REQ);
+
+   writel(PIF_PKT_TYPE_VALID | F_PACKET_TYPE(type) | entry_id,
+  dp->regs + SOURCE_PIF_PKT_ALLOC_REG);
+   writel(PIF_PKT_ALLOC_WR_EN, dp->regs + SOURCE_PIF_PKT_ALLOC_WR_EN);
+}
+
 int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio)
 {
int ret;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h 
b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
index c4bbb4a83..6ec0e81 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
@@ -424,6 +424,11 @@
 /* Reference cycles when using lane clock as reference */
 #define LANE_REF_CYC   0x8000
 
+#define F_HOST_WR  BIT(0)
+#define PIF_PKT_ALLOC_WR_ENBIT(0)
+#define PIF_PKT_TYPE_VALID (3 << 16)
+#define F_PACKET_TYPE(x)   (((x) & 0xff) << 8)
+
 enum voltage_swing_level {
VOLTAGE_LEVEL_0,
VOLTAGE_LEVEL_1,
@@ -478,5 +483,6 @@ int cdn_dp_set_video_status(struct cdn_dp_device *dp, int 
active);
 int cdn_dp_config_video(struct cdn_dp_device *dp);
 int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio);
 int cdn_dp_audio_mute(struct cdn_dp_device *dp, bool enable);
+void cdn_dp_sdp_write(struct cdn_dp_device *dp, int entry_id, u8 *buf, u32 
len);
 int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio);
 #endif /* _CDN_DP_REG_H */
-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH, RESEND 02/14] ata: avoid gcc-7 warning in ata_timing_quantize

[Tejun Heo]

On Fri, Jul 14, 2017 at 11:25:14AM +0200, Arnd Bergmann wrote:
> gcc-7 warns about the result of a constant multiplication used as
> a boolean:
> 
> drivers/ata/libata-core.c: In function 'ata_timing_quantize':
> drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest 
> '&&' instead [-Wint-in-bool-context]
> 
> This slightly rearranges the macro to simplify the code and avoid
> the warning at the same time.
> 
> Signed-off-by: Arnd Bergmann 

If the whole series will be routed together,

 Acked-by: Tejun Heo 

If not, please let me know.  I'll push it through
libata/for-4.13-fixes.

Thanks!

-- 
tejun
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

[Chris Wilson]

Quoting Daniel Vetter (2017-07-14 23:46:54)
> @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> drm_atomic_state *state,
> struct drm_connector_state *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> +   struct drm_device *dev = state->dev;
> +   int ret;
>  
> state->acquire_ctx = ctx;
>  
> @@ -2914,7 +2921,10 @@ int drm_atomic_helper_commit_duplicated_state(struct 
> drm_atomic_state *state,
> for_each_new_connector_in_state(state, connector, new_conn_state, i)
> state->connectors[i].old_state = connector->state;
>  
> -   return drm_atomic_commit(state);
> +   ret = drm_atomic_commit(state);
> +   drm_atomic_clean_old_fb(dev, ~0U, ret);

I have no idea what the rules should be here. Or how it should interact
with error. Should we just try the "drm: Track framebuffer references at
the point of assignment" approach to simplify the rules (at least from
my perspective)? The problem with that patch is sorting out the state
duplication done in a couple of drivers and figuring out if they are
transferring ownership or not.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

[Chris Wilson]

Quoting Daniel Vetter (2017-07-15 10:53:28)
> For modern drivers the DRM core doesn't use struct_mutex at all, which
> means it's defacto a driver-private lock. But since we still need it
> for legacy drivers we can't initialize it in drivers, which means all
> the different instances share one lockdep key. Despite that they might
> be placed in totally different places in the locking hierarchy.
> 
> This results in a lot of bogus lockdep splats when running stuff on
> systems with multiple gpus. Partially remedy the situation by only
> doing might_lock checks on drivers that do use struct_mutex still for
> gem locking.
> 
> A more complete solution would be to do the mutex_init in the drm core
> only for legacy drivers, plus add it to each modern driver that still
> needs it, which would also give each its own lockdep key. Trying to do
> that dynamically doesn't work, because lockdep requires it's keys to
> be statically allocated.

I placed it in drm_driver which is static to get around that, did you
see the patch adding drm_driver_class? I didn't choose that path since
this might_lock clearly belongs to kref_put_mutex...

Similarly might_lock can also include might_sleep

+#define lock_is_mutex(lock) \
+   __builtin_types_compatible_p(typeof(*lock), struct mutex)
+
 # define might_lock(lock)  \
 do {   \
+   might_sleep_if(lock_is_mutex(lock));


> Cc: Hans de Goede 
> Cc: Ben Skeggs 
> Cc: Jiri Slaby 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_gem.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 8dc11064253d..9663a79dd363 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -826,13 +826,15 @@ drm_gem_object_put_unlocked(struct drm_gem_object *obj)
> return;
>  
> dev = obj->dev;
> -   might_lock(&dev->struct_mutex);
>  
> if (dev->driver->gem_free_object_unlocked)
> kref_put(&obj->refcount, drm_gem_object_free);
> -   else if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
> +   else {
> +   might_lock(&dev->struct_mutex);
> +   if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
> &dev->struct_mutex))
> -   mutex_unlock(&dev->struct_mutex);
> +   mutex_unlock(&dev->struct_mutex);
> +   }
>  }
>  EXPORT_SYMBOL(drm_gem_object_put_unlocked);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Don't complain too much about struct_mutex.

[Daniel Vetter]

For modern drivers the DRM core doesn't use struct_mutex at all, which
means it's defacto a driver-private lock. But since we still need it
for legacy drivers we can't initialize it in drivers, which means all
the different instances share one lockdep key. Despite that they might
be placed in totally different places in the locking hierarchy.

This results in a lot of bogus lockdep splats when running stuff on
systems with multiple gpus. Partially remedy the situation by only
doing might_lock checks on drivers that do use struct_mutex still for
gem locking.

A more complete solution would be to do the mutex_init in the drm core
only for legacy drivers, plus add it to each modern driver that still
needs it, which would also give each its own lockdep key. Trying to do
that dynamically doesn't work, because lockdep requires it's keys to
be statically allocated.

Cc: Hans de Goede 
Cc: Ben Skeggs 
Cc: Jiri Slaby 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8dc11064253d..9663a79dd363 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -826,13 +826,15 @@ drm_gem_object_put_unlocked(struct drm_gem_object *obj)
return;
 
dev = obj->dev;
-   might_lock(&dev->struct_mutex);
 
if (dev->driver->gem_free_object_unlocked)
kref_put(&obj->refcount, drm_gem_object_free);
-   else if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
+   else {
+   might_lock(&dev->struct_mutex);
+   if (kref_put_mutex(&obj->refcount, drm_gem_object_free,
&dev->struct_mutex))
-   mutex_unlock(&dev->struct_mutex);
+   mutex_unlock(&dev->struct_mutex);
+   }
 }
 EXPORT_SYMBOL(drm_gem_object_put_unlocked);
 
-- 
2.13.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/atomic-helper: Fix leak in disable_all

[Daniel Vetter]

The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().

In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
  again, which means the plane->fb pointer won't change, hence can't
  leak.
- Drivers using drm_atomic_helper_shutdown call the fbdev cleanup
  first, and that usually cleans up the fb through
  drm_remove_framebuffer, which does this correctly.
- Without fbdev the only framebuffers are from userspace, and those
  get cleaned up (again using drm_remove_framebuffer) befor the driver
  can even be unloaded.

But in i915 I've switched the cleanup sequence around so that the
_shutdown() calls happens after the drm_remove_framebuffer(), which is
how I discovered this issue.

v2: My analysis why the current code was ok for gpu reset and
suspend/resume was correct, but then I totally failed to realize that
we better keep this symmetric. Thanksfully CI noticed that for
balance, a refcounting bug must exist at 2 places if previously there
was no issue ...

v3: Don't be lazy and compute the plane_mask in
commit_duplicated_state properly too, instead of just using ~0U.

Cc: martin.pe...@free.fr
Cc: ch...@chris-wilson.co.uk
Acked-by: Dave Airlie  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index b07fc30372d3..545328a9a769 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2726,6 +2726,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
struct drm_plane *plane;
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
+   unsigned plane_mask = 0;
int ret, i;
 
state = drm_atomic_state_alloc(dev);
@@ -2768,10 +2769,14 @@ int drm_atomic_helper_disable_all(struct drm_device 
*dev,
goto free;
 
drm_atomic_set_fb_for_plane(plane_state, NULL);
+   plane_mask |= BIT(drm_plane_index(plane));
+   plane->old_fb = plane->fb;
}
 
ret = drm_atomic_commit(state);
 free:
+   if (plane_mask)
+   drm_atomic_clean_old_fb(dev, plane_mask, ret);
drm_atomic_state_put(state);
return ret;
 }
@@ -2902,11 +2907,16 @@ int drm_atomic_helper_commit_duplicated_state(struct 
drm_atomic_state *state,
struct drm_connector_state *new_conn_state;
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state;
+   unsigned plane_mask = 0;
+   struct drm_device *dev = state->dev;
+   int ret;
 
state->acquire_ctx = ctx;
 
-   for_each_new_plane_in_state(state, plane, new_plane_state, i)
+   for_each_new_plane_in_state(state, plane, new_plane_state, i) {
+   plane_mask |= BIT(drm_plane_index(plane));
state->planes[i].old_state = plane->state;
+   }
 
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
state->crtcs[i].old_state = crtc->state;
@@ -2914,7 +2924,11 @@ int drm_atomic_helper_commit_duplicated_state(struct 
drm_atomic_state *state,
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
 
-   return drm_atomic_commit(state);
+   ret = drm_atomic_commit(state);
+   if (plane_mask)
+   drm_atomic_clean_old_fb(dev, plane_mask, ret);
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
 
-- 
2.13.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel