GSoC 2015: The X.Org Foundation has been accepted as a mentoring organisation

[Martin Peres]

Hello,

I have the pleasure to announce you that the X.Org Foundation has been 
accepted as a mentoring organisation for the Google Summer of Code 2015. 
This means that your project can receive students again this year!

Here are the important dates coming[0]:
- 16 March: Student application period opens.
- 27 March: Student application deadline.
- 24 April: All mentors must be signed up and all student proposals 
matched with a mentor
- 27 April: Accepted student proposals announced on the Google Summer of 
Code 2015 site

Potential mentors:
Please put up your project ideas on our ideas page[1] by the end of the 
week to get the maximum chance of finding the best student possible. In 
any case, you are required to put your project up before March 16th.

Students:
Consult our ideas page[1] or come up with your own project idea. In any 
case, apply as soon as possible, take contact with potential mentors and 
ask them for advices on how to improve your chances of being accepted. 
This year, we are going to be a bit stricter than usual when it comes to 
selecting students. You thus have until April 23rd to get a patch 
accepted upstream to show us you can work in the open source community 
and with the usual tools (git, gcc, autotools, cmake, ...). An idea 
could be for you to pick a simple bug from the project's bugzilla and 
fix it. If you already have submitted patches to your project of choice 
or a closely-related project, you do not have to do anything. We however 
would still advice you to show your interest by providing patches or 
participating to our discussions.

Finally, I would like to thank Google again this year for giving us the 
opportunity to get new blood to the projects under the X.Org 
Foundation's umbrella!

Martin Peres, on behalf of the board of directors

[0] https://www.google-melange.com/gsoc/events/google/gsoc2015
[1] http://www.x.org/wiki/SummerOfCodeIdeas/

[Bug 94151] Graphics (X11) hangs

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

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

--- Comment #1 from Victor Porton  ---
$ sudo lshw
victor.local
description: Computer
product: PROD
vendor: OEM0
width: 32 bits
capabilities: smbios-2.4 smp-1.4 smp vsyscall32
configuration: cpus=4
  *-core
   description: Motherboard
   physical id: 0
 *-cpu:0
  product: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
  vendor: Intel Corp.
  physical id: 0
  bus info: cpu at 0
  version: 6.10.7
  serial: 0002-06A7----
  size: 3400MHz
  capacity: 3800MHz
  width: 64 bits
  capabilities: boot fpu fpu_exception wp vme de pse tsc msr pae mce
cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
ht tm pbe syscall nx rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm
tpr_shadow vnmi flexpriority ept vpid cpufreq
  configuration: id=7
*-logicalcpu:0
 description: Logical CPU
 physical id: 7.1
 width: 64 bits
 capabilities: logical
*-logicalcpu:1
 description: Logical CPU
 physical id: 7.2
 width: 64 bits
 capabilities: logical
*-logicalcpu:2
 description: Logical CPU
 physical id: 7.3
 width: 64 bits
 capabilities: logical
*-logicalcpu:3
 description: Logical CPU
 physical id: 7.4
 width: 64 bits
 capabilities: logical
*-logicalcpu:4
 description: Logical CPU
 physical id: 7.5
 width: 64 bits
 capabilities: logical
*-logicalcpu:5
 description: Logical CPU
 physical id: 7.6
 width: 64 bits
 capabilities: logical
*-logicalcpu:6
 description: Logical CPU
 physical id: 7.7
 width: 64 bits
 capabilities: logical
*-logicalcpu:7
 description: Logical CPU
 physical id: 7.8
 width: 64 bits
 capabilities: logical
*-logicalcpu:8
 description: Logical CPU
 physical id: 7.9
 width: 64 bits
 capabilities: logical
*-logicalcpu:9
 description: Logical CPU
 physical id: 7.a
 width: 64 bits
 capabilities: logical
*-logicalcpu:10
 description: Logical CPU
 physical id: 7.b
 width: 64 bits
 capabilities: logical
*-logicalcpu:11
 description: Logical CPU
 physical id: 7.c
 width: 64 bits
 capabilities: logical
*-logicalcpu:12
 description: Logical CPU
 physical id: 7.d
 width: 64 bits
 capabilities: logical
*-logicalcpu:13
 description: Logical CPU
 physical id: 7.e
 width: 64 bits
 capabilities: logical
*-logicalcpu:14
 description: Logical CPU
 physical id: 7.f
 width: 64 bits
 capabilities: logical
*-logicalcpu:15
 description: Logical CPU
 physical id: 7.10
 width: 64 bits
 capabilities: logical
 *-cpu:1
  physical id: 1
  bus info: cpu at 1
  version: 6.10.7
  serial: 0002-06A7----
  size: 3400MHz
  capacity: 3800MHz
  capabilities: vmx ht cpufreq
  configuration: id=7
*-logicalcpu:0
 description: Logical CPU
 physical id: 7.1
 capabilities: logical
*-logicalcpu:1
 description: Logical CPU
 physical id: 7.2
 capabilities: logical
*-logicalcpu:2
 description: Logical CPU
 physical id: 7.3
 capabilities: logical
*-logicalcpu:3
 description: Logical CPU
 physical id: 7.4
 capabilities: logical
*-logicalcpu:4
 description: Logical CPU
 physical id: 7.5
 capabilities: logical
*-logicalcpu:5
 description: Logical CPU
 physical id: 7.6
 capabilities: logical
*-logicalcpu:6
 description: Logical CPU
 physical id: 7.7
 capabilities: logical
*-logicalcpu:7
 description: Logical CPU
 physical id: 7.8
 capabilities: logical
*-logicalcpu:8
 description: Logical CPU

[Bug 94151] New: Graphics (X11) hangs

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

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

Bug ID: 94151
   Summary: Graphics (X11) hangs
   Product: Drivers
   Version: 2.5
Kernel Version: 3.10-2-amd64
  Hardware: Intel
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: porton at narod.ru
Regression: No

In Gnome anything stopped to function except of mouse moving. Mouse clicks, key
presses (including attempts to switch windows) stopped to work.

I pressed Alt+Ctrl+Backspace. The top window (which was maximized) disappered,
the next (also maximized) window appeared with titlebar only and gray instead
of window content.

After pressing Alt+Ctrl+F1 I saw this message:

[87576.396057] nouveau E[ DRM] GPU lockup - switching to software fbcon

Then I gave `reboot` command. While rebooting there was an approximately the
following message:

nouveau ... failed to idle channel 0x ...

The bug repeats about once per two days :-(

I have a 32 bit Debian Linux "testing" system with 64 bit kernel.

$ uname -a
Linux victor.local 3.10-2-amd64 #1 SMP Debian 3.10.7-1 (2013-08-17) x86_64
GNU/Linux

$ lsmod
Module  Size  Used by
binfmt_misc12925  1 
cpufreq_powersave  12454  0 
cpufreq_stats  12866  0 
cpufreq_conservative14184  0 
cpufreq_userspace  12576  0 
snd_hda_codec_hdmi 31720  4 
coretemp   12898  0 
iTCO_wdt   12831  0 
iTCO_vendor_support12704  1 iTCO_wdt
kvm_intel 123583  0 
kvm   301458  1 kvm_intel
snd_hda_codec_realtek32712  1 
crc32c_intel   21850  0 
nouveau   731557  3 
gspca_t613 16982  0 
ghash_clmulni_intel13062  0 
gspca_main 26962  1 gspca_t613
videodev   92407  2 gspca_main,gspca_t613
aesni_intel50895  0 
media  18240  1 videodev
aes_x86_64 16719  1 aesni_intel
mxm_wmi12515  1 nouveau
ablk_helper12572  1 aesni_intel
snd_hda_intel  35718  7 
wmi13243  2 mxm_wmi,nouveau
cryptd 14560  3 ghash_clmulni_intel,aesni_intel,ablk_helper
video  17792  1 nouveau
lrw12871  1 aesni_intel
snd_hda_codec 122850  3
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
gf128mul   13047  1 lrw
ttm54470  1 nouveau
glue_helper12768  1 aesni_intel
snd_hwdep  13189  1 snd_hda_codec
drm_kms_helper 31837  1 nouveau
snd_pcm_oss41175  0 
evdev  17611  24 
drm   211856  5 ttm,drm_kms_helper,nouveau
snd_mixer_oss  18034  1 snd_pcm_oss
serio_raw  12940  0 
snd_pcm68525  5
snd_pcm_oss,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
i2c_algo_bit   12841  1 nouveau
i2c_i801   17045  0 
pcspkr 12632  0 
snd_page_alloc 13018  2 snd_pcm,snd_hda_intel
i2c_core   20257  6
drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
snd_timer  22773  1 snd_pcm
lpc_ich16757  0 
snd53068  22
snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec,snd_hda_intel,snd_mixer_oss
mfd_core   12601  1 lpc_ich
soundcore  13026  1 snd
mei_me 13568  0 
mei41790  1 mei_me
mperf  12453  0 
shpchp 31346  0 
button 12944  1 nouveau
processor  28526  0 
thermal_sys23137  2 video,processor
loop   22869  0 
fuse   67503  3 
parport_pc 22409  0 
ppdev  12763  0 
lp 13025  0 
parport31901  3 lp,ppdev,parport_pc
autofs427746  2 
ext4  381419  2 
crc16  12343  1 ext4
jbd2   76205  1 ext4
mbcache13082  1 ext4
microcode  30413  0 
sg 26095  0 
sd_mod 40541  5 
crc_t10dif 12348  1 sd_mod
hid_generic12393  0 
usbhid 40964  0 
hid81894  2 hid_generic,usbhid
ahci   25148  3 
libahci23136  1 ahci
ehci_pci   12472  0 
xhci_hcd   78280  0 
ehci_hcd   40590  1 ehci_pci
libata141969  2 ahci,libahci
firewire_ohci  31931  0 
scsi_mod  158249  3 sg,libata,sd_mod
firewire_core  49211  1 firewire_ohci
crc_itu_t  12347  1 firewire_core
r8169  52872  0 
usbcore   134993  7

[Bug 90741] Radeon: System pauses on TAHITI

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #72 from Alex Deucher  ---
Does reading any arbitrary register also work?  E.g., SRBM_STATUS

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

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

[Tommi Rantala]

2015-02-24 1:55 GMT+02:00 Marc Finet :
> On Sun, Feb 22, 2015 at 11:38:36AM +0100, 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 
>
> Tested-by: Marc Finet 
>
> Thanks.
>> ---
>>  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
>>

Hi,

I think this patch introduced the following.

If the drm_connector_find() call fails, we jump to the 'out' label and
call drm_modeset_unlock(), before the drm_modeset_lock() call.

[   59.076011] =
[   59.076011] [ BUG: bad unlock balance detected! ]
[   59.076011] 4.0.0-rc1+ #60 Tainted: GW
[   59.076011] -
[   59.076011] trinity-c14/2418 is trying to release lock
(crtc_ww_class_mutex) at:
[   59.076011] [] ww_mutex_unlock+0x42/0xb0
[   59.076011] but there are no more locks to release!
[   59.076011]
[   59.076011] other info that might help us debug this:
[   59.076011] 1 lock held by trinity-c14/2418:
[   59.076011]  #0:  (>mode_config.mutex){+.+.+.}, at:
[] drm_mode_getconnector+0x83/0x400
[   59.076011]
[   59.076011] stack backtrace:
[   59.076011] CPU: 0 PID: 2418 Comm: trinity-c14 Tainted: GW
 4.0.0-rc1+ #60
[   59.076011] Hardware name: Hewlett-Packard HP Compaq dc5750 Small
Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[   59.076011]  81dc2872 88005b777b48 81db6706

[   59.076011]  88005b719440 88005b777b78 810f8074
001d51c0
[   59.076011]  880069d3a5d0 88005b719440 81dc2872
88005b777bf8
[   59.076011] Call Trace:
[   59.076011]  [] ? ww_mutex_unlock+0x42/0xb0
[   59.076011]  [] dump_stack+0x4c/0x65
[   59.076011]  [] print_unlock_imbalance_bug+0xf4/0x100
[   59.076011]  [] ? ww_mutex_unlock+0x42/0xb0
[   59.076011]  [] lock_release_non_nested+0x24e/0x350
[   59.076011]  [] ? mark_held_locks+0x75/0xa0
[   59.076011]  [] ? __mutex_unlock_slowpath+0xad/0x170
[   59.076011]  [] ? ww_mutex_unlock+0x42/0xb0
[   59.076011]  [] lock_release+0xbc/0x380
[   59.076011]  [] __mutex_unlock_slowpath+0x71/0x170
[   59.076011]  [] ? drm_mode_getconnector+0x83/0x400
[   59.076011]  [] ww_mutex_unlock+0x42/0xb0
[   59.076011]  [] drm_modeset_unlock+0x2f/0x40
[   59.076011]  [] drm_mode_getconnector+0x280/0x400
[   59.076011]  [] ? might_fault+0x57/0xb0
[   59.076011]  [] drm_ioctl+0x19c/0x640
[   59.076011]  [] ? trace_hardirqs_on+0xd/0x10
[   59.076011]  [] radeon_drm_ioctl+0x46/0x80
[   59.076011]  [] do_vfs_ioctl+0x318/0x570
[   59.076011]  [] ? selinux_file_ioctl+0x56/0x110
[   59.076011]  [] SyS_ioctl+0x81/0xa0
[   59.076011]  [] system_call_fastpath+0x12/0x17
[   59.316190] [drm:radeon_gem_pread_ioctl] *ERROR* unimplemented
radeon_gem_pread_ioctl
[   59.579952] [drm:radeon_info_ioctl] *ERROR* copy_to_user
radeon_info_ioctl:555
[watchdog] kernel became tainted! (512/0) Last seed was 1541132817

Tommi

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #71 from Maarten Lankhorst  ---
Thanks for helping investigate, I will send the attachment as a bugfix to bug
90861, that bug is specifically about the waitqueue ordering in
radeon_fence_default_wait. That one was really caused by me.

The bug here just happened to be triggered more reliably because there is a lot
less wait time between sw_irq_get and radeon_fence_read. It needs some kind of
barrier but I'm not sure which one. The radeon dev Alex Deucher will look into
it and talk with some other people about the proper way to fix this.

Thanks for all your help, I'll cc you when I send my bugfix.

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

[PATCH] drm/radeon: fix DRM_IOCTL_RADEON_CS oops

[Tommi Rantala]

Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
following oops.

Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().

--

 #include 
 #include 
 #include 
 #include 
 #include 

 static const struct drm_radeon_cs cs;

 int main(int argc, char **argv)
 {
 return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, );
 }

--

[ttrantal at test2 ~]$ ./main /dev/dri/card0
[   46.904650] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   46.905022] IP: [] list_sort+0x42/0x240
[   46.905022] PGD 68f29067 PUD 688b5067 PMD 0
[   46.905022] Oops: 0002 [#1] SMP
[   46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
[   46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form 
Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[   46.905022] task: 880058e2bcc0 ti: 880058e64000 task.ti: 
880058e64000
[   46.905022] RIP: 0010:[]  [] 
list_sort+0x42/0x240
[   46.905022] RSP: 0018:880058e67998  EFLAGS: 00010246
[   46.905022] RAX:  RBX:  RCX: 
[   46.905022] RDX: 81644410 RSI: 880058e67b40 RDI: 880058e67a58
[   46.905022] RBP: 880058e67a88 R08:  R09: 
[   46.905022] R10: 880058e2bcc0 R11: 828e6ca0 R12: 81644410
[   46.905022] R13: 8800694b8018 R14:  R15: 880058e679b0
[   46.905022] FS:  7fdc65a65700() GS:88006d60() 
knlGS:
[   46.905022] CS:  0010 DS:  ES:  CR0: 80050033
[   46.905022] CR2:  CR3: 58dd9000 CR4: 06f0
[   46.905022] DR0:  DR1:  DR2: 
[   46.905022] DR3:  DR6: 4ff0 DR7: 0400
[   46.905022] Stack:
[   46.905022]  880058e67b40 880058e2bcc0 880058e67a78 

[   46.905022]     

[   46.905022]     

[   46.905022] Call Trace:
[   46.905022]  [] radeon_cs_parser_fini+0x195/0x220
[   46.905022]  [] radeon_cs_ioctl+0xa9/0x960
[   46.905022]  [] drm_ioctl+0x19c/0x640
[   46.905022]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[   46.905022]  [] ? trace_hardirqs_on+0xd/0x10
[   46.905022]  [] radeon_drm_ioctl+0x46/0x80
[   46.905022]  [] do_vfs_ioctl+0x318/0x570
[   46.905022]  [] ? selinux_file_ioctl+0x56/0x110
[   46.905022]  [] SyS_ioctl+0x81/0xa0
[   46.905022]  [] system_call_fastpath+0x12/0x17
[   46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7
00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
[   46.905022] RIP  [] list_sort+0x42/0x240
[   46.905022]  RSP 
[   46.905022] CR2: 
[   47.149253] ---[ end trace 09576b4e8b2c20b8 ]---

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index a579ed3..4d0f96c 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -256,11 +256,13 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
void *data)
u32 ring = RADEON_CS_RING_GFX;
s32 priority = 0;

+   INIT_LIST_HEAD(>validated);
+
if (!cs->num_chunks) {
return 0;
}
+
/* get chunks */
-   INIT_LIST_HEAD(>validated);
p->idx = 0;
p->ib.sa_bo = NULL;
p->const_ib.sa_bo = NULL;
-- 
1.9.3

[PATCH RFC v9 00/20] Add support for i.MX MIPI DSI DRM driver

[Shawn Guo]

On Thu, Feb 12, 2015 at 02:01:23PM +0800, Liu Ying wrote:
> Liu Ying (20):
>   clk: divider: Correct parent clk round rate if no bestdiv is normally
> found

>   ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits
> definition
>   ARM: imx6q: clk: Add the video_27m clock
>   ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock
>   ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate
>   ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock
> gate
>   ARM: imx6q: clk: Add support for mipi_ipg clock as a shared clock gate
>   ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports'
> node

Applied above 7 i.MX patches (#2 ~ #8).

Shawn

>   drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
>   Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
> bridge driver
>   drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
>   Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW
> MIPI DSI driver
>   drm: imx: Support Synopsys DesignWare MIPI DSI host controller
>   Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel
> driver
>   drm: panel: Add support for Himax HX8369A MIPI DSI panel
>   ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
>   ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI
> DSI panel
>   ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of
> staging
>   ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller
>   ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #70 from Gustaw Smolarczyk  ---
mb(); is ok.

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

[Bug 89374] Firefox smooth scrolling isn't smooth

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

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

--- Comment #2 from sunweb at hotmail.ru ---
Hi, here're the files https://bugs.freedesktop.org/show_bug.cgi?id=89275

I don't have xorg.conf and installing glamor package didn't work out because of
Ubuntu bug.

-- 
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/20150302/ca0a7971/attachment.html>

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #69 from Maarten Lankhorst  ---
Hm full mb(); ?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #68 from Gustaw Smolarczyk  ---
rmb(); doesn't seem to be enough.

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

[PATCH 14/21] drm/omap: stop connector polling during suspend

[Grygorii Strashko]

On 03/02/2015 01:03 PM, Tomi Valkeinen wrote:
> On 26/02/15 15:57, Grygorii.Strashko at linaro.org wrote:
> 
>> Could I ask you to update this patch as below, pls?
> 
> Your changes look ok to me, but they are not related to my patch so I
> don't see any reason to merge them. I'll pick your patch to my series.

Sure. Thanks a lot. Ping me if anything will need to be done from my side.

Regards,
- grygorii

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #67 from Maarten Lankhorst  ---
what about a rmb(); there instead?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #66 from Gustaw Smolarczyk  ---
It seems that way. I hope others can check that too.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #65 from Maarten Lankhorst  ---
So attachment 166571 and the rreg32 addition is enough?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #64 from Gustaw Smolarczyk  ---
Yes, the fix still works.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #63 from Maarten Lankhorst  ---
What about changing the udelay to a RREG32(DMA_CNTL + DMA0_REGISTER_OFFSET); ?

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

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #11 from Vedran Rodic  ---
Created attachment 113924
  --> https://bugs.freedesktop.org/attachment.cgi?id=113924=edit
valgrind steam run, error should near the end of the file

valgrind steam run, error should near the end of the 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/20150302/e64973d3/attachment.html>

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #10 from Vedran Rodic  ---
I don't have pre 3.16 kernel easily available. 

export GAME_DEBUGGER=gdb still makes the game crash before it runs it with the
debugger.

I've tried various things to make it work (modifying the game startup shell
script) but without success. 

When I put the older version of libdrm
(86b37c61c78edd1353a3f76f678c39e2ec168771, before Tvrtkos change), gdb runs
normally for the game. So the steam binary actually crashes, not the game
itself. 

It's funny because steam binary is 32bit, Dota 2 binary is 64 bit, and only
changing the 64bit version of libdrm_intel.so affects this bug. 

I've tried debugging steam with export DEBUGGER=gdb, but it seems spawn
multiple threads and I'm not experienced with multithreaded debugging. 

I did manage to run steam with valgrind, I'll add an attachment now.

-- 
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/20150302/de407288/attachment.html>

[PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio

[Yakir Yang]

在 2015/3/2 17:07, Paul Bolle 写道:
> On Sat, 2015-02-28 at 22:04 -0500, Yakir Yang wrote:
>> --- /dev/null
>> +++ b/sound/soc/rockchip/rockchip_hdmi_audio.c
>> @@ -0,0 +1,169 @@
>> +/*
>> + * rockchip-hdmi-card.c
> Doesn't match the filename. Is this line needed anyway?

Thanks, this comment are good for read, and seems others codec driver 
also content this comment,
so I think we can keep this comment.
I will correct the file name it in next version.

Thanks for you reply   :)

>> + *
>> + * ROCKCHIP ALSA SoC DAI driver for HDMI audio on rockchip processors.
>> + * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved.
>> + * Authors: Yakir Yang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .*
>> + *
>> + */
> This states the license is plain GPL v2.

Okay, thanks, correct it in next version.

Thanks

Yakir Yang
Best regards.
>> +MODULE_LICENSE("GPL");
> So you probably want
>  MODULE_LICENSE("GPL v2");
>
> here.
>
>
> Paul Bolle
>
>
>
>

[PATCH v4 13/15] ASoC: codec/dw-hdmi-audio: add codec driver for dw hdmi audio

[Yakir Yang]

在 2015/3/2 17:15, Paul Bolle 写道:
> On Sat, 2015-02-28 at 21:59 -0500, Yakir Yang wrote:
>> --- /dev/null
>> +++ b/sound/soc/codecs/dw-hdmi-audio.c
>> @@ -0,0 +1,379 @@
>> +/*
>> + * dw-hdmi-codec.c
> Doesn't match the filename. Is this line needed?

Thanks, this comment are good for read, and seems others codec driver 
also content this comment,
so I think we can keep this comment.
I will correct the file name it in next version.

Thanks for you reply :)
>
>> + * DesignerWare ALSA SoC DAI driver for DW HDMI audio.
>> + * Copyright (c) 2014,  CORPORATION. All rights reserved.
>> + * Authors: Yakir Yang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .*
>> + *
>> + */
> This states that the license is plain GPL v2.
>
> (Missing empty line here.)

Okay, thanks, correct it in next version.

Thanks :)
>> +#include 
> [...]
>
>> +MODULE_LICENSE("GPL");
> So you probably want
>  MODULE_LICENSE("GPL v2");
>
> here.
Okay, thanks, correct it in next version.

Thanks :)

Yakir Yang
Best regards.

>
> Paul Bolle
>
>
>
>

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #62 from Gustaw Smolarczyk  ---
Even 1us works.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #61 from Gustaw Smolarczyk  ---
5us is ok.

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

[PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Tomi Valkeinen]

On 02/03/15 18:06, Russell King - ARM Linux wrote:

>> This is missing the output of tda998x. It should have two ports, input
>> and output, output going to hdmi-connector.
> 
> We don't have that kind of level of modelling in DRM right now - as far
> as DRM is concerned, the tda998x is both the encoder _and_ the connector
> since it supplies both functionalities.

That's fine, but these are DT bindings which should reflect the
hardware, not the SW stack.

> We did discuss this ages ago, but afaik no concensus was reached how to
> model physical connectors in DT, so it never moved forward in DRM (and

I don't know about consensus, but omapdss is using connectors in DT, and
they were discussed in lists, and everyone seemed to be ok with that
model (Documentation/devicetree/bindings/video/hdmi-connector.txt). If I
recall right, the only real question was how the links should be modeled
(two way, one way, something else), but that's not specific to connectors.

So while it's open how they should be implemented in the DRM, I don't
see why we couldn't/shouldn't specify them in the .dts.

That said, if and when DRM supports connectors defined in .dts, we can
just assume that if tda998x does not have an output defined in the .dts,
it's connected to a HDMI connector. So we should do just fine even if we
end up not defining the connectors at this time.

> besides, everyone seems to be off doing their own thing when it comes
> to writing DT descriptions for video hardware.)

Yep... I've been trying to push the video ports/endpoints system which
afaik covers about all the use cases that have been raised. But the
counter argument usually is that "it's too complex".

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/ac273d97/attachment-0001.sig>

[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 #87 from Kamil Páral  ---
Hi Ben, this is not a forum, it's a bug reporting tool. You'll need to wait
until your distribution ships linux kernel 4.0 (I assume that would be Lubuntu
15.04 or 15.10). Then it should "just work". If it doesn't, you can create a
new ticket here, report the issue, and attach all relevant information to it
(ask for help at #radeon channel on freenode irc in that case).

-- 
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/20150302/f77e86fc/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 #86 from Ben  ---
Hello,

I am using Lubuntu 14.04 with 2 Apple Monitors using 2 mini Display ports on my
Gigabyte Radeon R7 250X OC and have the same issue: fan running fast while
temperature is low. I never used this forum before and browsed the net for
hours to find solutions. Can somebody explain to me what exactly to do to fix
this?

Best regards,
Ben

-- 
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/20150302/38c80c85/attachment-0001.html>

[PATCH] drm/msm: kexec fixes

[Rob Clark]

In kexec environment, we are more likely to encounter irq's already
enabled from previous environment.  At which point we find that writes
to disable/clear pending irq's are slightly less than useless without
first enabling clocks.

TODO: full blown state read-in so kexec'd kernel can inherit the mode
already setup.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 5 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
index 8edd531c..7369ee7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
@@ -32,7 +32,10 @@ static void mdp4_irq_error_handler(struct mdp_irq *irq, 
uint32_t irqstatus)
 void mdp4_irq_preinstall(struct msm_kms *kms)
 {
struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+   mdp4_enable(mdp4_kms);
mdp4_write(mdp4_kms, REG_MDP4_INTR_CLEAR, 0x);
+   mdp4_write(mdp4_kms, REG_MDP4_INTR_ENABLE, 0x);
+   mdp4_disable(mdp4_kms);
 }

 int mdp4_irq_postinstall(struct msm_kms *kms)
@@ -53,7 +56,9 @@ int mdp4_irq_postinstall(struct msm_kms *kms)
 void mdp4_irq_uninstall(struct msm_kms *kms)
 {
struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+   mdp4_enable(mdp4_kms);
mdp4_write(mdp4_kms, REG_MDP4_INTR_ENABLE, 0x);
+   mdp4_disable(mdp4_kms);
 }

 irqreturn_t mdp4_irq(struct msm_kms *kms)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index 70ac81e..a940710 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -34,7 +34,10 @@ static void mdp5_irq_error_handler(struct mdp_irq *irq, 
uint32_t irqstatus)
 void mdp5_irq_preinstall(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   mdp5_enable(mdp5_kms);
mdp5_write(mdp5_kms, REG_MDP5_INTR_CLEAR, 0x);
+   mdp5_write(mdp5_kms, REG_MDP5_INTR_EN, 0x);
+   mdp5_disable(mdp5_kms);
 }

 int mdp5_irq_postinstall(struct msm_kms *kms)
@@ -57,7 +60,9 @@ int mdp5_irq_postinstall(struct msm_kms *kms)
 void mdp5_irq_uninstall(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   mdp5_enable(mdp5_kms);
mdp5_write(mdp5_kms, REG_MDP5_INTR_EN, 0x);
+   mdp5_disable(mdp5_kms);
 }

 static void mdp5_irq_mdp(struct mdp_kms *mdp_kms)
-- 
2.1.0

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #60 from Maarten Lankhorst  ---
can you add a if (fence->ring == R600_RING_TYPE_DMA_INDEX) udelay(50); to
radeon_fence_enable_signaling? after the irq_get again. If that works try
udelay(5), if it doesn't udelay(500) ?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #59 from Maarten Lankhorst  ---
I was afraid of that, that's the ring used for eviction.

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

[Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Mon, Mar 2, 2015 at 5:53 PM, Linus Torvalds
 wrote:
> On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter  wrote:
>> And can you please attach a bactrace of the WARN in your patch, just to
>> double-check you blow up at the same spot?
>
> So the dmesg I attached had a backtrace for the new WARN_ONCE() (in
> addition to an unrelated(?) one from i915_gem_free_object()).
>
> Or did you mean a backtrace of the oops when things go wrong, when my
> patch is *not* applied? My first email had that with the kref.h
> warning from drm_framebuffer_reference, which is otherwise the same
> thing.

I've mixed things up with the other reporter which was full of the
subsequent oopses. But after I've sorted out why drm-intel-next
doesn't blow up the same way I see the bug now. Still baffled that we
underrun the refcount apparently since the same pile of legacy code +
atomic glue is used for the old modeset ioctl. But obviously something
is different, so still digging.

The gem_free_object backtrace is a completely unrelated issue. Fix for
that is in drm-intel-fixes and on the way to you:

commit 62e537f8d568347bbe4e00d7803a838750cdc618
Author: Rodrigo Vivi 
Date:   Tue Feb 24 13:37:54 2015 -0800

drm/i915: Fix frontbuffer false positve.

If that one doesn't help please scream ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v5 00/11] Improvements to Tegra-based Chromebook support

[Alexandre Courbot]

On Thu, Feb 12, 2015 at 5:50 PM, Tomeu Vizoso
 wrote:
> v5: * Moved to use gpio-restart for reboots, had to make tegra_pmc_restart
> a notification handler
>
> v4: * Added support for the system reset GPIO, for proper reboots
> * Moved out changes to ASOC to their own series, as requested by Mark
> Brown
> * Added patch to reset the SOR, to make sure it's in a known state
> * Changed nvidia,model property of the sound nodes to GoogleNyanBig
> and GoogleNyanBlaze so they can be told apart in userspace
>
> v3: * Added bindings for the LTN140AT29 panel
> * Removed the delay in pwrseq, as what was actually needed was to add
> a dependency on the power supplies of the host
> * Uses the pinmux for the Blaze as generated by tegra-pinmux-scripts
> * Uses the pinmux for the Big as in the last patch from Simon Glass
>
> Hello,
>
> this series adds support for the Tegra-based HP Chromebook 14 (aka nyan
> blaze), which is very similar to the Acer Chromebook 13 (aka nyan big).
> Because they both include tegra124-nyan.dtsi, some improvements to Blaze
> support have also benefitted the Big. I have tested that USB2, the panels,
> HDMI, the trackpad, Wifi and sound work on both.
>
> The leaf DTs contain the whole pinmux configuration as generated by
> tegra-pinmux-scripts. I chose to not put the common configuration in the
> common dtsi so we can paste the output as is and be sure that the kernel
> doesn't diverge from the canonical data.

FWIW, the series:

Reviewed-by: Alexandre Courbot 

[PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Russell King - ARM Linux]

On Mon, Mar 02, 2015 at 07:08:39PM +0200, Tomi Valkeinen wrote:
> On 02/03/15 18:06, Russell King - ARM Linux wrote:
> 
> >> This is missing the output of tda998x. It should have two ports, input
> >> and output, output going to hdmi-connector.
> > 
> > We don't have that kind of level of modelling in DRM right now - as far
> > as DRM is concerned, the tda998x is both the encoder _and_ the connector
> > since it supplies both functionalities.
> 
> That's fine, but these are DT bindings which should reflect the
> hardware, not the SW stack.

I still don't buy your argument.  The principle is right, but I think
you're taking it too far.

Look at ePAPR for a moment, and consider a serial port.  A serial UART
can be physically connected to a 9-pin or a 25-pin connector, which
may be male or female.  These details are not included in the DT
description.  Even when the serial port control signals are provided
by GPIOs rather than the UART, we don't model the connector - we
wrap the GPIOs directly into the UART driver.

Arguably, that's not following the hardware, it's following the software
representation - it's following the software representation of what a
serial port _should_ look like to a non-specific OS.

Consider an ethernet port.  You'll find the same thing applies - the
physical connector itself is not specified.

Yet, somehow, we're wanting to specify the physical connector for _all_
video devices?  I don't see why that should be mandatory when it's not
mandatory for other subsystems.

If we want to take this to the extreme, we should be specifying the
power connectors in DT and how they're wired up along with their
controls.  We don't though, we specify the control devices and
the function of those (eg, via a charger chip.)

To take this to the extreme, what about a device powered via PoE?
Should the PoE connector be modelled in DT?

When we say "DT should follow the hardware" we're not talking about
making DT be an alternative to the hardware's schematic.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v5 09/11] drm/tegra: Reset the SOR on probe

[Alexandre Courbot]

On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
 wrote:
> As there isn't a way for the firmware on the Nyan chromebooks to hand
> over the display to the kernel.

Could this have a side-effect on models for which the firmware *does*
hand over the display to the kernel? E.g. temporary glitch or black
screen?

This is probably ok though, as such a handing over would need to be
documented in the firmware/kernel command line, and could thus be
caught to disable that code block if needed.

[PATCH] drm/i915: Export total subslice and EU counts

[Jeff McGee]

On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> From: Jeff McGee 
> 
> Setup new I915_GETPARAM ioctl entries for subslice total and
> EU total. Userspace drivers need these values when constructing
> GPGPU commands. This kernel query method is intended to replace
> the PCI ID-based tables that userspace drivers currently maintain.
> The kernel driver can employ fuse register reads as needed to
> ensure the most accurate determination of GT config attributes.
> This first became important with Cherryview in which the config
> could differ between devices with the same PCI ID.
> 
> The kernel detection of these values is device-specific and not
> included in this patch. Because zero is not a valid value for any of
> these parameters, a value of zero is interpreted as unknown for the
> device. Userspace drivers should continue to maintain ID-based tables
> for older devices not supported by the new query method.
> 

We already have total EU detection support for Cherryview but we
need to add detection of total subslice. That support is included
in the below-linked series which has been reviewed but not yet
merged.

http://lists.freedesktop.org/archives/intel-gfx/2015-February/060945.html

Jeff

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #58 from Gustaw Smolarczyk  ---
This patch doesn't help.

I have been experimenting with forcing interrupts on only some rings. In the
end I have found that by adding "|| 1" only to R600_RING_TYPE_DMA_INDEX ring I
have removed the pauses.

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

[PATCH 1/5] drm: Pass in new and old plane state to prepare_fb and cleanup_fb

[Daniel Vetter]

On Mon, Mar 02, 2015 at 02:43:48PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Use cases like rotation require these hooks to have some context so they
> know how to prepare and cleanup the frame buffer correctly.
> 
> For i915 specifically, object backing pages need to be mapped differently
> for different rotation modes and the driver needs to know which mapping to
> instantiate and which to tear down when transitioning between them.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Cc: dri-devel at lists.freedesktop.org

Since I'm still somewhat afraid that drivers will abuse this creatively
and do some state computations in prepare_fb (which they absolutely may
not) I think it would be good to make this new parameter const. I plan to
follow up with other patches to make state objects const in the commit
phase.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c   | 13 -
>  drivers/gpu/drm/drm_plane_helper.c|  5 +++--
>  drivers/gpu/drm/i915/intel_display.c  |  6 --
>  drivers/gpu/drm/i915/intel_drv.h  |  6 --
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  6 --
>  drivers/gpu/drm/tegra/dc.c|  6 --
>  include/drm/drm_plane_helper.h|  6 --
>  7 files changed, 31 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3ce57f4..a745881 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1116,6 +1116,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
> *dev,
>   for (i = 0; i < nplanes; i++) {
>   struct drm_plane_helper_funcs *funcs;
>   struct drm_plane *plane = state->planes[i];
> + struct drm_plane_state *plane_state = state->plane_states[i];
>   struct drm_framebuffer *fb;
>  
>   if (!plane)
> @@ -1123,10 +1124,10 @@ int drm_atomic_helper_prepare_planes(struct 
> drm_device *dev,
>  
>   funcs = plane->helper_private;
>  
> - fb = state->plane_states[i]->fb;
> + fb = plane_state->fb;
>  
>   if (fb && funcs->prepare_fb) {
> - ret = funcs->prepare_fb(plane, fb);
> + ret = funcs->prepare_fb(plane, fb, plane_state);
>   if (ret)
>   goto fail;
>   }
> @@ -1138,6 +1139,7 @@ fail:
>   for (i--; i >= 0; i--) {
>   struct drm_plane_helper_funcs *funcs;
>   struct drm_plane *plane = state->planes[i];
> + struct drm_plane_state *plane_state = state->plane_states[i];
>   struct drm_framebuffer *fb;
>  
>   if (!plane)
> @@ -1148,7 +1150,7 @@ fail:
>   fb = state->plane_states[i]->fb;
>  
>   if (fb && funcs->cleanup_fb)
> - funcs->cleanup_fb(plane, fb);
> + funcs->cleanup_fb(plane, fb, plane_state);
>  
>   }
>  
> @@ -1254,6 +1256,7 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
> *dev,
>   for (i = 0; i < nplanes; i++) {
>   struct drm_plane_helper_funcs *funcs;
>   struct drm_plane *plane = old_state->planes[i];
> + struct drm_plane_state *plane_state = 
> old_state->plane_states[i];
>   struct drm_framebuffer *old_fb;
>  
>   if (!plane)
> @@ -1261,10 +1264,10 @@ void drm_atomic_helper_cleanup_planes(struct 
> drm_device *dev,
>  
>   funcs = plane->helper_private;
>  
> - old_fb = old_state->plane_states[i]->fb;
> + old_fb = plane_state->fb;
>  
>   if (old_fb && funcs->cleanup_fb)
> - funcs->cleanup_fb(plane, old_fb);
> + funcs->cleanup_fb(plane, old_fb, plane_state);
>   }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 5ba5792..813a066 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -437,7 +437,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>  
>   if (plane_funcs->prepare_fb && plane_state->fb &&
>   plane_state->fb != old_fb) {
> - ret = plane_funcs->prepare_fb(plane, plane_state->fb);
> + ret = plane_funcs->prepare_fb(plane, plane_state->fb,
> +   plane_state);
>   if (ret)
>   goto out;
>   }
> @@ -487,7 +488,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>   }
>  
>   if (plane_funcs->cleanup_fb && old_fb)
> - plane_funcs->cleanup_fb(plane, old_fb);
> + plane_funcs->cleanup_fb(plane, old_fb, plane_state);
>  out:
>   if (plane_state) {
>   if (plane->funcs->atomic_destroy_state)
> diff --git 

[PATCH] drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2

[Lucas Stach]

Am Montag, den 02.03.2015, 16:24 +0100 schrieb Philipp Zabel:
> This patch allows the IPU to divide the 27 MHz input clock from
> the TVE by two to obtain the 13.5 MHz pixel clock needed for
> NTSC/PAL SD modes.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/imx/ipuv3-crtc.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 35a3375..11a8d868 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -161,13 +161,16 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
>   __func__, encoder_types);
>  
>   /*
> -  * If we have DAC, TVDAC or LDB, then we need the IPU DI clock
> -  * to be the same as the LDB DI clock.
> +  * If we have DAC or LDB, then we need the IPU DI clock to be
> +  * the same as the LDB DI clock. For TVDAC, derive the IPU DI
> +  * clock from 27 MHz TVE_DI clock, but allow to divide it.
>*/
>   if (encoder_types & (BIT(DRM_MODE_ENCODER_DAC) |
>BIT(DRM_MODE_ENCODER_TVDAC) |

I suppose the above line has to be removed for this to work properly.

>BIT(DRM_MODE_ENCODER_LVDS)))
>   sig_cfg.clkflags = IPU_DI_CLKMODE_SYNC | IPU_DI_CLKMODE_EXT;
> + else if (encoder_types & BIT(DRM_MODE_ENCODER_TVDAC))
> + sig_cfg.clkflags = IPU_DI_CLKMODE_EXT;
>   else
>   sig_cfg.clkflags = 0;
>  

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH] Revert "drm/i915: Switch planes from transitional helpers to full atomic helpers"

[Daniel Vetter]

This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896.

We've been a bit too optimistic with this one here :(

The trouble is that internally we're still using these plane
update/disable hooks. Which was totally ok pre-atomic since the drm
core did all the book-keeping updating and these just mostly updated
hw state. But with atomic there's lots more going on, and it causes
heaps of trouble with the load detect code.

This one specifically cause a deadlock since both the load detect code
and the nested plane atomic helper functions tried to grab the same
locks. It only blows up because of the evil tricks though we play with
the implicit ww acquire context.

Applying this revert unearths the NULL deref on already freed
framebuffer objects reported as a regression in 4.0 by various people.

Fixing this will be fairly invasive, hence revert even for the
4.1-next queue.

Cc: Matt Roper 
Cc: Linus Torvalds 
Cc: Paul Bolle 
Signed-off-by: Daniel Vetter 
---
Just to make it really clear: This is 4.1-next material. It's simply
the explanation for why we didn't notice the oops ourselves. The 4.0
oops itself looks like some glue lacking in the load detect code,
still working on that one.
-Daniel
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3156d77b2215..cc3305e30c1b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12179,8 +12179,8 @@ void intel_plane_destroy(struct drm_plane *plane)
 }

 const struct drm_plane_funcs intel_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
+   .update_plane = drm_plane_helper_update,
+   .disable_plane = drm_plane_helper_disable,
.destroy = intel_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
.atomic_get_property = intel_plane_atomic_get_property,
-- 
1.8.4.rc3

[PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT

[Ajay kumar]

On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda  wrote:
> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
>> * Modify DECON-INT driver to support DECON-EXT.
>> * Add a table of porch values needed to set timing registers of DECON-EXT.
>> * DECON-EXT supports only H/w Triggered COMMAND mode.
>> * DECON-EXT supports only one DMA window(window 1), so modify
>>   all window management routines to support 2 windows of DECON-INT
>>   and 1 window of DECON-EXT.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/video/exynos7-decon.txt|8 +-
>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c |  229 
>> ++--
>>  include/video/exynos7_decon.h  |   13 ++
>>  3 files changed, 230 insertions(+), 20 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt 
>> b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> index f5f9c8d..87350c0 100644
>> --- a/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> @@ -2,10 +2,14 @@ Device-Tree bindings for Samsung Exynos7 SoC display 
>> controller (DECON)
>>
>>  DECON (Display and Enhancement Controller) is the Display Controller for the
>>  Exynos7 series of SoCs which transfers the image data from a video memory
>> -buffer to an external LCD interface.
>> +buffer to an external LCD/HDMI interface.
>> +
>> +Exynos7 supports DECON-INT for generating video signals for LCD.
>> +Exynos7 supports DECON-EXT for generating video signals for HDMI.
>>
>>  Required properties:
>> -- compatible: value should be "samsung,exynos7-decon";
>> +- compatible: value should be "samsung,exynos7-decon-int" for DECON-INT;
>> +   value should be "samsung,exynos7-decon-ext" for DECON-EXT;
>>
>>  - reg: physical base address and length of the DECON registers set.
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> index 63f02e2..9e2d083 100644
>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> @@ -41,6 +41,28 @@
>>
>>  #define WINDOWS_NR   2
>
> Maybe it would be better to rename it to MAX_WINDOWS_NR
Ok.
>>
>> +#define DECON_EXT_CH_MAPPING 0x432105
>
> I am not familiar with decon, could you explain what exactly
> this mapping means and why is it fixed in the driver to this value,
> not default one. By the way my specs says bits 0-3 are reserverd
> and here it seems you are using them.
I reused the value from the code which hardware team shared with me.
It tries to map a input hardware channel(IDMA or VPP channel) onto
a hardware window in DECON.
Channel_N is mapped onto window_N in case of DECON-INT.
In case of DECON-EXT, Channel 0 should be mapped to window 1 of DECON-EXT.
So, basically for the changes I have made, I should ideally set only
bits [4:6] to 0x1,
and leave other bits untouched, though modifying other bits wouldn't
affect in anyway.
>
>> +
>> +enum decon_type {
>> + DECON_INT,
>> + DECON_EXT,
>> +} decon_type;
>> +
>> +struct decon_driver_data {
>> + enum decon_type decon_type;
>> + unsigned intnr_windows;
>> +};
>> +
>> +static struct decon_driver_data exynos7_decon_int_driver_data = {
>> + .decon_type = DECON_INT,
>
> I wonder if it wouldn't be better to use different fields to describe
> each capability/property instead of decon_type. For example
> .display_type = EXYNOS_DISPLAY_TYPE_LCD,
> .map_channels = 0,
Ok, let me list down the differences between INT and EXT.
1) Only h/w triggered command mode for DECON-EXT.
2) Need to feed modified porch values(decon_ext_timings)
3) Input channel to H/w window mapping(WINCHMAP)
4) default_window - 0 for DECON-INT and 1 for DECON-EXT

Out of the above differences, the first 3 can somehow be converted
to capability/property and embedded into driver_data.
But the 4th difference is bothering me.
I tried using something like start_window, end_window and tried to make
The code common for DECON-INT and DECON-EXT, and it just doesn't work.
ex:
start_window = 0, end_window = 1 for DECON-INT
start_window = 1, end_window = 1 for DECON-EXT

When win_commit gets called for window 0 from crtc_commit/plane_commit:
Configure start_window(0  for DECON-INT and 1 for DECON-EXT)

When win_commit is called from decon_apply, it is called for window 1 also.
That time win_commit can skip updating actual window 1.
How do I take care of this ambiguity? This case happens with
win_disable routine also!


> This way the code will be cleaner (less ifs).
>
>
>> + .nr_windows = 2,
>> +};
>> +
>> +static struct decon_driver_data exynos7_decon_ext_driver_data = {
>> + .decon_type = DECON_EXT,
>> + .nr_windows = 1,
>> +};
>> +
>>  struct decon_win_data {
>>   unsigned intovl_x;
>>   unsigned intovl_y;
>> @@ -76,15 +98,28 @@ struct decon_context {
>>   atomic_t  

[PATCH] drm/imx: Add support for 15-bit RGB with 1-bit alpha formats

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 566cbe0..3371826 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -23,8 +23,12 @@
 #define to_ipu_plane(x)container_of(x, struct ipu_plane, base)

 static const uint32_t ipu_plane_formats[] = {
+   DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
+   DRM_FORMAT_RGBA5551,
+   DRM_FORMAT_BGRA5551,
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
DRM_FORMAT_ABGR,
@@ -176,6 +180,10 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
/* Enable local alpha on partial plane */
switch (fb->pixel_format) {
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ABGR1555:
+   case DRM_FORMAT_RGBA5551:
+   case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
-- 
2.1.4

[PATCH] drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2

[Philipp Zabel]

This patch allows the IPU to divide the 27 MHz input clock from
the TVE by two to obtain the 13.5 MHz pixel clock needed for
NTSC/PAL SD modes.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 35a3375..11a8d868 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -161,13 +161,16 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
__func__, encoder_types);

/*
-* If we have DAC, TVDAC or LDB, then we need the IPU DI clock
-* to be the same as the LDB DI clock.
+* If we have DAC or LDB, then we need the IPU DI clock to be
+* the same as the LDB DI clock. For TVDAC, derive the IPU DI
+* clock from 27 MHz TVE_DI clock, but allow to divide it.
 */
if (encoder_types & (BIT(DRM_MODE_ENCODER_DAC) |
 BIT(DRM_MODE_ENCODER_TVDAC) |
 BIT(DRM_MODE_ENCODER_LVDS)))
sig_cfg.clkflags = IPU_DI_CLKMODE_SYNC | IPU_DI_CLKMODE_EXT;
+   else if (encoder_types & BIT(DRM_MODE_ENCODER_TVDAC))
+   sig_cfg.clkflags = IPU_DI_CLKMODE_EXT;
else
sig_cfg.clkflags = 0;

-- 
2.1.4

[PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Russell King - ARM Linux]

On Mon, Mar 02, 2015 at 02:28:40PM +0200, Tomi Valkeinen wrote:
> On 26/02/15 16:55, Jyri Sarha wrote:
> > Use new binding for the external tda19988 HDMI encoder.
> > 
> > Signed-off-by: Jyri Sarha 
> > ---
> >  arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
> > b/arch/arm/boot/dts/am335x-boneblack.dts
> > index 5c42d25..eadbba3 100644
> > --- a/arch/arm/boot/dts/am335x-boneblack.dts
> > +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> > @@ -68,16 +68,26 @@
> >  
> >   {
> > status = "okay";
> > +   port {
> > +   lcdc_0: endpoint at 0 {
> > +   remote-endpoint = <_0>;
> > +   };
> > +   };
> >  };
> >  
> > -/ {
> > -   hdmi {
> > -   compatible = "ti,tilcdc,slave";
> > -   i2c = <>;
> > + {
> > +   tda19988 {
> > +   compatible = "nxp,tda998x";
> > +   reg = <0x70>;
> > pinctrl-names = "default", "off";
> > pinctrl-0 = <_hdmi_bonelt_pins>;
> > pinctrl-1 = <_hdmi_bonelt_off_pins>;
> > -   status = "okay";
> > +
> > +   port {
> > +   hdmi_0: endpoint at 0 {
> > +   remote-endpoint = <_0>;
> > +   };
> > +   };
> > };
> >  };
> 
> This is missing the output of tda998x. It should have two ports, input
> and output, output going to hdmi-connector.

We don't have that kind of level of modelling in DRM right now - as far
as DRM is concerned, the tda998x is both the encoder _and_ the connector
since it supplies both functionalities.

We did discuss this ages ago, but afaik no concensus was reached how to
model physical connectors in DT, so it never moved forward in DRM (and
besides, everyone seems to be off doing their own thing when it comes
to writing DT descriptions for video hardware.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

[Russell King - ARM Linux]

On Thu, Feb 26, 2015 at 04:55:32PM +0200, Jyri Sarha wrote:
> + ret = component_bind_all(dev->dev, dev);
> + if (ret < 0) {
> + dev_err(dev->dev, "Binding subcomponents failed: %d\n", ret);

Do you need to print this?  The component helper is already fairly
verbose about what succeeds and fails.

> +static const struct component_master_ops tilcdc_comp_ops = {
> + .add_components = tilcdc_add_external_components,

I'd much rather you used the new matching support rather than using the
old .add_components.  The new matching support is more efficient as you
only have to scan DT once, rather than each time we try to probe.  That
will mean...

> @@ -613,12 +643,12 @@ static int tilcdc_pdev_probe(struct platform_device 
> *pdev)
>   return -ENXIO;
>   }

You need to build a struct component_match array here using
component_match_add()...

>  
> - return drm_platform_init(_driver, pdev);
> + return component_master_add(>dev, _comp_ops);

and then finally register the ops with component_master_add_with_match().

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/imx: Add support for non-RGB output colorspace

[Philipp Zabel]

This patch allows to use non-RGB color formats on the output. This is needed
to support YUV output via HDMI or TV-Encoder.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c  | 3 ++-
 drivers/gpu/drm/imx/ipuv3-plane.c | 9 +
 drivers/gpu/drm/imx/ipuv3-plane.h | 3 ++-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 09d6f98..35a3375 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -203,7 +203,8 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
  crtc->primary->fb,
  0, 0, mode->hdisplay, mode->vdisplay,
  x, y, mode->hdisplay, mode->vdisplay,
- mode->flags & DRM_MODE_FLAG_INTERLACE);
+ mode->flags & DRM_MODE_FLAG_INTERLACE,
+ ipu_pixelformat_to_colorspace(out_pixel_fmt));
 }

 static void ipu_crtc_handle_pageflip(struct ipu_crtc *ipu_crtc)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 878a643..566cbe0 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -99,7 +99,8 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
   unsigned int crtc_w, unsigned int crtc_h,
   uint32_t src_x, uint32_t src_y,
-  uint32_t src_w, uint32_t src_h, bool interlaced)
+  uint32_t src_w, uint32_t src_h, bool interlaced,
+  enum ipu_color_space out_colorspace)
 {
struct device *dev = ipu_plane->base.dev->dev;
int ret;
@@ -158,8 +159,8 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
ret = ipu_dp_setup_channel(ipu_plane->dp,
-   IPUV3_COLORSPACE_RGB,
-   IPUV3_COLORSPACE_RGB);
+   ipu_drm_fourcc_to_colorspace(fb->pixel_format),
+   out_colorspace);
if (ret) {
dev_err(dev,
"initializing display processor failed with 
%d\n",
@@ -315,7 +316,7 @@ static int ipu_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
ret = ipu_plane_mode_set(ipu_plane, crtc, >hwmode, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x >> 16, src_y >> 16, src_w >> 16, src_h >> 16,
-   false);
+   false, IPUV3_COLORSPACE_UNKNOWN);
if (ret < 0) {
ipu_plane_put_resources(ipu_plane);
return ret;
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.h 
b/drivers/gpu/drm/imx/ipuv3-plane.h
index 9b5eff1..8a3ae68 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.h
+++ b/drivers/gpu/drm/imx/ipuv3-plane.h
@@ -42,7 +42,8 @@ int ipu_plane_mode_set(struct ipu_plane *plane, struct 
drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
   unsigned int crtc_w, unsigned int crtc_h,
   uint32_t src_x, uint32_t src_y, uint32_t src_w,
-  uint32_t src_h, bool interlaced);
+  uint32_t src_h, bool interlaced,
+  enum ipu_color_space out_colorspace);

 void ipu_plane_enable(struct ipu_plane *plane);
 void ipu_plane_disable(struct ipu_plane *plane);
-- 
2.1.4

[PATCH] drm/imx: Add support for interlaced scanout

[Philipp Zabel]

This patch allows interlaced frame buffer scanout for interlaced output
via HDMI or TV-Encoder.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-crtc.c  | 3 ++-
 drivers/gpu/drm/imx/ipuv3-plane.c | 7 +--
 drivers/gpu/drm/imx/ipuv3-plane.h | 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 98551e3..09d6f98 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -202,7 +202,8 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
return ipu_plane_mode_set(ipu_crtc->plane[0], crtc, mode,
  crtc->primary->fb,
  0, 0, mode->hdisplay, mode->vdisplay,
- x, y, mode->hdisplay, mode->vdisplay);
+ x, y, mode->hdisplay, mode->vdisplay,
+ mode->flags & DRM_MODE_FLAG_INTERLACE);
 }

 static void ipu_crtc_handle_pageflip(struct ipu_crtc *ipu_crtc)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 6987e16..878a643 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -99,7 +99,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
   unsigned int crtc_w, unsigned int crtc_h,
   uint32_t src_x, uint32_t src_y,
-  uint32_t src_w, uint32_t src_h)
+  uint32_t src_w, uint32_t src_h, bool interlaced)
 {
struct device *dev = ipu_plane->base.dev->dev;
int ret;
@@ -213,6 +213,8 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
if (ret < 0)
return ret;
+   if (interlaced)
+   ipu_cpmem_interlaced_scan(ipu_plane->ipu_ch, fb->pitches[0]);

ipu_plane->w = src_w;
ipu_plane->h = src_h;
@@ -312,7 +314,8 @@ static int ipu_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,

ret = ipu_plane_mode_set(ipu_plane, crtc, >hwmode, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
-   src_x >> 16, src_y >> 16, src_w >> 16, src_h >> 16);
+   src_x >> 16, src_y >> 16, src_w >> 16, src_h >> 16,
+   false);
if (ret < 0) {
ipu_plane_put_resources(ipu_plane);
return ret;
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.h 
b/drivers/gpu/drm/imx/ipuv3-plane.h
index af125fb..9b5eff1 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.h
+++ b/drivers/gpu/drm/imx/ipuv3-plane.h
@@ -42,7 +42,7 @@ int ipu_plane_mode_set(struct ipu_plane *plane, struct 
drm_crtc *crtc,
   struct drm_framebuffer *fb, int crtc_x, int crtc_y,
   unsigned int crtc_w, unsigned int crtc_h,
   uint32_t src_x, uint32_t src_y, uint32_t src_w,
-  uint32_t src_h);
+  uint32_t src_h, bool interlaced);

 void ipu_plane_enable(struct ipu_plane *plane);
 void ipu_plane_disable(struct ipu_plane *plane);
-- 
2.1.4

[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst

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

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

--- Comment #2 from Klaus Maier  ---
Yes - backlight management is switched off because it doesn't work at all w/
catalyst. Always full. Brightness, ... - it's all configured by the monitor
itself. Management via KDE or software is done only for on or off (switching
monitor to standby) - nothing more.

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

[PATCH 2/2] Query the driver directly for compute units and subslice

[jeff.mc...@intel.com]

From: Jeff McGee 

Values of device max compute units and max subslice obtained
directly from the driver should be more accurate than our own
ID-based lookup values. This is particularly important when a
single device ID may encompass more than one configuration. If
the driver cannot provide a valid value for the given device,
we fallback on the ID-based lookup value.

Signed-off-by: Jeff McGee 
---
 src/intel/intel_driver.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/intel/intel_driver.c b/src/intel/intel_driver.c
index d61988c..d99fea9 100644
--- a/src/intel/intel_driver.c
+++ b/src/intel/intel_driver.c
@@ -757,10 +757,8 @@ static int intel_buffer_set_tiling(cl_buffer bo,
 static void
 intel_update_device_info(cl_device_id device)
 {
-#ifdef HAS_USERPTR
   intel_driver_t *driver;
-  const size_t sz = 4096;
-  void *host_ptr;
+  unsigned int eu_total, subslice_total;

   driver = intel_driver_new();
   assert(driver != NULL);
@@ -769,6 +767,10 @@ intel_update_device_info(cl_device_id device)
 return;
   }

+#ifdef HAS_USERPTR
+  const size_t sz = 4096;
+  void *host_ptr;
+
   host_ptr = cl_aligned_malloc(sz, 4096);
   if (host_ptr != NULL) {
 cl_buffer bo = intel_buffer_alloc_userptr((cl_buffer_mgr)driver->bufmgr,
@@ -781,12 +783,18 @@ intel_update_device_info(cl_device_id device)
   }
   else
 device->host_unified_memory = CL_FALSE;
+#endif
+
+  /* Prefer driver-queried value if supported */
+  if (!drm_intel_get_eu_total(driver->fd, _total))
+device->max_compute_unit = eu_total;
+  if (!drm_intel_get_subslice_total(driver->fd, _total))
+device->sub_slice_count = subslice_total;

   intel_driver_context_destroy(driver);
   intel_driver_close(driver);
   intel_driver_terminate(driver);
   intel_driver_delete(driver);
-#endif
 }

 LOCAL void
-- 
2.3.0

[PATCH 1/2] Add driver callback for updating device info

[jeff.mc...@intel.com]

From: Jeff McGee 

We need to update some fields of the device's cl_device_id
struct at runtime using driver-specific methods. It is best to
group all such updates into a single driver callback to avoid
opening/initing and deiniting/closing the device multiple times.

Signed-off-by: Jeff McGee 
---
 src/cl_device_id.c   | 20 ++--
 src/cl_driver.h  |  4 
 src/cl_driver_defs.c |  1 +
 src/intel/intel_driver.c | 36 
 4 files changed, 43 insertions(+), 18 deletions(-)

diff --git a/src/cl_device_id.c b/src/cl_device_id.c
index 4e01c9f..fefcef3 100644
--- a/src/cl_device_id.c
+++ b/src/cl_device_id.c
@@ -506,24 +506,8 @@ skl_gt4_break:
 ret->profile_sz = strlen(ret->profile) + 1;
   }

-#ifdef HAS_USERPTR
-  cl_driver dummy = cl_driver_new(NULL);
-  cl_buffer_mgr bufmgr = cl_driver_get_bufmgr(dummy);
-
-  const size_t sz = 4096;
-  void* host_ptr = cl_aligned_malloc(sz, 4096);;
-  if (host_ptr != NULL) {
-cl_buffer bo = cl_buffer_alloc_userptr(bufmgr, "CL memory object", 
host_ptr, sz, 0);
-if (bo == NULL)
-  ret->host_unified_memory = CL_FALSE;
-else
-  cl_buffer_unreference(bo);
-cl_free(host_ptr);
-  }
-  else
-ret->host_unified_memory = CL_FALSE;
-  cl_driver_delete(dummy);
-#endif
+  /* Apply any driver-dependent updates to the device info */
+  cl_driver_update_device_info(ret);

   struct sysinfo info;
   if (sysinfo() == 0) {
diff --git a/src/cl_driver.h b/src/cl_driver.h
index 16f8bba..3f54a27 100644
--- a/src/cl_driver.h
+++ b/src/cl_driver.h
@@ -376,6 +376,10 @@ extern cl_buffer_get_tiling_align_cb 
*cl_buffer_get_tiling_align;
 typedef int (cl_driver_get_device_id_cb)(void);
 extern cl_driver_get_device_id_cb *cl_driver_get_device_id;

+/* Update the device info */
+typedef void (cl_driver_update_device_info_cb)(cl_device_id device);
+extern cl_driver_update_device_info_cb *cl_driver_update_device_info;
+
 /**
  * cl_khr_gl_sharing.
  **/
diff --git a/src/cl_driver_defs.c b/src/cl_driver_defs.c
index 2b68539..9a47210 100644
--- a/src/cl_driver_defs.c
+++ b/src/cl_driver_defs.c
@@ -26,6 +26,7 @@ LOCAL cl_driver_delete_cb *cl_driver_delete = NULL;
 LOCAL cl_driver_get_bufmgr_cb *cl_driver_get_bufmgr = NULL;
 LOCAL cl_driver_get_ver_cb *cl_driver_get_ver = NULL;
 LOCAL cl_driver_get_device_id_cb *cl_driver_get_device_id = NULL;
+LOCAL cl_driver_update_device_info_cb *cl_driver_update_device_info = NULL;

 /* Buffer */
 LOCAL cl_buffer_alloc_cb *cl_buffer_alloc = NULL;
diff --git a/src/intel/intel_driver.c b/src/intel/intel_driver.c
index ff0cf27..d61988c 100644
--- a/src/intel/intel_driver.c
+++ b/src/intel/intel_driver.c
@@ -754,6 +754,41 @@ static int intel_buffer_set_tiling(cl_buffer bo,
   return ret;
 }

+static void
+intel_update_device_info(cl_device_id device)
+{
+#ifdef HAS_USERPTR
+  intel_driver_t *driver;
+  const size_t sz = 4096;
+  void *host_ptr;
+
+  driver = intel_driver_new();
+  assert(driver != NULL);
+  if (intel_driver_open(driver, NULL) != CL_SUCCESS) {
+intel_driver_delete(driver);
+return;
+  }
+
+  host_ptr = cl_aligned_malloc(sz, 4096);
+  if (host_ptr != NULL) {
+cl_buffer bo = intel_buffer_alloc_userptr((cl_buffer_mgr)driver->bufmgr,
+  "CL memory object", host_ptr, sz, 0);
+if (bo == NULL)
+  device->host_unified_memory = CL_FALSE;
+else
+  drm_intel_bo_unreference((drm_intel_bo*)bo);
+cl_free(host_ptr);
+  }
+  else
+device->host_unified_memory = CL_FALSE;
+
+  intel_driver_context_destroy(driver);
+  intel_driver_close(driver);
+  intel_driver_terminate(driver);
+  intel_driver_delete(driver);
+#endif
+}
+
 LOCAL void
 intel_setup_callbacks(void)
 {
@@ -762,6 +797,7 @@ intel_setup_callbacks(void)
   cl_driver_get_ver = (cl_driver_get_ver_cb *) intel_driver_get_ver;
   cl_driver_get_bufmgr = (cl_driver_get_bufmgr_cb *) intel_driver_get_bufmgr;
   cl_driver_get_device_id = (cl_driver_get_device_id_cb *) intel_get_device_id;
+  cl_driver_update_device_info = (cl_driver_update_device_info_cb *) 
intel_update_device_info;
   cl_buffer_alloc = (cl_buffer_alloc_cb *) drm_intel_bo_alloc;
   cl_buffer_alloc_userptr = (cl_buffer_alloc_userptr_cb*) 
intel_buffer_alloc_userptr;
   cl_buffer_set_tiling = (cl_buffer_set_tiling_cb *) intel_buffer_set_tiling;
-- 
2.3.0

[PATCH] tests/core_getparams: Create new test core_getparams

[jeff.mc...@intel.com]

From: Jeff McGee 

New test core_getparams consists of 2 subtests, each one testing
the ability of userspace to query the correct value of a GT config
attribute: subslice total or EU total. drm/i915 implementation of
these queries is required for Cherryview and Gen9+ devices (non-
simulated).

For: VIZ-4636
Signed-off-by: Jeff McGee 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/core_getparams.c | 145 +
 3 files changed, 147 insertions(+)
 create mode 100644 tests/core_getparams.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 7b4dd94..39b4e28 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,6 +1,7 @@
 # Please keep sorted alphabetically
 core_get_client_auth
 core_getclient
+core_getparams
 core_getstats
 core_getversion
 drm_import_export
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 51e8376..999c8f8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \

 TESTS_progs_M = \
core_get_client_auth \
+   core_getparams \
drv_suspend \
drv_hangman \
gem_bad_reloc \
diff --git a/tests/core_getparams.c b/tests/core_getparams.c
new file mode 100644
index 000..37a4f63
--- /dev/null
+++ b/tests/core_getparams.c
@@ -0,0 +1,145 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Jeff McGee 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include "drmtest.h"
+#include "intel_chipset.h"
+#include "intel_bufmgr.h"
+
+int drm_fd;
+int devid;
+
+static void
+init(void)
+{
+   drm_fd = drm_open_any();
+   devid = intel_get_drm_devid(drm_fd);
+}
+
+static void
+deinit(void)
+{
+   close(drm_fd);
+}
+
+static void
+subslice_total(void)
+{
+   unsigned int subslice_total = 0;
+   int ret;
+
+   ret = drm_intel_get_subslice_total(drm_fd, _total);
+
+   if (ret) {
+   /*
+* These devices are not required to implement the
+* interface. If they do not, -ENODEV must be returned.
+   */
+   if ((intel_gen(devid) < 8) ||
+   IS_BROADWELL(devid) ||
+   igt_run_in_simulation()) {
+   igt_assert(ret == -ENODEV);
+   igt_info("subslice total: unknown\n");
+   /*
+* All other devices must implement the interface, so
+* fail them if we are here.
+   */
+   } else {
+   igt_assert(ret != EINVAL); /* request not recognized? */
+   igt_assert(ret != ENODEV); /* device not supported? */
+   igt_assert(ret == 0); /* other error? */
+   }
+   } else {
+   /*
+* On success, just make sure the returned count value is
+* non-zero. The validity of the count value for the given
+* device is not checked.
+   */
+   igt_assert(subslice_total != 0);
+   igt_info("subslice total: %u\n", subslice_total);
+   }
+}
+
+static void
+eu_total(void)
+{
+   unsigned int eu_total = 0;
+   int ret;
+
+   ret = drm_intel_get_eu_total(drm_fd, _total);
+
+   if (ret) {
+   /*
+* These devices are not required to implement the
+* interface. If they do not, -ENODEV must be returned.
+   */
+   if ((intel_gen(devid) < 8) ||
+   IS_BROADWELL(devid) ||
+   igt_run_in_simulation()) {
+   igt_assert(ret == -ENODEV);
+   igt_info("EU total: unknown\n");
+   /*
+* All other devices must implement the interface, so
+* fail them 

[PATCH] intel: Export total subslice and EU counts

[jeff.mc...@intel.com]

From: Jeff McGee 

Update kernel interface with new I915_GETPARAM ioctl entries for
subslice total and EU total. Add a wrapping function for each
parameter. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can employ fuse register reads as needed to
ensure the most accurate determination of GT config attributes.
This first became important with Cherryview in which the config
could differ between devices with the same PCI ID.

The kernel detection of these values is device-specific. Userspace
drivers should continue to maintain ID-based tables for older
devices which return ENODEV when using this query.

For: VIZ-4636
Signed-off-by: Jeff McGee 
---
 include/drm/i915_drm.h   |  2 ++
 intel/intel_bufmgr.h |  4 
 intel/intel_bufmgr_gem.c | 31 +++
 3 files changed, 37 insertions(+)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 15dd01d..e34f5b2 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -340,6 +340,8 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
 #define I915_PARAM_HAS_WT   27
 #define I915_PARAM_CMD_PARSER_VERSION   28
+#define I915_PARAM_SUBSLICE_TOTAL   32
+#define I915_PARAM_EU_TOTAL 33

 typedef struct drm_i915_getparam {
int param;
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index be83a56..4b2472e 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 

 struct drm_clip_rect;

@@ -264,6 +265,9 @@ int drm_intel_get_reset_stats(drm_intel_context *ctx,
  uint32_t *active,
  uint32_t *pending);

+int drm_intel_get_subslice_total(int fd, unsigned int *subslice_total);
+int drm_intel_get_eu_total(int fd, unsigned int *eu_total);
+
 /** @{ Compatibility defines to keep old code building despite the symbol 
rename
  * from dri_* to drm_intel_*
  */
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 78875fd..2d77f32 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3292,6 +3292,37 @@ drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
return ret;
 }

+drm_public int
+drm_intel_get_subslice_total(int fd, unsigned int *subslice_total)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memclear(gp);
+   gp.value = (int*)subslice_total;
+   gp.param = I915_PARAM_SUBSLICE_TOTAL;
+   ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+   if (ret)
+   return -errno;
+
+   return 0;
+}
+
+drm_public int
+drm_intel_get_eu_total(int fd, unsigned int *eu_total)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memclear(gp);
+   gp.value = (int*)eu_total;
+   gp.param = I915_PARAM_EU_TOTAL;
+   ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
+   if (ret)
+   return -errno;
+
+   return 0;
+}

 /**
  * Annotate the given bo for use in aub dumping.
-- 
2.3.0

[PATCH] drm/i915: Export total subslice and EU counts

[jeff.mc...@intel.com]

From: Jeff McGee 

Setup new I915_GETPARAM ioctl entries for subslice total and
EU total. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can employ fuse register reads as needed to
ensure the most accurate determination of GT config attributes.
This first became important with Cherryview in which the config
could differ between devices with the same PCI ID.

The kernel detection of these values is device-specific and not
included in this patch. Because zero is not a valid value for any of
these parameters, a value of zero is interpreted as unknown for the
device. Userspace drivers should continue to maintain ID-based tables
for older devices not supported by the new query method.

For: VIZ-4636
Signed-off-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_dma.c | 10 ++
 include/uapi/drm/i915_drm.h |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 053e178..9350ea2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -150,6 +150,16 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
case I915_PARAM_MMAP_VERSION:
value = 1;
break;
+   case I915_PARAM_SUBSLICE_TOTAL:
+   value = INTEL_INFO(dev)->subslice_total;
+   if (!value)
+   return -ENODEV;
+   break;
+   case I915_PARAM_EU_TOTAL:
+   value = INTEL_INFO(dev)->eu_total;
+   if (!value)
+   return -ENODEV;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..8672efc 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -347,6 +347,8 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
 #define I915_PARAM_MMAP_VERSION  30
 #define I915_PARAM_HAS_BSD2 31
+#define I915_PARAM_SUBSLICE_TOTAL   32
+#define I915_PARAM_EU_TOTAL 33

 typedef struct drm_i915_getparam {
int param;
-- 
2.3.0

[PATCH] drm: adv7511: Refactor power management

[Laurent Pinchart]

From: Laurent Pinchart 

Remove the internal dependency on DPMS mode for power management by
using a by a powered state boolean instead, and use the new power off
handler at probe time. This ensure that the regmap cache is properly
marked as dirty when the device is probed, and the registers properly
synced during the first power up.

As a side effect this removes the initialization of current_edid_segment
at probe time, as the field will be initialized when the device is
powered on, at the latest right before reading EDID data.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/i2c/adv7511.c | 97 +++
 1 file changed, 51 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index fa140e04d5fa..7fb7e22f4ad1 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -27,7 +27,7 @@ struct adv7511 {
struct regmap *regmap;
struct regmap *packet_memory_regmap;
enum drm_connector_status status;
-   int dpms_mode;
+   bool powered;

unsigned int f_tmds;

@@ -357,6 +357,46 @@ static void adv7511_set_link_config(struct adv7511 
*adv7511,
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
 }

+static void adv7511_power_on(struct adv7511 *adv7511)
+{
+   adv7511->current_edid_segment = -1;
+
+   regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
+ADV7511_INT0_EDID_READY | ADV7511_INT1_DDC_ERROR);
+   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
+  ADV7511_POWER_POWER_DOWN, 0);
+
+   /*
+* Per spec it is allowed to pulse the HDP signal to indicate that the
+* EDID information has changed. Some monitors do this when they wakeup
+* from standby or are enabled. When the HDP goes low the adv7511 is
+* reset and the outputs are disabled which might cause the monitor to
+* go to standby again. To avoid this we ignore the HDP pin for the
+* first few seconds after enabling the output.
+*/
+   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
+  ADV7511_REG_POWER2_HDP_SRC_MASK,
+  ADV7511_REG_POWER2_HDP_SRC_NONE);
+
+   /*
+* Most of the registers are reset during power down or when HPD is low.
+*/
+   regcache_sync(adv7511->regmap);
+
+   adv7511->powered = true;
+}
+
+static void adv7511_power_off(struct adv7511 *adv7511)
+{
+   /* TODO: setup additional power down modes */
+   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
+  ADV7511_POWER_POWER_DOWN,
+  ADV7511_POWER_POWER_DOWN);
+   regcache_mark_dirty(adv7511->regmap);
+
+   adv7511->powered = false;
+}
+
 /* 
-
  * Interrupt and hotplug detection
  */
@@ -526,7 +566,7 @@ static int adv7511_get_modes(struct drm_encoder *encoder,
unsigned int count;

/* Reading the EDID only works if the device is powered */
-   if (adv7511->dpms_mode != DRM_MODE_DPMS_ON) {
+   if (!adv7511->powered) {
regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
 ADV7511_INT0_EDID_READY | ADV7511_INT1_DDC_ERROR);
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
@@ -536,7 +576,7 @@ static int adv7511_get_modes(struct drm_encoder *encoder,

edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);

-   if (adv7511->dpms_mode != DRM_MODE_DPMS_ON)
+   if (!adv7511->powered)
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
   ADV7511_POWER_POWER_DOWN,
   ADV7511_POWER_POWER_DOWN);
@@ -558,41 +598,10 @@ static void adv7511_encoder_dpms(struct drm_encoder 
*encoder, int mode)
 {
struct adv7511 *adv7511 = encoder_to_adv7511(encoder);

-   switch (mode) {
-   case DRM_MODE_DPMS_ON:
-   adv7511->current_edid_segment = -1;
-
-   regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
-ADV7511_INT0_EDID_READY | ADV7511_INT1_DDC_ERROR);
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN, 0);
-   /*
-* Per spec it is allowed to pulse the HDP signal to indicate
-* that the EDID information has changed. Some monitors do this
-* when they wakeup from standby or are enabled. When the HDP
-* goes low the adv7511 is reset and the outputs are disabled
-* which might cause the monitor to go to standby again. To
-* avoid this we ignore the HDP pin for the first few seconds
-* after enabeling the 

[PATCH RFC 1/6] drm/tilcdc: Fix module unloading

[Tomi Valkeinen]

On 26/02/15 16:55, Jyri Sarha wrote:
> Force crtc dpms off before destroying the crtc instead of just
> checking the dpms state. This fixes warning message and frozen picture
> after tilcdc module unloading.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index c735884..c2d5980 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
>   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
>  }
>  
> +static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
>  static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
>  {
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
>  
> - WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
> + tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
>  
>   drm_crtc_cleanup(crtc);
>   drm_flip_work_cleanup(_crtc->unref_work);
> 

Looks fine to me, but makes me wonder what is the proper way to handle
this. I would presume that every DRM driver needs to shut down the
display HW when it's being unloaded.

And the current WARN_ON suggests that something is supposed to turn the
crtc off before it is destroyed. So either the tilcdc module unload has
never worked, or something has changed in the drm framework (or maybe
tilcdc).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/a8069b2c/attachment-0001.sig>

[PATCH RFC 4/6] drm/tilcdc: Add DRM_TILCDC_INIT for "ti, tilcdc, slave" binding support

[Tomi Valkeinen]

On 26/02/15 16:55, Jyri Sarha wrote:
> Adds a DRM_TILCDC_INIT module for "ti,tilcdc,slave" node
> conversion. The implementation is in tilcdc_boot_init.c and it uses
> tilcdc_slave_convert.dts as a basis for creating a DTS overlay. The
> DTS overlay adds an external tda998x encoder to tilcdc that
> corresponds to the old tda998x based slave encoder.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/Kconfig  |   6 +
>  drivers/gpu/drm/tilcdc/Makefile |   2 +
>  drivers/gpu/drm/tilcdc/tilcdc_boot_init.c   | 270 
> 
>  drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts |  70 ++
>  4 files changed, 348 insertions(+)
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts

All this is needed to support the old bindings, right? So I would
suggest scratching "DRM_TILCDC_INIT", and create
"DRM_TILCDC_COMPAT_SLAVE" or whatever, which would be a user visible
option, enabled by default.

This way one can just disable all this compatibility stuff if it's not
needed.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/06532c20/attachment-0001.sig>

[libdrm][PATCH 3/2] Fix always true comparison.

[Jan Vesely]

On Wed, 2015-02-25 at 18:41 +, Emil Velikov wrote:
> On 25/02/15 17:11, Jan Vesely wrote:
> > gentle ping
> > 
> Afaics it's very had to get in this code nowadays - drm_server_info is
> set only via the legacy (?) function drmSetServerInfo. With the latter
> only(?) used by the xserver when working with dri1 modules. So testing
> this is likely to be very painful :-(
> 
> This code hasn't changed since before 2007, so I doubt there are many
> people that know the details about it, so we might as well leave it for
> now ?

fair enough. the warning fixes push it to non-libudev side, so it's not
going to bug me on every build.

jan

> 
> -Emil
> 
> > 
> > On Mon, 2015-02-09 at 19:10 -0500, Jan Vesely wrote:
> >> The only user I found is xserver, it can return -1 under certain 
> >> conditions.
> >> So check for -1 explicitly.
> >>
> >> Signed-off-by: Jan Vesely 
> >> ---
> >>
> >> I could not find whether it's actually legal to return encoded negative 
> >> values
> >> in get_perm. This is a quick fix to detect the one case that I found.
> >>
> >>  xf86drm.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/xf86drm.c b/xf86drm.c
> >> index fb673b5..8e54ac9 100644
> >> --- a/xf86drm.c
> >> +++ b/xf86drm.c
> >> @@ -335,7 +335,7 @@ static int drmOpenDevice(dev_t dev, int minor, int 
> >> type)
> >>drm_server_info->get_perms(_group, _mode);
> >>devmode  = serv_mode ? serv_mode : DRM_DEV_MODE;
> >>devmode &= ~(S_IXUSR|S_IXGRP|S_IXOTH);
> >> -  group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> >> +  group = (serv_group != ~0U) ? serv_group : DRM_DEV_GID;
> >>  }
> >>  
> >>  #if !defined(UDEV)
> > 
> 

-- 
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/20150302/1bf439c1/attachment.sig>

[PATCH RFC 5/6] drm/tilcdc: Force building of DRM_TILCDC_INIT

[Tomi Valkeinen]

On 26/02/15 16:55, Jyri Sarha wrote:
> If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
> patch should not be needed. However, without this patch the objects
> needed for DRM_TILCDC_INIT are not linked, if DRM_TILCDC is built as
> module.

I also think there's something funny either with the documentation or
the kernel build system.

To summarize (Jyri correct me if I'm wrong):

We enter tilcdc directory using "obj-$(CONFIG_DRM_TILCDC)", and
CONFIG_DRM_TILCDC is either y or m. Inside the directory we have the
necessary makefile and code to build the driver as module or built-in.
And this works fine.

But now Jyri added new piece of code to tilcdc directory, which is
always built-in, even if the tilcdc driver itself is a module. So now if
we enter the directory with "obj-m", and inside the tilcdc/Makefile we
do "obj-y += foo.o" line, the result is that foo.o is compiled, but it
is not linked either to the kernel image nor to the tilcdc.ko.

The doc says:

"Kbuild only uses this information to decide that it needs to visit
the directory, it is the Makefile in the subdirectory that
specifies what is modular and what is built-in."

which doesn't seem to work for us.

> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2c239b9..62c6158 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
>  obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
>  obj-$(CONFIG_DRM_OMAP)   += omapdrm/
>  obj-$(CONFIG_DRM_TILCDC) += tilcdc/
> +obj-$(CONFIG_DRM_TILCDC_INIT)+= tilcdc/
>  obj-$(CONFIG_DRM_QXL) += qxl/
>  obj-$(CONFIG_DRM_BOCHS) += bochs/
>  obj-$(CONFIG_DRM_MSM) += msm/

I don't think the above is right. You add two rules for tilcdc
directory. I presume you meant to replace the current tilcdc line with
the new one?

But I don't think the new line makes sense. Using
obj-$(CONFIG_DRM_TILCDC) above makes sense, and also obj-y makes sense,
but obj-$(CONFIG_DRM_TILCDC_INIT) doesn't.

So I think it should be just obj-y, if obj-$(CONFIG_DRM_TILCDC) does not
work.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/3463a262/attachment-0001.sig>

[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

[Tomi Valkeinen]

te that there's an unmerged series "Add of-graph helpers to loop over
endpoints and find ports by id" from Philipp which changes the behavior
of of_graph_get_next_endpoint.

> + if (!node || !of_device_is_available(node))
> + continue;

Should you of_node_put(node) if node != NULL above?

> +
> + dev_info(master, "Subdevice node '%s' found\n", node->name);
> + ret = component_master_add_child(m, of_dev_node_match, node);
> + of_node_put(node);
> + if (ret) {
> + dev_err(master, "Adding component failed: %d\n", ret);
> + of_node_put(ep);
> + return ret;
> + }
> + }
> + return 0;
> +}

I don't know if it matters, but as tilcdc only supports a single
endpoint, and I think this is the earliest place where it can be
detected, you could fail above if there are more than one endpoint.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/8ae5e60c/attachment-0001.sig>

[PATCH 1/5] drm: Pass in new and old plane state to prepare_fb and cleanup_fb

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.

For i915 specifically, object backing pages need to be mapped differently
for different rotation modes and the driver needs to know which mapping to
instantiate and which to tear down when transitioning between them.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_atomic_helper.c   | 13 -
 drivers/gpu/drm/drm_plane_helper.c|  5 +++--
 drivers/gpu/drm/i915/intel_display.c  |  6 --
 drivers/gpu/drm/i915/intel_drv.h  |  6 --
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  6 --
 drivers/gpu/drm/tegra/dc.c|  6 --
 include/drm/drm_plane_helper.h|  6 --
 7 files changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3ce57f4..a745881 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1116,6 +1116,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
*dev,
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
+   struct drm_plane_state *plane_state = state->plane_states[i];
struct drm_framebuffer *fb;

if (!plane)
@@ -1123,10 +1124,10 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
*dev,

funcs = plane->helper_private;

-   fb = state->plane_states[i]->fb;
+   fb = plane_state->fb;

if (fb && funcs->prepare_fb) {
-   ret = funcs->prepare_fb(plane, fb);
+   ret = funcs->prepare_fb(plane, fb, plane_state);
if (ret)
goto fail;
}
@@ -1138,6 +1139,7 @@ fail:
for (i--; i >= 0; i--) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
+   struct drm_plane_state *plane_state = state->plane_states[i];
struct drm_framebuffer *fb;

if (!plane)
@@ -1148,7 +1150,7 @@ fail:
fb = state->plane_states[i]->fb;

if (fb && funcs->cleanup_fb)
-   funcs->cleanup_fb(plane, fb);
+   funcs->cleanup_fb(plane, fb, plane_state);

}

@@ -1254,6 +1256,7 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,
for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = old_state->planes[i];
+   struct drm_plane_state *plane_state = 
old_state->plane_states[i];
struct drm_framebuffer *old_fb;

if (!plane)
@@ -1261,10 +1264,10 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,

funcs = plane->helper_private;

-   old_fb = old_state->plane_states[i]->fb;
+   old_fb = plane_state->fb;

if (old_fb && funcs->cleanup_fb)
-   funcs->cleanup_fb(plane, old_fb);
+   funcs->cleanup_fb(plane, old_fb, plane_state);
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 5ba5792..813a066 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -437,7 +437,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,

if (plane_funcs->prepare_fb && plane_state->fb &&
plane_state->fb != old_fb) {
-   ret = plane_funcs->prepare_fb(plane, plane_state->fb);
+   ret = plane_funcs->prepare_fb(plane, plane_state->fb,
+ plane_state);
if (ret)
goto out;
}
@@ -487,7 +488,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
}

if (plane_funcs->cleanup_fb && old_fb)
-   plane_funcs->cleanup_fb(plane, old_fb);
+   plane_funcs->cleanup_fb(plane, old_fb, plane_state);
 out:
if (plane_state) {
if (plane->funcs->atomic_destroy_state)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3156d77..c54a6e9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11891,7 +11891,8 @@ static void intel_shared_dpll_init(struct drm_device 
*dev)
  */
 int
 intel_prepare_plane_fb(struct drm_plane *plane,
-  struct drm_framebuffer *fb)
+  struct drm_framebuffer *fb,
+  struct drm_plane_state *new_state)
 {

[PATCH v2] drm/i915: gen4: work around hang during hibernation

[Jani Nikula]

On Mon, 02 Mar 2015, Imre Deak  wrote:
> Bjørn reported that his machine hang during hibernation and eventually
> bisected the problem to the following commit:
>
> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> Author: Imre Deak 
> Date:   Thu Oct 23 19:23:26 2014 +0300
>
> drm/i915: add poweroff_late handler
>
> The problem seems to be that after the kernel puts the device into D3
> the BIOS still tries to access it, or otherwise assumes that it's in D0.
> This is clearly bogus, since ACPI mandates that devices are put into D3
> by the OSPM if they are not wake-up sources. In the future we want to
> unify more of the driver's runtime and system suspend paths, for example
> by skipping all the system suspend/hibernation hooks if the device is
> runtime suspended already. Accordingly for all other platforms the goal
> is still to properly power down the device during hibernation.
>
> v2:
> - Another GEN4 Lenovo laptop had the same issue, while platforms from
>   other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
>   to work fine. Based on this apply the workaround on all GEN4 Lenovo
>   platforms.
> - add code comment about failing platforms (Ville)
>
> Reference: 
> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
> Reported-and-bisected-by: Bjørn Mork 
> Signed-off-by: Imre Deak 

Bjørn, I would really appreciate your Tested-by on this patch before I
queue it for v4.0 and cc: stable for v3.19.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_drv.c | 30 +-
>  1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4badb23..ff3662f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -637,7 +637,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>   return 0;
>  }
>  
> -static int i915_drm_suspend_late(struct drm_device *drm_dev)
> +static int i915_drm_suspend_late(struct drm_device *drm_dev, bool 
> hibernation)
>  {
>   struct drm_i915_private *dev_priv = drm_dev->dev_private;
>   int ret;
> @@ -651,7 +651,17 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev)
>   }
>  
>   pci_disable_device(drm_dev->pdev);
> - pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> + /*
> +  * During hibernation on some GEN4 platforms the BIOS may try to access
> +  * the device even though it's already in D3 and hang the machine. So
> +  * leave the device in D0 on those platforms and hope the BIOS will
> +  * power down the device properly. Platforms where this was seen:
> +  * Lenovo Thinkpad X301, X61s
> +  */
> + if (!(hibernation &&
> +   drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> +   INTEL_INFO(dev_priv)->gen == 4))
> + pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>  
>   return 0;
>  }
> @@ -677,7 +687,7 @@ int i915_suspend_legacy(struct drm_device *dev, 
> pm_message_t state)
>   if (error)
>   return error;
>  
> - return i915_drm_suspend_late(dev);
> + return i915_drm_suspend_late(dev, false);
>  }
>  
>  static int i915_drm_resume(struct drm_device *dev)
> @@ -965,7 +975,17 @@ static int i915_pm_suspend_late(struct device *dev)
>   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
>   return 0;
>  
> - return i915_drm_suspend_late(drm_dev);
> + return i915_drm_suspend_late(drm_dev, false);
> +}
> +
> +static int i915_pm_poweroff_late(struct device *dev)
> +{
> + struct drm_device *drm_dev = dev_to_i915(dev)->dev;
> +
> + if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
> + return 0;
> +
> + return i915_drm_suspend_late(drm_dev, true);
>  }
>  
>  static int i915_pm_resume_early(struct device *dev)
> @@ -1535,7 +1555,7 @@ static const struct dev_pm_ops i915_pm_ops = {
>   .thaw_early = i915_pm_resume_early,
>   .thaw = i915_pm_resume,
>   .poweroff = i915_pm_suspend,
> - .poweroff_late = i915_pm_suspend_late,
> + .poweroff_late = i915_pm_poweroff_late,
>   .restore_early = i915_pm_resume_early,
>   .restore = i915_pm_resume,
>  
> -- 
> 2.1.0
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Tomi Valkeinen]

On 26/02/15 16:55, Jyri Sarha wrote:
> Use new binding for the external tda19988 HDMI encoder.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index 5c42d25..eadbba3 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -68,16 +68,26 @@
>  
>   {
>   status = "okay";
> + port {
> + lcdc_0: endpoint at 0 {
> + remote-endpoint = <_0>;
> + };
> + };
>  };
>  
> -/ {
> - hdmi {
> - compatible = "ti,tilcdc,slave";
> - i2c = <>;
> + {
> + tda19988 {
> + compatible = "nxp,tda998x";
> + reg = <0x70>;
>   pinctrl-names = "default", "off";
>   pinctrl-0 = <_hdmi_bonelt_pins>;
>   pinctrl-1 = <_hdmi_bonelt_off_pins>;
> - status = "okay";
> +
> + port {
> + hdmi_0: endpoint at 0 {
> + remote-endpoint = <_0>;
> + };
> + };
>   };
>  };

This is missing the output of tda998x. It should have two ports, input
and output, output going to hdmi-connector.

 Tomi


-- next part ------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/b4558195/attachment-0001.sig>

[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken

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

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

--- Comment #10 from Stefan Dösinger  ---
Created attachment 113921
  --> https://bugs.freedesktop.org/attachment.cgi?id=113921=edit
Precision fix

The attached patch seems to fix the precision problem for me. It seems to make
sense given the surrounding code, but I have no real clue what's special about
swizzles for these formats.

-- 
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/20150302/026d0a78/attachment.html>

[PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI

[Ajay kumar]

Hi Andrej,

On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  wrote:
> Hi Ajay,
>
> Thanks for the patch.
Thanks for reviewing the patch.

> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
>> Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
>> * Add phy configs for Exynos7.
>> * Exynos7 has a different clock structure for HDMI,
>>   so introduce the new clocks.
>> * Add sysreg support to enable HDMI SYSREG on Exynos7.
>> * Exynos7 based boards need a DCDC_EN and LS_EN pins
>>   for powering up HDMI. Add support for that too.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/video/exynos_hdmi.txt  |   21 +-
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  252 
>> 
>>  drivers/gpu/drm/exynos/regs-hdmi.h |4 +
>>  3 files changed, 231 insertions(+), 46 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 1fd8cf9..bb22a60 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -6,6 +6,7 @@ Required properties:
>>   2) "samsung,exynos4210-hdmi"
>>   3) "samsung,exynos4212-hdmi"
>>   4) "samsung,exynos5420-hdmi"
>> + 5) "samsung,exynos7-hdmi"
>
> Why not "samsung,exynos7420-hdmi" ?
> What compatible will you use for Exynos7430 or higher chip number?
I will leave this decision to Inki Dae or Kukjin.

>>  - reg: physical base address of the hdmi and length of memory mapped
>>   region.
>>  - interrupts: interrupt number to the cpu.
>> @@ -15,21 +16,33 @@ Required properties:
>>   c) optional flags and pull up/down.
>>  - clocks: list of clock IDs from SoC clock driver.
>>   a) hdmi: Gate of HDMI IP bus clock.
>> - b) sclk_hdmi: Gate of HDMI special clock.
>> - c) sclk_pixel: Pixel special clock, one of the two possible inputs of
>> + HDMI clocks necessary for non exynos7:
>> +  b) sclk_hdmi: Gate of HDMI special clock.
>> +  c) sclk_pixel: Pixel special clock, one of the two possible inputs of
>>   HDMI clock mux.
>> - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
>> +  d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
>>   HDMI clock mux.
>> - e) mout_hdmi: It is required by the driver to switch between the 2
>> +  e) mout_hdmi: It is required by the driver to switch between the 2
>>   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
>>   after configuration, parent is set to sclk_hdmiphy else
>>   sclk_pixel.
>> + HDMI clocks necessary for Exynos7:
>> +  b) pclk_hdmiphy: Gate to HDMIPHY clock.
>
> According to specs there is also pclk_hdmi, why do you specify only this
> one?
Right, I have reused "hdmi" gating clock for pclk_hdmi. That is why I have
left "hdmi" clock as common for exynos7 and non-exynos7.

>> +  c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
>> +  d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
>
> According to specs these clocks should be named i_pixel_clk and
> i_tmds_clk, shouldn't they?
I actually took these changes from an "internal" code(non-DRM).
The original author used these names, and I just carried the same names. :)

>>  - clock-names: aliases as per driver requirements for above clock IDs:
>>   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>>  - ddc: phandle to the hdmi ddc node
>>  - phy: phandle to the hdmi phy node
>>  - samsung,syscon-phandle: phandle for system controller node for PMU.
>>
>> +Only for Exynos7(when compatible = "samsung,exynos7-hdmi"):
>> +- samsung,sysreg-phandle: phandle for system controller node for SYSREG 
>> block.
>> +
>> +Optional properties:
>> +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
>> +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
>
> What is purpose of these gpios?
These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board.
Other boards need not provide the GPIO.

>> +
>>  Example:
>>
>>   hdmi {
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 229b361..1b579ea 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -67,6 +67,7 @@
>>  enum hdmi_type {
>>   HDMI_TYPE13,
>>   HDMI_TYPE14,
>> + HDMI_TYPE14_7,
>>  };
>>
>>  struct hdmi_driver_data {
>> @@ -82,6 +83,9 @@ struct hdmi_resources {
>>   struct clk  *sclk_pixel;
>>   struct clk  *sclk_hdmiphy;
>>   struct clk  *mout_hdmi;
>> + struct clk  *hdmi_pixel;
>> + struct clk  *pclk_hdmiphy;
>> + struct clk  *hdmi_tmds;
>>   struct regulator_bulk_data  *regul_bulk;
>>

[PATCH v2] drm/i915: gen4: work around hang during hibernation

[Bjørn Mork]

Jani Nikula  writes:

> On Mon, 02 Mar 2015, Imre Deak  wrote:
>> Bjørn reported that his machine hang during hibernation and eventually
>> bisected the problem to the following commit:
>>
>> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
>> Author: Imre Deak 
>> Date:   Thu Oct 23 19:23:26 2014 +0300
>>
>> drm/i915: add poweroff_late handler
>>
>> The problem seems to be that after the kernel puts the device into D3
>> the BIOS still tries to access it, or otherwise assumes that it's in D0.
>> This is clearly bogus, since ACPI mandates that devices are put into D3
>> by the OSPM if they are not wake-up sources. In the future we want to
>> unify more of the driver's runtime and system suspend paths, for example
>> by skipping all the system suspend/hibernation hooks if the device is
>> runtime suspended already. Accordingly for all other platforms the goal
>> is still to properly power down the device during hibernation.
>>
>> v2:
>> - Another GEN4 Lenovo laptop had the same issue, while platforms from
>>   other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
>>   to work fine. Based on this apply the workaround on all GEN4 Lenovo
>>   platforms.
>> - add code comment about failing platforms (Ville)
>>
>> Reference: 
>> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
>> Reported-and-bisected-by: Bjørn Mork 
>> Signed-off-by: Imre Deak 
>
> Bjørn, I would really appreciate your Tested-by on this patch before I
> queue it for v4.0 and cc: stable for v3.19.

No problem. This version still works fine for me.  Feel free to add

Tested-by: Bjørn Mork 



Bjørn

[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken

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

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

--- Comment #9 from Stefan Dösinger  ---
The reason why I am suspicious about the 3 bits precision and ATI1N is that
according to the GPU register docs TX_FMT_ATI1N is separated from TX_FMT_3_3_2
only by TX_FORMAT2.TXFORMAT_MSB. Is it possible that some code doesn't look at
TXFORMAT_MSB, thinks it sees TX_FMT_3_3_2 and sets up some other part of the
GPU to expect 3 bits of red data?

I'm skimming the code for something like this, so far I haven't found anything.

-- 
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/20150302/3ed01aad/attachment.html>

drm/gma500: Possible deadlock in gma_power_begin()

[One Thousand Gnomes]

On Sat, 28 Feb 2015 18:02:33 +0300
Alexey Khoroshilov  wrote:

> gma_power_begin() starts with locking power_ctrl_lock spinlock and then,
> if gma_resume_pci(dev->pdev) succeed, it calls
>   psb_irq_preinstall(dev);
>   psb_irq_postinstall(dev);
> 
> psb_irq_postinstall() does some pipestat enabling/disabling dance:
> if (dev->vblank[0].enabled)
> psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
> else
> psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
> 
> where
> void psb_enable_pipestat(struct drm_psb_private *dev_priv, int pipe, u32
> mask)
> {
> if ((dev_priv->pipestat[pipe] & mask) != mask) {
> u32 reg = psb_pipestat(pipe);
> dev_priv->pipestat[pipe] |= mask;
> /* Enable the interrupt, clear any pending status */
> if (gma_power_begin(dev_priv->dev, false)) {
> u32 writeVal = PSB_RVDC32(reg);
> writeVal |= (mask | (mask >> 16));
> PSB_WVDC32(writeVal, reg);
> (void) PSB_RVDC32(reg);
> gma_power_end(dev_priv->dev);
> }
> }
> }
> 
> So, if a flag in dev_priv->pipestat[pipe] is not in agreement with
> dev->vblank[0].enabled,
> we will have a call to gma_power_begin() again and got an unavoidable
> deadlock.

I don't think it can ever happen in the current driver but the fix also
looks trivial. I think its sufficient to do this

commit 76d209fc77516f638c6db0342fddd0930d8e5957
Author: Alan 
Date:   Mon Mar 2 13:32:46 2015 +

gma500: drop the power lock before doing the irq pre/postinstall

The irq install is not locked or managed by the power lock. It will take the
lock again internally to do the vblank update so we would deadlock if a
change was ever needed.

diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index b6b135f..8d101f4 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -266,11 +266,11 @@ bool gma_power_begin(struct drm_device *dev, bool 
force_on)
/* Ok power up needed */
ret = gma_resume_pci(dev->pdev);
if (ret == 0) {
-   psb_irq_preinstall(dev);
-   psb_irq_postinstall(dev);
pm_runtime_get(>pdev->dev);
dev_priv->display_count++;
spin_unlock_irqrestore(_ctrl_lock, flags);
+   psb_irq_preinstall(dev);
+   psb_irq_postinstall(dev);
return true;
}
 out_false:

[Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken

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

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

--- Comment #8 from Stefan Dösinger  ---
I ran some more tests, it seems that the format is operating at 3 bits
precision. I can produce 8 different output colors. Otherwise it seems to
follow the spec, so I don't think we're accidentally feeding the data into an
R3G3B2 texture.

On Windows the format operates at the expected precision - I can get any output
data from 0x00 to 0xff.

I skimmed the GPU docs for clues what may cause this behavior but could not
find anything. The things I checked were enabling / disabling filtering, make
sure texture address handling follows conditional NP2 texture rules, disabling
alpha blending. For the sake of testing I also tried disabling FBOs and all our
sRGB code.

I'm also quite sure that all 8 bits of red0 and red1 input arrive on the GPU. I
tested that by setting the code of each texel to 7 and then testing red0=1,
red1=0 and red0=0 and red1=1. In the former case this gives the result 0
(interpolation between red0 and red1), in the latter case this gives 0xfc
(MAXRED). The same works for the input values 0x80 and 0x7f.

I tested interpolation codes (e.g. red0=0x2, red1=0xa2, code 2 for each texel,
then try to reduce red0 or red1 by 1), and it seems that the input into the
interpolation is OK, but either the interpolation happens at a lower precision
or the output is clamped afterwards.

-- 
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/20150302/ab7e0332/attachment.html>

[PATCH RFC 0/6] Use DRM component API in tilcdc to connect to tda998x

[Tomi Valkeinen]

Hi Rob,

You weren't cc'd to this series. I don't know if you're still interested
in tilcdc, but if you are, any comments appreciated =).

 Tomi

On 26/02/15 16:55, Jyri Sarha wrote:
> Remove tilcdc slave support and connect to tda998x trough its
> component DRM API. For dtb backward compatibility the code creates at
> boot time a DT overlay based on the earlier binding. The overlay
> conforms to the new graph based binding.
> 
> The first patch is just a bugfix and can be applied or dropped
> independenty.
> 
> Jyri Sarha (6):
>   drm/tilcdc: Fix module unloading
>   drm/tilcdc: Remove tilcdc slave support for tda998x driver
>   drm/tilcdc: Add support for external compontised DRM encoder
>   drm/tilcdc: Add DRM_TILCDC_INIT for "ti,tilcdc,slave" binding support
>   drm/tilcdc: Force building of DRM_TILCDC_INIT
>   ARM: dts: am335x-boneblack: Use new binding for HDMI
> 
>  .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
>  .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
>  arch/arm/boot/dts/am335x-boneblack.dts |  20 +-
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tilcdc/Kconfig |   6 +
>  drivers/gpu/drm/tilcdc/Makefile|   4 +-
>  drivers/gpu/drm/tilcdc/tilcdc_boot_init.c  | 270 ++
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  36 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c|  69 ++--
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h|   3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_external.c   | 105 ++
>  drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 ++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 
> -
>  drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
>  drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts|  70 
>  15 files changed, 601 insertions(+), 489 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
>  delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
>  delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts
> 


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/5760250a/attachment-0001.sig>

[PATCH v2] drm/i915: gen4: work around hang during hibernation

[Imre Deak]

Bjørn reported that his machine hang during hibernation and eventually
bisected the problem to the following commit:

commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak 
Date:   Thu Oct 23 19:23:26 2014 +0300

drm/i915: add poweroff_late handler

The problem seems to be that after the kernel puts the device into D3
the BIOS still tries to access it, or otherwise assumes that it's in D0.
This is clearly bogus, since ACPI mandates that devices are put into D3
by the OSPM if they are not wake-up sources. In the future we want to
unify more of the driver's runtime and system suspend paths, for example
by skipping all the system suspend/hibernation hooks if the device is
runtime suspended already. Accordingly for all other platforms the goal
is still to properly power down the device during hibernation.

v2:
- Another GEN4 Lenovo laptop had the same issue, while platforms from
  other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
  to work fine. Based on this apply the workaround on all GEN4 Lenovo
  platforms.
- add code comment about failing platforms (Ville)

Reference: 
http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
Reported-and-bisected-by: Bjørn Mork 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4badb23..ff3662f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -637,7 +637,7 @@ static int i915_drm_suspend(struct drm_device *dev)
return 0;
 }

-static int i915_drm_suspend_late(struct drm_device *drm_dev)
+static int i915_drm_suspend_late(struct drm_device *drm_dev, bool hibernation)
 {
struct drm_i915_private *dev_priv = drm_dev->dev_private;
int ret;
@@ -651,7 +651,17 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev)
}

pci_disable_device(drm_dev->pdev);
-   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
+   /*
+* During hibernation on some GEN4 platforms the BIOS may try to access
+* the device even though it's already in D3 and hang the machine. So
+* leave the device in D0 on those platforms and hope the BIOS will
+* power down the device properly. Platforms where this was seen:
+* Lenovo Thinkpad X301, X61s
+*/
+   if (!(hibernation &&
+ drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
+ INTEL_INFO(dev_priv)->gen == 4))
+   pci_set_power_state(drm_dev->pdev, PCI_D3hot);

return 0;
 }
@@ -677,7 +687,7 @@ int i915_suspend_legacy(struct drm_device *dev, 
pm_message_t state)
if (error)
return error;

-   return i915_drm_suspend_late(dev);
+   return i915_drm_suspend_late(dev, false);
 }

 static int i915_drm_resume(struct drm_device *dev)
@@ -965,7 +975,17 @@ static int i915_pm_suspend_late(struct device *dev)
if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;

-   return i915_drm_suspend_late(drm_dev);
+   return i915_drm_suspend_late(drm_dev, false);
+}
+
+static int i915_pm_poweroff_late(struct device *dev)
+{
+   struct drm_device *drm_dev = dev_to_i915(dev)->dev;
+
+   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   return 0;
+
+   return i915_drm_suspend_late(drm_dev, true);
 }

 static int i915_pm_resume_early(struct device *dev)
@@ -1535,7 +1555,7 @@ static const struct dev_pm_ops i915_pm_ops = {
.thaw_early = i915_pm_resume_early,
.thaw = i915_pm_resume,
.poweroff = i915_pm_suspend,
-   .poweroff_late = i915_pm_suspend_late,
+   .poweroff_late = i915_pm_poweroff_late,
.restore_early = i915_pm_resume_early,
.restore = i915_pm_resume,

-- 
2.1.0

[PATCH 14/21] drm/omap: stop connector polling during suspend

[Tomi Valkeinen]

On 26/02/15 15:57, Grygorii.Strashko at linaro.org wrote:

> Could I ask you to update this patch as below, pls?

Your changes look ok to me, but they are not related to my patch so I
don't see any reason to merge them. I'll pick your patch to my series.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/0270a449/attachment-0001.sig>

[PATCH 09/21] drm/omap: handle mismatching color format and buffer width

[Tomi Valkeinen]

On 02/03/15 12:22, Daniel Stone wrote:

>> I don't know why Rob named it like that. "The bpp of the stride"? Shrug.
> 
> It's just the bpp of the pixel format; it's not at all associated with
> the stride?

The comment says "this times width is stride", so I thought the naming comes
from that train of thought. But I agree, it's just bpp.

Here's updated patch:

[git pull] drm fixes

[Jani Nikula]

On Mon, 02 Mar 2015, Paul Bolle  wrote:
> On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
>> Hmm. 3.19 works fine, even if it ends up spewing
>> 
>> WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
>> drm_wait_one_vblank+0x125/0x130()
>> vblank not available on crtc 1, ret=-22
>> 
>> a lot.
>
> For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
> in http://lkml.kernel.org/r/20150131211609.GA3710 at yulia-desktop .
>
> Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
> encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
> commit will end up in v3.19-stable in due time.

Yes; the commit lacked cc: stable, I just requested a backport moments
before your mail [1].

BR,
Jani.


[1] http://mid.gmane.org/874mq3oif5.fsf at intel.com


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 06/21] drm/omap: check CRTC color format earlier

[Tomi Valkeinen]

On 27/02/15 14:07, Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 03:20:14PM +0200, Tomi Valkeinen wrote:
>> When setting a color format to a DRM plane, the DRM core checks whether
>> the format is supported by the HW. However, it seems that when setting
>> the color format of a CRTC (i.e. a root plane), there's no checking
>> done. This causes omapdrm to configure omapdss with the bad color
>> format, which omapdss then rejects.
>>
>> While the above is ok, the error message is a bit confusing, and the
>> configuring of omapdss happens asynchronously from the ioctl that does
>> the color format change.
>>
>> This patch adds a color format check to omap_plane_mode_set() which
>> causes the ioctl to return an error for invalid color format. This means
>> that the userspace will get to know of the wrong setting, instead of the
>> current behavior where the error is not seen by the userspace.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>> index 1f4f2b866379..bedd6f7af0f1 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>> @@ -207,6 +207,24 @@ int omap_plane_mode_set(struct drm_plane *plane,
>>  {
>>  struct omap_plane *omap_plane = to_omap_plane(plane);
>>  struct omap_drm_window *win = _plane->win;
>> +int i;
>> +
>> +/*
>> + * Check whether this plane supports the fb pixel format.
>> + * I don't think this should really be needed, but it looks like the
>> + * drm core only checks the format for planes, not for the crtc. So
>> + * when setting the format for crtc, without this check we would
>> + * get an error later when trying to program the color format into the
>> + * HW.
>> + */
> 
> I think we should add a format check to the setcrtc ioctl if crtc->primary
> is set. Atm the code is in __setplane_internal but could easily be shared
> - there's already a copy in drm_atomi.c.
> 
> Omapdrm wouldn't benefit from this yet since it doesn't support universal
> planes. But adding universal planes should be on your todo anyway ;-)

Laurent is working on universal planes and atomic modesetting for
omapdrm. In fact, I think universal planes is already done in his WIP
branch.

So, if this check is already done with universal planes (if I understood
correctly), I'm fine with dropping this patch.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/8cd47b4d/attachment-0001.sig>

[PATCH 09/21] drm/omap: handle mismatching color format and buffer width

[Tomi Valkeinen]

On 27/02/15 16:40, Daniel Stone wrote:
> Hi,
> 
> On 27 February 2015 at 13:01, Daniel Vetter  wrote:
>> On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
>>> omapdrm doesn't check if the width of the framebuffer and the color
> 
> s/width/pitch/
> 
>>> format's bits-per-pixel match.
> 
> s/match/are compatible/
> 
>>> For example, using a display with a width of 1280, and a buffer
>>> allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
> 
> Might be clearer to say 'i.e. byte stride of ...', and also s/with using/for/.

Above you said pitch, here you say stride. They are the same thing, right?

>>> a 24 bits per pixel color format, leads to the following mismatch:
>>> 5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
> 
> s/bytes/pixels/
> 
>>> screen.
>>>
>>> Add a check into omapdrm to return an error if the user tries to use
>>> such a combination.
>>>
>>> Signed-off-by: Tomi Valkeinen 
>>> ---
>>>  drivers/gpu/drm/omapdrm/omap_fb.c | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
>>> b/drivers/gpu/drm/omapdrm/omap_fb.c
>>> index 2975096abdf5..bf98580223d0 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
>>> @@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
>>> drm_device *dev,
>>>   goto fail;
>>>   }
>>>
>>> + if (mode_cmd->width % format->planes[i].stride_bpp != 0) {
>>
>> width is in pixels. No idea what you're trying to check here, but this
>> probably isn't it.

Yep, I don't know what I was smoking when writing the patch...

> stride_bpp is very misnamed: it is the bits per pixel for that plane,
> and not stride at all. I think the check should in fact be be (pitch %

I don't know why Rob named it like that. "The bpp of the stride"? Shrug.

> format->planes[i].stride_bpp), which would achieve the desired result,
> i.e. that the stride can be expressed as an integer number of pixels.

Yes, that looks correct.

>> Also drm checks that things fit into the specified pitch (which is in
>> bytes), see the pichtes[i] < width * cpp check in framebuffer_check.
> 
> This isn't that check. At some stages, OMAP IIRC requires pitch to be
> specified in pixels rather than bytes, so this makes sure that's
> possible to express.

Right, that's what this patch was trying to achieve.

However... After thinking about this and going through some of the DISPC
code, I think that's not a strict requirement. We do calculate all the
configs using pixels as units, so at the moment the stride has to be an
integer number of pixels. But the hardware actually takes the row-inc
and pix-inc as bytes.

That said, the HW supports features like rotation and whatnot, and it
was not clear with a quick study if there are corner cases where the
hardware also requires the stride to be an integer number of pixels.
Also, the HW documentation only talks about pixels in this context, even
if the final value written to the registers is in bytes. I don't know if
that's just to make the documentation simpler, or if there's some
reasoning to only use pixel units.

So I think for the time being I'll just fix this patch, and look at the
possibility of allowing any stride size in the future.

Thanks for the review!

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150302/c58b5b81/attachment-0001.sig>

[PATCH 2/2] tests/kmstest: support atmel-hlcdc

[Boris Brezillon]

From: Boris BREZILLON 

Signed-off-by: Boris BREZILLON 
---
 tests/kmstest/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 2c87b1c..7028cb2 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -63,6 +63,7 @@ char *drivers[] = {
"vmwgfx",
"exynos",
"imx-drm",
+   "atmel-hlcdc",
NULL
 };

-- 
1.9.1

[PATCH 1/2] modetest: add atmel-hlcdc driver support

[Boris Brezillon]

From: Boris BREZILLON 

Signed-off-by: Boris BREZILLON 
---
 tests/modetest/modetest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 425e528..ae261f0 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1453,7 +1453,7 @@ int main(int argc, char **argv)
int drop_master = 0;
int test_vsync = 0;
int test_cursor = 0;
-   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
"omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm" };
+   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
"omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm", "atmel-hlcdc" 
};
char *device = NULL;
char *module = NULL;
unsigned int i;
-- 
1.9.1

[Intel-gfx] [git pull] drm fixes

[Daniel Vetter]

On Mon, Mar 02, 2015 at 10:44:16AM +0100, Paul Bolle wrote:
> On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> > Hmm. 3.19 works fine, even if it ends up spewing
> > 
> > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> > drm_wait_one_vblank+0x125/0x130()
> > vblank not available on crtc 1, ret=-22
> > 
> > a lot.
> 
> For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
> in http://lkml.kernel.org/r/20150131211609.GA3710 at yulia-desktop .
> 
> Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
> encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
> commit will end up in v3.19-stable in due time.

Yeah we've forgotten to tag it as stable (it missed 3.19 by a notch and
we didn't add teh tag when moving it to the 3.20^W4.0 branch) but Jani
just sent out the mail for that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #57 from Gustaw Smolarczyk  ---
Will try when I return home.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

Maarten Lankhorst  changed:

   What|Removed |Added

 Attachment #168571|0   |1
is obsolete||

--- Comment #56 from Maarten Lankhorst  ---
Created attachment 168581
  --> https://bugzilla.kernel.org/attachment.cgi?id=168581=edit
reshuffle evergreen_dma_fence_ring_emit

Try this patch perhaps, and remove the || 1's?

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

[Bug 89377] [radeonsi] "Hand of Fate" is stuck on SIGPWR/SIGXCPU after start

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

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

Kai  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Kai  ---
(In reply to smoki from comment #1)
> (In reply to Kai from comment #0)
> > 
> > Let me know, if you need something else.
> 
>  Xorg.0.log and glxinfo output.

Nope. glxinfo would only be helpful, if you want to suggest I'm not using
radeonsi and falling back to e.g. llvmpipe. Xorg.0.log would have been posted
(and mentioned), if something would have been logged there, after starting the
game (same goes for the obvious other places like dmesg).

>  Because it must be specific to resolution or you might miss s3tc extension,
> or such...

No. Have a look at the referenced bug, and you can see that this assumption is
baseless. A missing S3TC extension might lead to textureless models, but most
likely not to a SIGPWR/SIGXCPU. Please don't just throw random stuff in bug
reports, keep the noise down. My reply here was inflated unnecessarily.

But since yesterday I've been able to find, that the game generating "Got a bad
hardware address length for an AF_PACKET 16 8" is a known bug with Unity/Mono
and some games express the same behaviour (black screen). I'm going to close
this bug for the moment and open it later, if the developer fixed the issue and
this problem persists.

-- 
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/20150302/f649a9d5/attachment.html>

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #55 from Maarten Lankhorst  ---
Do you happen to know if it's DMA or DMA1?

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

[Intel-gfx] [PATCH] drm/i915: fix failure to power off after hibernate

[David Weinehall]

On Fri, Feb 27, 2015 at 08:23:41PM +0200, Imre Deak wrote:
> We've checked today with Ville a few machines we've found from GEN2 to
> GEN5+. There was one Thinkpad x61s (GEN4) where I could reproduce the
> exact same problem and get rid of it using the same workaround. All the
> others were non-Lenovo (including GEN4) mobile and desktop platforms and
> none of these had the problem. I also tried it on a Lenovo IVB
> ultrabook, which also works fine. So the current theory is that it's
> related to GEN4 Thinkpad BIOSes, and so we need to change the condition
> to match that at least.

If you need more ThinkPads to test with I have a few at home :)


Kind regards, David

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #54 from Maarten Lankhorst  ---
Just look if there's some output in dmesg or not.

To verify, only having interrupts enabled on the DMA conditions fixes your bug?

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

[git pull] drm fixes

[Paul Bolle]

On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> Hmm. 3.19 works fine, even if it ends up spewing
> 
> WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> drm_wait_one_vblank+0x125/0x130()
> vblank not available on crtc 1, ret=-22
> 
> a lot.

For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
in http://lkml.kernel.org/r/20150131211609.GA3710 at yulia-desktop .

Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
commit will end up in v3.19-stable in due time.


Paul Bolle

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #53 from Gustaw Smolarczyk  ---
At first, I added "|| 1" only to GFX, CP1 and CP2 (I omitted the two DMA
conditions). This did NOT fix the pauses.

However, after converting these final two DMA conditions, the pauses are gone.
Reverting GFX condition didn't change that.

Also - is there an easy way to check whether the WARN_ON have been fired or
not?

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

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

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

--- Comment #33 from russianneuromancer at ya.ru ---
Same issue with RS880M. Sometimes hang on very beginning (before first frame
appear on the screen) and sometimes after one/few/many attempts to rewind.

Tested with Linux 3.19, latest Mesa snapshot from Oibaf PPA, and mpv 0.8.

-- 
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/20150302/1677a36b/attachment.html>

[PATCH 09/21] drm/omap: handle mismatching color format and buffer width

[Daniel Stone]

Hi,

On 2 March 2015 at 09:50, Tomi Valkeinen  wrote:
> On 27/02/15 16:40, Daniel Stone wrote:
>> On 27 February 2015 at 13:01, Daniel Vetter  wrote:
>>> On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
 omapdrm doesn't check if the width of the framebuffer and the color
>>
>> s/width/pitch/
>>
 format's bits-per-pixel match.
>>
>> s/match/are compatible/
>>
 For example, using a display with a width of 1280, and a buffer
 allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
>>
>> Might be clearer to say 'i.e. byte stride of ...', and also s/with 
>> using/for/.
>
> Above you said pitch, here you say stride. They are the same thing, right?

Yeah, they're interchangeable. In theory, I think it's supposed to be
that pitch is in pixels and stride in bpp, but they're so often
interchanged that they've lost that distinction. Still, using one
consistently is always good - and since KMS uses pitch exclusively,
that might be a good one to settle on.

>> stride_bpp is very misnamed: it is the bits per pixel for that plane,
>> and not stride at all. I think the check should in fact be be (pitch %
>
> I don't know why Rob named it like that. "The bpp of the stride"? Shrug.

It's just the bpp of the pixel format; it's not at all associated with
the stride?

>> This isn't that check. At some stages, OMAP IIRC requires pitch to be
>> specified in pixels rather than bytes, so this makes sure that's
>> possible to express.
>
> Right, that's what this patch was trying to achieve.
>
> However... After thinking about this and going through some of the DISPC
> code, I think that's not a strict requirement. We do calculate all the
> configs using pixels as units, so at the moment the stride has to be an
> integer number of pixels. But the hardware actually takes the row-inc
> and pix-inc as bytes.
>
> That said, the HW supports features like rotation and whatnot, and it
> was not clear with a quick study if there are corner cases where the
> hardware also requires the stride to be an integer number of pixels.
> Also, the HW documentation only talks about pixels in this context, even
> if the final value written to the registers is in bytes. I don't know if
> that's just to make the documentation simpler, or if there's some
> reasoning to only use pixel units.

Indeed that was my impression from a quick look, but my OMAP is
extremely rusty these days, so wasn't quite sure ... :) Specifying
pixel units isn't totally unheard of, but bytes is definitely more
common.

Cheers,
Daniel

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #52 from Maarten Lankhorst  ---
Yes, and also add a WARN_ON(!rdev->ih.enabled); to
radeon_fence_enable_signaling, just to be thorough..

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #51 from Gustaw Smolarczyk  ---
Should I apply it on top of attachment 166571?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #50 from Maarten Lankhorst  ---
Ok never mind that approach then..

in radeon_fence.c, add a
WARN_ON((int)atomic_read(>irq.ring_int[fence->ring]) <= 0); after the
sw_irq_get, it should never fire.

in si.c you have a few lines like this:

if (atomic_read(>irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
DRM_DEBUG("si_irq_set: sw int gfx\n");
cp_int_cntl |= TIME_STAMP_INT_ENABLE;
}
if (atomic_read(>irq.ring_int[CAYMAN_RING_TYPE_CP1_INDEX])) {
DRM_DEBUG("si_irq_set: sw int cp1\n");
cp_int_cntl1 |= TIME_STAMP_INT_ENABLE;
}
if (atomic_read(>irq.ring_int[CAYMAN_RING_TYPE_CP2_INDEX])) {
DRM_DEBUG("si_irq_set: sw int cp2\n");
cp_int_cntl2 |= TIME_STAMP_INT_ENABLE;
}

Can you first change all of the conditions to atomic_read(..) || 1 so it always
sets the irqs? That should fix the hangs at some cpu overhead..

If that works and you no longer get hangs, can you remove the || 1 for
RADEON_RING_TYPE_GFX_INDEX, see if the hangs are still gone?

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

[PATCH v4 13/15] ASoC: codec/dw-hdmi-audio: add codec driver for dw hdmi audio

[Paul Bolle]

On Sat, 2015-02-28 at 21:59 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/sound/soc/codecs/dw-hdmi-audio.c
> @@ -0,0 +1,379 @@
> +/*
> + * dw-hdmi-codec.c

Doesn't match the filename. Is this line needed?

> + * DesignerWare ALSA SoC DAI driver for DW HDMI audio.
> + * Copyright (c) 2014,  CORPORATION. All rights reserved.
> + * Authors: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .*
> + *
> + */

This states that the license is plain GPL v2.

(Missing empty line here.)

> +#include 

[...]

> +MODULE_LICENSE("GPL");

So you probably want
MODULE_LICENSE("GPL v2");

here.


Paul Bolle

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #49 from Gustaw Smolarczyk  ---
(had to remove "robj->" from the patch).

Doesn't help.

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

[PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio

[Paul Bolle]

On Sat, 2015-02-28 at 22:04 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/sound/soc/rockchip/rockchip_hdmi_audio.c
> @@ -0,0 +1,169 @@
> +/*
> + * rockchip-hdmi-card.c

Doesn't match the filename. Is this line needed anyway?

> + *
> + * ROCKCHIP ALSA SoC DAI driver for HDMI audio on rockchip processors.
> + * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved.
> + * Authors: Yakir Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .*
> + *
> + */

This states the license is plain GPL v2.

> +MODULE_LICENSE("GPL");

So you probably want
MODULE_LICENSE("GPL v2");

here.


Paul Bolle

[PATCH] drm/i915: Fix trivial typos in comments and warning message

[Daniel Vetter]

On Sat, Feb 28, 2015 at 05:20:41PM +0100, Yannick Guerrini wrote:
> Change 'mutliple' to 'multiple'
> Change 'mutlipler' to 'multiplier'
> Change 'Haswel' to 'Haswell'
> 
> Signed-off-by: Yannick Guerrini 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
>  drivers/gpu/drm/i915/i915_reg.h| 2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 85a6ada..213a261 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1518,7 +1518,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
> *data,
>* - The batch is already pinned into the relevant ppgtt, so we
>*   already have the backing storage fully allocated.
>* - No other BO uses the global gtt (well contexts, but meh),
> -  *   so we don't really have issues with mutliple objects not
> +  *   so we don't really have issues with multiple objects not
>*   fitting due to fragmentation.
>* So this is actually safe.
>*/
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 55143cb..56b97c4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3019,7 +3019,7 @@ enum skl_disp_power_wells {
>  
>  /* Video Data Island Packet control */
>  #define VIDEO_DIP_DATA   0x61178
> -/* Read the description of VIDEO_DIP_DATA (before Haswel) or VIDEO_DIP_ECC
> +/* Read the description of VIDEO_DIP_DATA (before Haswell) or VIDEO_DIP_ECC
>   * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each 
> byte
>   * of the infoframe structure specified by CEA-861. */
>  #define   VIDEO_DIP_DATA_SIZE32
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 64ad2b4..9e554c2 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1247,7 +1247,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder 
> *intel_encoder)
>  
>   switch (crtc->config->pixel_multiplier) {
>   default:
> - WARN(1, "unknown pixel mutlipler specified\n");
> + WARN(1, "unknown pixel multiplier specified\n");
>   case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break;
>   case 2: rate = SDVO_CLOCK_RATE_MULT_2X; break;
>   case 4: rate = SDVO_CLOCK_RATE_MULT_4X; break;
> -- 
> 1.9.5.msysgit.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[git pull] drm fixes

[Daniel Vetter]

On Sun, Mar 01, 2015 at 05:59:53PM -0800, Linus Torvalds wrote:
> On Sun, Mar 1, 2015 at 1:00 PM, Linus Torvalds
>  wrote:
> >
> > Back to the drawing board.
> 
> Ok, many hours later, but I found it.
> 
> The bisection was a disaster, having to work around other bugs in this
> area, but it ended up getting "close enough" that I figured out what
> went wrong.

Sorry for all the bisect work. Ville dug as far as the load detect being
unhappy due to atomic last week. But since I general don't real mail on
w/e I've only seen this thread now.

> The "intel_plane_duplicate_state()" is horribly horribly buggy. It
> looks at the state->fb pointer, but it may have been free'd already.
> 
> This workaround "works for me", but it's really still very
> questionable, because while the "kref_get_unless_zero()" works
> correctly when the last reference has been dropped, I'm not sure that
> there is any guarantee that the whole allocation even exists any more,
> so I think the *correct* thing to do would be to clear state->fb when
> dropping the kref. But this was the smallest working patch I could
> come up with. Somebody who actually knows the code should start
> looking at the places that do drm_framebuffer_unreference(), and
> actually clear that pointer instead.
> 
> Added Matt Roper and Ander Conselvan de Oliveira to the discussion,
> since they are the ones git says are involved with the original broken
> intel_plane_duplicate_state().
> 
> Anyway, attached is
> 
>  (a) the patch with a big comment
> 
>  (b) the warnings I get on that machine that show where this problem
> triggers (and another warning earlier).
> 
> Comments? I'm sure this probably only triggers with *old* X servers
> that don't do all the modern dri stuff.

It's not old X servers but old machines which don't have hotplug
interrupts (or still have tv-out, which doesn't have hpd support
anywhere).

I'll dig into this now just fyi the rules about how plane->state should be
handled:
- you need plane->lock
- it's invariant once assigned, updates should only be done with a
  duplicate_state(), update state you want to change and the going through
  the atomic commit machinery
- drm_plane_state->fb should always be a full reference

But switching to atomic amounts to a full rewrite of the drm core and
drivers (semantics for modeset updates are totally different). So there's
lots of glue and ducttape going on to keep up the illusion for both old
code and partially transitioned driver. It's all a bit wobbly atm and
don't loook too closely at some of the hacks we have.

And can you please attach a bactrace of the WARN in your patch, just to
double-check you blow up at the same spot?

Thanks, Daniel

>Linus

> From c182b15c3abee75cdc9d9564b6ab826403690f4e Mon Sep 17 00:00:00 2001
> From: Linus Torvalds 
> Date: Sat, 28 Feb 2015 21:44:48 -0800
> Subject: [PATCH] Workaround for drm bug
> 
> Signed-off-by: Linus Torvalds 
> 
> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 9e6f727..72714d3 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -85,8 +85,23 @@ intel_plane_duplicate_state(struct drm_plane *plane)
>   return NULL;
>  
>   state = _state->base;
> - if (state->fb)
> - drm_framebuffer_reference(state->fb);
> +
> + /*
> +  * We cannot do drm_framebuffer_reference(), because the reference
> +  * may already have been dropped.
> +  *
> +  * So we do what drm_framebuffer_lookup() does, namely do a
> +  * kref_get_unless_zero(). Even that is somewhat questionable,
> +  * in that maybe the 'fb' already got free'd. So warn loudly
> +  * about this.
> +  *
> +  * Maybe the base.fb should be cleared by whatever drops the
> +  * reference?
> +  */
> + if (state->fb && !kref_get_unless_zero(>fb->refcount)) {
> + state->fb = NULL;
> + WARN_ONCE(1, "intel_plane_duplicate_state got plane with dead 
> frame buffer");
> + }
>  
>   return state;
>  }
> -- 
> 2.3.1.167.g7f4ba4b
> 


> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #48 from Maarten Lankhorst  ---
Created attachment 168571
  --> https://bugzilla.kernel.org/attachment.cgi?id=168571=edit
flush hdp harder

No idea if this does anything, adding a bunch of flushes instead of doing a
sleep.. pauses still occur?

If not can you check if it still works with only the chunk in
radeon_fence_enable_signalling?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #47 from Gustaw Smolarczyk  ---
With 500us delay, the performance is nearly back to how it was (~70fps). And
the pauses are still gone.

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

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #9 from Tvrtko Ursulin  ---
Thanks Emil! Unfortunaltey I am not familiar with Optimus nor do I have
appropriate hardware.

Could someone provide a backtrace (with symbols) of the binary which ends up
saying "malloc: unknown:0: assertion botched", etc? Or maybe even Valgrind it?
Although that may be pretty advanced.

I don't think this commit is the actual culprit, but it is possible that the
failing binary uses UserPtr if it detects it, and has a bug in those optional
code paths.

Another interesting test would be to try non-working libdrm on a kernel without
UserPtr support.

-- 
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/20150302/19b8ee3b/attachment.html>

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #46 from Maarten Lankhorst  ---
Ok what about udelay(500), should be a smaller pause?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #45 from Gustaw Smolarczyk  ---
(In the end I had to use mdelay(50))

The performance was really traumatic (8-11fps). But on a positive side, there
seemed to be no pauses. There was one moment when fps dropped to 0 (for ~1/3 of
a second), but it may have been due to completely different reason.

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