[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank

[Andrey Skvortsov]

On Mon, Feb 23, 2015 at 02:54:47PM +0200, Jani Nikula wrote:
> On Mon, 23 Feb 2015, Jani Nikula  wrote:
> > On Mon, 16 Feb 2015, Paul Bolle  wrote:
> >> I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K
> >> lines in dmesg containing either "[drm" or this WARNING are pasted
> >> below. I really know nothing about all this, but I do note that only the
> >> WARNINGS are preceded by:
> >> [drm:intel_calculate_wm] FIFO watermark level: -5
> >> [drm:i9xx_update_wm] FIFO watermarks - A: 26, B: 8
> >>
> >> But perhaps that's another symptom of the same issue. A bit of staring
> >> at the code couldn't help me determine that.
> >>
> >> Perhaps these debug messages help someone in discovering what might be
> >> going on here.
> >
> > Please try v4.0-rc1 or try cherry-picking this on top of v3.19 and
> > report back:
> >
> > commit f9b61ff6bce9a44555324b29e593fdffc9a115bc
> > Author: Daniel Vetter 
> > Date:   Wed Jan 7 13:54:39 2015 +0100
> >
> > drm/i915: Push vblank enable/disable past encoder->enable/disable
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=89108
> 

Hi, Sitsofe,

you wrote in your bug report (#89108), that you've got a black screen, when you 
tried drm-intel-nightly branch.
Do you have black screen with v4.0-rc1 on your eeepc?
If so, is it similar to that I described here 
https://lkml.org/lkml/2015/2/3/594 ? 
As we both had drm_wait_one_vblank warnings, I assume that we have the same or 
similar chipsets.
And your black screen could be potentially the same as mine. 

-- 
Best regards,
Andrey Skvortsov

PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/0431062f/attachment-0001.sig>

[Bug 89034] Firefox crashing xserver and some major rendering bugs

[bugzilla-dae...@freedesktop.org]

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

--- Comment #29 from smoki  ---
(In reply to Tom Stellard from comment #28)

> Which piglit tests regress and what GPU do you have?

 Kabini. I did fresh piglit run now and it shows there are 159 regressed now...
too many to be listed so i upload html summary:

 https://dl.dropboxusercontent.com/u/74553632/compare.tar.bz2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/68ad38d4/attachment.html>

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

[Andrey Skvortsov]

> > > Those two warnings are more or less symptoms of the black screen (well
> > > the first is just overzealous). More important would be the drm.debug=6
> > > dmesg from boot along with the gdm.log (or equivalent) aned Xorg.0.log
> > > as my guess is that X (or the display server) is crashing.
> > 
> > Requested logs with drm.debug=6 are attached. lightdm was running after 
> > WARN_ON, but I couldn't restart it.
> > The command hanged.
> > 
> > As I booted next-20150202 system crashed several times with a lot of drm_ 
> > calls in the backtrace, but I couldn't catch kernel logs,
> > because I have not serial port on the laptop.
> > 
> > If you need to get other information or to test patches, I would be glad to 
> > help.
> 
> Right, here it looks like it freezing in intel_get_load_detect_pipe()
> during the initial configuration probe of X. Given the other crashes,
> we're back to worring about memory corruption.
> 
> > [   29.292333] [drm:intel_tv_detect] [CONNECTOR:33:SVIDEO-1] force=1
> > [   29.292336] [drm:intel_get_load_detect_pipe] [CONNECTOR:33:SVIDEO-1], 
> > [ENCODER:34:TV-34]
> > [   29.292339] [drm:intel_get_load_detect_pipe] creating tmp fb for 
> > load-detection
> > [   29.292396] [drm:intel_modeset_affected_pipes] set mode pipe masks: 
> > modeset: 1, prepare: 1, disable: 0
> > [   29.292408] [drm:connected_sink_compute_bpp] [CONNECTOR:33:SVIDEO-1] 
> > checking for sink bpp constrains
> > [   29.292413] [drm:intel_tv_compute_config] forcing bpc to 8 for TV
> > [   29.292416] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, 
> > dithering: 0
> > [   29.292418] [drm:intel_dump_pipe_config] [CRTC:20][modeset] config for 
> > pipe A
> > [   29.292419] [drm:intel_dump_pipe_config] cpu_transcoder: A
> > [   29.292421] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0
> > [   29.292423] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 
> > 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
> > [   29.292425] [drm:intel_dump_pipe_config] dp: 0, gmch_m: 0, gmch_n: 0, 
> > link_m: 0, link_n: 0, tu: 0
> > [   29.292428] [drm:intel_dump_pipe_config] dp: 0, gmch_m2: 0, gmch_n2: 0, 
> > link_m2: 0, link_n2: 0, tu2: 0
> > [   29.292429] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0
> > [   29.292431] [drm:intel_dump_pipe_config] requested mode:
> > [   29.292433] [drm:drm_mode_debug_printmodeline] Modeline 0:"NTSC 480i" 0 
> > 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0
> > [   29.292435] [drm:intel_dump_pipe_config] adjusted mode:
> > [   29.292438] [drm:drm_mode_debug_printmodeline] Modeline 0:"NTSC 480i" 0 
> > 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0
> > [   29.292440] [drm:intel_dump_crtc_timings] crtc timings: 108000 1280 1368 
> > 1496 1712 1024 1027 1034 1104, type: 0x40 flags: 0x0
> > [   29.292442] [drm:intel_dump_pipe_config] port clock: 108000
> > [   29.292444] [drm:intel_dump_pipe_config] pipe src size: 1280x1024
> > [   29.292446] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, 
> > ratios: 0x, lvds border: 0x
> > [   29.292447] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, 
> > size: 0x, disabled
> > [   29.292449] [drm:intel_dump_pipe_config] ips: 0
> > [   29.292451] [drm:intel_dump_pipe_config] double wide: 0
> > [   29.292565] [ cut here ]
> > [   29.293785] WARNING: CPU: 0 PID: 53 at include/linux/kref.h:47 
> > drm_framebuffer_reference+0x5b/0x64 [drm]()
> > [   29.295032] Modules linked in: bnep(E) cfg80211(E) cpufreq_stats(E) 
> > cpufreq_powersave(E) cpufreq_userspace(E) cpufreq_conservative(E) nfsd(E) 
> > auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) cdc_wdm(E) cdc_acm(E) 
> > cdc_ether(E) usbnet(E) joydev(E) coretemp(E) kvm_intel(E) kvm(E) i8k(E) 
> > btusb(E) psmouse(E) snd_pcsp(E) i915(E) evdev(E) bluetooth(E) i2c_i801(E) 
> > snd_hda_codec_generic(E) lpc_ich(E) mfd_core(E) xhci_pci(E) xhci_hcd(E) 
> > serio_raw(E) rfkill(E) drm_kms_helper(E) drm(E) i2c_algo_bit(E) i2c_core(E) 
> > snd_hda_intel(E) snd_hda_controller(E) snd_hda_codec(E) button(E) 
> > snd_hwdep(E) battery(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) 
> > video(E) ac(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) 
> > lp(E) parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) 
> > ata_generic(E)
> > [   29.295080]  ahci(E) libahci(E) ata_piix(E) libata(E) scsi_mod(E) b44(E) 
> > firewire_ohci(E) sdhci_pci(E) sdhci(E) firewire_core(E) crc_itu_t(E) mii(E) 
> > ssb(E) mmc_core(E) libphy(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) thermal(E) 
> > thermal_sys(E) usbcore(E) usb_common(E)
> > [   29.296301] CPU: 0 PID: 53 Comm: kworker/0:3 Tainted: GW   E   
> > 3.19.0-rc6-next-20150202-150201- #4
> > [   29.296303] Hardware name: Dell Inc. Vostro 1500 
> > /0NX907, BIOS A06 04/21/2008
> > [   29.296314] Workqueue: events output_poll_execute [drm_kms_helper]
> > [   29.296316]   0009 

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

[Andrey Skvortsov]

; ssb(E) mmc_core(E) libphy(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) thermal(E) 
> > thermal_sys(E) usbcore(E) usb_common(E)
> > [   29.296301] CPU: 0 PID: 53 Comm: kworker/0:3 Tainted: GW   E   
> > 3.19.0-rc6-next-20150202-150201- #4
> > [   29.296303] Hardware name: Dell Inc. Vostro 1500 
> > /0NX907, BIOS A06 04/21/2008
> > [   29.296314] Workqueue: events output_poll_execute [drm_kms_helper]
> > [   29.296316]   0009 813e790a 
> > 
> > [   29.296319]  8104178e 880197a38e40 a04eb56d 
> > 
> > [   29.296323]  880195844d80 0500 0400 
> > 
> > [   29.296326] Call Trace:
> > [   29.296332]  [] ? dump_stack+0x4a/0x74
> > [   29.296337]  [] ? warn_slowpath_common+0x9d/0xb5
> > [   29.296354]  [] ? drm_framebuffer_reference+0x5b/0x64 
> > [drm]
> > [   29.296368]  [] ? drm_framebuffer_reference+0x5b/0x64 
> > [drm]
> > [   29.296408]  [] ? 
> > intel_plane_duplicate_state+0x4d/0x69 [i915]
> > [   29.296415]  [] ? drm_plane_helper_update+0x61/0xff 
> > [drm_kms_helper]
> > [   29.296439]  [] ? __intel_set_mode+0x796/0x89a [i915]
> > [   29.296464]  [] ? intel_set_mode+0x6e/0x8f [i915]
> > [   29.296489]  [] ? 
> > intel_get_load_detect_pipe+0x382/0x420 [i915]
> > [   29.296517]  [] ? intel_tv_detect+0x116/0x43d [i915]
> > [   29.296522]  [] ? preempt_count_sub+0xab/0xca
> > [   29.296529]  [] ? 
> > drm_helper_probe_single_connector_modes_merge_bits+0xc7/0x392 
> > [drm_kms_helper]
> > [   29.296538]  [] ? 
> > drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper]
> > [   29.296545]  [] ? 
> > drm_fb_helper_hotplug_event+0x75/0xac [drm_kms_helper]
> > [   29.296551]  [] ? output_poll_execute+0x125/0x154 
> > [drm_kms_helper]
> > [   29.296555]  [] ? process_one_work+0x171/0x28e
> > [   29.296558]  [] ? worker_thread+0x1a5/0x272
> > [   29.296560]  [] ? process_scheduled_works+0x2a/0x2a
> > [   29.296564]  [] ? kthread+0x9e/0xa6
> > [   29.296567]  [] ? __kthread_parkme+0x5c/0x5c
> > [   29.296571]  [] ? ret_from_fork+0x7c/0xb0
> > [   29.296574]  [] ? __kthread_parkme+0x5c/0x5c
> > [   29.296576] ---[ end trace 4742dbfffee243fc ]---
> 
> Which makes me wonder whether this is not the more significant warning?
> -Chris

Hi, 

This warning is moved from linux-next to v4.0-rc1 now. After system boot is 
just a black screen.
I ssh'ed into the machine and saved the log. I attached updated dmesg.log with 
drm.debug=6. Hopefully it helps. 
If you need any other debug information, traces, core dump or something else. 
Feel free to ask.

-- 
Best regards,
Andrey Skvortsov

PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/9364bfd8/attachment-0001.sig>

[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank

[Andrey Skvortsov]

On Mon, Feb 23, 2015 at 02:45:26PM +0200, Jani Nikula wrote:
> On Mon, 16 Feb 2015, Paul Bolle  wrote:
> > I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K
> > lines in dmesg containing either "[drm" or this WARNING are pasted
> > below. I really know nothing about all this, but I do note that only the
> > WARNINGS are preceded by:
> > [drm:intel_calculate_wm] FIFO watermark level: -5
> > [drm:i9xx_update_wm] FIFO watermarks - A: 26, B: 8
> >
> > But perhaps that's another symptom of the same issue. A bit of staring
> > at the code couldn't help me determine that.
> >
> > Perhaps these debug messages help someone in discovering what might be
> > going on here.
> 
> Please try v4.0-rc1 or try cherry-picking this on top of v3.19 and
> report back:
> 
> commit f9b61ff6bce9a44555324b29e593fdffc9a115bc
> Author: Daniel Vetter 
> Date:   Wed Jan 7 13:54:39 2015 +0100
> 
> drm/i915: Push vblank enable/disable past encoder->enable/disable
> 
Hi, 

Can't test this on v4.0-rc1, because I get black screen unfortunatelly. 
But cherry-picking on v3.19 fixes all warnings drm_wait_one_vblank. 

-- 
Best regards,
Andrey Skvortsov

PGP Key ID: 0x57A3AEAD
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/611cf5fa/attachment.sig>

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #8 from Frederik vom Hofe  ---
Trying this did not fix it for me:
xrandr --output HDMI-0 --off; xrandr --output HDMI-0 --auto

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Alex Deucher  ---
Created attachment 113778
  --> https://bugs.freedesktop.org/attachment.cgi?id=113778=edit
set quantization_range in AVI infoframe if the monitor supports selectable
range

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/c73b5285/attachment.html>

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

Andy Furniss  changed:

   What|Removed |Added

 CC||adf.lists at gmail.com

--- Comment #7 from Andy Furniss  ---
(In reply to Frederik vom Hofe from comment #6)
> I bisected it to this change:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/
> ?id=baa7d8e451f030c049f83f943b9995620d6d6bd3

FWIW when I hit this issue I could "mend" it without using radeon.audio=0 - all
I had to do was use xrandr to do something that refreshed the display eg. off
then auto.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Andy Furniss  ---
(In reply to Alex Deucher from comment #6)
> (In reply to Andy Furniss from comment #5)
> > I see these are in your tree now - a question: what does tvrgb do?
> > 
> > By which I mean does it just "tell" the TV via hdmi info that the signal is
> > limited or does it do more eg. scale so it really is limited between 16 &
> > 235?
> 
> The latter.

OK, thanks, so it doesn't signal just scales - which makes me wonder if TVs
would behave differently if it did - but then I don't know if the normal case
actually signals full range - and if it doesn't what TVs assume by default.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/969dcfb6/attachment.html>

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #6 from frederik.hofe at gmail.com ---
I bisected it to this change:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=baa7d8e451f030c049f83f943b9995620d6d6bd3

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [Regression] WARNING: drivers/gpu/drm/i915/i915_gem.c:4525 i915_gem_free_object

[Chris Wilson]

On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote:
> Hi, 
> 
> This warning is moved from linux-next to v4.0-rc1 now. After system boot is 
> just a black screen.
> I ssh'ed into the machine and saved the log. I attached updated dmesg.log 
> with drm.debug=6. Hopefully it helps. 
> If you need any other debug information, traces, core dump or something else. 
> Feel free to ask.

The warning from free_object is annoying (and quite possibly dangerous),
but the actual hang during boot is:

[  243.876375] INFO: task Xorg:2422 blocked for more than 120 seconds.
[  243.876382]   Tainted: GW   E   4.0.0-rc1-150223- #2
[  243.876388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  243.876393] XorgD 88019fc12dc0 0  2422   2180 0x0040
[  243.876404]  8800dabfe1a0 0002 880194537fd8 
880194537ba0
[  243.876416]  8800dab9e22c 8800dabfe1a0 8800dab9e230 

[  243.876426]  813e2479 8800dab9e228 813e26a7 

[  243.876438] Call Trace:
[  243.876449]  [] ? schedule+0x6f/0x7c
[  243.876459]  [] ? schedule_preempt_disabled+0x15/0x21
[  243.876469]  [] ? __ww_mutex_lock_slowpath+0xdf/0x1c2
[  243.876480]  [] ? __ww_mutex_lock+0x1c/0x93
[  243.876541]  [] ? modeset_lock+0x8f/0xf2 [drm]
[  243.876632]  [] ? intel_get_load_detect_pipe+0x80/0x427 
[i915]
[  243.876674]  [] ? drm_ut_debug_printk+0x5e/0x63 [drm]
[  243.876771]  [] ? intel_tv_detect+0x115/0x43a [i915]
[  243.876783]  [] ? preempt_count_sub+0xbf/0xca
[  243.876809]  [] ? 
drm_helper_probe_single_connector_modes_merge_bits+0xc6/0x38d [drm_kms_helper]
[  243.876860]  [] ? drm_mode_getconnector+0xf4/0x2ac [drm]
[  243.876900]  [] ? drm_ioctl+0x338/0x3c5 [drm]
[  243.876949]  [] ? drm_mode_getcrtc+0xb3/0xb3 [drm]
[  243.876961]  [] ? fsnotify+0x314/0x35d
[  243.876973]  [] ? do_vfs_ioctl+0x379/0x431
[  243.876983]  [] ? SyS_ioctl+0x56/0x7c
[  243.876994]  [] ? system_call_fastpath+0x12/0x17

i.e. it is a mutex deadlock inside tv detect. Daniel does that make sense?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from Alex Deucher  ---
(In reply to Andy Furniss from comment #5)
> I see these are in your tree now - a question: what does tvrgb do?
> 
> By which I mean does it just "tell" the TV via hdmi info that the signal is
> limited or does it do more eg. scale so it really is limited between 16 &
> 235?

The latter.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/0962987c/attachment.html>

[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

[bugzilla-dae...@freedesktop.org]

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

Andy Furniss  changed:

   What|Removed |Added

 CC||adf.lists at gmail.com

--- Comment #5 from Andy Furniss  ---
I see these are in your tree now - a question: what does tvrgb do?

By which I mean does it just "tell" the TV via hdmi info that the signal is
limited or does it do more eg. scale so it really is limited between 16 & 235?

It's a bit hard to tell by testing as it could just be the way my TV behaves -
it looks scaled judging by how much I have to alter black level but IIRC the
HDMI/CEA specs say that all but 0 and 255 are still legal in limited range to
allow for sub/super that occurs "naturally" in video and sub in a pluge for
proper black level setup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/04e4e53d/attachment.html>

[Bug 89286] Xorg SEGFAULT on 3d/glx related application

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 89286
   Summary: Xorg SEGFAULT on 3d/glx related application
   Product: Mesa
   Version: 10.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: fdo at won2.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 113766
  --> https://bugs.freedesktop.org/attachment.cgi?id=113766=edit
kernel dmesg

I have a debian jessie install and Xorg segfaults on any 3d/glx related
application. The application works (i.e. 3D rendering works) but on process
exit Xorg crashes. I'm using a custom 3D app, but this also happens with a
simple "glxinfo" on exit.

I have gdb'ed it for a stacktrace:

#0  0x0020 in ?? ()
#1  0x70b66f62 in pb_get_base_buffer (offset=0x7fffd83c,
base_buf=0x7fffd840, buf=) at
../../../../../../../src/gallium/auxiliary/pipebuffer/pb_buffer.h:197
#2  get_radeon_bo (_buf=) at
../../../../../../../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:96
#3  0x70b674e3 in radeon_bo_get_tiling (_buf=,
microtiled=0x7fffd908, macrotiled=0x7fffd90c, bankw=0x7fffd950,
bankh=0x7fffd954, tile_split=0x7fffd95c, 
stencil_tile_split=0x7fffd960, mtilea=0x7fffd958,
scanout=0x7fffd903) at
../../../../../../../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:690
#4  0x70b788f2 in r600_texture_from_handle (screen=0x559fa640,
templ=0x7fffe6d0, whandle=) at
../../../../../../src/gallium/drivers/radeon/r600_texture.c:826
#5  0x70953bcf in dri2_create_image_from_winsys (_screen=, width=1280, height=1024, format=4099,
whandle=whandle at entry=0x7fffe760, pitch=1280, loaderPrivate=0x0)
at ../../../../../../src/gallium/state_trackers/dri/dri2.c:733
#6  0x70953df8 in dri2_create_image_from_name (_screen=,
width=, height=, format=,
name=, pitch=, loaderPrivate=0x0)
at ../../../../../../src/gallium/state_trackers/dri/dri2.c:759
#7  0x7fffecfa220c in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
#8  0x7fffecf968e7 in eglCreateImageKHR () from
/usr/lib/x86_64-linux-gnu/libEGL.so.1
#9  0x71d8ee14 in _glamor_egl_create_image (glamor_egl=,
glamor_egl=, depth=, name=1, stride=, height=, width=)
at ../../../../glamor/glamor_egl.c:137
#10 glamor_egl_create_textured_pixmap (pixmap=pixmap at entry=0x5652a8a0,
handle=handle at entry=45, stride=stride at entry=5120) at
../../../../glamor/glamor_egl.c:302
#11 0x71d8f03d in glamor_egl_create_textured_screen
(screen=screen at entry=0x560fcc50, handle=handle at entry=45,
stride=stride at entry=5120) at ../../../../glamor/glamor_egl.c:232
#12 0x71d8f13d in glamor_egl_create_textured_screen_ext
(screen=screen at entry=0x560fcc50, handle=45, stride=5120,
back_pixmap=back_pixmap at entry=0x0) at ../../../../glamor/glamor_egl.c:254
#13 0x7222f48c in radeon_glamor_create_screen_resources
(screen=screen at entry=0x560fcc50) at ../../src/radeon_glamor.c:67
#14 0x72227e0a in RADEONCreateScreenResources_KMS
(pScreen=0x560fcc50) at ../../src/radeon_kms.c:258
#15 0x556204de in xf86CrtcCreateScreenResources (screen=0x560fcc50)
at ../../../../hw/xfree86/modes/xf86Crtc.c:709
#16 0x555af456 in dix_main (argc=3, argv=0x7fffebf8,
envp=) at ../../dix/main.c:223
#17 0x75d15b45 in __libc_start_main (main=0x555998e0 ,
argc=3, argv=0x7fffebf8, init=, fini=,
rtld_fini=, stack_end=0x7fffebe8) at libc-start.c:287
#18 0x5559990e in _start ()

It's a dual CPU Xeon E5 server with a onboard matrox card:
# lspci |grep VGA
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland
PRO [Radeon R7 240]
07:01.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200eW
WPCM450 (rev 0a)

I have Xorg 7.7+7, that is xserver 1.16.4, there's no old glamor package flying
around (as asked on IRC). It's mesa 10.3.2-1, kernel 3.16.0-4-amd64.

I had to create a xorg.conf so the driver will load/find my card. It looks like
this:

Section "Device"
Identifier  "radeon"
Driver  "radeon"
BusID   "PCI:03:00:0"
EndSection

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/da1a3ad8/attachment.html>

[Bug 89256] [radeonsi][CSGO] many rendering artifacts and more

[bugzilla-dae...@freedesktop.org]

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

Sylvain BERTRAND  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #4 from Sylvain BERTRAND  ---
Sorry, cannot build easily mesa git on fedora rawhide for x86_64 and x86. Some
dark kludge related to llvm blocked it (got some troubles with some "python
mako" stuff too). I would need to build manually a near whole devel graphic
stack on
the side with all SDK dependencies.

Have to wait for fedora to sort out their kludgy kludge llvm mess or pray for a
fedora recent mesa update with the above patch.

Leave that bug be. Once I have a reasonable way to test mesa git, I'll come
back. (hope the fedora guys will provide a mesa update before me finishing my
distro).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/af68d379/attachment.html>

[PATCH 3/4] drm/rcar-du: use for_each_endpoint_of_node macro

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

On Monday 23 February 2015 17:34:28 Philipp Zabel wrote:
> Using the for_each_... macro should make the code a bit shorter and
> easier to read.
> 
> Signed-off-by: Philipp Zabel 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 68dab26..c235074 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -224,12 +224,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu,
> 
>   entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
> 
> - while (1) {
> - ep_node = of_graph_get_next_endpoint(entity, ep_node);
> -
> - if (!ep_node)
> - break;
> -
> + for_each_endpoint_of_node(entity, ep_node) {
>   if (ep_node == entity_ep_node)
>   continue;
> 
> @@ -296,24 +291,19 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, static int rcar_du_encoders_init(struct
> rcar_du_device *rcdu)
>  {
>   struct device_node *np = rcdu->dev->of_node;
> - struct device_node *ep_node = NULL;
> + struct device_node *ep_node;
>   unsigned int num_encoders = 0;
> 
>   /*
>* Iterate over the endpoints and create one encoder for each output
>* pipeline.
>*/
> - while (1) {
> + for_each_endpoint_of_node(np, ep_node) {
>   enum rcar_du_output output;
>   struct of_endpoint ep;
>   unsigned int i;
>   int ret;
> 
> - ep_node = of_graph_get_next_endpoint(np, ep_node);
> -
> - if (ep_node == NULL)
> - break;
> -
>   ret = of_graph_parse_endpoint(ep_node, );
>   if (ret < 0) {
>   of_node_put(ep_node);

-- 
Regards,

Laurent Pinchart

[Bug 89034] Firefox crashing xserver and some major rendering bugs

[bugzilla-dae...@freedesktop.org]

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

--- Comment #28 from Tom Stellard  ---
(In reply to smoki from comment #26)
>  @ Lorenzo Bona
> 
>  That is for SI, i am on CIK... this issue whole another one, probably
> affect all chips.
> 
>  @Tom
> 
>  There are also ~140 piglit quick tests failed once subreg liveness is
> enabled.

Which piglit tests regress and what GPU do you have?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/c256fbd0/attachment.html>

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #5 from frederik.hofe at gmail.com ---
Booting with radeon.audio=0 removes this phenomena.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #4 from frederik.hofe at gmail.com ---
Created attachment 168071
  --> https://bugzilla.kernel.org/attachment.cgi?id=168071=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #3 from frederik.hofe at gmail.com ---
Created attachment 168061
  --> https://bugzilla.kernel.org/attachment.cgi?id=168061=edit
dmesg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 4/4] drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on break

[Philipp Zabel]

Using the for_each_... macro should make the code a bit shorter and
easier to read. Also, when breaking out of the loop, the endpoint node
reference count needs to be decremented.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 21a481b..9bb4fd2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -366,7 +366,7 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
 int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder)
 {
-   struct device_node *ep = NULL;
+   struct device_node *ep;
struct drm_crtc *crtc = encoder->crtc;
struct of_endpoint endpoint;
struct device_node *port;
@@ -375,18 +375,15 @@ int rockchip_drm_encoder_get_mux_id(struct device_node 
*node,
if (!node || !crtc)
return -EINVAL;

-   do {
-   ep = of_graph_get_next_endpoint(node, ep);
-   if (!ep)
-   break;
-
+   for_each_endpoint_of_node(node, ep) {
port = of_graph_get_remote_port(ep);
of_node_put(port);
if (port == crtc->port) {
ret = of_graph_parse_endpoint(ep, );
+   of_node_put(ep);
return ret ?: endpoint.id;
}
-   } while (ep);
+   }

return -EINVAL;
 }
-- 
2.1.4

[PATCH 3/4] drm/rcar-du: use for_each_endpoint_of_node macro

[Philipp Zabel]

Using the for_each_... macro should make the code a bit shorter and
easier to read.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 68dab26..c235074 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -224,12 +224,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,

entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);

-   while (1) {
-   ep_node = of_graph_get_next_endpoint(entity, ep_node);
-
-   if (!ep_node)
-   break;
-
+   for_each_endpoint_of_node(entity, ep_node) {
if (ep_node == entity_ep_node)
continue;

@@ -296,24 +291,19 @@ static int rcar_du_encoders_init_one(struct 
rcar_du_device *rcdu,
 static int rcar_du_encoders_init(struct rcar_du_device *rcdu)
 {
struct device_node *np = rcdu->dev->of_node;
-   struct device_node *ep_node = NULL;
+   struct device_node *ep_node;
unsigned int num_encoders = 0;

/*
 * Iterate over the endpoints and create one encoder for each output
 * pipeline.
 */
-   while (1) {
+   for_each_endpoint_of_node(np, ep_node) {
enum rcar_du_output output;
struct of_endpoint ep;
unsigned int i;
int ret;

-   ep_node = of_graph_get_next_endpoint(np, ep_node);
-
-   if (ep_node == NULL)
-   break;
-
ret = of_graph_parse_endpoint(ep_node, );
if (ret < 0) {
of_node_put(ep_node);
-- 
2.1.4

[PATCH 2/4] drm/imx: use for_each_endpoint_of_node macro in imx_drm_encoder_get_mux_id

[Philipp Zabel]

Using the for_each_... macro should make the code bit shorter and
easier to read. This patch also properly decrements the endpoint node
reference count before returning out of the loop.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 84cf99f..3da9cc5 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -447,18 +447,15 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
if (!node || !imx_crtc)
return -EINVAL;

-   do {
-   ep = of_graph_get_next_endpoint(node, ep);
-   if (!ep)
-   break;
-
+   for_each_endpoint_of_node(node, ep) {
port = of_graph_get_remote_port(ep);
of_node_put(port);
if (port == imx_crtc->crtc->port) {
ret = of_graph_parse_endpoint(ep, );
+   of_node_put(ep);
return ret ? ret : endpoint.port;
}
-   } while (ep);
+   }

return -EINVAL;
 }
-- 
2.1.4

[PATCH 1/4] drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs

[Philipp Zabel]

Using the for_each_... macro should make the code a bit shorter and
easier to read.

Signed-off-by: Philipp Zabel 
Acked-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_of.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 16150a0..aaa1307 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -43,14 +43,10 @@ static uint32_t drm_crtc_port_mask(struct drm_device *dev,
 uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port)
 {
-   struct device_node *remote_port, *ep = NULL;
+   struct device_node *remote_port, *ep;
uint32_t possible_crtcs = 0;

-   do {
-   ep = of_graph_get_next_endpoint(port, ep);
-   if (!ep)
-   break;
-
+   for_each_endpoint_of_node(port, ep) {
remote_port = of_graph_get_remote_port(ep);
if (!remote_port) {
of_node_put(ep);
@@ -60,7 +56,7 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
possible_crtcs |= drm_crtc_port_mask(dev, remote_port);

of_node_put(remote_port);
-   } while (1);
+   }

return possible_crtcs;
 }
-- 
2.1.4

[PATCH 0/4] drm: use for_each_endpoint_of_node macro

[Philipp Zabel]

Hi,

once the "Add of-graph helpers to loop over endpoints and find ports by id"
series [1] gets merged, these patches simplify the common case of looping
over all of graph endpoints in a device node.

[1] https://lkml.org/lkml/2015/2/23/115

regards
Philipp

Philipp Zabel (4):
  drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs
  drm/imx: use for_each_endpoint_of_node macro in
imx_drm_encoder_get_mux_id
  drm/rcar-du: use for_each_endpoint_of_node macro
  drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint
reference on break

 drivers/gpu/drm/drm_of.c| 10 +++---
 drivers/gpu/drm/imx/imx-drm-core.c  |  9 +++--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 16 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 11 ---
 4 files changed, 13 insertions(+), 33 deletions(-)

-- 
2.1.4

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #2 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Can you bisect?  Does disabling audio fix it?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 93701] New: radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

Bug ID: 93701
   Summary: radeon: two "empty" pixel lines on left side of
screen, rest of screen gets slightly squished
   Product: Drivers
   Version: 2.5
Kernel Version: 4.0-rc1
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: frederik.hofe at gmail.com
Regression: No

This happens in the current 4.0-rc1. 3.19 does not show this.

Basicly it looks like my resolution of 1920x1080 gets blitted into 1918,1080
with linear filtering somewhere before it gets on my screen.

When I take a screenshot with gimp, I get a normal 1920x1080 image without the
defect.

I use a Radeon 7870 (Pitcairn) -> HDMI -> Samsung S22A350H

Also I use the padoka PPA for bleeding edge mesa/llvm drivers.

glxinfo|grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.0-devel
(padoka PPA)
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.6.0-devel (padoka PPA)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.6.0-devel (padoka PPA)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] DRM: i.MX: parallel display: Support probe deferral for finding DRM panel

[Philipp Zabel]

Hi,

Am Montag, den 23.02.2015, 11:09 +0800 schrieb Liu Ying:
> Signed-off-by: Liu Ying 

thank you for the patch. I've applied it to my branch.

> ---
>  drivers/gpu/drm/imx/parallel-display.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imx/parallel-display.c 
> b/drivers/gpu/drm/imx/parallel-display.c
> index 5e83e00..900dda6 100644
> --- a/drivers/gpu/drm/imx/parallel-display.c
> +++ b/drivers/gpu/drm/imx/parallel-display.c
> @@ -236,8 +236,11 @@ static int imx_pd_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>  
>   panel_node = of_parse_phandle(np, "fsl,panel", 0);

This property is not documented anywhere and I'd like to get rid of this
in the future. This should be replaced with of graph endpoint links.

regards
Philipp

[PATCH v8 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint

[Laurent Pinchart]

Hi Philipp,

Thank you for the patch.

Benoit, please see below for a possible issue in the am437x-vpfe driver.

On Monday 23 February 2015 11:54:04 Philipp Zabel wrote:
> Decrementing the reference count of the previous endpoint node allows to
> use the of_graph_get_next_endpoint function in a for_each_... style macro.
> All current users of this function that pass a non-NULL prev parameter
> (that is, soc_camera and imx-drm) are changed to not decrement the passed
> prev argument's refcount themselves.
> 
> Signed-off-by: Philipp Zabel 
> Acked-by: Mauro Carvalho Chehab 
> Acked-by: Mathieu Poirier 
> Acked-by: Laurent Pinchart 
> Acked-by: Tomi Valkeinen 
> ---
> Changes since v7:
>  - Rebased onto v4.0-rc1
>  - Added fix for am437x-vpfe
> ---
>  drivers/coresight/of_coresight.c  | 13 ++---
>  drivers/gpu/drm/imx/imx-drm-core.c| 11 +--
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 ---
>  drivers/media/platform/am437x/am437x-vpfe.c   |  1 -
>  drivers/media/platform/soc_camera/soc_camera.c|  3 ++-
>  drivers/of/base.c |  9 +
>  drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |  7 +--
>  7 files changed, 11 insertions(+), 48 deletions(-)

[snip]

> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c index 56a5cb0..0d07fca 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2504,7 +2504,6 @@ vpfe_get_pdata(struct platform_device *pdev)
>GFP_KERNEL);
>   pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_OF;
>   pdata->asd[i]->match.of.node = rem;
> - of_node_put(endpoint);
>   of_node_put(rem);
>   }

For the am47x-vpfe driver,

Acked-by: Laurent Pinchart 

Benoit, there seems to be a refcount issue with rem. The node pointer is 
assigned to pdata->asd[i]->match.of.node, which should require a reference, 
but you then call of_node_put(rem), releasing the only reference held. Isn't 
that a problem ?

Furthermore, on the next iteration, if an error occurs the goto done will 
result in of_node_put(rem) being called again, releasing a reference that you 
don't hold. I've sent a patch to fix that.

-- 
Regards,

Laurent Pinchart

[PATCH] drm: msm: Fix build when legacy fbdev support isn't set

[Daniel Vetter]

On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter  wrote:
> > On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
> >> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja  
> >> wrote:
> >> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config 
> >> > is
> >> > selected. The driver accesses drm_fb_helper_* functions even when legacy 
> >> > fbdev
> >> > support is disabled in msm. Wrap around these functions with #ifdef 
> >> > checks to
> >> > prevent build break.
> >>
> >> hmm, perhaps rather than solving this in each driver, we should do
> >> some stub versions of those fb-helper fxns?
> >>
> >> There are at least one or two other drivers that can build without
> >> fbdev, and I guess more going forward..
> >
> > It's not quite that easy since you also have to start/stop the vt
> > subsystem at the right point in time in your own driver. See
> > intel_fbdev_set_suspend. If you don't do that there's no synchronization
> > between fbcon shutting down/resuming and your driver, which in the best
> > case means fbcon does some writes to nowhere and worst case means your
> > chip dies (mmio to offline chip blocks) or writes go to somewhere random
> > in system memory (iommu contains some stale ptes since not yet fully
> > restored, more an issue with hibernate).
> 
> I guess I don't fully follow the vt/fbcon interaction if there is no
> fbdev driver...  but then again I don't have vesafb/efifb to contend
> with, so I'm assuming something to do with that..

It's the other way round: There's interaction when we have fbdev enabled
beyond just calling a few fbdev helper functions. And we should compile
that out too since the console_lock is way too evil ;-)

Only with these additional #ifdefs is i915 completely console_lock free if
you disable i915 fbdev support. Just stubbing out the fbdev helper
functions is not enough.

> > And because the console_lock is massively contended we do that in a async
> > worker in i915.
> >
> > But anyway I agree it would still simply drivers quite a bit if we'd have
> > support for dummy fb helpers in the core, maybe with an explicit Kconfig.
> > Then drivers could switch to using that for the additional #ifdef (like
> > the vt stuff i915 does) and otherwise rely upon dummy static inline. That
> > would give us fbdev-less support for most drivers for free, which is kinda
> > neat.
> 
> I guess at least for all the arm drivers, life without fbdev doesn't
> have these extra complications, so at least they could use stubs..

Does the problem sound more tricky with the above clarification? If you
don't do the fb_set_suspend call then I expect you'll have some
interesting problems.

> Plus, I kind of expect phone/tablet/chromebook type stuff would lead
> the charge into an fbdev-less world..

Yeah, that's another reason to support fbdev-less in the helpers instead
of each driver.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Alex Deucher  ---
Created attachment 113758
  --> https://bugs.freedesktop.org/attachment.cgi?id=113758=edit
patch 2/2

Please apply both patches.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/9c10a2af/attachment-0001.html>

[Bug 83226] Allow use of ColorRange and ColorSpace in xorg.conf.d files

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Alex Deucher  ---
Created attachment 113757
  --> https://bugs.freedesktop.org/attachment.cgi?id=113757=edit
patch 1/2

These two patches implement support for this on DCE5+ hardware via the
output_csc property.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/f810c554/attachment.html>

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

[bugzilla-dae...@freedesktop.org]

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #82 from Alex Deucher  ---
Everything is upstream now in kernel 4.0.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/07a5110b/attachment.html>

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

[bugzilla-dae...@freedesktop.org]

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

--- Comment #81 from !evil  ---
I just tried kernel v4.0rc1 and my R9 280 is quiet :)
Thank you !!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/c1327f35/attachment.html>

[PATCH] drm: msm: Fix build when legacy fbdev support isn't set

[Archit Taneja]

The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev
support is disabled in msm. Wrap around these functions with #ifdef checks to
prevent build break.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index a426911..f15494c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -21,9 +21,11 @@

 static void msm_fb_output_poll_changed(struct drm_device *dev)
 {
+#ifdef CONFIG_DRM_MSM_FBDEV
struct msm_drm_private *priv = dev->dev_private;
if (priv->fbdev)
drm_fb_helper_hotplug_event(priv->fbdev);
+#endif
 }

 static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -373,9 +375,11 @@ static void msm_preclose(struct drm_device *dev, struct 
drm_file *file)

 static void msm_lastclose(struct drm_device *dev)
 {
+#ifdef CONFIG_DRM_MSM_FBDEV
struct msm_drm_private *priv = dev->dev_private;
if (priv->fbdev)
drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
+#endif
 }

 static irqreturn_t msm_irq(int irq, void *arg)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Bug 89282] new error messages 4.0-rc1 kernel

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output and xorg log.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/1e456105/attachment.html>

[PATCH] drm: msm: Fix build when legacy fbdev support isn't set

[Daniel Vetter]

On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja  
> wrote:
> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
> > selected. The driver accesses drm_fb_helper_* functions even when legacy 
> > fbdev
> > support is disabled in msm. Wrap around these functions with #ifdef checks 
> > to
> > prevent build break.
> 
> hmm, perhaps rather than solving this in each driver, we should do
> some stub versions of those fb-helper fxns?
> 
> There are at least one or two other drivers that can build without
> fbdev, and I guess more going forward..

It's not quite that easy since you also have to start/stop the vt
subsystem at the right point in time in your own driver. See
intel_fbdev_set_suspend. If you don't do that there's no synchronization
between fbcon shutting down/resuming and your driver, which in the best
case means fbcon does some writes to nowhere and worst case means your
chip dies (mmio to offline chip blocks) or writes go to somewhere random
in system memory (iommu contains some stale ptes since not yet fully
restored, more an issue with hibernate).

And because the console_lock is massively contended we do that in a async
worker in i915.

But anyway I agree it would still simply drivers quite a bit if we'd have
support for dummy fb helpers in the core, maybe with an explicit Kconfig.
Then drivers could switch to using that for the additional #ifdef (like
the vt stuff i915 does) and otherwise rely upon dummy static inline. That
would give us fbdev-less support for most drivers for free, which is kinda
neat.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/3] drm/panel: Add display_timing support

[Philipp Zabel]

Hi Thierry,

do you have any further thoughts on this?

Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding:
> On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote:
> > Many panel data sheets additionally to typical values list allowed ranges 
> > for
> > timings such as hsync/vsync lengths, porches, and the pixel clock rate. 
> > These
> > can be stored in a struct display_timing, to be used by an encoder 
> > mode_fixup
> > callback to clamp user provided timing values or to validate workarounds for
> > clock source limitations.
> > 
> > This patch adds a new drm_panel_funcs callback that returns the panels'
> > available display_timing entries.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  include/drm/drm_panel.h | 5 +
> >  1 file changed, 5 insertions(+)
> 
> Sorry for taking so long to get back on this. I generally like the idea,
> though a couple of things are unclear to me.
> 
> In struct display_timing we have:
> 
>   struct timing_entry hactive;
>   ...
>   struct timing_entry vactive;
> 
> I wonder if that really makes sense. Are there really datasheets that
> provide a valid range for the number of horizontal and vertical active
> pixels?

I could send a patch to change hactive/vactive to a single value
and change Documentation/devicetree/bindings/video/display-timing.txt
to clarify ranges are not allowed for these properties until somebody
digs out a panel that actually needs this.
Adding Steffen to Cc: in case there was a reason other than symmetry.

> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index 1fbcc96..13ff44b 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -29,6 +29,7 @@
> >  struct drm_connector;
> >  struct drm_device;
> >  struct drm_panel;
> > +struct display_timing;
> >  
> >  /**
> >   * struct drm_panel_funcs - perform operations on a given panel
> > @@ -38,6 +39,8 @@ struct drm_panel;
> >   * @enable: enable panel (turn on back light, etc.)
> >   * @get_modes: add modes to the connector that the panel is attached to and
> >   * return the number of modes added
> > + * @get_timings: copy display timings into the provided array and return
> > + * the number of display timings available
> >   *
> >   * The .prepare() function is typically called before the display 
> > controller
> >   * starts to transmit video data. Panel drivers can use this to turn the 
> > panel
> > @@ -68,6 +71,8 @@ struct drm_panel_funcs {
> > int (*prepare)(struct drm_panel *panel);
> > int (*enable)(struct drm_panel *panel);
> > int (*get_modes)(struct drm_panel *panel);
> > +   int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
> > +  struct display_timing *timings);
> 
> Also are there even panels that support more than one set of timings?
> I've never heard of panels that are actually able to do more than one
> mode, so I'm wondering if num_timings isn't overdoing it a little here.
> I guess it doesn't hurt all that much, though.

Would you prefer
struct display_timing *(*get_timing)(struct drm_panel *panel);
?

regards
Philipp

[PATCH libdrm v2] drm: add drmGet(Master|Render)NameFrom(Render|Master)FD functions

[Emil Velikov]

On 23 February 2015 at 14:35, Frank Binns  wrote:
> Hi Emil,
>
> On 23/02/15 12:22, Emil Velikov wrote:
>> Currently most places assume reliable master <> render node mapping.
>> Although this may work in some cases, it is not correct.
>>
>> Add a couple of helpers that hide the details and provide the name of
>> the master/render device name, given an render/master FD.
>>
>> v2:
>>  - Rename Device and Primary to Master (aka the /dev/dri/cardX device).
>>  - Check for the file via readdir_r() rather than stat().
>>  - Wrap the check into a single function.
>>  - Return NULL for non-linux platforms.
>>
>> Cc: Frank Binns 
>> Cc: Daniel Vetter 
>> Cc: David Herrmann 
>> Signed-off-by: Emil Velikov 
>> ---
>>  xf86drm.c | 82 
>> +++
>>  xf86drm.h |  3 +++
>>  2 files changed, 85 insertions(+)
>>
>> diff --git a/xf86drm.c b/xf86drm.c
>> index e117bc6..d4a4dc6 100644
>> --- a/xf86drm.c
>> +++ b/xf86drm.c
>> @@ -40,6 +40,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -522,6 +524,20 @@ static int drmGetMinorType(int minor)
>>  }
>>  }
>>
>> +static const char *drmGetMinorName(int type)
>> +{
>> +switch (type) {
>> +case DRM_NODE_PRIMARY:
>> +return "card";
>> +case DRM_NODE_CONTROL:
>> +return "controlD";
>> +case DRM_NODE_RENDER:
>> +return "renderD";
>> +default:
>> +return NULL;
>> +}
>> +}
>> +
>>  /**
>>   * Open the device by bus ID.
>>   *
>> @@ -2736,3 +2752,69 @@ int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t 
>> *handle)
>>   return 0;
>>  }
>>
>> +static char *drmGetMinorNameForFD(int fd, int type)
>> +{
>> +#ifdef __linux__
>> + DIR *sysdir;
>> + struct dirent *pent, *ent;
>> + struct stat sbuf;
>> + const char *name = drmGetMinorName(type);
>> + const int len = strlen(name);
> This will cause a segfault if 'name' is NULL.
>
>> + char dev_name[64], buf[64];
>> + long name_max;
>> + int maj, min;
>> +
>> + if (!name)
>> + return NULL;
>> +
>> + if (fstat(fd, ))
>> + return NULL;
>> +
>> + maj = major(sbuf.st_rdev);
>> + min = minor(sbuf.st_rdev);
>> +
>> + if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
>> + return NULL;
>> +
>> + snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min);
>> +
>> + sysdir = opendir(buf);
>> + if (!sysdir)
>> + return NULL;
>> +
>> + name_max = fpathconf(dirfd(sysdir), _PC_NAME_MAX);
>> + if (name_max == -1)
>> + goto out_close_dir;
>> +
>> + pent = malloc(offsetof(struct dirent, d_name) + name_max + 1);
>> + if (pent == NULL)
>> +  goto out_close_dir;
>> +
>> + while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
>> + if (strncmp(ent->d_name, name, len) == 0) {
>> + free(pent);
>> + closedir(sysdir);
>> +
>> + snprintf(dev_name, sizeof(dev_name), DRM_DIR_NAME 
>> "/%s",
>> +  ent->d_name);
>> + return strdup(dev_name);
>> + }
>> + }
>> +
>> + free(pent);
>> +
>> +out_close_dir:
>> + closedir(sysdir);
>> +#endif
>> + return NULL;
>> +}
>> +
>> +char *drmGetMasterNameFromRenderFD(int fd)
> I think drmGetPrimaryDeviceNameFromFd would be more appropriate given
> the node type is 'primary',
Most places that I've seen call "/dev/dri/cardX" master node, although
with the introduction of DRM_NODE_PRIMARY I believe your suggestion
may be better.

> the type of the fd doesn't matter afaics and
> for consistency with other drmGet* functions. However, given that's a
> bit of a mouthful I guess the 'Device' part could be dropped.
>
I was thinking about this initially then decided to keep the
Render/MasterFD explicit. Mainly because I'm don't know how cumbersome
the *BSD implementation will be.

But with that said it none of the BSD guys objects within 1-2 weeks
I'll go with your suggestion.

Thanks
Emil

[Bug 89282] new error messages 4.0-rc1 kernel

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 89282
   Summary: new error messages 4.0-rc1 kernel
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: jarkko_korpi at hotmail.com
QA Contact: dri-devel at lists.freedesktop.org

[   17.407579] [drm] VGACON disable radeon kernel modesetting.
[   17.407597] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon
module!


I don't know if those have impact, but they have never been there before.

r9 290

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/c5575180/attachment.html>

[PATCH libdrm 4/4] tests/radeon: set the list* functions as inline

[Emil Velikov]

To silence the chatty compiler.
As a future work we may want to merge these with libdrm_lists.h

Cc: Jerome Glisse 
Signed-off-by: Emil Velikov 
---
 tests/radeon/list.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/radeon/list.h b/tests/radeon/list.h
index 305c903..27e0761 100644
--- a/tests/radeon/list.h
+++ b/tests/radeon/list.h
@@ -44,13 +44,13 @@ struct list_head
 struct list_head *next;
 };

-static void list_inithead(struct list_head *item)
+static inline void list_inithead(struct list_head *item)
 {
 item->prev = item;
 item->next = item;
 }

-static void list_add(struct list_head *item, struct list_head *list)
+static inline void list_add(struct list_head *item, struct list_head *list)
 {
 item->prev = list;
 item->next = list->next;
@@ -58,7 +58,7 @@ static void list_add(struct list_head *item, struct list_head 
*list)
 list->next = item;
 }

-static void list_addtail(struct list_head *item, struct list_head *list)
+static inline void list_addtail(struct list_head *item, struct list_head *list)
 {
 item->next = list;
 item->prev = list->prev;
@@ -66,7 +66,7 @@ static void list_addtail(struct list_head *item, struct 
list_head *list)
 list->prev = item;
 }

-static void list_replace(struct list_head *from, struct list_head *to)
+static inline void list_replace(struct list_head *from, struct list_head *to)
 {
 to->prev = from->prev;
 to->next = from->next;
@@ -74,13 +74,13 @@ static void list_replace(struct list_head *from, struct 
list_head *to)
 from->prev->next = to;
 }

-static void list_del(struct list_head *item)
+static inline void list_del(struct list_head *item)
 {
 item->prev->next = item->next;
 item->next->prev = item->prev;
 }

-static void list_delinit(struct list_head *item)
+static inline void list_delinit(struct list_head *item)
 {
 item->prev->next = item->next;
 item->next->prev = item->prev;
-- 
2.3.0

[PATCH libdrm 3/4] exynos_fimg2d_test: remove unused function connector_find_plane()

[Emil Velikov]

Cc: Inki Dae 
Cc: Kyungmin Park 
Signed-off-by: Emil Velikov 
---
 tests/exynos/exynos_fimg2d_test.c | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index 17e8e53..dc7c5cb 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -142,37 +142,6 @@ static void connector_find_mode(int fd, struct connector 
*c,
c->crtc = c->encoder->crtc_id;
 }

-static int connector_find_plane(int fd, unsigned int *plane_id)
-{
-   drmModePlaneRes *plane_resources;
-   drmModePlane *ovr;
-   int i;
-
-   plane_resources = drmModeGetPlaneResources(fd);
-   if (!plane_resources) {
-   fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
-   strerror(errno));
-   return -1;
-   }
-
-   for (i = 0; i < plane_resources->count_planes; i++) {
-   plane_id[i] = 0;
-
-   ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
-   if (!ovr) {
-   fprintf(stderr, "drmModeGetPlane failed: %s\n",
-   strerror(errno));
-   continue;
-   }
-
-   if (ovr->possible_crtcs & (1 << 0))
-   plane_id[i] = ovr->plane_id;
-   drmModeFreePlane(ovr);
-   }
-
-   return 0;
-}
-
 static int drm_set_crtc(struct exynos_device *dev, struct connector *c,
unsigned int fb_id)
 {
-- 
2.3.0

[PATCH libdrm 2/4] exynos_fimg2d_test: remove unused variables

[Emil Velikov]

Cc: Inki Dae 
Cc: Kyungmin Park 
Signed-off-by: Emil Velikov 
---
 tests/exynos/exynos_fimg2d_test.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index f141964..17e8e53 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -269,7 +269,6 @@ static int g2d_copy_test(struct exynos_device *dev, struct 
exynos_bo *src,
 {
struct g2d_context *ctx;
struct g2d_image src_img, dst_img;
-   unsigned int count;
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -353,7 +352,6 @@ static int g2d_copy_with_scale_test(struct exynos_device 
*dev,
 {
struct g2d_context *ctx;
struct g2d_image src_img, dst_img;
-   unsigned int count;
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -442,7 +440,6 @@ static int g2d_blend_test(struct exynos_device *dev,
 {
struct g2d_context *ctx;
struct g2d_image src_img, dst_img;
-   unsigned int count;
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -557,7 +554,6 @@ int main(int argc, char **argv)
struct exynos_device *dev;
struct exynos_bo *bo, *src;
struct connector con;
-   char *modeset = NULL;
unsigned int fb_id;
uint32_t handles[4] = {0}, pitches[4] = {0}, offsets[4] = {0};
drmModeRes *resources;
@@ -573,7 +569,6 @@ int main(int argc, char **argv)
while ((c = getopt(argc, argv, optstr)) != -1) {
switch (c) {
case 's':
-   modeset = strdup(optarg);
con.crtc = -1;
if (sscanf(optarg, "%d:0x%64s",
,
-- 
2.3.0

[PATCH libdrm 1/4] tests: remove unused variables

[Emil Velikov]

As kindly pointed out by GCC.

Signed-off-by: Emil Velikov 
---
 tests/name_from_fd.c | 3 +--
 tests/updatedraw.c   | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/tests/name_from_fd.c b/tests/name_from_fd.c
index e3db413..24af6e6 100644
--- a/tests/name_from_fd.c
+++ b/tests/name_from_fd.c
@@ -40,8 +40,7 @@
  */
 int main(int argc, char **argv)
 {
-   int fd, ret;
-   drm_set_version_t sv, version;
+   int fd;
const char *name = "/dev/dri/card0";
char *v;

diff --git a/tests/updatedraw.c b/tests/updatedraw.c
index 8e0b94b..d01fa96 100644
--- a/tests/updatedraw.c
+++ b/tests/updatedraw.c
@@ -122,7 +122,7 @@ static int rm_drawable(int fd, int drawable, int fail)
  */
 int main(int argc, char **argv)
 {
-   int fd, ret, d1, d2;
+   int fd, d1, d2;

if (getuid() != 0) {
fprintf(stderr, "updatedraw test requires root, skipping\n");
-- 
2.3.0

[PATCH libdrm 00/04] Silence compiler warnings

[Emil Velikov]

Short follow up to my earlier series "The rocky road to building with 
-Wextra". This gets rid of ~20 warnings, with ~45 remainig.

-Emil

[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank

[Jani Nikula]

On Mon, 23 Feb 2015, Jani Nikula  wrote:
> On Mon, 16 Feb 2015, Paul Bolle  wrote:
>> I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K
>> lines in dmesg containing either "[drm" or this WARNING are pasted
>> below. I really know nothing about all this, but I do note that only the
>> WARNINGS are preceded by:
>> [drm:intel_calculate_wm] FIFO watermark level: -5
>> [drm:i9xx_update_wm] FIFO watermarks - A: 26, B: 8
>>
>> But perhaps that's another symptom of the same issue. A bit of staring
>> at the code couldn't help me determine that.
>>
>> Perhaps these debug messages help someone in discovering what might be
>> going on here.
>
> Please try v4.0-rc1 or try cherry-picking this on top of v3.19 and
> report back:
>
> commit f9b61ff6bce9a44555324b29e593fdffc9a115bc
> Author: Daniel Vetter 
> Date:   Wed Jan 7 13:54:39 2015 +0100
>
> drm/i915: Push vblank enable/disable past encoder->enable/disable

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

>
> BR,
> Jani.
>
>
>
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Jani Nikula, Intel Open Source Technology Center

[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank

[Jani Nikula]

On Mon, 16 Feb 2015, Paul Bolle  wrote:
> I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K
> lines in dmesg containing either "[drm" or this WARNING are pasted
> below. I really know nothing about all this, but I do note that only the
> WARNINGS are preceded by:
> [drm:intel_calculate_wm] FIFO watermark level: -5
> [drm:i9xx_update_wm] FIFO watermarks - A: 26, B: 8
>
> But perhaps that's another symptom of the same issue. A bit of staring
> at the code couldn't help me determine that.
>
> Perhaps these debug messages help someone in discovering what might be
> going on here.

Please try v4.0-rc1 or try cherry-picking this on top of v3.19 and
report back:

commit f9b61ff6bce9a44555324b29e593fdffc9a115bc
Author: Daniel Vetter 
Date:   Wed Jan 7 13:54:39 2015 +0100

drm/i915: Push vblank enable/disable past encoder->enable/disable

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/radeon: fix interlaced modes

[Alex Deucher]

The viewport needs the frame size, not the field size.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 7d827cb..41b460a 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1405,6 +1405,9 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
   (x << 16) | y);
viewport_w = crtc->mode.hdisplay;
viewport_h = (crtc->mode.vdisplay + 1) & ~1;
+   /* viewport is frame size, not field */
+   if (crtc->mode.flags & DRM_MODE_FLAG_INTERLACE)
+   viewport_h *= 2;
WREG32(EVERGREEN_VIEWPORT_SIZE + radeon_crtc->crtc_offset,
   (viewport_w << 16) | viewport_h);

@@ -1605,6 +1608,9 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
   (x << 16) | y);
viewport_w = crtc->mode.hdisplay;
viewport_h = (crtc->mode.vdisplay + 1) & ~1;
+   /* viewport is frame size, not field */
+   if (crtc->mode.flags & DRM_MODE_FLAG_INTERLACE)
+   viewport_h *= 2;
WREG32(AVIVO_D1MODE_VIEWPORT_SIZE + radeon_crtc->crtc_offset,
   (viewport_w << 16) | viewport_h);

-- 
1.8.3.1

[PATCH libdrm v2] drm: add drmGet(Master|Render)NameFrom(Render|Master)FD functions

[Frank Binns]

Hi Emil,

On 23/02/15 12:22, Emil Velikov wrote:
> Currently most places assume reliable master <> render node mapping.
> Although this may work in some cases, it is not correct.
>
> Add a couple of helpers that hide the details and provide the name of
> the master/render device name, given an render/master FD.
>
> v2:
>  - Rename Device and Primary to Master (aka the /dev/dri/cardX device).
>  - Check for the file via readdir_r() rather than stat().
>  - Wrap the check into a single function.
>  - Return NULL for non-linux platforms.
>
> Cc: Frank Binns 
> Cc: Daniel Vetter 
> Cc: David Herrmann 
> Signed-off-by: Emil Velikov 
> ---
>  xf86drm.c | 82 
> +++
>  xf86drm.h |  3 +++
>  2 files changed, 85 insertions(+)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index e117bc6..d4a4dc6 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -40,6 +40,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -522,6 +524,20 @@ static int drmGetMinorType(int minor)
>  }
>  }
>  
> +static const char *drmGetMinorName(int type)
> +{
> +switch (type) {
> +case DRM_NODE_PRIMARY:
> +return "card";
> +case DRM_NODE_CONTROL:
> +return "controlD";
> +case DRM_NODE_RENDER:
> +return "renderD";
> +default:
> +return NULL;
> +}
> +}
> +
>  /**
>   * Open the device by bus ID.
>   *
> @@ -2736,3 +2752,69 @@ int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t 
> *handle)
>   return 0;
>  }
>  
> +static char *drmGetMinorNameForFD(int fd, int type)
> +{
> +#ifdef __linux__
> + DIR *sysdir;
> + struct dirent *pent, *ent;
> + struct stat sbuf;
> + const char *name = drmGetMinorName(type);
> + const int len = strlen(name);
This will cause a segfault if 'name' is NULL.

> + char dev_name[64], buf[64];
> + long name_max;
> + int maj, min;
> +
> + if (!name)
> + return NULL;
> +
> + if (fstat(fd, ))
> + return NULL;
> +
> + maj = major(sbuf.st_rdev);
> + min = minor(sbuf.st_rdev);
> +
> + if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> + return NULL;
> +
> + snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min);
> +
> + sysdir = opendir(buf);
> + if (!sysdir)
> + return NULL;
> +
> + name_max = fpathconf(dirfd(sysdir), _PC_NAME_MAX);
> + if (name_max == -1)
> + goto out_close_dir;
> +
> + pent = malloc(offsetof(struct dirent, d_name) + name_max + 1);
> + if (pent == NULL)
> +  goto out_close_dir;
> +
> + while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
> + if (strncmp(ent->d_name, name, len) == 0) {
> + free(pent);
> + closedir(sysdir);
> +
> + snprintf(dev_name, sizeof(dev_name), DRM_DIR_NAME "/%s",
> +  ent->d_name);
> + return strdup(dev_name);
> + }
> + }
> +
> + free(pent);
> +
> +out_close_dir:
> + closedir(sysdir);
> +#endif
> + return NULL;
> +}
> +
> +char *drmGetMasterNameFromRenderFD(int fd)
I think drmGetPrimaryDeviceNameFromFd would be more appropriate given
the node type is 'primary', the type of the fd doesn't matter afaics and
for consistency with other drmGet* functions. However, given that's a
bit of a mouthful I guess the 'Device' part could be dropped.

> +{
> + return drmGetMinorNameForFD(fd, DRM_NODE_PRIMARY);
> +}
> +
> +char *drmGetRenderNameFromMasterFD(int fd)
As above, maybe drmGetRenderDeviceNameFromFd?

With those things changed/fixed you can have a:
Reviewed-by: Frank Binns 

Thanks
Frank

> +{
> + return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
> +}
> diff --git a/xf86drm.h b/xf86drm.h
> index afd38a1..5fdf27b 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -749,6 +749,9 @@ extern int drmGetNodeTypeFromFd(int fd);
>  extern int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int 
> *prime_fd);
>  extern int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle);
>  
> +extern char *drmGetRenderNameFromMasterFD(int fd);
> +extern char *drmGetMasterNameFromRenderFD(int fd);
> +
>  #if defined(__cplusplus) || defined(c_plusplus)
>  }
>  #endif

[PATCH libdrm 4/4] autotools: add WARN_CFLAGS to all targets

[Emil Velikov]

... minus test/ttmtest. The latter is not really hooked up with the
actual build.

This will give us 66 warnings on a distribution build of which
 - 12 -Wunused-variable
 - 11 -Wunused-function
 - 19 -Wmissing-prototypes
and a few -Wswitch-enum, -Wtype-limits etc.

Adding the CFLAGS gives some exposure to these so that we can fix them.

Signed-off-by: Emil Velikov 
---
 Makefile.am | 1 +
 tests/Makefile.am   | 3 ++-
 tests/exynos/Makefile.am| 1 +
 tests/kmstest/Makefile.am   | 1 +
 tests/modeprint/Makefile.am | 1 +
 tests/proptest/Makefile.am  | 1 +
 tests/radeon/Makefile.am| 1 +
 tests/tegra/Makefile.am | 2 +-
 tests/vbltest/Makefile.am   | 2 ++
 9 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 062feb4..9514cc5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -82,6 +82,7 @@ libdrm_la_LIBADD = @CLOCK_LIB@

 libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm
 AM_CFLAGS = \
+   $(WARN_CFLAGS) \
$(VALGRIND_CFLAGS)

 libdrm_la_SOURCES = $(LIBDRM_FILES)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 37b8d3a..f989d8e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1,6 +1,7 @@
 NULL:=#

-AM_CPPFLAGS = \
+AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I $(top_srcdir)/include/drm \
-I $(top_srcdir)

diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
index 92de4e4..b21d016 100644
--- a/tests/exynos/Makefile.am
+++ b/tests/exynos/Makefile.am
@@ -1,4 +1,5 @@
 AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I $(top_srcdir)/include/drm \
-I $(top_srcdir)/libkms/ \
-I $(top_srcdir)/exynos \
diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am
index 7903a26..fd21e61 100644
--- a/tests/kmstest/Makefile.am
+++ b/tests/kmstest/Makefile.am
@@ -1,4 +1,5 @@
 AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)/libkms/ \
-I$(top_srcdir)
diff --git a/tests/modeprint/Makefile.am b/tests/modeprint/Makefile.am
index 6420ef3..895805f 100644
--- a/tests/modeprint/Makefile.am
+++ b/tests/modeprint/Makefile.am
@@ -1,4 +1,5 @@
 AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)

diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
index f81a3c0..48a84c1 100644
--- a/tests/proptest/Makefile.am
+++ b/tests/proptest/Makefile.am
@@ -1,4 +1,5 @@
 AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)

diff --git a/tests/radeon/Makefile.am b/tests/radeon/Makefile.am
index 1775669..d18620d 100644
--- a/tests/radeon/Makefile.am
+++ b/tests/radeon/Makefile.am
@@ -1,4 +1,5 @@
 AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I $(top_srcdir)/include/drm \
-I $(top_srcdir)

diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
index ca63d92..8e625c8 100644
--- a/tests/tegra/Makefile.am
+++ b/tests/tegra/Makefile.am
@@ -3,7 +3,7 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/tegra \
-I$(top_srcdir)

-AM_CFLAGS = -Wall -Werror
+AM_CFLAGS = $(WARN_CFLAGS)

 LDADD = \
../../tegra/libdrm_tegra.la \
diff --git a/tests/vbltest/Makefile.am b/tests/vbltest/Makefile.am
index 34a35e7..4d87887 100644
--- a/tests/vbltest/Makefile.am
+++ b/tests/vbltest/Makefile.am
@@ -1,6 +1,8 @@
 AM_CFLAGS = \
+   $(WARN_CFLAGS)\
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)
+
 if HAVE_INSTALL_TESTS
 bin_PROGRAMS = \
vbltest
-- 
2.3.0

[PATCH libdrm 3/4] tests: fix implicit funciton declaration errors

[Emil Velikov]

ioctl() and strcmp() were used without the relevent header being
included.

Signed-off-by: Emil Velikov 
---
 tests/auth.c | 1 +
 tests/getclient.c| 1 +
 tests/getstats.c | 1 +
 tests/lock.c | 1 +
 tests/name_from_fd.c | 1 +
 tests/setversion.c   | 1 +
 tests/updatedraw.c   | 1 +
 7 files changed, 7 insertions(+)

diff --git a/tests/auth.c b/tests/auth.c
index 9b6fca9..9147b11 100644
--- a/tests/auth.c
+++ b/tests/auth.c
@@ -26,6 +26,7 @@
  */

 #include 
+#include 
 #include "drmtest.h"

 enum auth_event {
diff --git a/tests/getclient.c b/tests/getclient.c
index 349c16e..481ce11 100644
--- a/tests/getclient.c
+++ b/tests/getclient.c
@@ -26,6 +26,7 @@
  */

 #include 
+#include 
 #include "drmtest.h"

 /**
diff --git a/tests/getstats.c b/tests/getstats.c
index bd55b12..8d40d0b 100644
--- a/tests/getstats.c
+++ b/tests/getstats.c
@@ -26,6 +26,7 @@
  */

 #include 
+#include 
 #include "drmtest.h"

 /**
diff --git a/tests/lock.c b/tests/lock.c
index 86caa28..365681b 100644
--- a/tests/lock.c
+++ b/tests/lock.c
@@ -30,6 +30,7 @@
  */

 #include 
+#include 
 #include "drmtest.h"

 enum auth_event {
diff --git a/tests/name_from_fd.c b/tests/name_from_fd.c
index 330c8ff..e3db413 100644
--- a/tests/name_from_fd.c
+++ b/tests/name_from_fd.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmtest.h"

 /**
diff --git a/tests/setversion.c b/tests/setversion.c
index 5a5d01c..2f7b529 100644
--- a/tests/setversion.c
+++ b/tests/setversion.c
@@ -27,6 +27,7 @@

 #include 
 #include 
+#include 
 #include "drmtest.h"

 /**
diff --git a/tests/updatedraw.c b/tests/updatedraw.c
index a61eb15..8e0b94b 100644
--- a/tests/updatedraw.c
+++ b/tests/updatedraw.c
@@ -25,6 +25,7 @@
  *
  */

+#include 
 #include "drmtest.h"

 static void
-- 
2.3.0

[PATCH libdrm 2/4] exynos_fimg2d_test: fix implicit funciton declaration errors

[Emil Velikov]

As one adds WARN_CFLAGS to the build the compiler throws a couple of
lovely error messages. Add the relevant includes to fix them.

  error: implicit declaration of function ‘time’
  error: implicit declaration of function ‘getopt’

Cc: Inki Dae 
Cc: Kyungmin Park 
Signed-off-by: Emil Velikov 
---
 tests/exynos/exynos_fimg2d_test.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index c6bd558..f141964 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
-- 
2.3.0

[PATCH libdrm 1/4] autotools: add AM_DISTCHECK_CONFIGURE_FLAGS

[Emil Velikov]

To make sure that the release/distribution tarball is not broken for all
the targets. Currently the experimental APIs are disabled by default
amongst others.

Signed-off-by: Emil Velikov 
---
 Makefile.am | 16 
 1 file changed, 16 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 3cb516c..062feb4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,6 +22,22 @@ include Makefile.sources

 ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}

+AM_DISTCHECK_CONFIGURE_FLAGS = \
+   --enable-udev \
+   --enable-libkms \
+   --enable-intel \
+   --enable-radeon \
+   --enable-nouveau \
+   --enable-vmwgfx \
+   --enable-omap-experimental-api \
+   --enable-exynos-experimental-api \
+   --enable-freedreno \
+   --enable-freedreno-kgsl\
+   --enable-tegra-experimental-api \
+   --enable-install-test-programs \
+   --enable-cairo-tests \
+   --enable-manpages
+
 pkgconfigdir = @pkgconfigdir@
 pkgconfig_DATA = libdrm.pc

-- 
2.3.0

[PATCH 00/04 libdrm] The rocky road to building with -Wextra

[Emil Velikov]

Hi all,

A few small patches, that handle the initial step of building the whole 
of libdrm with WARN_CFLAGS (-Wall -Wextra and friends).

The first patch makes sure we build everything at make distcheck time, 
followed by a couple of warnings-turned-errors, and finally adding the 
cflags everywhere in the project.

Individual fixes for the 66 warnings will follow up in due time :-)

Thanks
Emil

Problems with DRI on Acube Sam460 AMCC 460ex board

[Julian Margetson]

09799] LR [c049e2f4] radeon_audio_detect+0x288/0x290
> [   35.815480] Call Trace:
> [   35.818053] [eeb13cd0] [c049e254] radeon_audio_detect+0x1e8/0x290 
> (unreliable)
> [   35.825694] [eeb13d00] [c03dfe7c] radeon_dvi_detect+0x388/0x3ac
> [   35.831956] [eeb13d30] [c038b9d4] 
> drm_helper_probe_single_connector_modes_merge_bits+0xf4/0x434
> [   35.841137] [eeb13d70] [c03a7670] drm_mode_getconnector+0xf4/0x334
> [   35.847663] [eeb13e10] [c039a8c0] drm_ioctl+0x348/0x464
> [   35.853183] [eeb13ed0] [c00d0ca0] do_vfs_ioctl+0x52c/0x6e8
> [   35.858974] [eeb13f20] [c00d0e9c] SyS_ioctl+0x40/0x68
> [   35.864307] [eeb13f40] [c000ab04] ret_from_syscall+0x0/0x3c
> [   35.870196] --- interrupt: c01 at 0x6fb1b8dc
> [   35.870196] LR = 0x6fb1b800
> [   35.877971] Instruction dump:
> [   35.881106] 8129012c 806a0018 2f89 419e0018 81290004 2f89 419e000c 
> 7d2903a6
> [   35.889403] 4e800420 3860 4e800020 81231c70 <81290008> 2f89 
> 4d9e0020 7d2903a6
> [   36.042121] ---[ end trace 3e83f5fa0d05c678 ]---
> [   36.046739]
>
With Kernel 3.19

[2.454668] Linux agpgart interface v0.103
[2.458979] [drm] Initialized drm 1.1.0 20060810
[2.463814] [drm] radeon kernel modesetting enabled.
[2.469870] [drm] initializing kernel modesetting (TURKS 0x1002:0x6758 
0x1682:0x318B).
[2.478007] [drm] register mmio base: 0xe9000
[2.482774] [drm] register mmio size: 131072
[2.665432] ATOM BIOS: TURKS
[2.668602] radeon 0001:81:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)
[2.677521] radeon 0001:81:00.0: GTT: 1024M 0x4000 - 
0x7FFF
[2.685201] [drm] Detected VRAM RAM=1024M, BAR=256M
[2.690094] [drm] RAM width 128bits DDR
[2.694109] [TTM] Zone  kernel: Available graphics memory: 379192 kiB
[2.700596] [TTM] Zone highmem: Available graphics memory: 1034552 kiB
[2.707147] [TTM] Initializing pool allocator
[2.711540] [TTM] Initializing DMA pool allocator
[2.716359] [drm] radeon: 1024M of VRAM memory ready
[2.721355] [drm] radeon: 1024M of GTT memory ready.
[2.726395] [drm] Loading TURKS Microcode
[2.730457] [drm] Internal thermal controller with fan control
[2.741697] [drm] radeon: dpm initialized
[2.745907] [drm] GART: num cpu pages 262144, num gpu pages 262144
[2.787690] [drm] PCIE GART of 1024M enabled (table at 0x00274000).
[2.794953] radeon 0001:81:00.0: WB enabled
[2.799182] radeon 0001:81:00.0: fence driver on ring 0 use gpu addr 
0x4c00 and cpu addr 0xffc01c00
[2.809300] radeon 0001:81:00.0: fence driver on ring 3 use gpu addr 
0x4c0c and cpu addr 0xffc01c0c
[2.839260] radeon 0001:81:00.0: fence driver on ring 5 use gpu addr 
0x00072118 and cpu addr 0xf9032118
[2.849411] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.856067] [drm] Driver supports precise vblank timestamp query.
[2.862183] radeon 0001:81:00.0: radeon: MSI limited to 32-bit
[2.868058] ppc4xx_setup_msi_irqs: fail allocating msi interrupt
[2.874153] [drm] radeon: irq initialized.
[3.103973] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed 
(scratch(0x8504)=0xCAFEDEAD)
[3.112806] radeon 0001:81:00.0: disabling GPU acceleration
[3.128627] [drm] Radeon Display Connectors
[3.133369] [drm] Connector 0:
[3.136481] [drm]   DP-1
[3.139089] [drm]   HPD1
[3.141665] [drm]   DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 
0x647c
[3.149146] [drm]   Encoders:
[3.152157] [drm] DFP1: INTERNAL_UNIPHY2
[3.156473] [drm] Connector 1:
[3.159570] [drm]   HDMI-A-1
[3.162469] [drm]   HPD5
[3.165019] [drm]   DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c 
0x648c
[3.172436] [drm]   Encoders:
[3.175415] [drm] DFP2: INTERNAL_UNIPHY2
[3.179703] [drm] Connector 2:
[3.182766] [drm]   DVI-I-1
[3.185570] [drm]   HPD4
[3.188117] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 
0x645c
[3.195535] [drm]   Encoders:
[3.198513] [drm] DFP3: INTERNAL_UNIPHY
[3.202706] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[3.352245] [drm] fb mappable at 0x80475000
[3.356458] [drm] vram apper at 0x8000
[3.360570] [drm] size 8294400
[3.363634] [drm] fb depth is 24
[3.366873] [drm]pitch is 7680
[3.575080] Console: switching to colour frame buffer device 240x67
[3.649278] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device
[3.656071] radeon 0001:81:00.0: registered panic notifier
[3.666472] [drm] Initialized radeon 2.40.0 20080528 for 0001:81:00.0 on 
minor 0



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/254a38bd/attachment-0001.html>

[Intel-gfx] [PATCH 3/4] drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c

[Imre Deak]

Hi Dave,

On to, 2015-02-19 at 15:42 +0200, Imre Deak wrote:
> On to, 2015-02-19 at 15:39 +0200, Imre Deak wrote:
> > On to, 2015-02-19 at 12:25 +, Dave Gordon wrote:
> > > On 12/02/15 22:38, Imre Deak wrote:
> > > > On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote:
> > > >> UMS is no more!
> > > >>
> > > >> Signed-off-by: Daniel Vetter 
> > > 
> > > Some machines now won't boot in "recovery mode", which specifies
> > > "nomodeset" and therefore results in various important bits of code not
> > > being executed. Will we eventually ignore "modeset" completely, or just
> > > refuse to load at all if "nomodeset" is explicitly specified?
> > 
> > The driver will already refuse to load with nomodeset for GEN6+ for
> > quite some time now. On old platforms UMS would still work before this
> > patch, but afaik there was a decision to stop supporting UMS. Note that
> > this doesn't mean "recovery mode" or equivalently nomodeset will break
> > booting, it just means user space will fall back to vesa/vga or text
> > mode.
> 
> Ah, or did you mean after this patch we should refuse loading the driver
> in case of nomodeset even for old platforms? That would make sense
> indeed.

I was wrong here, I was thinking only about the GEN6 MODESET check in
i915_driver_load. As Daniel pointed out on IRC in addition to that we
also silently fail to load driver in i915_init for !MODESET always,
regardless of the platform, so the check in i915_driver_load is
redundant. Based on this it's safe to remove the !MODESET parts.

--Imre

[PATCH] drm/radeon: fix atom aux payload size check for writes

[Michel Dänzer]

On 21.02.2015 01:56, Alex Deucher wrote:
> The atom aux param interface only supports 4 bits for
> the total write transfer size (header + payload).  This
> limits us to 12 bytes of payload rather than 16.  Add a
> check for this. Reads are not affected.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/atombios_dp.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 5bf825d..c57706e6 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -178,6 +178,13 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
> drm_dp_aux_msg *msg)
>   switch (msg->request & ~DP_AUX_I2C_MOT) {
>   case DP_AUX_NATIVE_WRITE:
>   case DP_AUX_I2C_WRITE:
> + /* The atom implementation only supports writes with a max 
> payload of
> +  * 12 bytes since it uses 4 bits for the total count (header + 
> payload)
> +  * in the parameter space.  The atom interface supports 16 byte
> +  * payloads for reads. The hw itself supports up to 16 bytes of 
> payload.
> +  */
> + if (WARN_ON(msg->size > 12))
> + return -E2BIG;
>   /* tx_size needs to be 4 even for bare address packets since 
> the atom
>* table needs the info in tx_buf[3].
>*/
> 

Might be safer to use WARN_ON_ONCE to avoid spamming dmesg if the
warning ever gets triggered.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

VM on GPUs

[Jan Vesely]

t;
> >> PTE:
> >> 39:12 - page address
> >> 11:7 - fragment
> >> 6 - write
> >> 5 - read
> >> 2 - CPU cache snoop (for accessing cached system memory)
> >> 1 - system (page is in system memory rather than vram)
> >> 0 - PTE valid (the entry is valid)
> >>
> >> Fragment needs some explanation. The logical/physical fragment size in
> >> bytes = 2 ^ (12 + fragment).  A fragment size of 0 means 4k, 1 means,
> >> 8k, etc.  The logical address must be aligned to the fragment size and
> >> the memory backing it must be contiguous and at least as large as the
> >> fragment size.  Larger fragment sizes reduce the pressure on the TLB
> >> since fewer entries are required for the same amount of memory.
> >>
> >> For system pages, the page address is the dma address of the page.
> >> The system bit must be set and the snoop bit can be optionally set
> >> depending on whether you are using cachable memory.
> >>
> >> For vram pages, the address is the GPU physical address of vram
> >> (starts at 0 on dGPUs, starts at MC_VM_FB_OFFSET (dma address of
> >> "vram" carve out) on APUs).
> >>
> >> You can also adjust the page table block size which controls the
> >> number of pages per PTB.  I.e., how many PDEs you need to cover the
> >> address space.  E.g., if you set the block size to 0, each PTB is 4k
> >> which holds 512 PTEs; if you set it to 1 each PTB is 8k which holds
> >> 1024 PTEs, etc.
> >>
> >> GPUVM is only concerned with memory management and protection.  There
> >> are other protection features in other hw blocks for things beyond
> >> memory.  For example, on CI and newer asics, the CP and SDMA blocks
> >> execute command buffers in a secure mode that limits them to accessing
> >> only registers that are relevant for those blocks (e.g., gfx or
> >> compute state registers, but not display registers) or only executing
> >> certain packets.
> >>
> >> I hope this helps.  Let me know if you have any more questions.
> >>
> >> Alex
> >>
> >> >
> >> >
> >> > thank you,
> >> > Jan
> >> >
> >> > [0]http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
> >> > [1]http://lists.freedesktop.org/archives/dri-devel/2014-May/058858.html
> >> >
> >> >
> >> > --
> >> > Jan Vesely 
> >
> > --
> > Jan Vesely 

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/a2f0631c/attachment.sig>

[PATCH 05/45] drm.h: include stdlib.h in userspace

[Mikko Rapeli]

On Mon, Feb 23, 2015 at 10:26:58AM +, Emil Velikov wrote:
> On 16/02/15 23:05, Mikko Rapeli wrote:
> > Fixes  compilation error:
> > 
> > drm/drm.h:132:2: error: unknown type name ‘size_t’
> > 
> Hi Mikko,
> 
> Can you let us know how you're getting these (series-wise) errors ? I've
> been meaning to sync the uapi/drm and libdrm headers and would be nice
> to have an extra step to test things.

This should have everything needed to reproduce these compile errors,
though some of the errors hide behind other errors and fixes:

https://lkml.org/lkml/2015/2/16/525

-Mikko

[PATCH v2 06/15] tests/exynos: introduce wait_for_user_input

[Daniel Vetter]

On Mon, Feb 23, 2015 at 11:22:09AM +, Emil Velikov wrote:
> On 16/02/15 13:46, Tobias Jakobi wrote:
> > Currently getchar() is used to pause execution after each test.
> > The user isn't informed if one is supposed to do anything for
> > the tests to continue, so print a simple message to make this
> > more clear.
> > 
> > Signed-off-by: Tobias Jakobi 
> > ---
> >  tests/exynos/exynos_fimg2d_test.c | 20 
> >  1 file changed, 16 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tests/exynos/exynos_fimg2d_test.c 
> > b/tests/exynos/exynos_fimg2d_test.c
> > index 55d2970..446a6c6 100644
> > --- a/tests/exynos/exynos_fimg2d_test.c
> > +++ b/tests/exynos/exynos_fimg2d_test.c
> > @@ -237,6 +237,18 @@ void *create_checkerboard_pattern(unsigned int 
> > num_tiles_x,
> > return buf;
> >  }
> >  
> > +static void wait_for_user_input(int last)
> > +{
> > +   printf("press  to ");
> > +
> > +   if (last)
> > +   printf("exit test application\n");
> > +   else
> > +   printf("skip to next test\n");
> > +
> If interested you can compact this as
> 
>   printf("press  to %s\n", last ? "exit test application" :
>  "skip to next test");

We have this and a ton of other neat helpers in igt. As I've probably said
countless times on irc and at conferences if someone bothers to make the
core of igt i915-agnostic (just needs changes in the function to open the
drm dev mostly) I'd love to see igt converted into a generic drm
testsuite.

And similar to piglit I think it makes more sense to have that outside of
any userspace components we ship to users, i.e. not in libdrm.

But I really can't justify doing this work to my dear employer ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH libdrm v2] drm: add drmGet(Master|Render)NameFrom(Render|Master)FD functions

[Emil Velikov]

Currently most places assume reliable master <> render node mapping.
Although this may work in some cases, it is not correct.

Add a couple of helpers that hide the details and provide the name of
the master/render device name, given an render/master FD.

v2:
 - Rename Device and Primary to Master (aka the /dev/dri/cardX device).
 - Check for the file via readdir_r() rather than stat().
 - Wrap the check into a single function.
 - Return NULL for non-linux platforms.

Cc: Frank Binns 
Cc: Daniel Vetter 
Cc: David Herrmann 
Signed-off-by: Emil Velikov 
---
 xf86drm.c | 82 +++
 xf86drm.h |  3 +++
 2 files changed, 85 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index e117bc6..d4a4dc6 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -40,6 +40,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -522,6 +524,20 @@ static int drmGetMinorType(int minor)
 }
 }

+static const char *drmGetMinorName(int type)
+{
+switch (type) {
+case DRM_NODE_PRIMARY:
+return "card";
+case DRM_NODE_CONTROL:
+return "controlD";
+case DRM_NODE_RENDER:
+return "renderD";
+default:
+return NULL;
+}
+}
+
 /**
  * Open the device by bus ID.
  *
@@ -2736,3 +2752,69 @@ int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t 
*handle)
return 0;
 }

+static char *drmGetMinorNameForFD(int fd, int type)
+{
+#ifdef __linux__
+   DIR *sysdir;
+   struct dirent *pent, *ent;
+   struct stat sbuf;
+   const char *name = drmGetMinorName(type);
+   const int len = strlen(name);
+   char dev_name[64], buf[64];
+   long name_max;
+   int maj, min;
+
+   if (!name)
+   return NULL;
+
+   if (fstat(fd, ))
+   return NULL;
+
+   maj = major(sbuf.st_rdev);
+   min = minor(sbuf.st_rdev);
+
+   if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+   return NULL;
+
+   snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min);
+
+   sysdir = opendir(buf);
+   if (!sysdir)
+   return NULL;
+
+   name_max = fpathconf(dirfd(sysdir), _PC_NAME_MAX);
+   if (name_max == -1)
+   goto out_close_dir;
+
+   pent = malloc(offsetof(struct dirent, d_name) + name_max + 1);
+   if (pent == NULL)
+goto out_close_dir;
+
+   while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
+   if (strncmp(ent->d_name, name, len) == 0) {
+   free(pent);
+   closedir(sysdir);
+
+   snprintf(dev_name, sizeof(dev_name), DRM_DIR_NAME "/%s",
+ent->d_name);
+   return strdup(dev_name);
+   }
+   }
+
+   free(pent);
+
+out_close_dir:
+   closedir(sysdir);
+#endif
+   return NULL;
+}
+
+char *drmGetMasterNameFromRenderFD(int fd)
+{
+   return drmGetMinorNameForFD(fd, DRM_NODE_PRIMARY);
+}
+
+char *drmGetRenderNameFromMasterFD(int fd)
+{
+   return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
+}
diff --git a/xf86drm.h b/xf86drm.h
index afd38a1..5fdf27b 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -749,6 +749,9 @@ extern int drmGetNodeTypeFromFd(int fd);
 extern int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int 
*prime_fd);
 extern int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle);

+extern char *drmGetRenderNameFromMasterFD(int fd);
+extern char *drmGetMasterNameFromRenderFD(int fd);
+
 #if defined(__cplusplus) || defined(c_plusplus)
 }
 #endif
-- 
2.3.0

[PATCH v8 3/3] of: Add of_graph_get_port_by_id function

[Philipp Zabel]

This patch adds a function to get a port device tree node by port id,
or reg property value.

Signed-off-by: Philipp Zabel 
Acked-by: Laurent Pinchart 
---
 drivers/of/base.c| 32 
 include/linux/of_graph.h |  7 +++
 2 files changed, 39 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 05b20f1..6398b9c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2081,6 +2081,38 @@ int of_graph_parse_endpoint(const struct device_node 
*node,
 EXPORT_SYMBOL(of_graph_parse_endpoint);

 /**
+ * of_graph_get_port_by_id() - get the port matching a given id
+ * @parent: pointer to the parent device node
+ * @id: id of the port
+ *
+ * Return: A 'port' node pointer with refcount incremented. The caller
+ * has to use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_port_by_id(struct device_node *parent, u32 id)
+{
+   struct device_node *node, *port;
+
+   node = of_get_child_by_name(parent, "ports");
+   if (node)
+   parent = node;
+
+   for_each_child_of_node(parent, port) {
+   u32 port_id = 0;
+
+   if (of_node_cmp(port->name, "port") != 0)
+   continue;
+   of_property_read_u32(port, "reg", _id);
+   if (id == port_id)
+   break;
+   }
+
+   of_node_put(node);
+
+   return port;
+}
+EXPORT_SYMBOL(of_graph_get_port_by_id);
+
+/**
  * of_graph_get_next_endpoint() - get next endpoint node
  * @parent: pointer to the parent device node
  * @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index e43442e..3c1c95a 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -40,6 +40,7 @@ struct of_endpoint {
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
+struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
 struct device_node *of_graph_get_remote_port_parent(
@@ -53,6 +54,12 @@ static inline int of_graph_parse_endpoint(const struct 
device_node *node,
return -ENOSYS;
 }

+static inline struct device_node *of_graph_get_port_by_id(
+   struct device_node *node, u32 id)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_next_endpoint(
const struct device_node *parent,
struct device_node *previous)
-- 
2.1.4

[PATCH v8 2/3] of: Add for_each_endpoint_of_node helper macro

[Philipp Zabel]

Note that while of_graph_get_next_endpoint decrements the reference count
of the child node passed to it, of_node_put(child) still has to be called
manually when breaking out of the loop.

Signed-off-by: Philipp Zabel 
Acked-by: Laurent Pinchart 
---
 include/linux/of_graph.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e43442e 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -26,6 +26,17 @@ struct of_endpoint {
const struct device_node *local_node;
 };

+/**
+ * for_each_endpoint_of_node - iterate over every endpoint in a device node
+ * @parent: parent device node containing ports and endpoints
+ * @child: loop variable pointing to the current endpoint node
+ *
+ * When breaking out of the loop, of_node_put(child) has to be called manually.
+ */
+#define for_each_endpoint_of_node(parent, child) \
+   for (child = of_graph_get_next_endpoint(parent, NULL); child != NULL; \
+child = of_graph_get_next_endpoint(parent, child))
+
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
-- 
2.1.4

[PATCH v8 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint

[Philipp Zabel]

Decrementing the reference count of the previous endpoint node allows to
use the of_graph_get_next_endpoint function in a for_each_... style macro.
All current users of this function that pass a non-NULL prev parameter
(that is, soc_camera and imx-drm) are changed to not decrement the passed
prev argument's refcount themselves.

Signed-off-by: Philipp Zabel 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Mathieu Poirier 
Acked-by: Laurent Pinchart 
Acked-by: Tomi Valkeinen 
---
Changes since v7:
 - Rebased onto v4.0-rc1
 - Added fix for am437x-vpfe
---
 drivers/coresight/of_coresight.c  | 13 ++---
 drivers/gpu/drm/imx/imx-drm-core.c| 11 +--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 ---
 drivers/media/platform/am437x/am437x-vpfe.c   |  1 -
 drivers/media/platform/soc_camera/soc_camera.c|  3 ++-
 drivers/of/base.c |  9 +
 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |  7 +--
 7 files changed, 11 insertions(+), 48 deletions(-)

diff --git a/drivers/coresight/of_coresight.c b/drivers/coresight/of_coresight.c
index c3efa41..6f75e9d 100644
--- a/drivers/coresight/of_coresight.c
+++ b/drivers/coresight/of_coresight.c
@@ -52,15 +52,6 @@ of_coresight_get_endpoint_device(struct device_node 
*endpoint)
   endpoint, of_dev_node_match);
 }

-static struct device_node *of_get_coresight_endpoint(
-   const struct device_node *parent, struct device_node *prev)
-{
-   struct device_node *node = of_graph_get_next_endpoint(parent, prev);
-
-   of_node_put(prev);
-   return node;
-}
-
 static void of_coresight_get_ports(struct device_node *node,
   int *nr_inport, int *nr_outport)
 {
@@ -68,7 +59,7 @@ static void of_coresight_get_ports(struct device_node *node,
int in = 0, out = 0;

do {
-   ep = of_get_coresight_endpoint(node, ep);
+   ep = of_graph_get_next_endpoint(node, ep);
if (!ep)
break;

@@ -140,7 +131,7 @@ struct coresight_platform_data 
*of_get_coresight_platform_data(
/* Iterate through each port to discover topology */
do {
/* Get a handle on a port */
-   ep = of_get_coresight_endpoint(node, ep);
+   ep = of_graph_get_next_endpoint(node, ep);
if (!ep)
break;

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index a002f53..84cf99f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -431,15 +431,6 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
 }
 EXPORT_SYMBOL_GPL(imx_drm_encoder_parse_of);

-static struct device_node *imx_drm_of_get_next_endpoint(
-   const struct device_node *parent, struct device_node *prev)
-{
-   struct device_node *node = of_graph_get_next_endpoint(parent, prev);
-
-   of_node_put(prev);
-   return node;
-}
-
 /*
  * @node: device tree node containing encoder input ports
  * @encoder: drm_encoder
@@ -457,7 +448,7 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
return -EINVAL;

do {
-   ep = imx_drm_of_get_next_endpoint(node, ep);
+   ep = of_graph_get_next_endpoint(node, ep);
if (!ep)
break;

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index cc9136e..68dab26 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -206,7 +206,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
enum rcar_du_encoder_type enc_type = RCAR_DU_ENCODER_NONE;
struct device_node *connector = NULL;
struct device_node *encoder = NULL;
-   struct device_node *prev = NULL;
+   struct device_node *ep_node = NULL;
struct device_node *entity_ep_node;
struct device_node *entity;
int ret;
@@ -225,11 +225,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);

while (1) {
-   struct device_node *ep_node;
-
-   ep_node = of_graph_get_next_endpoint(entity, prev);
-   of_node_put(prev);
-   prev = ep_node;
+   ep_node = of_graph_get_next_endpoint(entity, ep_node);

if (!ep_node)
break;
@@ -300,7 +296,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
 static int rcar_du_encoders_init(struct rcar_du_device *rcdu)
 {
struct device_node *np = rcdu->dev->of_node;
-   struct device_node *prev = NULL;
+   struct device_node *ep_node = NULL;
unsigned int num_encoders = 0;

/*
@@ 

[PATCH v8 0/3] Add of-graph helpers to loop over endpoints and find ports by id

[Philipp Zabel]

Hi,

Since there now is a merge conflict in imx-drm-core, I've rebased the series
onto v4.0-rc1. Also a new driver touched by this change appeared, so the first
patch now includes a fix for am437x-vfpe, too. I'd be happy to get an ack for
that.

This series converts all existing users of of_graph_get_next_endpoint that pass
a non-NULL prev argument to the function and decrement its refcount themselves
to stop doing that. The of_node_put is moved into of_graph_get_next_endpoint
instead.
This allows to add a for_each_endpoint_of_node helper macro to loop over all
endpoints in a device tree node.

Changes since v8:
 - Rebased onto v4.0-rc1
 - Added fix to am437x-vpfe

The previous version can be found here: https://lkml.org/lkml/2014/12/23/219

regards
Philipp

Philipp Zabel (3):
  of: Decrement refcount of previous endpoint in
of_graph_get_next_endpoint
  of: Add for_each_endpoint_of_node helper macro
  of: Add of_graph_get_port_by_id function

 drivers/coresight/of_coresight.c  | 13 ++-
 drivers/gpu/drm/imx/imx-drm-core.c| 11 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 +++--
 drivers/media/platform/am437x/am437x-vpfe.c   |  1 -
 drivers/media/platform/soc_camera/soc_camera.c|  3 +-
 drivers/of/base.c | 41 ++-
 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c |  7 +---
 include/linux/of_graph.h  | 18 ++
 8 files changed, 61 insertions(+), 48 deletions(-)

-- 
2.1.4

[Bug 90741] Radeon: System pauses on TAHITI

[bugzilla-dae...@bugzilla.kernel.org]

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

Damien Grassart  changed:

   What|Removed |Added

 CC||damien at grassart.com

--- Comment #42 from Damien Grassart  ---
Hi, is there any progress on this bug? The current kernel makes Dota 2
unplayable on my Radeon HD 7870. I can also confirm that the "another approach"
patch with the two lines uncommented fixes the problem (as Gustaw already
mentioned above).

Is there anything I can do or provide that might help resolve this?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCHv3 0/2] drm: atmel-hlcdc: PM support

[Boris Brezillon]

Hi Sylvain,

On Sun, 22 Feb 2015 18:51:02 +0100
Sylvain Rochet  wrote:

> This series adds basic PM support for Atmel HLCDC.
> 
> This series depends on:
> 
> [PATCH] drm: atmel-hlcdc: remove useless pm_runtime_put_sync in probe
>   <1423841785-23105-1-git-send-email-boris.brezillon at free-electrons.com>
> [PATCH v3] drm: atmel-hlcdc: Atomic mode-setting conversion
>   <1423842415-23412-1-git-send-email-boris.brezillon at free-electrons.com>

Thanks, I'll queue the series to my drm-atmel-hlcdc-devel branch (with
Andrzej's Reviewed-by).

> 
> Changes since v2:
>   * Save previous state of crtc's so we don't enable them unconditionally
> at resume.
>   * Remove obsolete use of drm_driver.suspend and drm_driver.resume
> callbacks
>   * Merged atmel_hlcdc_dc_suspend to atmel_hlcdc_dc_drm_suspend and
> atmel_hlcdc_dc_resume to atmel_hlcdc_dc_drm_resume since we don't
> need the previous callbacks anymore
>   * Removed useless check of drm_dev in suspend/resume functions
> 
> Changes since v1:
>   * (*crtc_funcs->disable)(crtc) replaced to crtc_funcs->disable(crtc)
> 
> Sylvain Rochet (2):
>   drm: atmel-hlcdc: Add PM suspend/resume support
>   drm: atmel-hlcdc: Add pinctrl PM select sleep,default state in CRTC
> suspend/resume
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |  3 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 47 
> ++
>  2 files changed, 50 insertions(+)
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[v2] libdrm: improvements to userspace exynos component

[Emil Velikov]

On 16/02/15 13:46, Tobias Jakobi wrote:
> Hello,
> 
> here are some miscellaneous improvements (small features, bugfixes, spelling 
> fixes, etc.) for the exynos component of libdrm. The general idea is to let 
> userspace use the G2D engine functionality more 
> efficiently.
> 
> If someone is interested in an application that actually makes use of this, 
> the RetroArch frontend has a custom video backend:
> https://github.com/libretro/RetroArch/blob/master/gfx/drivers/exynos_gfx.c
> 
> 
> Please review and let me know what I can improve.
> 
> v2:
> - Mention value of G2D scaling normalization factor (02/15).
> - Moved patch (04/15) description from commit message to source itself, like 
> suggested by Joonyoung Shim.
> 
Hi Tobias,

Imho these are some nice cleanups. I believe that the Samsung/Exynos
people need to comment on the device specific ones, but I've checked
2-4, 6, 8, 10, 13-15 and they are quite ok (baring a trivial comment)

Reviewed-by: Emil Velikov 

Thanks
Emil

P.S. Please don't recent the entire series, unless needed.

[PATCH] drm/radeon: fix atom aux payload size check for writes (v2)

[Alex Deucher]

The atom aux param interface only supports 4 bits for
the total write transfer size (header + payload).  This
limits us to 12 bytes of payload rather than 16.  Add a
check for this. Reads are not affected.

v2: switch to WARN_ON_ONCE

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 5bf825d..8d74de8 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -178,6 +178,13 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+   /* The atom implementation only supports writes with a max 
payload of
+* 12 bytes since it uses 4 bits for the total count (header + 
payload)
+* in the parameter space.  The atom interface supports 16 byte
+* payloads for reads. The hw itself supports up to 16 bytes of 
payload.
+*/
+   if (WARN_ON_ONCE(msg->size > 12))
+   return -E2BIG;
/* tx_size needs to be 4 even for bare address packets since 
the atom
 * table needs the info in tx_buf[3].
 */
-- 
1.8.3.1

[PATCH 5/5] drm/atomic-helpers: make mode_set hooks optional

[Daniel Vetter]

On Sun, Feb 22, 2015 at 08:17:04PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Sunday 22 February 2015 19:53:23 Laurent Pinchart wrote:
> > On Sunday 22 February 2015 12:24:20 Daniel Vetter wrote:
> > > With runtime PM the hw might still be off while doing the ->mode_set
> > > callbacks - runtime PM get/put should only happen in the
> > > enable/disable hooks to properly support DPMS. Which essentially makes
> > > these callbacks useless for drivers support runtime PM, so make them
> > > optional. Again motivated by discussions with Laurent.
> > > 
> > > Cc: Laurent Pinchart 
> > > Signed-off-by: Daniel Vetter 
> > 
> > I think we should go one step further and remove .mode_set() completely for
> > drivers converted to atomic updates. There are two cases to consider:
> > 
> > - Drivers that implement runtime PM can't use the .mode_set() callback for
> > the reason explained above. Those drivers will thus not implement
> > .mode_set() and will perform mode setting related hardware configuration in
> > .enable().
> > 
> > - Drivers that don't implement runtime PM (we probably want to discourage
> > this globally, but that's a different topic) can use the .mode_set()
> > callbacks, but they could equally well perform mode setting in .enable() as
> > the runtime PM- enabled drivers, without any drawback.
> > 
> > To increase consistency, I thus believe we should get rid of .mode_set()
> > completely for drivers converted to atomic updates.
> 
> On second thought, I've confused .mode_set() and .mode_set_nofb(). 
> .mode_set() 
> still makes sense for encoders, but the above reasoning should apply in my 
> opinion for the CRTC .mode_set_nofb().

You're reasoning is correct, but we need to keep smooth transitioning in
mind for driver coming from crtc helpers. And since those use
->mode_set(_nofb) all over the place it's imo better to keep this. At
least until we've run out of drivers to convert ;-)

We could add a DRM_INFO_ONCE though to remind drivers that they're using
deprecated hooks and should convert over. I plan to submit such a patch at
least for dpms/prepare/commit, maybe we could throw in ->mode_set into the
mix too.

> 
> > However, this patch is good as a first step, so if you want to apply it
> > already,
> > 
> > Acked-by: Laurent Pinchart 

Merged the entire series to drm-misc, thanks for the feedback.
-Daniel

> > 
> > > ---
> > > 
> > >  drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
> > >  include/drm/drm_crtc_helper.h   | 3 ++-
> > >  2 files changed, 5 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c index 9fd3466bf277..5e10bcb7d98d
> > > 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -723,7 +723,7 @@ crtc_set_mode(struct drm_device *dev, struct
> > > drm_atomic_state *old_state)
> > > 
> > >   funcs = crtc->helper_private;
> > > 
> > > - if (crtc->state->enable) {
> > > + if (crtc->state->enable && funcs->mode_set_nofb) {
> > > 
> > >   DRM_DEBUG_ATOMIC("modeset on [CRTC:%d]\n",
> > >   
> > >crtc->base.id);
> > > 
> > > @@ -759,7 +759,8 @@ crtc_set_mode(struct drm_device *dev, struct
> > > drm_atomic_state *old_state) * Each encoder has at most one connector
> > > (since we always steal * it away), so we won't call call mode_set hooks
> > > twice.
> > > 
> > >*/
> > > 
> > > - funcs->mode_set(encoder, mode, adjusted_mode);
> > > + if (funcs->mode_set)
> > > + funcs->mode_set(encoder, mode, adjusted_mode);
> > > 
> > >   if (encoder->bridge && encoder->bridge->funcs->mode_set)
> > >   
> > >   encoder->bridge->funcs->mode_set(encoder->bridge,
> > > 
> > > diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> > > index c250a22b39ab..92d5135b55d2 100644
> > > --- a/include/drm/drm_crtc_helper.h
> > > +++ b/include/drm/drm_crtc_helper.h
> > > @@ -89,6 +89,7 @@ struct drm_crtc_helper_funcs {
> > > 
> > >   int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
> > >   
> > >   struct drm_display_mode *adjusted_mode, int x, int y,
> > >   struct drm_framebuffer *old_fb);
> > > 
> > > + /* Actually set the mode for atomic helpers, optional */
> > > 
> > >   void (*mode_set_nofb)(struct drm_crtc *crtc);
> > >   
> > >   /* Move the crtc on the current fb to the given position *optional* 
> */
> > > 
> > > @@ -119,7 +120,7 @@ struct drm_crtc_helper_funcs {
> > > 
> > >   * @mode_fixup: try to fixup proposed mode for this connector
> > >   * @prepare: part of the disable sequence, called before the CRTC modeset
> > >   * @commit: called after the CRTC modeset
> > > 
> > > - * @mode_set: set this mode
> > > + * @mode_set: set this mode, optional for atomic 

[PATCH v2 08/15] exynos: introduce g2d_add_base_addr helper function

[Emil Velikov]

On 16/02/15 13:46, Tobias Jakobi wrote:
> In almost all functions the base address register is written, so it
> makes sense to have a helper function for this.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  exynos/exynos_fimg2d.c | 87 
> +++---
>  1 file changed, 33 insertions(+), 54 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index b79081e..c08974a 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -41,6 +41,11 @@
>  
>  #define MIN(a, b)((a) < (b) ? (a) : (b))
>  
> +enum g2d_base_addr_reg {
> + g2d_dst = 0,
> + g2d_src
> +};
> +
>  static unsigned int g2d_get_scaling(unsigned int src, unsigned int dst)
>  {
>   /* The G2D hw scaling factor is a normalized inverse of the scaling 
> factor. *
> @@ -132,6 +137,25 @@ static int g2d_add_cmd(struct g2d_context *ctx, unsigned 
> long cmd,
>  }
>  
>  /*
> + * g2d_add_base_addr - helper function to set dst/src base address register.
> + *
> + * @ctx: a pointer to g2d_context structure.
> + * @img: a pointer to the dst/src g2d_image structure.
> + * @reg: the register that should be set.
> + */
> +static void g2d_add_base_addr(struct g2d_context *ctx, struct g2d_image *img,
> + enum g2d_base_addr_reg reg)
> +{
> + const unsigned long cmd = (reg == g2d_dst) ? DST_BASE_ADDR_REG : 
> SRC_BASE_ADDR_REG;
> +
Can we wrap this to 80 columns please ?

-Emil

[PATCH v2 06/15] tests/exynos: introduce wait_for_user_input

[Emil Velikov]

On 16/02/15 13:46, Tobias Jakobi wrote:
> Currently getchar() is used to pause execution after each test.
> The user isn't informed if one is supposed to do anything for
> the tests to continue, so print a simple message to make this
> more clear.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  tests/exynos/exynos_fimg2d_test.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/exynos/exynos_fimg2d_test.c 
> b/tests/exynos/exynos_fimg2d_test.c
> index 55d2970..446a6c6 100644
> --- a/tests/exynos/exynos_fimg2d_test.c
> +++ b/tests/exynos/exynos_fimg2d_test.c
> @@ -237,6 +237,18 @@ void *create_checkerboard_pattern(unsigned int 
> num_tiles_x,
>   return buf;
>  }
>  
> +static void wait_for_user_input(int last)
> +{
> + printf("press  to ");
> +
> + if (last)
> + printf("exit test application\n");
> + else
> + printf("skip to next test\n");
> +
If interested you can compact this as

printf("press  to %s\n", last ? "exit test application" :
   "skip to next test");


Cheers
Emil

[PATCH v2 04/15] tests/exynos: disable the G2D userptr/blend test

[Emil Velikov]

On 16/02/15 13:46, Tobias Jakobi wrote:
> v2: Move the commit description into the patch itself.
> Signed-off-by: Tobias Jakobi 
> ---
>  tests/exynos/exynos_fimg2d_test.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tests/exynos/exynos_fimg2d_test.c 
> b/tests/exynos/exynos_fimg2d_test.c
> index aa140e5..55d2970 100644
> --- a/tests/exynos/exynos_fimg2d_test.c
> +++ b/tests/exynos/exynos_fimg2d_test.c
> @@ -788,11 +788,19 @@ int main(int argc, char **argv)
>  
>   getchar();
>  
> +  /* The blend test uses the userptr functionality of exynos-drm, which *
> +   * is currently not safe to use. If the kernel hasn't been build with *
> +   * exynos-iommu support, then the blend test is going to produce (kernel) *
> +   * memory corruption, eventually leading to a system crash.   *
> +   **
> +   * Disable the test for now, until the kernel code has been sanitized.
> */
> +#if 0
I cannot see a part of libdrm that uses this commenting format. Perhaps
use the more common:

/*
 * Some comment
 */

Cheers,
Emil

[PATCH v2 12/15] exynos: add fimg2d header to common includes

[Emil Velikov]

On 16/02/15 13:46, Tobias Jakobi wrote:
> The reason for this change is to let userspace use the header.
> Currently 'make install' does not install it.
> 
Hi Tobias,

Afaict that this was done intentionally. I believe the Samsung guys got
this out only to fulfil the "no drm(render) driver without open
userspace" policy.

Although it's nice to see actual user(s) (outside of libdrm) perhaps the
header could be cleaned up (#define TRUE 0, #define FALSE -1) a bit
before that ?

Either way it's up-to the Samsung/Exynos people to make the call.

Cheers
Emil

[PATCH] DRM: i.MX: parallel display: Support probe deferral for finding DRM panel

[Liu Ying]

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/imx/parallel-display.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index 5e83e00..900dda6 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -236,8 +236,11 @@ static int imx_pd_bind(struct device *dev, struct device 
*master, void *data)
}

panel_node = of_parse_phandle(np, "fsl,panel", 0);
-   if (panel_node)
+   if (panel_node) {
imxpd->panel = of_drm_find_panel(panel_node);
+   if (!imxpd->panel)
+   return -EPROBE_DEFER;
+   }

imxpd->dev = dev;

-- 
2.1.0

[PATCHv3 1/2] drm: atmel-hlcdc: Add PM suspend/resume support

[Andrzej Hajda]

On 02/22/2015 06:51 PM, Sylvain Rochet wrote:
> On suspend: switch off CRTC if not already suspended with runtime PM
> 
> On resume: switch on CRTC if we were not already suspended from runtime
> PM while suspending.
> 
> Signed-off-by: Sylvain Rochet 

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 47 
> 
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 22c3cca..c4bb1f9 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -559,6 +559,52 @@ static int atmel_hlcdc_dc_drm_remove(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> +#ifdef CONFIG_PM
> +static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(dev);
> + struct drm_crtc *crtc;
> +
> + if (pm_runtime_suspended(dev))
> + return 0;
> +
> + drm_modeset_lock_all(drm_dev);
> + list_for_each_entry(crtc, _dev->mode_config.crtc_list, head) {
> + struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> + if (crtc->enabled) {
> + crtc_funcs->disable(crtc);
> + /* save enable state for resume */
> + crtc->enabled = true;
> + }
> + }
> + drm_modeset_unlock_all(drm_dev);
> + return 0;
> +}
> +
> +static int atmel_hlcdc_dc_drm_resume(struct device *dev)
> +{
> + struct drm_device *drm_dev = dev_get_drvdata(dev);
> + struct drm_crtc *crtc;
> +
> + if (pm_runtime_suspended(dev))
> + return 0;
> +
> + drm_modeset_lock_all(drm_dev);
> + list_for_each_entry(crtc, _dev->mode_config.crtc_list, head) {
> + struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> + if (crtc->enabled) {
> + crtc->enabled = false;
> + crtc_funcs->enable(crtc);
> + }
> + }
> + drm_modeset_unlock_all(drm_dev);
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(atmel_hlcdc_dc_drm_pm_ops,
> + atmel_hlcdc_dc_drm_suspend, atmel_hlcdc_dc_drm_resume);
> +
>  static const struct of_device_id atmel_hlcdc_dc_of_match[] = {
>   { .compatible = "atmel,hlcdc-display-controller" },
>   { },
> @@ -569,6 +615,7 @@ static struct platform_driver 
> atmel_hlcdc_dc_platform_driver = {
>   .remove = atmel_hlcdc_dc_drm_remove,
>   .driver = {
>   .name   = "atmel-hlcdc-display-controller",
> + .pm = _hlcdc_dc_drm_pm_ops,
>   .of_match_table = atmel_hlcdc_dc_of_match,
>   },
>  };
> 

[PULL] drm-amdkfd-fixes

[Oded Gabbay]

Hi Dave,

Two amdkfd fixes for -rc2:

- Fix a bug that caused 15% CPU performance drop in Kaveri. This was caused 
  because we overwritten the initialization of the first pipe (out of eight),
  which is dedicated to radeon operation. The fix was tested by Michel Dänzer.
  This bug was introduced by a patch I prepared (yeah, my bad) and was merged
  to 3.19-rc6. Therefore, I also marked it as Cc:stable.

- Fix sparse warning

Thanks,

Oded

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-fixes-2015-02-23

for you to fetch changes up to 64ea8f4af57cee9f8b0bf542819b41ee82acfcb9:

  drm/amdkfd: don't set get_pipes_num() as inline (2015-02-23 10:48:02 +0200)


Oded Gabbay (2):
  drm/amdkfd: Initialize only amdkfd's assigned pipelines
  drm/amdkfd: don't set get_pipes_num() as inline

 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 10 --
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h |  8 ++--
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c |  2 +-
 3 files changed, 11 insertions(+), 9 deletions(-)

[PATCH 1/5] drm/irq: Add drm_crtc_vblank_reset

[Daniel Vetter]

On Sun, Feb 15, 2015 at 04:08:31PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> Thank you for the patch.
> 
> On Friday 13 February 2015 21:03:42 Daniel Vetter wrote:
> > At driver load we need to tell the vblank code about the state of the
> > pipes, so that the logic around reject vblank_get when the pipe is off
> > works correctly.
> > 
> > Thus far i915 used drm_vblank_off, but one of the side-effects of it
> > is that it also saves the vblank counter. And for that it calls down
> > into the ->get_vblank_counter hook. Which isn't really a good idea
> > when the pipe is off for a few reasons:
> > - With runtime pm the register might not respond.
> > - If the pipe is off some datastructures might not be around or
> >   unitialized.
> > 
> > The later is what blew up on gen3: We look at intel_crtc->config to
> > compute the vblank counter, and for a disabled pipe at boot-up that's
> > just not there. Thus far this was papered over by a check for
> > intel_crtc->active, but I want to get rid of that (since it's fairly
> > race, vblank hooks are called from all kinds of places).
> > 
> > So prep for that by adding a _reset functions which only does what we
> > really need to be done at driver load: Mark the vblank pipe as off,
> > but don't do any vblank counter saving or event flushing - neither of
> > that is required.
> > 
> > v2: Clarify the code flow slightly as suggested by Ville.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Laurent Pinchart 
> > Cc: Imre Deak 
> > Reviewed-by: Imre Deak 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_irq.c| 32 
> >  drivers/gpu/drm/i915/intel_display.c |  6 +++---
> >  include/drm/drmP.h   |  1 +
> >  3 files changed, 36 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 75647e7f012b..1e5fb1b994d7 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -1226,6 +1226,38 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
> >  EXPORT_SYMBOL(drm_crtc_vblank_off);
> > 
> >  /**
> > + * drm_crtc_vblank_reset - reset vblank state to off on a CRTC
> > + * @crtc: CRTC in question
> > + *
> > + * Drivers can use this function to reset the vblank state to off at load
> > time.
> > + * Drivers should use this together with the drm_crtc_vblank_off() and
> > + * drm_crtc_vblank_on() functions. The diffrence comparet to
> 
> s/diffrence comparet/difference compared/
> 
> With that fixed,
> 
> Acked-by: Laurent Pinchart 

Fixed while applying, thanks for the feedback.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Fix deadlock due to getconnector locking changes

[Jani Nikula]

On Sun, 22 Feb 2015, Daniel Vetter  wrote:
> In
>
> daniel at phenom:~/linux/src$ git show ccfc08655

copy-paste fail?

J.

> commit ccfc08655d5fd5076828f45fb09194c070f2f63a
> Author: Rob Clark 
> Date:   Thu Dec 18 16:01:48 2014 -0500
>
> drm: tweak getconnector locking
>
> We need to extend the locking to cover connector->state reading for
> atomic drivers, but the above commit was a bit too eager and also
> included the fill_modes callback. Which on i915 on old platforms using
> load detection needs to acquire modeset locks, resulting in a deadlock
> on output probing.
>
> Reported-by: Marc Finet 
> Cc: Marc Finet 
> Cc: robdclark at gmail.com
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b15d720eda4c..ce5f1193ecd6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2180,7 +2180,6 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id);
>  
>   mutex_lock(>mode_config.mutex);
> - drm_modeset_lock(>mode_config.connection_mutex, NULL);
>  
>   connector = drm_connector_find(dev, out_resp->connector_id);
>   if (!connector) {
> @@ -2210,6 +2209,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   out_resp->mm_height = connector->display_info.height_mm;
>   out_resp->subpixel = connector->display_info.subpixel_order;
>   out_resp->connection = connector->status;
> +
> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
>   encoder = drm_connector_get_encoder(connector);
>   if (encoder)
>   out_resp->encoder_id = encoder->base.id;
> -- 
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2/2] drm: WARN if drm_handle_vblank is called errornously

[Daniel Vetter]

On Sun, Feb 22, 2015 at 03:11:20PM +0100, Daniel Vetter wrote:
> KMS drivers are in full control of their irq and vblank handling, if
> they get a vblank interrupt before drm_vblank_init or after
> drm_vblank_cleanup that's just a driver bug.
> 
> For ums driver there's only r128 and radeon which support vblank, and
> they call drm_vblank_init in their driver load functions. Which again
> means that userspace can do whatever it wants with interrupt, vblank
> structures will always be there.
> 
> So this should never happen, let's catch driver issues with a WARN_ON.
> Motivated by some discussions with Imre.
> 
> v2: Use WARN_ON_ONCE as suggested by Imre.
> 
> Cc: Imre Deak 
> Reviewed-by: Imre Deak 
> Signed-off-by: Daniel Vetter 

Merged the entire series to dinq with Dave's irc-ack for the core bits.
Thanks a lot for the review feedback.
-Daniel

> ---
>  drivers/gpu/drm/drm_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3c18e522cc3b..dbece03979f3 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1682,7 +1682,7 @@ bool drm_handle_vblank(struct drm_device *dev, int crtc)
>   struct timeval tvblank;
>   unsigned long irqflags;
>  
> - if (!dev->num_crtcs)
> + if (WARN_ON_ONCE(!dev->num_crtcs))
>   return false;
>  
>   if (WARN_ON(crtc >= dev->num_crtcs))
> -- 
> 1.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/atomic-helpers: Fix documentation typos and wrong copy

[Daniel Vetter]

On Mon, Feb 23, 2015 at 02:50:23AM +0200, Laurent Pinchart wrote:
> The kerneldoc blocks for the drm_atomic_helper_*_set_property()
> functions seem to have been copied from the plane disable handler
> without being properly updated. Fix them.
> 
> Signed-off-by: Laurent Pinchart 

Merged to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 05/45] drm.h: include stdlib.h in userspace

[Emil Velikov]

On 16/02/15 23:05, Mikko Rapeli wrote:
> Fixes  compilation error:
> 
> drm/drm.h:132:2: error: unknown type name ‘size_t’
> 
Hi Mikko,

Can you let us know how you're getting these (series-wise) errors ? I've
been meaning to sync the uapi/drm and libdrm headers and would be nice
to have an extra step to test things.

Thanks
Emil

Update front buffer without CPU interaction?

[Daniel Vetter]

On Mon, Feb 23, 2015 at 09:22:56AM +0100, Volker Vogelhuber wrote:
> 
> On 22.02.2015 12:52, Daniel Vetter wrote:
> >On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
> >>I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
> >>cpu.
> >>In our product we want to have an FPGA streaming video images to a
> >>predefined memory area using bus master dma and render those images using
> >>OpenGL. So far this works in a preliminary state.
> >>We now have the security requirement that in case the CPU (software/kernel
> >>driver) crashes for what ever reason, the GPU display signal should still
> >>output at least the video images (obviously any additional render stuff will
> >>not be available anymore). My question is now, would it be possible to get
> >>the physical address of the DRM front buffer, so that I can provide this
> >>address to the FPGA (connected via PCIe) and is it possible to have the GPU
> >>still reading the last front buffer for the display output while the FPGA
> >>writes to that area. So I would think that the GPU has some kind of DMA
> >>engine running, that continuously reading the last front buffer until
> >>switched to another buffer by the CPU. So even if the CPU does not control
> >>the GPU anymore, it might be possible to have the front buffer updated by
> >>the FPGA directly. Of course there will be tearing artefacts as no VSYNC
> >>will be available but that wouldn't be an issue so far.
> >Just share buffers between your fpga driver and the i915 driver using
> >prime/dma-buf and before each pageflip tell your fpga driver to render
> >into the new buffer. We don't have any interfaces to tell userspace
> >physical addresses of anything, and that's fairly intentional - the kernel
> >is and must be in control of memory management.
> >-Daniel
> Thanks for the reply. I already stumbled across the PRIME way to get access
> to the buffer within the source code but it wasn't totally clear to me, how
> one would access this API.
> I guess one have to call drmPrimeHandleToFD with the /dev/dri/card0 file
> descriptor, a gem handle (probably retrieved using gbm_bo_get_handle),
> DRM_CLOEXEC and some output variable.
> The Prime file descriptor returned, should be usable with the dma-buf API,
> right? So I can call dma_buf_get(prime_fd) within the FPGA driver and pass
> the sg_table I get from dma_buf_map_attachment to the DMA engine within the
> FPGA.
> Does this concept work in theory? Or did I miss something?

It should work even in practice ;-) And yeah description of the dance
looks complete.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: msm: Fix build when legacy fbdev support isn't set

[Rob Clark]

On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter  wrote:
> On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
>> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja  
>> wrote:
>> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
>> > selected. The driver accesses drm_fb_helper_* functions even when legacy 
>> > fbdev
>> > support is disabled in msm. Wrap around these functions with #ifdef checks 
>> > to
>> > prevent build break.
>>
>> hmm, perhaps rather than solving this in each driver, we should do
>> some stub versions of those fb-helper fxns?
>>
>> There are at least one or two other drivers that can build without
>> fbdev, and I guess more going forward..
>
> It's not quite that easy since you also have to start/stop the vt
> subsystem at the right point in time in your own driver. See
> intel_fbdev_set_suspend. If you don't do that there's no synchronization
> between fbcon shutting down/resuming and your driver, which in the best
> case means fbcon does some writes to nowhere and worst case means your
> chip dies (mmio to offline chip blocks) or writes go to somewhere random
> in system memory (iommu contains some stale ptes since not yet fully
> restored, more an issue with hibernate).

I guess I don't fully follow the vt/fbcon interaction if there is no
fbdev driver...  but then again I don't have vesafb/efifb to contend
with, so I'm assuming something to do with that..

> And because the console_lock is massively contended we do that in a async
> worker in i915.
>
> But anyway I agree it would still simply drivers quite a bit if we'd have
> support for dummy fb helpers in the core, maybe with an explicit Kconfig.
> Then drivers could switch to using that for the additional #ifdef (like
> the vt stuff i915 does) and otherwise rely upon dummy static inline. That
> would give us fbdev-less support for most drivers for free, which is kinda
> neat.

I guess at least for all the arm drivers, life without fbdev doesn't
have these extra complications, so at least they could use stubs..

Plus, I kind of expect phone/tablet/chromebook type stuff would lead
the charge into an fbdev-less world..

BR,
-R


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

eDP display control registers in Linux kernel

[Jani Nikula]

Hi Michael -

Please always cc: the relevant mailing lists; done now.

On Sun, 22 Feb 2015, Michael Leuchtenburg  wrote:
> Hi Jani,
>
> I've been trying to figure out how to control the dynamic backlight control
> on my new Dell XPS 13 since the defaults are atrocious - huge swings in
> brightness from a black background to a white one, over a few seconds
> period so it's very obvious. I eventually tracked down a patch from the
> Chromium folks that adds a sysfs interface (
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/db5eacd6ac7a0cbda4ea1010fabbd3ff6b30e0bc%5E%21/),
> but it seems to depend on your patch that adds eDP display control
> registers (
> http://lists.freedesktop.org/archives/dri-devel/2013-November/049098.html),
> which was never merged into mainline as far as I can tell.
>
> Do you know what the status of that is? Is it still wending its way through
> the process (now, over a year later) or did it die somewhere along the way?
> The patch doesn't apply to mainline today, though it's simple enough that I
> suspect it'd be easy to adapt. I'd rather see where it went, though.
>
> I'd appreciate any help you can offer.

The Chrome OS patches wouldn't be acceptable upstream, and indeed
they've never been posted upstream. A more driver agnostic approach
would be required.

My patches were simple, adding some macros etc. They were reviewed but
apparently forgotten, also by me. I'll repost them, but they won't do
you much good in this case.

I'm also not convinced yet that your problem would be solved by the
patches; are you sure Dell XPS 13 does have dynamic backlight control in
the panel, adjustable via DPCD?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH libdrm] Add new drmGetNodeTypeFromFd function

[Emil Velikov]

On 17/02/15 16:10, Frank Binns wrote:
> Hi Emil,
> 
> On 13/02/15 16:38, Emil Velikov wrote:
>> Hi Frank,
>> On 13/02/15 10:51, Frank Binns wrote:
>>> Add a helper function that returns the type of device node from an fd.
>>>
>>> Signed-off-by: Frank Binns 
>> Reviewed-by: Emil Velikov 
>>
>> Thank you for getting rid of the silly file probing that I went with
>> initially.
>>
>> -Emil
> 
> Would you mind pushing this as I don't have commit access.
> 
Hi Frank,

Wanted to give some extra time for people to take a look and comment.
dri-devel has been quite busy lately :-)

Pushed to master, now let's respin the other helpers (using readdir_r).

Cheers,
Emil

Update front buffer without CPU interaction?

[Volker Vogelhuber]

On 22.02.2015 12:52, Daniel Vetter wrote:
> On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
>> cpu.
>> In our product we want to have an FPGA streaming video images to a
>> predefined memory area using bus master dma and render those images using
>> OpenGL. So far this works in a preliminary state.
>> We now have the security requirement that in case the CPU (software/kernel
>> driver) crashes for what ever reason, the GPU display signal should still
>> output at least the video images (obviously any additional render stuff will
>> not be available anymore). My question is now, would it be possible to get
>> the physical address of the DRM front buffer, so that I can provide this
>> address to the FPGA (connected via PCIe) and is it possible to have the GPU
>> still reading the last front buffer for the display output while the FPGA
>> writes to that area. So I would think that the GPU has some kind of DMA
>> engine running, that continuously reading the last front buffer until
>> switched to another buffer by the CPU. So even if the CPU does not control
>> the GPU anymore, it might be possible to have the front buffer updated by
>> the FPGA directly. Of course there will be tearing artefacts as no VSYNC
>> will be available but that wouldn't be an issue so far.
> Just share buffers between your fpga driver and the i915 driver using
> prime/dma-buf and before each pageflip tell your fpga driver to render
> into the new buffer. We don't have any interfaces to tell userspace
> physical addresses of anything, and that's fairly intentional - the kernel
> is and must be in control of memory management.
> -Daniel
Thanks for the reply. I already stumbled across the PRIME way to get 
access to the buffer within the source code but it wasn't totally clear 
to me, how one would access this API.
I guess one have to call drmPrimeHandleToFD with the /dev/dri/card0 file 
descriptor, a gem handle (probably retrieved using gbm_bo_get_handle), 
DRM_CLOEXEC and some output variable.
The Prime file descriptor returned, should be usable with the dma-buf 
API, right? So I can call dma_buf_get(prime_fd) within the FPGA driver 
and pass the sg_table I get from dma_buf_map_attachment to the DMA 
engine within the FPGA.
Does this concept work in theory? Or did I miss something?

Regards, Volker

[PATCH] drm: msm: Fix build when legacy fbdev support isn't set

[Rob Clark]

On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja  
wrote:
> The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
> selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev
> support is disabled in msm. Wrap around these functions with #ifdef checks to
> prevent build break.

hmm, perhaps rather than solving this in each driver, we should do
some stub versions of those fb-helper fxns?

There are at least one or two other drivers that can build without
fbdev, and I guess more going forward..

BR,
-R


> Signed-off-by: Archit Taneja 
> ---
>  drivers/gpu/drm/msm/msm_drv.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index a426911..f15494c 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -21,9 +21,11 @@
>
>  static void msm_fb_output_poll_changed(struct drm_device *dev)
>  {
> +#ifdef CONFIG_DRM_MSM_FBDEV
> struct msm_drm_private *priv = dev->dev_private;
> if (priv->fbdev)
> drm_fb_helper_hotplug_event(priv->fbdev);
> +#endif
>  }
>
>  static const struct drm_mode_config_funcs mode_config_funcs = {
> @@ -373,9 +375,11 @@ static void msm_preclose(struct drm_device *dev, struct 
> drm_file *file)
>
>  static void msm_lastclose(struct drm_device *dev)
>  {
> +#ifdef CONFIG_DRM_MSM_FBDEV
> struct msm_drm_private *priv = dev->dev_private;
> if (priv->fbdev)
> drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
> +#endif
>  }
>
>  static irqreturn_t msm_irq(int irq, void *arg)
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>

eDP display control registers in Linux kernel

[Michael Leuchtenburg]

On Mon, Feb 23, 2015 at 2:59 AM, Jani Nikula  wrote:

>
> Hi Michael -
>
> Please always cc: the relevant mailing lists; done now.
>

Sorry, will do; thanks.


>
> On Sun, 22 Feb 2015, Michael Leuchtenburg  wrote:
> > Hi Jani,
> >
> > I've been trying to figure out how to control the dynamic backlight
> control
> > on my new Dell XPS 13 since the defaults are atrocious - huge swings in
> > brightness from a black background to a white one, over a few seconds
> > period so it's very obvious. I eventually tracked down a patch from the
> > Chromium folks that adds a sysfs interface (
> >
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/db5eacd6ac7a0cbda4ea1010fabbd3ff6b30e0bc%5E%21/
> ),
> > but it seems to depend on your patch that adds eDP display control
> > registers (
> >
> http://lists.freedesktop.org/archives/dri-devel/2013-November/049098.html
> ),
> > which was never merged into mainline as far as I can tell.
> >
> > Do you know what the status of that is? Is it still wending its way
> through
> > the process (now, over a year later) or did it die somewhere along the
> way?
> > The patch doesn't apply to mainline today, though it's simple enough
> that I
> > suspect it'd be easy to adapt. I'd rather see where it went, though.
> >
> > I'd appreciate any help you can offer.
>
> The Chrome OS patches wouldn't be acceptable upstream, and indeed
> they've never been posted upstream. A more driver agnostic approach
> would be required.
>
> My patches were simple, adding some macros etc. They were reviewed but
> apparently forgotten, also by me. I'll repost them, but they won't do
> you much good in this case.
>
> I'm also not convinced yet that your problem would be solved by the
> patches; are you sure Dell XPS 13 does have dynamic backlight control in
> the panel, adjustable via DPCD?
>

I'm certain that it has dynamic backlight control of some sort, as the
brightness varies based on content. I'm also sure it has an eDP panel, and
an Intel graphics adapter. I'm not certain that DPCD will let me adjust it,
or how to check, though the ChromeOS patch seems to assume that intel + edp
-> DBC adjustable via DPCD.

Michael
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/f0e2b0f1/attachment.html>

[PATCH] drm: Fix deadlock due to getconnector locking changes

[Rob Clark]

On Sun, Feb 22, 2015 at 5:38 AM, Daniel Vetter  
wrote:
> In
>
> daniel at phenom:~/linux/src$ git show ccfc08655
> commit ccfc08655d5fd5076828f45fb09194c070f2f63a
> Author: Rob Clark 
> Date:   Thu Dec 18 16:01:48 2014 -0500
>
> drm: tweak getconnector locking
>
> We need to extend the locking to cover connector->state reading for
> atomic drivers, but the above commit was a bit too eager and also
> included the fill_modes callback. Which on i915 on old platforms using
> load detection needs to acquire modeset locks, resulting in a deadlock
> on output probing.
>
> Reported-by: Marc Finet 
> Cc: Marc Finet 
> Cc: robdclark at gmail.com
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_crtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b15d720eda4c..ce5f1193ecd6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2180,7 +2180,6 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
> DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id);
>
> mutex_lock(>mode_config.mutex);
> -   drm_modeset_lock(>mode_config.connection_mutex, NULL);
>
> connector = drm_connector_find(dev, out_resp->connector_id);
> if (!connector) {
> @@ -2210,6 +2209,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
> out_resp->mm_height = connector->display_info.height_mm;
> out_resp->subpixel = connector->display_info.subpixel_order;
> out_resp->connection = connector->status;
> +
> +   drm_modeset_lock(>mode_config.connection_mutex, NULL);
> encoder = drm_connector_get_encoder(connector);
> if (encoder)
> out_resp->encoder_id = encoder->base.id;
> --
> 2.1.4
>

[Bug 90861] Panic on suspend from KDE with radeon

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #13 from Maarten Lankhorst  ---
Does attachment 166571 fix the bug for you too? I think that would be the best
version to upstream.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 89256] [radeonsi][CSGO] many rendering artifacts and more

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Michel Dänzer  ---
Does it work better with current Mesa Git master? Specifically, this commit
might help at least for the rendering artifacts:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=7692704b144b2aa9a57767a43212ceb5aad6638a

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/dfbb6e66/attachment.html>

[Bug 89275] PC sometimes hangs on suspend

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from sunweb at hotmail.ru ---
Created attachment 113748
  --> https://bugs.freedesktop.org/attachment.cgi?id=113748=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/2ebfd9df/attachment-0001.html>

[Bug 89275] PC sometimes hangs on suspend

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from sunweb at hotmail.ru ---
Created attachment 113747
  --> https://bugs.freedesktop.org/attachment.cgi?id=113747=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/2ebe520a/attachment.html>

[PATCH] drm/atomic-helpers: Fix documentation typos and wrong copy

[Laurent Pinchart]

The kerneldoc blocks for the drm_atomic_helper_*_set_property()
functions seem to have been copied from the plane disable handler
without being properly updated. Fix them.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_helper.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index caafc237c28b..df13c70d7899 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1689,12 +1689,13 @@ backoff:
 EXPORT_SYMBOL(drm_atomic_helper_set_config);

 /**
- * drm_atomic_helper_crtc_set_property - helper for crtc prorties
+ * drm_atomic_helper_crtc_set_property - helper for crtc properties
  * @crtc: DRM crtc
  * @property: DRM property
  * @val: value of property
  *
- * Provides a default plane disablle handler using the atomic driver interface.
+ * Provides a default crtc set_property handler using the atomic driver
+ * interface.
  *
  * RETURNS:
  * Zero on success, error code on failure
@@ -1748,12 +1749,13 @@ backoff:
 EXPORT_SYMBOL(drm_atomic_helper_crtc_set_property);

 /**
- * drm_atomic_helper_plane_set_property - helper for plane prorties
+ * drm_atomic_helper_plane_set_property - helper for plane properties
  * @plane: DRM plane
  * @property: DRM property
  * @val: value of property
  *
- * Provides a default plane disable handler using the atomic driver interface.
+ * Provides a default plane set_property handler using the atomic driver
+ * interface.
  *
  * RETURNS:
  * Zero on success, error code on failure
@@ -1807,12 +1809,13 @@ backoff:
 EXPORT_SYMBOL(drm_atomic_helper_plane_set_property);

 /**
- * drm_atomic_helper_connector_set_property - helper for connector prorties
+ * drm_atomic_helper_connector_set_property - helper for connector properties
  * @connector: DRM connector
  * @property: DRM property
  * @val: value of property
  *
- * Provides a default plane disablle handler using the atomic driver interface.
+ * Provides a default connector set_property handler using the atomic driver
+ * interface.
  *
  * RETURNS:
  * Zero on success, error code on failure
-- 
2.0.5

eDP display control registers in Linux kernel

[Stéphane Marchesin]

On Sun, Feb 22, 2015 at 11:59 PM, Jani Nikula  wrote:
>
> Hi Michael -
>
> Please always cc: the relevant mailing lists; done now.
>
> On Sun, 22 Feb 2015, Michael Leuchtenburg  wrote:
>> Hi Jani,
>>
>> I've been trying to figure out how to control the dynamic backlight control
>> on my new Dell XPS 13 since the defaults are atrocious - huge swings in
>> brightness from a black background to a white one, over a few seconds
>> period so it's very obvious. I eventually tracked down a patch from the
>> Chromium folks that adds a sysfs interface (
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/db5eacd6ac7a0cbda4ea1010fabbd3ff6b30e0bc%5E%21/),
>> but it seems to depend on your patch that adds eDP display control
>> registers (
>> http://lists.freedesktop.org/archives/dri-devel/2013-November/049098.html),
>> which was never merged into mainline as far as I can tell.
>>
>> Do you know what the status of that is? Is it still wending its way through
>> the process (now, over a year later) or did it die somewhere along the way?
>> The patch doesn't apply to mainline today, though it's simple enough that I
>> suspect it'd be easy to adapt. I'd rather see where it went, though.
>>
>> I'd appreciate any help you can offer.
>
> The Chrome OS patches wouldn't be acceptable upstream, and indeed
> they've never been posted upstream. A more driver agnostic approach
> would be required.

I actually asked Eric to make a property version of this:
https://chromium-review.googlesource.com/#/c/244165/

Once this lands in Chrome OS, we should upstream it.

Stéphane

>
> My patches were simple, adding some macros etc. They were reviewed but
> apparently forgotten, also by me. I'll repost them, but they won't do
> you much good in this case.
>
> I'm also not convinced yet that your problem would be solved by the
> patches; are you sure Dell XPS 13 does have dynamic backlight control in
> the panel, adjustable via DPCD?
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 89275] PC sometimes hangs on suspend

[bugzilla-dae...@freedesktop.org]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Drivers/Gallium/r600|DRM/Radeon
Version|10.3|unspecified
Product|Mesa|DRI
 QA Contact|dri-devel at lists.freedesktop |
   |.org|

--- Comment #1 from Michel Dänzer  ---
Please attach the output of dmesg and the /var/log/Xorg.0.log file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150223/d5cc2837/attachment.html>

[PATCH] drm/msm/atomic: Don't leak atomic commit object when commit fails

[Laurent Pinchart]

If the atomic commit fails due to completion wait interruption the
atomic commit object is not freed and is thus leaked. Free it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/msm/msm_atomic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 7c412292a0ff..5b192128cda2 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -219,8 +219,10 @@ int msm_atomic_commit(struct drm_device *dev,
 * mark our set of crtc's as busy:
 */
ret = start_atomic(dev->dev_private, c->crtc_mask);
-   if (ret)
+   if (ret) {
+   kfree(c);
return ret;
+   }

/*
 * This is the point of no return - everything below never fails except
-- 
Regards,

Laurent Pinchart