[PATCH v3 22/24] drm/i2c: tda998x: change the frequence in the audio channel

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:47PM +0100, Jean-Francois Moine wrote:
> This patch sets the frequence as 'not indicated' instead of '48kHz'
> and adds some comments.
> 
> Signed-off-by: Jean-Francois Moine 

Good catch that byte 2 doesn't exist in this set.

sound/asounddef.h has definitions for these:

IEC958_AES0_CON_NOT_COPYRIGHT
IEC958_AES3_CON_FS_NOTID
IEC958_AES4_CON_MAX_WORDLEN_24
IEC958_AES4_CON_ORIGFS_NOTID

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 21/24] drm/i2c: tda998x: add the active aspect in HDMI AVI frame

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:46PM +0100, Jean-Francois Moine wrote:
> Signed-off-by: Jean-Francois Moine 

"The picture aspect setting was zero, which is reserved.  A setting of
Same As Picture makes more sense."

Tested-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 20/24] drm/i2c: tda998x: remove the unused variable ca_i2s

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:46PM +0100, Jean-Francois Moine wrote:
> Signed-off-by: Jean-Francois Moine 

"ca_i2s is only ever written to, but never read, so let's get rid of it."

Tested-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 19/24] drm/i2c: tda998x: use global constants

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:45PM +0100, Jean-Francois Moine wrote:
> Signed-off-by: Jean-Francois Moine 

Might be worth also saying "and tidy up AIP_CLKSEL" since arguably they
were already using global constants.  In any case, no one likes single
line patch descriptions.  Always try to write something more about the
patch.

I've verified this via inspection, and tested it.

Tested-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 18/24] drm/i2c: tda998x: fix the ENABLE_SPACE register

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:45PM +0100, Jean-Francois Moine wrote:
> This patch fixes the ENABLE_SPACE register, the value of which was
> inverted.
> 
> Signed-off-by: Jean-Francois Moine 

I've researched the change to PLL_SERIAL_2, and this is correct.  I think
your change to REG_ENABLE_SPACE is also correct.  This looks like a bug
fix to me, so maybe consider having it applied to previous kernel
versions as well?

Also... please try putting yourself in the position of a reviewer of your
own patches - read the patch and then read the description, and ask whether
the description is adequate for the patch... the description talks just
about the ENABLE_SPACE register.  But what about the PLL_SERIAL_2 register
changes?  They're *totally* not described.

Hence...

Tested-by: Russell King 

and no acked-by.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15

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

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

--- Comment #7 from Alex Deucher  ---
Does manually disabling audio on 3.13 break things?  E.g., set radeon.audio=0
on the kernel command line in grub.

-- 
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/20140122/2aab5c1d/attachment.html>

[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15

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

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

--- Comment #6 from Marti Raudsepp  ---
Created attachment 92625
  --> https://bugs.freedesktop.org/attachment.cgi?id=92625=edit
dmesg when booting with git rev 10ebc0b

This message looks interesting (also present int the original upload)
Jan 23 00:45:54 tewn kernel: radeon :01:00.0: Invalid ROM contents

-- 
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/20140122/a49268ae/attachment.html>

[PATCH v3 17/24] drm/i2c: tda998x: get a better status of the connection

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:44PM +0100, Jean-Francois Moine wrote:
> This patch refines the connection status testing both bits RXSENS and
> HPD of the CEC register giving the connection level.

Can you explain why this is necessary?

I believe this is not necessary for the following reason:

HDMI cables are required to mate in a certain order:
- First to mate is the shell.
- Second are all pins with the exception of the +5V line.
- Third is the +5V line.

Sinks are not permitted to assert the HPD line until the EDID memory is
ready to be read, and +5V is indicated from the source.

Hence, HPD will not be asserted until the connector is fully mated, and
there are receivers available on the line.

This doesn't indicate whether the sink is powered and able to display
a picture - it merely means that the sink is present and valid EDID is
available to be read.  That's all that we really need here.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15

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

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

--- Comment #5 from Marti Raudsepp  ---
(In reply to comment #3)
> Any chance you could bisect to see what the fix was?

I got my hands on a spare disk and did the bisect.
Strangely enough this turned up (!?)

["first bad commit" meaning good, since I had to invert bisect bad/good]

ad41550666f89b5af9335fcde9e98b61190daf99 is the first bad commit
commit ad41550666f89b5af9335fcde9e98b61190daf99
Author: Alex Deucher 
Date:   Thu Sep 26 13:11:18 2013 -0400

drm/radeon: enable hdmi audio by default

Seems to be stable enough for the majority of users.
It can be disabled on the fly via connector attributes.

Signed-off-by: Alex Deucher 

Just to make sure, I double-checked...

uname -r && dmesg |grep 'VM fault'
3.12.0-rc3-ARCH-00404-gad41550

uname -r && dmesg |grep 'VM fault'
3.12.0-rc3-ARCH-00403-g10ebc0b
[   18.716461] VM fault (0x00, vmid 0) at page 0, read from unknown (0)
[   18.716466] VM fault (0x00, vmid 0) at page 0, read from unknown (0)
[   18.716470] VM fault (0x00, vmid 0) at page 0, read from unknown (0)
...

GDM successfully starts with the 1st and fails with the 2nd.

What does this even mean, how can disabling HDMI audio break things? :)

-- 
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/20140122/548c6f28/attachment-0001.html>

[PATCH v3 15/24] drm/i2c: tda998x: use irq for connection status and EDID read

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
> This patch adds the optional treatment of the tda998x IRQ.
> 
> The interrupt function is used to know the display connection status
> without polling and to speedup reading the EDID.
> 
> The interrupt number may be defined either in the DT or at encoder set
> config time for non-DT boards.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
> v3
> - remarks from Russell King
>   - move the setting of the wq_edid_wait flag before asking the
> device to read the EDID
> Thanks about this bug fix, but I don't see the other problem:
> there is no reason for the read_edid_block function to be
> called more than once...

It will happen whenever DRM asks the connector for the modes.  However,
since the read process is triggered each time, I think this is fine.

>   - use '0' as 'no irq'
>   - remove the useless delay after irq init

Some further comments...

> @@ -720,6 +787,10 @@ tda998x_encoder_set_config(struct drm_encoder *encoder, 
> void *params)
>   priv->audio_port = p->audio_cfg;
>   priv->audio_format = p->audio_format;
>   }
> +
> + priv->irq = p->irq;
> + if (p->irq)
> + tda_irq_init(priv);

If we're going to do it this way, this should probably release the IRQ if
there was one before re-claiming it, just in case this function gets called
more than once by some driver using it.

The alternative is, as I said before, to use the infrastructure which is
already there, namely setting the interrupt via struct i2c_client's
irq member.  Yes, that doesn't satisfy Sebastian's comment about using
a GPIO, but there's no sign of GPIO usage in here at the moment anyway.
So we might as well use what's already provided.

That would then avoid the need to deal with IRQ changes etc in
tda998x_encoder_set_config().

In any case, I've tested this patch in both non-IRQ and IRQ modes, and it
appears to work - but I'd like the suggestion above before I provide any
attributations.

Thanks.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[Bug 73947] [DPM] Cape Verde PRO - GPU lockup when dpm is enabled

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

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

--- Comment #2 from Alexander Tsoy  ---
(In reply to comment #0)
> My software:
> 
> linux-3.12.8 && linux-3.13.0

Same problem with 3.11.9

-- 
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/20140122/bb232b46/attachment.html>

[PATCH v3 13/24] drm/i2c: tda998x: fix a NULL pointer dereference

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
> This patch fixes a NULL pointer dereference when the set_config
> function has not been called (priv->params == NULL).

No, that's not what this patch is doing.  Maybe you could enlighten me
how priv->params could ever be NULL when that is _not_ a pointer?  That's
completely impossible as it isn't a pointer.

If you tried "priv->params = NULL" the C compiler would barf on it.

I suspect you've misunderstood the code, and this change isn't actually
necessary.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 14/24] drm/i2c: tda998x: add DT support

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
> This patch adds DT support to the tda998x.
> 
> Signed-off-by: Jean-Francois Moine 

Acked-by: Russell King 
Tested-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 10/24] drm/i2c: tda998x: don't read write-only registers

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:42PM +0100, Jean-Francois Moine wrote:
> This patch takes care of the write-only registers of the tda998x.
> 
> The value 'MAT_CONTRL_MAT_SC(1)' in the register MAT_CONTRL has been
> set as it is at reset time.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
> v3
> - remarks from Russell King
>   - don't move the sync polarity setting after the setting of the
> register TBG_CNTRL_0 which must be the last setting of the
> init sequence

This is better, except I find that there's an additional change in this
version which wasn't in the original patch 9:

>   /* must be last register set: */
> - reg_clear(priv, REG_TBG_CNTRL_0, TBG_CNTRL_0_SYNC_ONCE);
> + reg_write(priv, REG_TBG_CNTRL_0, 0);

Register changes which have a potential effect shouldn't be part of a
patch which is really only trying to avoid reading from write only
registers.

This could be a potential functional change - and it's probably one
which Rob Clark should at least be made aware of.  As I commented last
time, when you're changing register values in an otherwise innocuous
patch, you should comment about them in the patch description.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 07/24] drm/i2c: tda998x: set the video mode from the adjusted value

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:40PM +0100, Jean-Francois Moine wrote:
> This patch uses always the adjusted video mode instead of a mix of
> original and adjusted mode.
> 
> Signed-off-by: Jean-Francois Moine 

Nothing obviously wrong and appears to work, thanks.

Acked-by: Russell King 
Tested-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 03/24] drm/i2c: tda998x: code cleanup

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:38PM +0100, Jean-Francois Moine wrote:
> This patch:
> - replaces ARRAY_SIZE() by sizeof() when a number of bytes is needed,
> - adds a linefeed in an error message and
> - removes an useless variable setting.
> 
> Tested-by: Russell King 
> Signed-off-by: Jean-Francois Moine 

Thanks.

Acked-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[PATCH v3 02/24] drm/i2c: tda998x: check more I/O errors

[Russell King - ARM Linux]

On Sun, Jan 19, 2014 at 07:58:38PM +0100, Jean-Francois Moine wrote:
> This patch adds more error checking inn I2C I/O functions.
> In case of I/O error, this permits to avoid writing in bad controller
> pages, a bad chipset detection or looping when getting the EDID.
> 
> Tested-by: Russell King 
> Signed-off-by: Jean-Francois Moine 

Thanks.

Acked-by: Russell King 

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

[Bug 73947] [DPM] Cape Verde PRO - GPU lockup when dpm is enabled

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

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

--- Comment #1 from Alexander Tsoy  ---
Created attachment 92620
  --> https://bugs.freedesktop.org/attachment.cgi?id=92620=edit
Xorg.0.log

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

[Bug 73947] New: [DPM] Cape Verde PRO - GPU lockup when dpm is enabled

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

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

  Priority: medium
Bug ID: 73947
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [DPM] Cape Verde PRO - GPU lockup when dpm is enabled
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: alexander at tsoy.me
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

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

Running Unigine Heaven 3.0 causes GPU lockup after 1-2 seconds. This happens
only if dpm is enabled. GPU can be restored to a normal operation only via
system reboot.

My software:

linux-3.12.8 && linux-3.13.0
mesa-10.0.2
llvm-3.4
xf86-video-ati- (latest git)
glamor- (latest git)
libdrm-2.4.50
xorg-server-1.14.3

My hardware:

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Cape Verde PRO [Radeon HD 7750] [1002:683f]

-- 
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/20140122/14780024/attachment.html>

[Bug 73946] scanout broken on radeon SI (OLAND)

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

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

--- Comment #5 from glphvgacs  ---
Created attachment 92617
  --> https://bugs.freedesktop.org/attachment.cgi?id=92617=edit
kconfig

-- 
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/20140122/9133549e/attachment.html>

[Bug 73946] scanout broken on radeon SI (OLAND)

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

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

--- Comment #4 from glphvgacs  ---
Created attachment 92616
  --> https://bugs.freedesktop.org/attachment.cgi?id=92616=edit
radeon-ucode version

-- 
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/20140122/db7e1e03/attachment-0001.html>

[Bug 73946] scanout broken on radeon SI (OLAND)

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

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

--- Comment #3 from glphvgacs  ---
Created attachment 92615
  --> https://bugs.freedesktop.org/attachment.cgi?id=92615=edit
lspci -k (VGA and audio part)

-- 
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/20140122/a30c06a1/attachment.html>

[Bug 73946] scanout broken on radeon SI (OLAND)

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

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

--- Comment #2 from glphvgacs  ---
Created attachment 92614
  --> https://bugs.freedesktop.org/attachment.cgi?id=92614=edit
hwinfo --gfxcard --reallyall

-- 
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/20140122/39169025/attachment.html>

[Bug 73946] scanout broken on radeon SI (OLAND)

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

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

--- Comment #1 from glphvgacs  ---
Created attachment 92613
  --> https://bugs.freedesktop.org/attachment.cgi?id=92613=edit
drm msg in kernel

-- 
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/20140122/f8b43106/attachment.html>

[Bug 73946] New: scanout broken on radeon SI (OLAND)

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

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

  Priority: medium
Bug ID: 73946
  Assignee: dri-devel at lists.freedesktop.org
   Summary: scanout broken on radeon SI (OLAND)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: darwinskernel at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 92611
  --> https://bugs.freedesktop.org/attachment.cgi?id=92611=edit
dmesg from journalctl

running kmscube on kernel (for version and config see the attached) VT i get
scrambled graphics. hardware is ATI OLAND (see the attached for more detail)
you can get kmscube here:
https://github.com/robclark/kmscube.git

-- 
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/20140122/b4327475/attachment.html>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

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

Pali Roh?r  changed:

   What|Removed |Added

 CC||pali.rohar at gmail.com

--- Comment #55 from Pali Roh?r  ---
I have similar or same problem. I wrote info to this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71488#c10 If you need some more
info let me know and I will try to provide it. I would like to see working
radonsi driver with my card.

-- 
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/20140122/c4035473/attachment.html>

[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server

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

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

--- Comment #10 from Pali Roh?r  ---
I have same problem with card AMD Radeon HD 7730. When glamor is enabled I see
same screen corruption (as in attached screenshot) in Xserver (also in login
screen KDM). When glamor is disabled everything is OK, but very very slow.
Problem is still present in mesa, drm, xorg ati - all from git from end of
December. Problem is also in Fedora live CD which has enabled radeonsi and
glamor by default. Enabling/Disabling ColorTiling and ColorTiling2D did not
help I still saw same problem.

-- 
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/20140122/3ff45d13/attachment.html>

BUG: kernel-3.13: switch off backlight on Acer 3820TG

[Nicolai Lissner]

Hi,
After updating from linux 3.12.8 to 3.13 my display backlight 
switches off when starting X. As it seems, the kernel doesn't 
crash, it just switched off the backlight.

Hardware name: Acer Aspire 3820T/JM31_CP, BIOS V1.19 10/27/2010
This is a notebook with an intel/radeon hybrid graphics. I use 
intel for my X only. 

I've bisect'd the problem in the linux-stable tree and it says:

10ebc0bc09344ab6310309169efc73dfe6c23d72 is the first bad commit
commit 10ebc0bc09344ab6310309169efc73dfe6c23d72
Author: Dave Airlie 
Date:   Mon Sep 17 14:40:31 2012 +1000

drm/radeon: add runtime PM support (v2)

This hooks radeon up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and powerxpress laptops.

v2: agd5f: clean up, add module parameter

Signed-off-by: Dave Airlie 
Signed-off-by: Alex Deucher 


Please let me know if you need addititonal information.

[PATCH v3] backlight: turn backlight on/off when necessary

[Liu Ying]

We don't have to turn backlight on/off every time a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely being active to display something. This patch adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight should be turned on or off. To be more specific,
only one unblank operation on a certain blanked framebuffer
may increase the backlight device's use count by one, while
one blank operation on a certain unblanked framebuffer may
decrease the use count by one, because the userspace is
likely to unblank an unblanked framebuffer or blank a blanked
framebuffer.

Signed-off-by: Liu Ying 
---
v1 can be found at https://lkml.org/lkml/2013/5/30/139

v2->v3:
* Set fb_blank(*(int *)evdata->data) to bd->props.fb_blank
  when we turn off a blacklight.
* Correct some trivial typos in the commit message.

v1->v2:
* Make the commit message be more specific about the condition
  in which backlight device use count can be increased/decreased.
* Correct the setting for bd->props.fb_blank.

 drivers/video/backlight/backlight.c |   28 +---
 include/linux/backlight.h   |6 ++
 2 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 5d0..27d3cf2 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
   defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
 /* This callback gets called when something important happens inside a
  * framebuffer driver. We're looking if that important event is blanking,
- * and if it is, we're switching backlight power as well ...
+ * and if it is and necessary, we're switching backlight power as well ...
  */
 static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
 {
struct backlight_device *bd;
struct fb_event *evdata = data;
+   int node = evdata->info->node;
+   int fb_blank = 0;

/* If we aren't interested in this event, skip it immediately ... */
if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
@@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
if (bd->ops)
if (!bd->ops->check_fb ||
bd->ops->check_fb(bd, evdata->info)) {
-   bd->props.fb_blank = *(int *)evdata->data;
-   if (bd->props.fb_blank == FB_BLANK_UNBLANK)
-   bd->props.state &= ~BL_CORE_FBBLANK;
-   else
-   bd->props.state |= BL_CORE_FBBLANK;
-   backlight_update_status(bd);
+   fb_blank = *(int *)evdata->data;
+   if (fb_blank == FB_BLANK_UNBLANK &&
+   !bd->fb_bl_on[node]) {
+   bd->fb_bl_on[node] = true;
+   if (!bd->use_count++) {
+   bd->props.state &= ~BL_CORE_FBBLANK;
+   bd->props.fb_blank = FB_BLANK_UNBLANK;
+   backlight_update_status(bd);
+   }
+   } else if (fb_blank != FB_BLANK_UNBLANK &&
+  bd->fb_bl_on[node]) {
+   bd->fb_bl_on[node] = false;
+   if (!(--bd->use_count)) {
+   bd->props.state |= BL_CORE_FBBLANK;
+   bd->props.fb_blank = fb_blank;
+   backlight_update_status(bd);
+   }
+   }
}
mutex_unlock(>ops_lock);
return 0;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f9cd96..7264742 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -9,6 +9,7 @@
 #define _LINUX_BACKLIGHT_H

 #include 
+#include 
 #include 
 #include 

@@ -104,6 +105,11 @@ struct backlight_device {
struct list_head entry;

struct device dev;
+
+   /* Multiple framebuffers may share one backlight device */
+   bool fb_bl_on[FB_MAX];
+
+   int use_count;
 };

 static inline void backlight_update_status(struct backlight_device *bd)
-- 
1.7.9.5

[PATCH 3/6] drm/radeon: Use new drm debugfs file helper

[Ben Widawsky]

On Wed, Jan 22, 2014 at 11:11:10AM +0100, Christian K?nig wrote:
> Am 21.01.2014 21:33, schrieb Ben Widawsky:
> >The debugfs helper duplicates the functionality used by Armada, so let's
> >just use that.
> >
> >WARNING: only compile tested
> >
> >Cc: Christian K?nig 
> >Signed-off-by: Ben Widawsky 
> >---
> >  drivers/gpu/drm/radeon/radeon.h |  5 -
> >  drivers/gpu/drm/radeon/radeon_ttm.c | 43 
> > ++---
> >  2 files changed, 26 insertions(+), 22 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/radeon/radeon.h 
> >b/drivers/gpu/drm/radeon/radeon.h
> >index c5519ca..ceec468 100644
> >--- a/drivers/gpu/drm/radeon/radeon.h
> >+++ b/drivers/gpu/drm/radeon/radeon.h
> >@@ -418,11 +418,6 @@ struct radeon_mman {
> > struct ttm_bo_devicebdev;
> > boolmem_global_referenced;
> > boolinitialized;
> >-
> >-#if defined(CONFIG_DEBUG_FS)
> >-struct dentry   *vram;
> >-struct dentry   *gtt;
> >-#endif
> >  };
> >  /* bo virtual address in a specific vm */
> >diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> >b/drivers/gpu/drm/radeon/radeon_ttm.c
> >index 77f5b0c..cf7caf2 100644
> >--- a/drivers/gpu/drm/radeon/radeon_ttm.c
> >+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> >@@ -971,27 +971,34 @@ static const struct file_operations 
> >radeon_ttm_gtt_fops = {
> > .llseek = default_llseek
> >  };
> >+static const struct radeon_debugfs_files {
> >+const char *name;
> >+const struct file_operations *fops;
> >+} radeon_debugfs_files[] = {
> >+{"radeon_vram", _ttm_vram_fops},
> >+{"radeon_gtt", _ttm_gtt_fops},
> >+};
> >  #endif
> >  static int radeon_ttm_debugfs_init(struct radeon_device *rdev)
> >  {
> >  #if defined(CONFIG_DEBUG_FS)
> > unsigned count;
> >+int i, ret;
> > struct drm_minor *minor = rdev->ddev->primary;
> >-struct dentry *ent, *root = minor->debugfs_root;
> >-
> >-ent = debugfs_create_file("radeon_vram", S_IFREG | S_IRUGO, root,
> >-  rdev, _ttm_vram_fops);
> >-if (IS_ERR(ent))
> >-return PTR_ERR(ent);
> >-rdev->mman.vram = ent;
> >-
> >-ent = debugfs_create_file("radeon_gtt", S_IFREG | S_IRUGO, root,
> >-  rdev, _ttm_gtt_fops);
> >-if (IS_ERR(ent))
> >-return PTR_ERR(ent);
> >-rdev->mman.gtt = ent;
> >+struct dentry *root = minor->debugfs_root;
> >+
> >+for (i = 0; i < ARRAY_SIZE(radeon_debugfs_files); i++) {
> >+ret = drm_debugfs_create_file(root, minor,
> >+  radeon_debugfs_files[i].name,
> >+  radeon_debugfs_files[i].fops,
> >+  S_IFREG | S_IWUSR);
> >+if (ret) {
> >+radeon_ttm_debugfs_fini(rdev);
> >+return ret;
> >+}
> >+}
> > count = ARRAY_SIZE(radeon_ttm_debugfs_list);
> >@@ -1010,11 +1017,13 @@ static int radeon_ttm_debugfs_init(struct 
> >radeon_device *rdev)
> >  static void radeon_ttm_debugfs_fini(struct radeon_device *rdev)
> >  {
> >  #if defined(CONFIG_DEBUG_FS)
> >+int i;
> >-debugfs_remove(rdev->mman.vram);
> >-rdev->mman.vram = NULL;
> >+for (i = 0; i < ARRAY_SIZE(radeon_debugfs_files); i++) {
> >+struct drm_info_list *info_list =
> >+(struct drm_info_list *)_debugfs_files[i];
> >-debugfs_remove(rdev->mman.gtt);
> >-rdev->mman.gtt = NULL;
> >+drm_debugfs_remove_files(info_list, 1, rdev->ddev->primary);
> 
> This won't work correctly because info_ent doesn't contain this pointer but
> a pointer to the fops instead.

You are correct. It should have been _debugfs_files[i].fops.

> Additional to that the fops might not be unique (you can use the same
> fops for different files) so they are probably not such a good choice
> as the key.

This is correct, and I elaborate a bit on this in a later patch (or
earlier, I forget). Essentially we have exactly one usage (afaict) of a
caller that wants a fops != key. I didn't want to create the interface
around this possibility, but rather let other extend it when it becomes
more common.

However, if this is requested/required, what I would do is provide a
void *key argument, where a NULL value will result in using fops.


> 
> On the other hand why do the drm layer want to do this bookkeeping of
> all the created files in the first place? We could just use
> debugfs_remove_recursive instead and don't need to mess with this at
> all.
> 
> Regards, Christian.
> 

The answer to the question predates me. I think having the helpers for
the common case, where you only want a show() function is handy. The
decision to split off and continue to shoehorn newer, more featured
debugfs files (as you have done in Radeon with these two, and as we have
done in i915 all over) was not one I made, nor one I 

[PATCH v2] backlight: turn backlight on/off when necessary

[Liu Ying]

On 01/22/2014 05:35 PM, Jani Nikula wrote:
> On Mon, 20 Jan 2014, Liu Ying  wrote:
>> We don't have to turn backlight on/off everytime a blanking
>> or unblanking event comes because the backlight status may
>> have already been what we want. Another thought is that one
>> backlight device may be shared by multiple framebuffers. We
>> don't hope blanking one of the framebuffers may turn the
>> backlight off for all the other framebuffers, since they are
>> likely being active to display something. This patch adds
>> some logics to record each framebuffer's backlight usage to
>> determine the backlight device use count and whether the
>> backlight should be turned on or off. To be more specific,
>> only one unblank operation on a certain blanked framebuffer
>> may increase the backlight device's use count by one, while
>> one blank operation on a certain unblanked framebuffer may
>> decrease the use count by one, because the userspace is
>> likely to unblank a unblanked framebuffer or blank a blanked
>> framebuffer.
>>
>> Signed-off-by: Liu Ying 
>> ---
>> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>>
>> v1->v2:
>> * Make the commit message be more specific about the condition
>>   in which backlight device use count can be increased/decreased.
>> * Correct the setting for bd->props.fb_blank.
>>
>>  drivers/video/backlight/backlight.c |   28 +---
>>  include/linux/backlight.h   |6 ++
>>  2 files changed, 27 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/video/backlight/backlight.c 
>> b/drivers/video/backlight/backlight.c
>> index 5d0..42044be 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
>> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
>>  /* This callback gets called when something important happens inside a
>>   * framebuffer driver. We're looking if that important event is blanking,
>> - * and if it is, we're switching backlight power as well ...
>> + * and if it is and necessary, we're switching backlight power as well ...
>>   */
>>  static int fb_notifier_callback(struct notifier_block *self,
>>  unsigned long event, void *data)
>>  {
>>  struct backlight_device *bd;
>>  struct fb_event *evdata = data;
>> +int node = evdata->info->node;
>> +int fb_blank = 0;
>>  
>>  /* If we aren't interested in this event, skip it immediately ... */
>>  if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
>> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block 
>> *self,
>>  if (bd->ops)
>>  if (!bd->ops->check_fb ||
>>  bd->ops->check_fb(bd, evdata->info)) {
>> -bd->props.fb_blank = *(int *)evdata->data;
>> -if (bd->props.fb_blank == FB_BLANK_UNBLANK)
>> -bd->props.state &= ~BL_CORE_FBBLANK;
>> -else
>> -bd->props.state |= BL_CORE_FBBLANK;
>> -backlight_update_status(bd);
>> +fb_blank = *(int *)evdata->data;
>> +if (fb_blank == FB_BLANK_UNBLANK &&
>> +!bd->fb_bl_on[node]) {
>> +bd->fb_bl_on[node] = true;
>> +if (!bd->use_count++) {
>> +bd->props.state &= ~BL_CORE_FBBLANK;
>> +bd->props.fb_blank = FB_BLANK_UNBLANK;
>> +backlight_update_status(bd);
>> +}
>> +} else if (fb_blank != FB_BLANK_UNBLANK &&
>> +   bd->fb_bl_on[node]) {
>> +bd->fb_bl_on[node] = false;
>> +if (!(--bd->use_count)) {
>> +bd->props.state |= BL_CORE_FBBLANK;
>> +bd->props.fb_blank = FB_BLANK_POWERDOWN;

Looking at the patch again, I think we should set fb_blank to 
bd->props.fb_blank here to minimize the logic change.
I'll do more test for this and provide v3 if necessary.

>> +backlight_update_status(bd);
>> +}
>> +}
> 
> Anything backlight worries me a little, and there are actually three
> changes bundled into one patch here:
> 
> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
>changes from 0->1 or 1->0.
> 
> 2. Calling backlight_update_status() only with the above change, and not
>on all notifier callbacks.
> 
> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
>FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
> 
> The rationale in the commit message seems plausible, and AFAICT the code
> does what it says on the box, so for that 

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Takashi Iwai]

At Wed, 22 Jan 2014 10:45:26 -0500,
Rob Clark wrote:
> 
> On Wed, Jan 22, 2014 at 10:20 AM, Daniel Vetter  wrote:
> > On Wed, Jan 22, 2014 at 10:04:14AM -0500, Rob Clark wrote:
> >> sorry to jump into this a bit late, so maybe this was covered already 
> >> earlier..
> >
> > It just started, I've quoted everything when cc'ing dri-devel. But good to
> > have examples outside of x86 (where things are mostly standardized by the
> > Eye of Redmond).
> 
> perhaps the arm/SoC stuff was standardized by the Eye of Cthulhu
> 
> btw, added a few other SoC drm types who might be interested in the topic
> 
> >> For drm/msm the hdmi code needs something along these lines from audio:
> >>
> >> int hdmi_audio_info_setup(struct platform_device *pdev, bool enabled,
> >> uint32_t num_of_channels, uint32_t channel_allocation,
> >> uint32_t level_shift, bool down_mix);
> >> void hdmi_audio_set_sample_rate(struct platform_device *pdev, int rate);
> >>
> >> (former is mainly to setup avi audio infoframe, latter for clks)
> >>
> >> in addition to hotplug and ELD stuff
> >
> > Can you elaborate a bit on what you need for msm? On intel (and I think
> > the other x86 platforms are similar) we have separate buffers in the hw
> > for avi infoframes and audio infoframes, so the drm and alsa driver can
> > bash the right stuff into the hardware on their own. I'm mostly confused
> > since you say _AVI_ infoframe here, which is purely generated by the drm
> > side of the code here. Or at least that's been my understanding.
> 
> Sorry, typo, meant audio infoframe
> 
> We could have the API such that the audio driver constructs the
> infoframe.. that probably makes more sense and simplifies things.

The HD-audio has a code for doing that, so if needed, it can be copied
from there.  But, even AMD HD-audio codec doesn't use this scheme but
just sets up a few verbs for channel-allocations, etc, so the complete
audio infoframe isn't necessary in most cases, as it seems.

>  But
> the drm driver is the one that needs to bash that constructed buffer
> into the hw.  Or, well, either that or both drivers ioremap the same
> block of registers, but that seems somewhat lame.
> 
> But I do need to know some basic things, like # of channels.. and
> would kinda prefer not to have to parse the audio infoframe to get
> that info.

Yes, it makes things complex.  It's one of the reasons we'd like to
have a more straightforward interface.

> > The clocks are also funny really, but I'm not sure whether this fits. I'd
> > have expected some DT-based generic clock source which the audio driver
> > just grabs as part of his multi-device beast (maybe using Russell's new
> > driver core code) and used directly. What's the reason that this has to go
> > through the drm driverr?
> 
> possibly it could be exposed to the audio driver as a 'struct clk'
> that is implemented/registered/exported by the drm driver, I guess?

Hrm, but I guess this is also purely optional?
I'd like to start rather from a minimum set.

> fwiw, if curious, what I have on msm so far is at:
> 
> https://github.com/freedreno/kernel-msm/commit/6ffd278d39a3ff8712c70b5fd98dc135bd6c7b8a
> 
> It works on downstream qcom android kernel.. the API exported by drm
> driver, called by audio driver, is basically just a clone of the hack
> that was already there between fbdev and alsa.  I haven't tried to
> clean that up at all yet.  It was enough work just untangling ION (!!)
> from alsa in that kernel :-/

Thanks for the pointer!


Takashi


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

Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Takashi Iwai]

At Wed, 22 Jan 2014 15:18:21 +0100,
Daniel Vetter wrote:
> 
> On Wed, Jan 22, 2014 at 12:48:04PM +, Lin, Mengdong wrote:
> > > -Original Message-
> > > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On 
> > > Behalf Of
> > > Daniel Vetter
> > > Sent: Tuesday, January 21, 2014 9:11 PM
> > > To: Lin, Mengdong
> > > Cc: Takashi Iwai (tiwai at suse.de); Barnes, Jesse; Zanoni, Paulo R;
> > > alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org
> > > Subject: Re: Need your advice: Add a new communication inteface
> > > between HD-Audio and Gfx drivers for hotplug notification/ELD update
> > > 
> > > On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong 
> > > wrote:
> > > > Dear audio and gfx stakeholders,
> > > >
> > > >
> > > >
> > > > We hope to add a new interface between audio and gfx driver, for gfx
> > > > driver to notify audio about HDMI/DP hot-plug and ELD update.
> > > >
> > > > Would you please share some comments on the proposal below?
> > > >
> > > >
> > > >
> > > > Background of this issue: On Intel Haswell/Broadwell platforms, there
> > > > is a HW restriction that after the display HD-Audio controller is in
> > > > D3,
> > > >
> > > > it cannot be waken up by HDMI/DP hot-plug. Consequently, although the
> > > > gfx driver can still detect the HDMI/DP hot-plug,
> > > >
> > > > audio driver has no idea about this and cannot notify user space
> > > > whether the external HDMI/DP monitor is available for audio playback,
> > > >
> > > > because the audio controller cannot wake up to D0 and receive HW
> > > > unsolicited event about hot-plug from the audio codec.
> > > >
> > > > This limitation will affect user space to decide whether we can output
> > > > audio over HDMI/DP.
> > > >
> > > >
> > > >
> > > > To solve the above limitation, Takashi suggested to add a new
> > > > communication interface between audio and gfx driver: create a
> > > common
> > > > object
> > > >
> > > > containing the ops registered by both graphics and audio drivers, then
> > > > communicate through it, something like vga_switcheroo.
> > > >
> > > >
> > > >
> > > > Is it okay to create this kernel object in i915 driver?
> > > >
> > > >
> > > >
> > > > I915 can export an API like "display_register_audio_client" for audio
> > > > driver to register a client and hot-plug notification ops.
> > > >
> > > >
> > > >
> > > > I915 can also call some API like "display_register_gfx_client" itself
> > > > and register ops for audio driver to query monitor presence and ELD
> > > > info on a specific port.
> > > >
> > > > It would be faster for audio driver than quering ELD by
> > > > command/response over the HD-A bus, thus avoid delay in i915 mode
> > > set.
> > > >
> > > > This will also avoid waking up the audio devices unnecessarily if the
> > > > user space does not really want to use HDMI/DP for audio playback.
> > > >
> > > >
> > > >
> > > > Whenever i195 enables/disables audio on a port in modeset, it can call
> > > > some API like "display_set_audio_state()" on this kernel object and
> > > > trigger notifications to the audio driver.
> > > >
> > > >
> > > >
> > > > When the audio driver is probed (in the delayed probe stage), it can
> > > > request
> > > > i915 API symbol to register the audio client for this communication
> > > > kernel object.
> > > >
> > > > Since the 1st i915 mode set may happen before audio driver registers
> > > > the ops, we'll let audio driver check ELD once after registering the
> > > > audio client ops.
> > > >
> > > > And for the platforms which uses this communication interface, we can
> > > > disable unsolicited event for HDMI/DP hot-plug in the audio driver.
> > > >
> > > >
> > > >
> > > > We hope to hear your feedback and start to work out more details.
> > 
> > Thanks for your advice, Daniel!
> > 
> > > Yeah, I've discussed this at KS with Takashi and we've agreed that some
> > > common object to facilitate driver interactions. A few things
> > > though:
> > > - This should be common infrastructure useable by all alsa and drm
> > > drivers, not just i915 and snd-hda. Especially on embedded platforms this
> > > issue is fairly rampant ...
> > 
> > Agree. Where to put this common object? 
> > Is it okay to put it under /driver/gpu/drm, similar to vga_switchroo?
> > Shall we divide clients into audio and gfx categories, and define
> > different ops for them? Since different info/request flow in different
> > direction between audio and gfx.
> 
> I guess we could place them into drivers/gpu, yeah. For a name I'd suggest
> avsink or something like that, to make it clear that it's the combination
> of audio+video. For the actual interfaces I guess we just need one object
> in the device model, but the interface should be split into things called
> from the audio side only, functions for the video driver side only and
> stuff which can be called from both sides. This matters mostly just so we
> don't end up with deadlocks since we need a lock to protect the 

[PATCHv6 4/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.

[Dan Carpenter]

On Wed, Jan 22, 2014 at 02:48:28PM +0100, Denis Carikli wrote:
> If de-active and/or pixelclk-active properties were set in the
> display-timings DT node, they were not used.
> 
> Instead the data-enable and the pixel data clock polarity
> were hardcoded.
> 
> This change is needed for making the eukrea-cpuimx51
>   QVGA display work.
> 
> Cc: David Airlie 
> Cc: Eric B?nard 
> Cc: Greg Kroah-Hartman 
> Cc: Philipp Zabel 
> Cc: Sascha Hauer 
> Cc: Shawn Guo 
> Cc: dri-devel at lists.freedesktop.org
> Cc: driverdev-devel at linuxdriverproject.org
> Cc: linux-arm-kernel at lists.infradead.org

These CC blocks are massive...  What's the point of them?

>   if (np) {
>   struct drm_display_mode *mode = drm_mode_create(connector->dev);
> + struct device_node *timings_np;
> + struct device_node *mode_np;
> + u32 val;
> +
>   of_get_drm_display_mode(np, >mode, 0);
> +
> + timings_np = of_get_child_by_name(np, "display-timings");
> + if (timings_np) {
> + /* get the display mode node */
> + mode_np = of_parse_phandle(timings_np,
> +"native-mode", 0);
> + if (!mode_np)
> + mode_np = of_get_next_child(timings_np, NULL);
> +
> + /* set de-active to 1 if not set */
> + of_property_read_u32(mode_np, "de-active", );
> + if (val) {

If of_property_read_u32() fails then val is uninitialized.

regards,
dan carpenter

linux-next: manual merge of the drm-intel tree with the drm tree

[Olof Johansson]

On Wed, Jan 22, 2014 at 2:06 AM, Daniel Vetter  
wrote:
> Hi Stephen,
>
> On Wed, Jan 22, 2014 at 4:04 AM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> Today's linux-next merge of the drm-intel tree got a conflict in
>> drivers/gpu/drm/i915/i915_irq.c between commit abca9e454498 ("drm: Pass
>> 'flags' from the caller to .get_scanout_position()") from the drm tree
>> and commit d59a63ad8234 ("drm/i915: Add intel_get_crtc_scanline()") from
>> the drm-intel tree.
>>
>> I fixed it up (I think - see below) and can carry the fix as necessary
>> (no action is required).
>
> Oops, this patch escaped - it's only for 3.15. I've shuffled my
> branches around now for the merge window so this should not pop up in
> your -next tree again until 3.15 starts.

I just bisected boot failures on x86 chromebooks with -next to this
merge commit. I'll take a look tomorrow morning and make sure they're
gone.


-Olof

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Thomas Hellstrom]

On 01/22/2014 04:09 PM, Daniel Vetter wrote:
> On Wed, Jan 22, 2014 at 01:52:51PM +0100, Thomas Hellstrom wrote:
>> On 01/22/2014 01:38 PM, Maarten Lankhorst wrote:
>>> op 22-01-14 13:11, Thomas Hellstrom schreef:
 On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
> op 22-01-14 11:27, Thomas Hellstrom schreef:
>> On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
>>> op 22-01-14 10:40, Thomas Hellstrom schreef:
 On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
> op 21-01-14 18:44, Thomas Hellstrom schreef:
>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> op 21-01-14 16:17, Thomas Hellstrom schreef:
 Maarten, for this and the other patches in this series,

 I seem to recall we have this discussion before?
 IIRC I stated that reservation was a too heavy-weight lock to
 hold to
 determine whether a buffer was idle? It's a pretty nasty
 thing to
 build in.

>>> I've sent this patch after determining that this already didn't
>>> end up
>>> being heavyweight.
>>> Most places were already using the fence_lock and reservation, I
>>> just
>>> fixed up the few
>>> places that didn't hold a reservation while waiting.
>>> Converting the
>>> few places that didn't
>>> ended up being trivial, so I thought I'd submit it.
>> Actually the only *valid* reason for holding a reservation when
>> waiting
>> for idle is
>> 1) You want to block further command submission on the buffer.
>> 2) You want to switch GPU engine and don't have access to gpu
>> semaphores
>> / barriers.
>>
>> Reservation has the nasty side effect that it blocks command
>> submission
>> and pins the buffer (in addition now makes the evict list
>> traversals
>> skip the buffer) which in general is *not* necessary for most wait
>> cases, so we should instead actually convert the wait cases that
>> don't
>> fulfill 1) and 2) above in the other direction if we have
>> performance
>> and latency-reduction in mind. I can't see how a spinlock
>> protecting a
>> fence pointer or fence list is stopping you from using RW
>> fences as
>> long
>> as the spinlock is held while manipulating the fence list?
>>
> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
> patchset, though) and enumerate if they can be changed to work
> without
> reservation or not.
>
> ttm/ttm_bo.c
> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
> finish for the direct destroy fastpath, if either fails it needs
> to be
> queued. Cannot work without reservation.
 Doesn't block and no significant reservation contention expected.

> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
> doesn't need to re-acquire. Simply reordering ttm_bo_wait until
> after
> re-reserve is enough.
 Currently follows the above rules.

> ttm_bo_evict: already has the reservation, cannot be dropped since
> only trylock is allowed. Dropping reservation would cause badness,
> cannot be converted.
 Follows rule 2 above. We're about to move the buffer and if that
 can't
 be pipelined using the GPU (which TTM currently doesn't allow), we
 need
 to wait. Although eviction should be low priority compared to new
 command submission, so I can't really see why we couldn't wait
 before
 trying to reserve here?

> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
> reservation for same reason as ttm_bo_evict. It might be part of a
> ticketed reservation so really don't drop lock here.
 Part of command submission and as such follows rule 2 above. If
 we can
 pipeline the move with the GPU, no need to wait (but needs to be
 implemented, of course).

> ttm_bo_synccpu_write_grab: the wait could be converted to be done
> afterwards, without  fence_lock. But in this case reservation could
> take the role of fence_lock too,
>
> so no separate fence_lock would be needed.
 With the exception that reservation is more likely to be contended.
>>> True but rule 1.
> ttm_bo_swapout: see ttm_bo_evict.
>
> ttm/ttm_bo_util.c:
> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
> ttm_bo_move_buffer, can be called from that function.
 Rule 2.

> ttm/ttm_bo_vm.c
> ttm_bo_vm_fault_idle: I guess you 

[Bug 73788] [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed

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

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

--- Comment #11 from Alex Deucher  ---
(In reply to comment #8)
> 
> There are no errors and no success in changing power_method. Where did I do
> mistake?

We don't support changing between dpm and the older methods dynamically.  When
you enable dpm, you can't switch to the older pm methods.

-- 
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/20140122/b4f6d4a0/attachment.html>

[Bug 73788] [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed

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

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

--- Comment #10 from Alex Deucher  ---
(In reply to comment #7)
> (In reply to comment #4)
> > Is this a regression?  Was dpm working previously at some point, if so when?
> 
> It worked fine in 3.11 and 3.12. The problem appeared somewhere during the
> development of 3.13. At those point vgaswitcheroo didn't work and I had to
> stick to older versions of the kernel.

Any chance you could bisect?

-- 
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/20140122/233a15ad/attachment-0001.html>

[Bug 73788] [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed

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

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

--- Comment #9 from Stepan Bakshaev <step2back+freedesktop at gmail.com> ---
Return to 3.13

root at silverstone:/sys/class/drm/card0/device# uname -a
Linux silverstone 3.13.0-5-generic #20-Ubuntu SMP Mon Jan 20 19:56:38 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
root at silverstone:/sys/class/drm/card0/device# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.13.0-5-generic
root=UUID=4d025cce-1bf0-466f-a5c3-501d3f548e70 ro quiet splash vt.handoff=7
radeon.dpm=1

root at silverstone:/sys/class/drm/card0/device# echo "dynpm" > power_method 
bash: echo: write error: Invalid argument
root at silverstone:/sys/class/drm/card0/device# cat power_method 
dpm

root at silverstone:/sys/class/drm/card0/device# echo "high" > power_profile 
bash: echo: write error: Invalid argument

root at silverstone:/sys/class/drm/card0/device# dmesg | grep -i "drm.*error"
[   13.800555] [drm:si_dpm_set_power_state] *ERROR* si_set_sw_state failed

root at silverstone:/sys/class/drm/card0/device# cat vendor 
0x1002
root at silverstone:/sys/class/drm/card0/device# cat device 
0x683d

-- 
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/20140122/344b2344/attachment.html>

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Thomas Hellstrom]

On 01/22/2014 04:09 PM, Daniel Vetter wrote:
> On Wed, Jan 22, 2014 at 01:52:51PM +0100, Thomas Hellstrom wrote:
>> On 01/22/2014 01:38 PM, Maarten Lankhorst wrote:
>>> op 22-01-14 13:11, Thomas Hellstrom schreef:
 On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
> op 22-01-14 11:27, Thomas Hellstrom schreef:
>> On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
>>> op 22-01-14 10:40, Thomas Hellstrom schreef:
 On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
> op 21-01-14 18:44, Thomas Hellstrom schreef:
>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> op 21-01-14 16:17, Thomas Hellstrom schreef:
 Maarten, for this and the other patches in this series,

 I seem to recall we have this discussion before?
 IIRC I stated that reservation was a too heavy-weight lock to
 hold to
 determine whether a buffer was idle? It's a pretty nasty
 thing to
 build in.

>>> I've sent this patch after determining that this already didn't
>>> end up
>>> being heavyweight.
>>> Most places were already using the fence_lock and reservation, I
>>> just
>>> fixed up the few
>>> places that didn't hold a reservation while waiting.
>>> Converting the
>>> few places that didn't
>>> ended up being trivial, so I thought I'd submit it.
>> Actually the only *valid* reason for holding a reservation when
>> waiting
>> for idle is
>> 1) You want to block further command submission on the buffer.
>> 2) You want to switch GPU engine and don't have access to gpu
>> semaphores
>> / barriers.
>>
>> Reservation has the nasty side effect that it blocks command
>> submission
>> and pins the buffer (in addition now makes the evict list
>> traversals
>> skip the buffer) which in general is *not* necessary for most wait
>> cases, so we should instead actually convert the wait cases that
>> don't
>> fulfill 1) and 2) above in the other direction if we have
>> performance
>> and latency-reduction in mind. I can't see how a spinlock
>> protecting a
>> fence pointer or fence list is stopping you from using RW
>> fences as
>> long
>> as the spinlock is held while manipulating the fence list?
>>
> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
> patchset, though) and enumerate if they can be changed to work
> without
> reservation or not.
>
> ttm/ttm_bo.c
> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
> finish for the direct destroy fastpath, if either fails it needs
> to be
> queued. Cannot work without reservation.
 Doesn't block and no significant reservation contention expected.

> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
> doesn't need to re-acquire. Simply reordering ttm_bo_wait until
> after
> re-reserve is enough.
 Currently follows the above rules.

> ttm_bo_evict: already has the reservation, cannot be dropped since
> only trylock is allowed. Dropping reservation would cause badness,
> cannot be converted.
 Follows rule 2 above. We're about to move the buffer and if that
 can't
 be pipelined using the GPU (which TTM currently doesn't allow), we
 need
 to wait. Although eviction should be low priority compared to new
 command submission, so I can't really see why we couldn't wait
 before
 trying to reserve here?

> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
> reservation for same reason as ttm_bo_evict. It might be part of a
> ticketed reservation so really don't drop lock here.
 Part of command submission and as such follows rule 2 above. If
 we can
 pipeline the move with the GPU, no need to wait (but needs to be
 implemented, of course).

> ttm_bo_synccpu_write_grab: the wait could be converted to be done
> afterwards, without  fence_lock. But in this case reservation could
> take the role of fence_lock too,
>
> so no separate fence_lock would be needed.
 With the exception that reservation is more likely to be contended.
>>> True but rule 1.
> ttm_bo_swapout: see ttm_bo_evict.
>
> ttm/ttm_bo_util.c:
> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
> ttm_bo_move_buffer, can be called from that function.
 Rule 2.

> ttm/ttm_bo_vm.c
> ttm_bo_vm_fault_idle: I guess you 

[Bug 73788] [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed

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

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

--- Comment #8 from Stepan Bakshaev <step2back+freedesktop at gmail.com> ---
I installed kernel from here
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-trusty/

and try to change power_method by
http://xorg.freedesktop.org/wiki/RadeonFeature/#kmspowermanagementoptions

root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# uname -a
Linux silverstone 3.12.0-031200-generic #201311071835 SMP Thu Nov 7 23:36:07
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# cat
/proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.12.0-031200-generic
root=UUID=4d025cce-1bf0-466f-a5c3-501d3f548e70 ro quiet splash vt.handoff=7
radeon.dpm=1

root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# echo
"dynpm" > power_method 
bash: echo: write error: Invalid argument
root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# echo
"profile" > power_method 
bash: echo: write error: Invalid argument
root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# cat
power_method 
dpm

root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# echo 
"high"
> power_profile 
bash: echo: write error: Invalid argument
root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# cat
power_profile 
default

root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# dmesg |
grep 'drm.*error'

root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# cat 
class 
0x03
root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# cat 
vendor 
0x1002
root at silverstone:/sys/devices/pci:00/:00:01.0/:01:00.0# cat 
device 
0x683d

There are no errors and no success in changing power_method. Where did I do
mistake?

-- 
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/20140122/75934f0a/attachment.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #48 from Alex Deucher  ---
You might try adjusting the delays in radeon_dp_link_train() and the functions
it calls.  Some panels are really picky about the timing during the training
sequence.

-- 
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/20140122/5f48ae51/attachment.html>

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Daniel Vetter]

On Wed, Jan 22, 2014 at 10:04:14AM -0500, Rob Clark wrote:
> sorry to jump into this a bit late, so maybe this was covered already 
> earlier..

It just started, I've quoted everything when cc'ing dri-devel. But good to
have examples outside of x86 (where things are mostly standardized by the
Eye of Redmond).

> For drm/msm the hdmi code needs something along these lines from audio:
> 
> int hdmi_audio_info_setup(struct platform_device *pdev, bool enabled,
> uint32_t num_of_channels, uint32_t channel_allocation,
> uint32_t level_shift, bool down_mix);
> void hdmi_audio_set_sample_rate(struct platform_device *pdev, int rate);
> 
> (former is mainly to setup avi audio infoframe, latter for clks)
> 
> in addition to hotplug and ELD stuff

Can you elaborate a bit on what you need for msm? On intel (and I think
the other x86 platforms are similar) we have separate buffers in the hw
for avi infoframes and audio infoframes, so the drm and alsa driver can
bash the right stuff into the hardware on their own. I'm mostly confused
since you say _AVI_ infoframe here, which is purely generated by the drm
side of the code here. Or at least that's been my understanding.

The clocks are also funny really, but I'm not sure whether this fits. I'd
have expected some DT-based generic clock source which the audio driver
just grabs as part of his multi-device beast (maybe using Russell's new
driver core code) and used directly. What's the reason that this has to go
through the drm driverr?

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

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #47 from Paul Menzel  ---
Looking at the panel/monitor CMN 1343, I found a list with more information
[1].

Chi Mei Innolux N133HSE-EA1
Asus U38N(-C4010H)
Asus Zenbook UX31A, UX32VD
Clevo W230ST
1920x1080, IPS, matte
30 pin eDP
shop: diytrade.com
review: Notebook
review: The Verge
shortname: CMN 1343

It seems that it is used in other systems and works with GNU/Linux there.
Though I only found Intel systems [1][2] and I have no idea if the panel is
really connected using eDP, though the note above says so.

So it might be a problem specific to the Radeon driver.

[1] https://hackpad.com/Best-Panels-Wiki-D5UvkrtVvJ9
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687203
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724510

-- 
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/20140122/0c576001/attachment.html>

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Daniel Vetter]

On Wed, Jan 22, 2014 at 01:52:51PM +0100, Thomas Hellstrom wrote:
> On 01/22/2014 01:38 PM, Maarten Lankhorst wrote:
> > op 22-01-14 13:11, Thomas Hellstrom schreef:
> >> On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
> >>> op 22-01-14 11:27, Thomas Hellstrom schreef:
>  On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
> > op 22-01-14 10:40, Thomas Hellstrom schreef:
> >> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
> >>> op 21-01-14 18:44, Thomas Hellstrom schreef:
>  On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
> > Hey,
> >
> > op 21-01-14 16:17, Thomas Hellstrom schreef:
> >> Maarten, for this and the other patches in this series,
> >>
> >> I seem to recall we have this discussion before?
> >> IIRC I stated that reservation was a too heavy-weight lock to
> >> hold to
> >> determine whether a buffer was idle? It's a pretty nasty
> >> thing to
> >> build in.
> >>
> > I've sent this patch after determining that this already didn't
> > end up
> > being heavyweight.
> > Most places were already using the fence_lock and reservation, I
> > just
> > fixed up the few
> > places that didn't hold a reservation while waiting.
> > Converting the
> > few places that didn't
> > ended up being trivial, so I thought I'd submit it.
>  Actually the only *valid* reason for holding a reservation when
>  waiting
>  for idle is
>  1) You want to block further command submission on the buffer.
>  2) You want to switch GPU engine and don't have access to gpu
>  semaphores
>  / barriers.
> 
>  Reservation has the nasty side effect that it blocks command
>  submission
>  and pins the buffer (in addition now makes the evict list
>  traversals
>  skip the buffer) which in general is *not* necessary for most wait
>  cases, so we should instead actually convert the wait cases that
>  don't
>  fulfill 1) and 2) above in the other direction if we have
>  performance
>  and latency-reduction in mind. I can't see how a spinlock
>  protecting a
>  fence pointer or fence list is stopping you from using RW
>  fences as
>  long
>  as the spinlock is held while manipulating the fence list?
> 
> >>> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
> >>> patchset, though) and enumerate if they can be changed to work
> >>> without
> >>> reservation or not.
> >>>
> >>> ttm/ttm_bo.c
> >>> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
> >>> finish for the direct destroy fastpath, if either fails it needs
> >>> to be
> >>> queued. Cannot work without reservation.
> >> Doesn't block and no significant reservation contention expected.
> >>
> >>> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
> >>> doesn't need to re-acquire. Simply reordering ttm_bo_wait until
> >>> after
> >>> re-reserve is enough.
> >> Currently follows the above rules.
> >>
> >>> ttm_bo_evict: already has the reservation, cannot be dropped since
> >>> only trylock is allowed. Dropping reservation would cause badness,
> >>> cannot be converted.
> >> Follows rule 2 above. We're about to move the buffer and if that
> >> can't
> >> be pipelined using the GPU (which TTM currently doesn't allow), we
> >> need
> >> to wait. Although eviction should be low priority compared to new
> >> command submission, so I can't really see why we couldn't wait
> >> before
> >> trying to reserve here?
> >>
> >>> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
> >>> reservation for same reason as ttm_bo_evict. It might be part of a
> >>> ticketed reservation so really don't drop lock here.
> >> Part of command submission and as such follows rule 2 above. If
> >> we can
> >> pipeline the move with the GPU, no need to wait (but needs to be
> >> implemented, of course).
> >>
> >>> ttm_bo_synccpu_write_grab: the wait could be converted to be done
> >>> afterwards, without  fence_lock. But in this case reservation could
> >>> take the role of fence_lock too,
> >>>
> >>> so no separate fence_lock would be needed.
> >> With the exception that reservation is more likely to be contended.
> > True but rule 1.
> >>> ttm_bo_swapout: see ttm_bo_evict.
> >>>
> >>> ttm/ttm_bo_util.c:
> >>> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
> >>> ttm_bo_move_buffer, can be called from that function.
> >> Rule 2.
> >>
> >>> ttm/ttm_bo_vm.c
> >>> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here,
> >>> but
> 

[RFC PATCH 1/9] drm/exynos: correct timing porch conversion

[Andrzej Hajda]

Hi,

It seems I have not added description to this patch.
In this patch porch is calculated in compatible way to
drm_display_mode_from_videomode core function.
The way it was seems to me incorrect and it did not work on my hw.

Anyway this patch could be merged with Sean's patches, if he agrees.

Regards
Andrzej

On 01/22/2014 03:35 PM, Andrzej Hajda wrote:
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8caaac2..b611f33 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -538,21 +538,18 @@ static void fimd_mode_set(struct exynos_drm_manager 
> *mgr,
>  {
>   struct fimd_context *ctx = mgr->ctx;
>   struct fimd_mode_data *mode = >mode;
> - int hblank, vblank;
>  
> - vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
>   mode->vtotal = in_mode->crtc_vtotal;
>   mode->vdisplay = in_mode->crtc_vdisplay;
>   mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
> - mode->vbpd = (vblank - mode->vsync_len) / 2;
> - mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
> + mode->vbpd = in_mode->crtc_vtotal - in_mode->crtc_vsync_end;
> + mode->vfpd = in_mode->crtc_vsync_start - in_mode->crtc_vdisplay;
>  
> - hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
>   mode->htotal = in_mode->crtc_htotal;
>   mode->hdisplay = in_mode->crtc_hdisplay;
>   mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
> - mode->hbpd = (hblank - mode->hsync_len) / 2;
> - mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
> + mode->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
> + mode->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;
>  
>   mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
>  
> 

[RFC PATCH 9/9] ARM: dts: exynos4412-trats2: add panel node

[Andrzej Hajda]

The patch adds s6e8aa0 panel node for trats2.
It adds also trats2 specific properties for DSI
and regulator required by panel.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 45 +
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 2867c4e..3243b76 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -442,6 +442,15 @@
};
};

+   lcd_vdd3_reg: voltage-regulator at 1 {
+   compatible = "regulator-fixed";
+   regulator-name = "LCD_VDD_2.2V";
+   regulator-min-microvolt = <220>;
+   regulator-max-microvolt = <220>;
+   gpio = < 1 0>;
+   enable-active-high;
+   };
+
sdhci at 1251 {
bus-width = <8>;
non-removable;
@@ -498,6 +507,42 @@
};
};

+   dsi_0: dsi at 11C8 {
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,pll-clk-freq = <2400>;
+   status = "okay";
+
+   panel at 0 {
+   compatible = "samsung,s6e8aa0";
+   reg = <0>;
+   vdd3-supply = <_vdd3_reg>;
+   vci-supply = <_reg>;
+   reset-gpio = < 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   flip-horizontal;
+   flip-vertical;
+   samsung,panel-width-mm = <58>;
+   samsung,panel-height-mm = <103>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
+   };
+
fimd at 11c0 {
samsung,fimd-vidout-rgb;
samsung,fimd-inv-vclk;
-- 
1.8.3.2

[RFC PATCH 8/9] ARM: dts: exynos4210-trats: add panel node

[Andrzej Hajda]

The patch adds s6e8aa0 panel node for trats.
It adds also trats specific properties for DSI.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 36 ++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index e4c4913..105f212 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -379,6 +379,42 @@
};
};

+   dsi_0: dsi at 11C8 {
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,pll-clk-freq = <2400>;
+   status = "okay";
+
+   panel at 0 {
+   reg = <0>;
+   compatible = "samsung,s6e8aa0";
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpio = < 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   flip-horizontal;
+   flip-vertical;
+   samsung,panel-width-mm = <58>;
+   samsung,panel-height-mm = <103>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
+   };
+
fimd at 11c0 {
samsung,fimd-vidout-rgb;
samsung,fimd-inv-vclk;
-- 
1.8.3.2

[RFC PATCH 7/9] ARM: dts: exynos4: add MIPI DSI Master node

[Andrzej Hajda]

This is a common part of DSI node for all Exynos4 boards.

Signed-off-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos4.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index a73eeb5..7102f29 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -104,6 +104,20 @@
reg = <0x1001 0x400>;
};

+   dsi_0: dsi at 11C8 {
+   compatible = "samsung,exynos4210-mipi-dsi";
+   reg = <0x11C8 0x1>;
+   interrupts = <0 79 0>;
+   samsung,power-domain = <_lcd0>;
+   phys = <_phy 1>;
+   phy-names = "dsim";
+   clocks = < 286>, < 143>;
+   clock-names = "bus_clk", "pll_clk";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
camera {
compatible = "samsung,fimc", "simple-bus";
status = "disabled";
-- 
1.8.3.2

[RFC PATCH 6/9] drm/panel: add s6e8aa0 driver

[Andrzej Hajda]

The patch adds MIPI-DSI based s6e8aa0 AMOLED LCD 5.3 inch panel driver.
Driver uses mipi_dsi bus to communicate with panel and exposes drm_panel
interface.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig |7 +
 drivers/gpu/drm/panel/Makefile|1 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c | 1046 +
 3 files changed, 1054 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4f40d19..63b33ef 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -17,4 +17,11 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.

+config DRM_PANEL_S6E8AA0
+   tristate "S6E8AA0 DSI video mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af9dfa2..181265b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c 
b/drivers/gpu/drm/panel/panel-s6e8aa0.c
new file mode 100644
index 000..e9b9ec1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
@@ -0,0 +1,1046 @@
+/*
+ * MIPI-DSI based s6e8aa0 AMOLED LCD 5.3 inch panel driver.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, 
+ * Donghwa Lee, 
+ * Joongmock Shin 
+ * Eunchul Kim 
+ * Tomasz Figa 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define LDI_MTP_LENGTH 24
+#define GAMMA_LEVEL_NUM25
+#define GAMMA_TABLE_LEN26
+
+#define PANELCTL_SS_MASK   (1 << 5)
+#define PANELCTL_SS_1_800  (0 << 5)
+#define PANELCTL_SS_800_1  (1 << 5)
+#define PANELCTL_GTCON_MASK(7 << 2)
+#define PANELCTL_GTCON_110 (6 << 2)
+#define PANELCTL_GTCON_111 (7 << 2)
+
+#define PANELCTL_CLK1_CON_MASK (7 << 3)
+#define PANELCTL_CLK1_000  (0 << 3)
+#define PANELCTL_CLK1_001  (1 << 3)
+#define PANELCTL_CLK2_CON_MASK (7 << 0)
+#define PANELCTL_CLK2_000  (0 << 0)
+#define PANELCTL_CLK2_001  (1 << 0)
+
+#define PANELCTL_INT1_CON_MASK (7 << 3)
+#define PANELCTL_INT1_000  (0 << 3)
+#define PANELCTL_INT1_001  (1 << 3)
+#define PANELCTL_INT2_CON_MASK (7 << 0)
+#define PANELCTL_INT2_000  (0 << 0)
+#define PANELCTL_INT2_001  (1 << 0)
+
+#define PANELCTL_BICTL_CON_MASK(7 << 3)
+#define PANELCTL_BICTL_000 (0 << 3)
+#define PANELCTL_BICTL_001 (1 << 3)
+#define PANELCTL_BICTLB_CON_MASK   (7 << 0)
+#define PANELCTL_BICTLB_000(0 << 0)
+#define PANELCTL_BICTLB_001(1 << 0)
+
+#define PANELCTL_EM_CLK1_CON_MASK  (7 << 3)
+#define PANELCTL_EM_CLK1_110   (6 << 3)
+#define PANELCTL_EM_CLK1_111   (7 << 3)
+#define PANELCTL_EM_CLK1B_CON_MASK (7 << 0)
+#define PANELCTL_EM_CLK1B_110  (6 << 0)
+#define PANELCTL_EM_CLK1B_111  (7 << 0)
+
+#define PANELCTL_EM_CLK2_CON_MASK  (7 << 3)
+#define PANELCTL_EM_CLK2_110   (6 << 3)
+#define PANELCTL_EM_CLK2_111   (7 << 3)
+#define PANELCTL_EM_CLK2B_CON_MASK (7 << 0)
+#define PANELCTL_EM_CLK2B_110  (6 << 0)
+#define PANELCTL_EM_CLK2B_111  (7 << 0)
+
+#define PANELCTL_EM_INT1_CON_MASK  (7 << 3)
+#define PANELCTL_EM_INT1_000   (0 << 3)
+#define PANELCTL_EM_INT1_001   (1 << 3)
+#define PANELCTL_EM_INT2_CON_MASK  (7 << 0)
+#define PANELCTL_EM_INT2_000   (0 << 0)
+#define PANELCTL_EM_INT2_001   (1 << 0)
+
+#define AID_DISABLE(0x4)
+#define AID_1  (0x5)
+#define AID_2  (0x6)
+#define AID_3  (0x7)
+
+#define s6e8aa0_dcs_write(lcd, seq...) \
+({\
+   const u8 d[] = { seq };\
+   struct mipi_dsi_device *dsi = to_mipi_dsi_device(lcd->dev); \
+   BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "DCS sequence too big for stack");\
+   mipi_dsi_dcs_write(dsi, dsi->channel, d, ARRAY_SIZE(d));\
+})
+
+#define s6e8aa0_dcs_write_static(lcd, seq...) \
+({\
+   static const u8 d[] = { seq };\
+   struct mipi_dsi_device *dsi = to_mipi_dsi_device(lcd->dev); \
+   mipi_dsi_dcs_write(dsi, dsi->channel, d, ARRAY_SIZE(d));\
+})
+
+typedef u8 

[RFC PATCH 5/9] panel/s6e8aa0: add DT bindings

[Andrzej Hajda]

The patch adds bindings for s6e8aa0 panel.
Bindings describes panel resources, boot delays,
display timings, orientation and physical size.

Signed-off-by: Andrzej Hajda 
---
 .../devicetree/bindings/panel/samsung-s6e8aa0.txt  | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt 
b/Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt
new file mode 100644
index 000..675e66e
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt
@@ -0,0 +1,53 @@
+Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e8aa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpio: a GPIO spec for the reset pin
+  - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+  - power-on-delay: delay after turning regulators on [ms]
+  - reset-delay: delay after reset sequence [ms]
+  - init-delay: delay after initialization sequence [ms]
+  - samsung,panel-width-mm: physical panel width [mm]
+  - samsung,panel-height-mm: physical panel height [mm]
+  - flip-horizontal: boolean to flip image horizontally
+  - flip-vertical: boolean to flip image vertically
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+   panel {
+   compatible = "samsung,s6e8aa0";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpio = < 5 0>;
+   power-on-delay= <50>;
+   reset-delay = <100>;
+   init-delay = <100>;
+   samsung,panel-width-mm = <58>;
+   samsung,panel-height-mm = <103>;
+   flip-horizontal;
+   flip-vertical;
+
+   display-timings {
+   native-mode = <>;
+
+   timing0: timing-0 {
+   clock-frequency = <57153600>;
+   hactive = <720>;
+   vactive = <1280>;
+   hfront-porch = <5>;
+   hback-porch = <5>;
+   hsync-len = <5>;
+   vfront-porch = <13>;
+   vback-porch = <1>;
+   vsync-len = <2>;
+   };
+   };
+   };
-- 
1.8.3.2

[RFC PATCH 4/9] drm/exynos: add DSIM driver

[Andrzej Hajda]

The patch adds driver for Exynos DSI master (DSIM). It is a platform driver
which is registered as exynos_drm_display sub-driver of exynos_drm framework
and implements DRM encoder/connector pair.
It is also MIPI-DSI host driver and provides DSI bus for panels.
It interacts with its panel(s) using drm_panel framework.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/Kconfig  |9 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   14 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1393 +++
 5 files changed, 1418 insertions(+)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7441c4a..3681a06 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -31,6 +31,15 @@ config DRM_EXYNOS_FIMD
help
  Choose this option if you want to use Exynos FIMD for DRM.

+config DRM_EXYNOS_DSI
+   bool "EXYNOS DRM MIPI-DSI driver support"
+   depends on DRM_EXYNOS
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   default n
+   help
+ This enables support for Exynos MIPI-DSI device.
+
 config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on ARCH_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index b1839e8..02dde22 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -11,6 +11,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DP)  += exynos_dp_core.o exynos_dp_reg.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4dc9f0d..57ee22a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -419,6 +419,12 @@ static int __init exynos_drm_init(void)
goto out_dp;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_DSI
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_dsi;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -534,6 +540,10 @@ out_hdmi:
platform_driver_unregister(_driver);
 out_fimd:
 #endif
+#ifdef CONFIG_DRM_EXYNOS_DSI
+   platform_driver_unregister(_driver);
+out_dsi:
+#endif
 #ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(_driver);
 out_dp:
@@ -581,6 +591,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_DSI
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_DP
platform_driver_unregister(_driver);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 26bf10a..03c1f4d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -361,6 +361,7 @@ int exynos_platform_device_ipp_register(void);
 void exynos_platform_device_ipp_unregister(void);

 extern struct platform_driver dp_driver;
+extern struct platform_driver dsi_driver;
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
new file mode 100644
index 000..794bca0
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -0,0 +1,1393 @@
+/*
+ * Samsung SoC MIPI DSI Master driver.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd
+ *
+ * Contacts: Tomasz Figa 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "exynos_drm_drv.h"
+
+#define DSIM_STATUS_REG0x0 /* Status register */
+#define DSIM_SWRST_REG 0x4 /* Software reset register */
+#define DSIM_CLKCTRL_REG   0x8 /* Clock control register */
+#define DSIM_TIMEOUT_REG   0xc /* Time out register */
+#define DSIM_CONFIG_REG0x10/* Configuration register */
+#define DSIM_ESCMODE_REG   0x14/* Escape mode register */
+
+/* Main display image resolution register */
+#define DSIM_MDRESOL_REG   0x18
+#define DSIM_MVPORCH_REG   0x1c

[RFC PATCH 3/9] exynos/dsim: add DT bindings

[Andrzej Hajda]

The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
for DSI bus host bindings [1].
Other properties describes its resources: memory, interrupt, clocks,
phy, regulators.
There is only one configuration property: pll-clock-frequency.

[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt

Signed-off-by: Andrzej Hajda 
---
 .../devicetree/bindings/video/exynos_dsim.txt  | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
new file mode 100644
index 000..0246e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -0,0 +1,48 @@
+Exynos MIPI DSI Master
+
+Required properties:
+  - compatible: "samsung,exynos4210-mipi-dsi"
+  - reg: physical base address and length of the registers set for the device
+  - interrupts: should contain DSI interrupt
+  - clocks: list of clock specifiers, must contain an entry for each required
+entry in clock-names
+  - clock-names: should include "bus_clk"and "pll_clk" entries
+  - phys: list of phy specifiers, must contain an entry for each required
+entry in phy-names
+  - phy-names: should include "dsim" entry
+  - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
+  - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
+  - pll-clock-frequency: specifies frequency of "pll_clk" clock
+  - #address-cells, #size-cells: should be set respectively to <1> and <0>
+according to DSI host bindings (see MIPI DSI bindings [1])
+
+Optional properties:
+  - samsung,power-domain: a phandle to DSIM power domain node
+
+Child nodes:
+  Should contain DSI peripheral nodes (see DSI bindings [1])
+
+[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+Example:
+
+   dsi at 11C8 {
+   compatible = "samsung,exynos4210-mipi-dsi";
+   reg = <0x11C8 0x1>;
+   interrupts = <0 79 0>;
+   clocks = < 286>, < 143>;
+   clock-names = "bus_clk", "pll_clk";
+   phys = <_phy 1>;
+   phy-names = "dsim";
+   vddcore-supply = <_reg>;
+   vddio-supply = <_reg>;
+   samsung,power-domain = <_lcd0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pll-clock-frequency = <2400>;
+
+   panel at 0 {
+   reg = <0>;
+   ...
+   };
+   };
-- 
1.8.3.2

[RFC PATCH 2/9] drm/exynos: delay fbdev initialization until an output is connected

[Andrzej Hajda]

In case fbdev is initialized before any output is connected,
fb resolution defaults to 1024x768. After that any output with
bigger resolution is ignored and fbdev is not displayed.
The patch postpones fbdev initialization to avoid such situation.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 12 
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  3 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  4 +++-
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cbb53a3..4dc9f0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -107,22 +107,10 @@ static int exynos_drm_load(struct drm_device *dev, 
unsigned long flags)
/* setup possible_clones. */
exynos_drm_encoder_setup(dev);

-   /*
-* create and configure fb helper and also exynos specific
-* fbdev object.
-*/
-   ret = exynos_drm_fbdev_init(dev);
-   if (ret) {
-   DRM_ERROR("failed to initialize drm fbdev\n");
-   goto err_drm_device;
-   }
-
drm_vblank_offdelay = VBLANK_OFF_DELAY;

return 0;

-err_drm_device:
-   exynos_drm_device_unregister(dev);
 err_vblank:
drm_vblank_cleanup(dev);
 err_display_cleanup:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c7c08d0..65a22ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -20,6 +20,7 @@

 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
+#include "exynos_drm_fbdev.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_iommu.h"
 #include "exynos_drm_crtc.h"
@@ -300,6 +301,8 @@ static void exynos_drm_output_poll_changed(struct 
drm_device *dev)

if (fb_helper)
drm_fb_helper_hotplug_event(fb_helper);
+   else
+   exynos_drm_fbdev_init(dev);
 }

 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e7c2f2d..9a5ec83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -249,8 +249,10 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
return 0;

fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
-   if (!fbdev)
+   if (!fbdev) {
+   DRM_ERROR("failed to allocate fbdev.\n");
return -ENOMEM;
+   }

private->fb_helper = helper = >drm_fb_helper;
helper->funcs = _drm_fb_helper_funcs;
-- 
1.8.3.2

[RFC PATCH 1/9] drm/exynos: correct timing porch conversion

[Andrzej Hajda]

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8caaac2..b611f33 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -538,21 +538,18 @@ static void fimd_mode_set(struct exynos_drm_manager *mgr,
 {
struct fimd_context *ctx = mgr->ctx;
struct fimd_mode_data *mode = >mode;
-   int hblank, vblank;

-   vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
mode->vtotal = in_mode->crtc_vtotal;
mode->vdisplay = in_mode->crtc_vdisplay;
mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
-   mode->vbpd = (vblank - mode->vsync_len) / 2;
-   mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
+   mode->vbpd = in_mode->crtc_vtotal - in_mode->crtc_vsync_end;
+   mode->vfpd = in_mode->crtc_vsync_start - in_mode->crtc_vdisplay;

-   hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
mode->htotal = in_mode->crtc_htotal;
mode->hdisplay = in_mode->crtc_hdisplay;
mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
-   mode->hbpd = (hblank - mode->hsync_len) / 2;
-   mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
+   mode->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
+   mode->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;

mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);

-- 
1.8.3.2

[RFC PATCH 0/9] Exynos DSI master and S6E8AA0 panel drivers

[Andrzej Hajda]

Hi,

This patch set adds bindings and drivers to Exynos MIPI-DSI host and S6E8AA0 
panel.
Both devices are present in Trats and Trats2 targets which are present
in mainline kernel and currently have no display support.
Patchset contains also patches adding corresponding DTS nodes to both devices.

Both drivers are based on patches posted by Tomasz [2].

Drivers have been successfully tested on both devices.

Exynos DSI driver supports only video mode, command mode will be added later.

Patchset contains two additional patches:
- 1st patch corrects porch calculation in function introduced by refactoring
  patches [1],
- 2nd patch delays fbdev initialization to allow fbdev work with devices

Patches are based on branch next-20131211 plus exynos refactoring patches
by Sean Paul [1] plus resolving many merge conflicts.
I have also cherry-picked patches adding drm_panel and drm_mipi_dsi support 
which
were not merged at this time. I hope Sean's patches will be merged soon,
so I could rebase this patchset in saner way.

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/94358
[2]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/15684

Regards
Andrzej

Andrzej Hajda (9):
  drm/exynos: correct timing porch conversion
  drm/exynos: delay fbdev initialization until an output is connected
  exynos/dsim: add DT bindings
  drm/exynos: add DSIM driver
  panel/s6e8aa0: add DT bindings
  drm/panel: add s6e8aa0 driver
  ARM: dts: exynos4: add MIPI DSI Master node
  ARM: dts: exynos4210-trats: add panel node
  ARM: dts: exynos4412-trats2: add panel node

 .../devicetree/bindings/panel/samsung-s6e8aa0.txt  |   53 +
 .../devicetree/bindings/video/exynos_dsim.txt  |   48 +
 arch/arm/boot/dts/exynos4.dtsi |   14 +
 arch/arm/boot/dts/exynos4210-trats.dts |   36 +
 arch/arm/boot/dts/exynos4412-trats2.dts|   45 +
 drivers/gpu/drm/exynos/Kconfig |9 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   26 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1393 
 drivers/gpu/drm/exynos/exynos_drm_fb.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |4 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   11 +-
 drivers/gpu/drm/panel/Kconfig  |7 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1046 +++
 16 files changed, 2678 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung-s6e8aa0.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

-- 
1.8.3.2

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #46 from Paul Menzel  ---
Current status is that I mostly get it to work after the first xrandr off/auto
cycle, meaning 80 % of the cases.

The other 19 % of the cases it takes longer and in 1 % it works right away.

I still do not understand how training works, meaning why it has a higher
chance of working in subsequent tries and is not uniformly distributed.

-- 
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/20140122/fcecc21f/attachment-0001.html>

Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Daniel Vetter]

On Wed, Jan 22, 2014 at 12:48:04PM +, Lin, Mengdong wrote:
> > -Original Message-
> > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On 
> > Behalf Of
> > Daniel Vetter
> > Sent: Tuesday, January 21, 2014 9:11 PM
> > To: Lin, Mengdong
> > Cc: Takashi Iwai (tiwai at suse.de); Barnes, Jesse; Zanoni, Paulo R;
> > alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org
> > Subject: Re: Need your advice: Add a new communication inteface
> > between HD-Audio and Gfx drivers for hotplug notification/ELD update
> > 
> > On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong 
> > wrote:
> > > Dear audio and gfx stakeholders,
> > >
> > >
> > >
> > > We hope to add a new interface between audio and gfx driver, for gfx
> > > driver to notify audio about HDMI/DP hot-plug and ELD update.
> > >
> > > Would you please share some comments on the proposal below?
> > >
> > >
> > >
> > > Background of this issue: On Intel Haswell/Broadwell platforms, there
> > > is a HW restriction that after the display HD-Audio controller is in
> > > D3,
> > >
> > > it cannot be waken up by HDMI/DP hot-plug. Consequently, although the
> > > gfx driver can still detect the HDMI/DP hot-plug,
> > >
> > > audio driver has no idea about this and cannot notify user space
> > > whether the external HDMI/DP monitor is available for audio playback,
> > >
> > > because the audio controller cannot wake up to D0 and receive HW
> > > unsolicited event about hot-plug from the audio codec.
> > >
> > > This limitation will affect user space to decide whether we can output
> > > audio over HDMI/DP.
> > >
> > >
> > >
> > > To solve the above limitation, Takashi suggested to add a new
> > > communication interface between audio and gfx driver: create a
> > common
> > > object
> > >
> > > containing the ops registered by both graphics and audio drivers, then
> > > communicate through it, something like vga_switcheroo.
> > >
> > >
> > >
> > > Is it okay to create this kernel object in i915 driver?
> > >
> > >
> > >
> > > I915 can export an API like "display_register_audio_client" for audio
> > > driver to register a client and hot-plug notification ops.
> > >
> > >
> > >
> > > I915 can also call some API like "display_register_gfx_client" itself
> > > and register ops for audio driver to query monitor presence and ELD
> > > info on a specific port.
> > >
> > > It would be faster for audio driver than quering ELD by
> > > command/response over the HD-A bus, thus avoid delay in i915 mode
> > set.
> > >
> > > This will also avoid waking up the audio devices unnecessarily if the
> > > user space does not really want to use HDMI/DP for audio playback.
> > >
> > >
> > >
> > > Whenever i195 enables/disables audio on a port in modeset, it can call
> > > some API like "display_set_audio_state()" on this kernel object and
> > > trigger notifications to the audio driver.
> > >
> > >
> > >
> > > When the audio driver is probed (in the delayed probe stage), it can
> > > request
> > > i915 API symbol to register the audio client for this communication
> > > kernel object.
> > >
> > > Since the 1st i915 mode set may happen before audio driver registers
> > > the ops, we'll let audio driver check ELD once after registering the
> > > audio client ops.
> > >
> > > And for the platforms which uses this communication interface, we can
> > > disable unsolicited event for HDMI/DP hot-plug in the audio driver.
> > >
> > >
> > >
> > > We hope to hear your feedback and start to work out more details.
> 
> Thanks for your advice, Daniel!
> 
> > Yeah, I've discussed this at KS with Takashi and we've agreed that some
> > common object to facilitate driver interactions. A few things
> > though:
> > - This should be common infrastructure useable by all alsa and drm
> > drivers, not just i915 and snd-hda. Especially on embedded platforms this
> > issue is fairly rampant ...
> 
> Agree. Where to put this common object? 
> Is it okay to put it under /driver/gpu/drm, similar to vga_switchroo?
> Shall we divide clients into audio and gfx categories, and define
> different ops for them? Since different info/request flow in different
> direction between audio and gfx.

I guess we could place them into drivers/gpu, yeah. For a name I'd suggest
avsink or something like that, to make it clear that it's the combination
of audio+video. For the actual interfaces I guess we just need one object
in the device model, but the interface should be split into things called
from the audio side only, functions for the video driver side only and
stuff which can be called from both sides. This matters mostly just so we
don't end up with deadlocks since we need a lock to protect the avsink
state itself (e.g. the EDL or the audio_output_connected state).

> > - While at it it should also encompass power management handling of the
> > shared hw imo so that we can get rid of the hsw specific hacks for the
> > power well code. Or at least we need to rework the power well code to
> > 

[PATCHv6 4/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.

[Denis Carikli]

If de-active and/or pixelclk-active properties were set in the
display-timings DT node, they were not used.

Instead the data-enable and the pixel data clock polarity
were hardcoded.

This change is needed for making the eukrea-cpuimx51
  QVGA display work.

Cc: David Airlie 
Cc: Eric B?nard 
Cc: Greg Kroah-Hartman 
Cc: Philipp Zabel 
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: dri-devel at lists.freedesktop.org
Cc: driverdev-devel at linuxdriverproject.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli 
---
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Removed wrong coments from the code.
- Corrected the code style of the "if (!!val)"

ChangeLog v3->v4:
- The old patch was named "staging: imx-drm: ipuv3-crtc: don't harcode some 
mode".
- Reworked the patch entierly: we now takes the mode flags from the device tree.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Ajusted the flags to match the changes in "drm: Add the lacking
  DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
---
 drivers/staging/imx-drm/imx-drm.h  |3 +++
 drivers/staging/imx-drm/ipuv3-crtc.c   |8 ++--
 drivers/staging/imx-drm/parallel-display.c |   27 +++
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm.h 
b/drivers/staging/imx-drm/imx-drm.h
index ae90c9c..dfdc180 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -5,6 +5,9 @@

 #define IPU_PIX_FMT_GBR24  v4l2_fourcc('G', 'B', 'R', '3')

+#define IMXDRM_MODE_FLAG_DE_HIGH   (1<<0)
+#define IMXDRM_MODE_FLAG_PIXDATA_POSEDGE   (1<<1)
+
 struct drm_crtc;
 struct drm_connector;
 struct drm_device;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index ce6ba98..ce8e6e4 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -156,8 +156,12 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;

-   sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 1;
+   if (mode->private_flags & IMXDRM_MODE_FLAG_DE_HIGH)
+   sig_cfg.enable_pol = 1;
+
+   if (mode->private_flags & IMXDRM_MODE_FLAG_PIXDATA_POSEDGE)
+   sig_cfg.clk_pol = 1;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index bb71d6d..02aa4da 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -74,7 +74,34 @@ static int imx_pd_connector_get_modes(struct drm_connector 
*connector)

if (np) {
struct drm_display_mode *mode = drm_mode_create(connector->dev);
+   struct device_node *timings_np;
+   struct device_node *mode_np;
+   u32 val;
+
of_get_drm_display_mode(np, >mode, 0);
+
+   timings_np = of_get_child_by_name(np, "display-timings");
+   if (timings_np) {
+   /* get the display mode node */
+   mode_np = of_parse_phandle(timings_np,
+  "native-mode", 0);
+   if (!mode_np)
+   mode_np = of_get_next_child(timings_np, NULL);
+
+   /* set de-active to 1 if not set */
+   of_property_read_u32(mode_np, "de-active", );
+   if (val) {
+   imxpd->mode.private_flags |=
+   IMXDRM_MODE_FLAG_DE_HIGH;
+   }
+
+   /* set pixelclk-active to 1 if not set */
+   of_property_read_u32(mode_np, "pixelclk-active", );
+   if (val) {
+   imxpd->mode.private_flags |=
+   IMXDRM_MODE_FLAG_PIXDATA_POSEDGE;
+   }
+   }
drm_mode_copy(mode, >mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
drm_mode_probed_add(connector, mode);
-- 
1.7.9.5

[Bug 73785] Team Fortress 2 causes random GPU stalls on radeonsi with dpm enabled

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/Gallium/radeonsi|DRM/Radeon

-- 
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/20140122/5178bad3/attachment.html>

[PATCH v4] ACPI: Fix acpi_evaluate_object() return value check

[Bjorn Helgaas]

On Mon, Jan 20, 2014 at 7:46 PM, Yijing Wang  wrote:
> Since acpi_evaluate_object() returns acpi_status and not plain int,
> ACPI_FAILURE() should be used for checking its return value.
>
> Reviewed-by: Jani Nikula 
> Signed-off-by: Yijing Wang 
> ---
> v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> v2->v3: Fix compile error pointed out by Hanjun.
> v1->v2: Add CC to related subsystem MAINTAINERS
> ---
>  drivers/gpu/drm/i915/intel_acpi.c  |   24 
> ++--
>  drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |9 +
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |   23 +--
>  drivers/pci/pci-label.c|9 ++---

For the drivers/pci/pci-label.c part,

Acked-by: Bjorn Helgaas 

> +   status = acpi_evaluate_object(handle, "_DSM", , );
> +   if (ACPI_FAILURE(status)) {
> +   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
> +   acpi_format_exception(status));

It's too bad there isn't an easy way to produce more informative error
messages, e.g., by including a namespace path or something.  A message
like:

failed to evaluate _DSM: A requested entity is not found

is only useful if there's enough context to figure out what's going on.

Bjorn

[Bug 73785] Team Fortress 2 causes random GPU stalls on radeonsi with dpm enabled

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

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

Alex Deucher  changed:

   What|Removed |Added

Summary|Team Fortress 2 causes  |Team Fortress 2 causes
   |random GPU stalls on|random GPU stalls on
   |radeonsi|radeonsi with dpm enabled

--- Comment #3 from Alex Deucher  ---
(In reply to comment #2)
> Hello Alex,
> 
> Thanks for replying to my bug report.
> 
> I am not certain exactly when this bug was introduced or even which
> component is involved, but since TF2 was stable a month ago it must be a
> regression.
> 
> I can report that having played well over 2 h with dynamic power management
> disabled, that this bug is related to dpm.
> 
> However, playing with radeon.dpm=1 and setting
> /sys/class/drm/card0/device/power_dpm_state to 'balanced' (down from
> 'performance'), the stalls become much less frequent, more in the range of
> once or twice every 2-3 hours.

I think it's coincidence.  balanced and performance are the same on your chip.

-- 
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/20140122/51a3213f/attachment.html>

[Bug 73785] Team Fortress 2 causes random GPU stalls on radeonsi

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

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

--- Comment #2 from Remco Zoet  ---
Hello Alex,

Thanks for replying to my bug report.

I am not certain exactly when this bug was introduced or even which component
is involved, but since TF2 was stable a month ago it must be a regression.

I can report that having played well over 2 h with dynamic power management
disabled, that this bug is related to dpm.

However, playing with radeon.dpm=1 and setting
/sys/class/drm/card0/device/power_dpm_state to 'balanced' (down from
'performance'), the stalls become much less frequent, more in the range of once
or twice every 2-3 hours.

-- 
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/20140122/26dfe6fe/attachment.html>

[PATCH v4 5/5] drm/tegra: Add eDP support

[Stephen Warren]

On 01/21/2014 12:24 PM, Thierry Reding wrote:
> Add support for eDP functionality found on Tegra124 and later SoCs. Only
> fast link training is currently supported.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../bindings/gpu/nvidia,tegra20-host1x.txt |   42 +

This part should go to the DT mailing list, although it looks fine to me.

> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c

> + * Copyright (C) 2013 NVIDIA Corporation

2014? Perhaps elsewhere too?

> +static void tegra_dpaux_write_fifo(struct tegra_dpaux *dpaux, const u8 
> *buffer,

Is that anything like writesl(); similar for
tegra_dpaux_read_fifo()/readsl()?

[PATCH v2] backlight: turn backlight on/off when necessary

[Jingoo Han]

On Wednesday, January 22, 2014 2:04 PM, Liu Ying wrote:
> 
> Ping...
> 
> Regards,
> Liu Ying

Please, don't send the ping within 2 days.
It is not a good practice. You sent the v1 patch 6 months ago.
However, why I should review the patch within 2 days?
Please wait.

Best regards,
Jingoo Han

> 
> On 01/20/2014 12:52 PM, Liu Ying wrote:
> > We don't have to turn backlight on/off everytime a blanking
> > or unblanking event comes because the backlight status may
> > have already been what we want. Another thought is that one
> > backlight device may be shared by multiple framebuffers. We
> > don't hope blanking one of the framebuffers may turn the
> > backlight off for all the other framebuffers, since they are
> > likely being active to display something. This patch adds
> > some logics to record each framebuffer's backlight usage to
> > determine the backlight device use count and whether the
> > backlight should be turned on or off. To be more specific,
> > only one unblank operation on a certain blanked framebuffer
> > may increase the backlight device's use count by one, while
> > one blank operation on a certain unblanked framebuffer may
> > decrease the use count by one, because the userspace is
> > likely to unblank a unblanked framebuffer or blank a blanked
> > framebuffer.
> >
> > Signed-off-by: Liu Ying 
> > ---
> > v1 can be found at https://lkml.org/lkml/2013/5/30/139
> >
> > v1->v2:
> > * Make the commit message be more specific about the condition
> >   in which backlight device use count can be increased/decreased.
> > * Correct the setting for bd->props.fb_blank.
> >
> >  drivers/video/backlight/backlight.c |   28 +---
> >  include/linux/backlight.h   |6 ++
> >  2 files changed, 27 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/backlight/backlight.c 
> > b/drivers/video/backlight/backlight.c
> > index 5d0..42044be 100644
> > --- a/drivers/video/backlight/backlight.c
> > +++ b/drivers/video/backlight/backlight.c
> > @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
> >defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
> >  /* This callback gets called when something important happens inside a
> >   * framebuffer driver. We're looking if that important event is blanking,
> > - * and if it is, we're switching backlight power as well ...
> > + * and if it is and necessary, we're switching backlight power as well ...
> >   */
> >  static int fb_notifier_callback(struct notifier_block *self,
> > unsigned long event, void *data)
> >  {
> > struct backlight_device *bd;
> > struct fb_event *evdata = data;
> > +   int node = evdata->info->node;
> > +   int fb_blank = 0;
> >
> > /* If we aren't interested in this event, skip it immediately ... */
> > if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> > @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block 
> > *self,
> > if (bd->ops)
> > if (!bd->ops->check_fb ||
> > bd->ops->check_fb(bd, evdata->info)) {
> > -   bd->props.fb_blank = *(int *)evdata->data;
> > -   if (bd->props.fb_blank == FB_BLANK_UNBLANK)
> > -   bd->props.state &= ~BL_CORE_FBBLANK;
> > -   else
> > -   bd->props.state |= BL_CORE_FBBLANK;
> > -   backlight_update_status(bd);
> > +   fb_blank = *(int *)evdata->data;
> > +   if (fb_blank == FB_BLANK_UNBLANK &&
> > +   !bd->fb_bl_on[node]) {
> > +   bd->fb_bl_on[node] = true;
> > +   if (!bd->use_count++) {
> > +   bd->props.state &= ~BL_CORE_FBBLANK;
> > +   bd->props.fb_blank = 
> > FB_BLANK_UNBLANK;
> > +   backlight_update_status(bd);
> > +   }
> > +   } else if (fb_blank != FB_BLANK_UNBLANK &&
> > +  bd->fb_bl_on[node]) {
> > +   bd->fb_bl_on[node] = false;
> > +   if (!(--bd->use_count)) {
> > +   bd->props.state |= BL_CORE_FBBLANK;
> > +   bd->props.fb_blank = 
> > FB_BLANK_POWERDOWN;
> > +   backlight_update_status(bd);
> > +   }
> > +   }
> > }
> > mutex_unlock(>ops_lock);
> > return 0;
> > diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> > index 5f9cd96..7264742 100644
> > --- a/include/linux/backlight.h
> > +++ b/include/linux/backlight.h
> > @@ -9,6 +9,7 @@
> >  #define 

linux-next: manual merge of the drm-intel tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit c326c0a9c98c
("drm/i915: Call drm_calc_timestamping_constants() earlier") from the drm
tree and commit bbee18af2a25 ("drm/i915: Prepare to track new pipe config
per pipe") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_display.c
index 14b024becb91,e1d3ae1212a7..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -9660,14 -9705,7 +9703,15 @@@ static int __intel_set_mode(struct drm_
/* mode_set/enable/disable functions rely on a correct pipe
 * config. */
to_intel_crtc(crtc)->config = *pipe_config;
+   to_intel_crtc(crtc)->new_config = _intel_crtc(crtc)->config;
 +
 +  /*
 +   * Calculate and store various constants which
 +   * are later needed by vblank and swap-completion
 +   * timestamping. They are derived from true hwmode.
 +   */
 +  drm_calc_timestamping_constants(crtc,
 +  _config->adjusted_mode);
}

/* Only after disabling all output pipelines that will be changed can we
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140122/0d3ca13d/attachment-0001.pgp>

linux-next: manual merge of the drm-intel tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_irq.c between commit abca9e454498 ("drm: Pass
'flags' from the caller to .get_scanout_position()") from the drm tree
and commit d59a63ad8234 ("drm/i915: Add intel_get_crtc_scanline()") from
the drm-intel tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_irq.c
index 17d8fcb1b6f7,ffb56a9db9cc..
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@@ -649,8 -675,9 +649,9 @@@ static bool ilk_pipe_in_vblank_locked(s
  }

  static int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe,
 -  int *vpos, int *hpos,
 +  unsigned int flags, int *vpos, int *hpos,
-   ktime_t *stime, ktime_t *etime)
+   ktime_t *stime, ktime_t *etime,
+   bool adjust)
  {
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
@@@ -788,6 -786,24 +791,24 @@@
return ret;
  }

+ static int i915_get_scanout_position(struct drm_device *dev, int pipe,
+int *vpos, int *hpos,
+ktime_t *stime, ktime_t *etime)
+ {
 -  return i915_get_crtc_scanoutpos(dev, pipe, vpos, hpos,
++  return i915_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
+   stime, etime, true);
+ }
+ 
+ int intel_get_crtc_scanline(struct drm_crtc *crtc)
+ {
+   int vpos = 0, hpos = 0;
+ 
 -  i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe,
++  i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe, 0,
+, , NULL, NULL, false);
+ 
+   return vpos;
+ }
+ 
  static int i915_get_vblank_timestamp(struct drm_device *dev, int pipe,
  int *max_error,
  struct timeval *vblank_time,
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140122/02afb4c2/attachment.pgp>

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Thomas Hellstrom]

On 01/22/2014 01:38 PM, Maarten Lankhorst wrote:
> op 22-01-14 13:11, Thomas Hellstrom schreef:
>> On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
>>> op 22-01-14 11:27, Thomas Hellstrom schreef:
 On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
> op 22-01-14 10:40, Thomas Hellstrom schreef:
>> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
>>> op 21-01-14 18:44, Thomas Hellstrom schreef:
 On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 21-01-14 16:17, Thomas Hellstrom schreef:
>> Maarten, for this and the other patches in this series,
>>
>> I seem to recall we have this discussion before?
>> IIRC I stated that reservation was a too heavy-weight lock to
>> hold to
>> determine whether a buffer was idle? It's a pretty nasty
>> thing to
>> build in.
>>
> I've sent this patch after determining that this already didn't
> end up
> being heavyweight.
> Most places were already using the fence_lock and reservation, I
> just
> fixed up the few
> places that didn't hold a reservation while waiting.
> Converting the
> few places that didn't
> ended up being trivial, so I thought I'd submit it.
 Actually the only *valid* reason for holding a reservation when
 waiting
 for idle is
 1) You want to block further command submission on the buffer.
 2) You want to switch GPU engine and don't have access to gpu
 semaphores
 / barriers.

 Reservation has the nasty side effect that it blocks command
 submission
 and pins the buffer (in addition now makes the evict list
 traversals
 skip the buffer) which in general is *not* necessary for most wait
 cases, so we should instead actually convert the wait cases that
 don't
 fulfill 1) and 2) above in the other direction if we have
 performance
 and latency-reduction in mind. I can't see how a spinlock
 protecting a
 fence pointer or fence list is stopping you from using RW
 fences as
 long
 as the spinlock is held while manipulating the fence list?

>>> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
>>> patchset, though) and enumerate if they can be changed to work
>>> without
>>> reservation or not.
>>>
>>> ttm/ttm_bo.c
>>> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
>>> finish for the direct destroy fastpath, if either fails it needs
>>> to be
>>> queued. Cannot work without reservation.
>> Doesn't block and no significant reservation contention expected.
>>
>>> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
>>> doesn't need to re-acquire. Simply reordering ttm_bo_wait until
>>> after
>>> re-reserve is enough.
>> Currently follows the above rules.
>>
>>> ttm_bo_evict: already has the reservation, cannot be dropped since
>>> only trylock is allowed. Dropping reservation would cause badness,
>>> cannot be converted.
>> Follows rule 2 above. We're about to move the buffer and if that
>> can't
>> be pipelined using the GPU (which TTM currently doesn't allow), we
>> need
>> to wait. Although eviction should be low priority compared to new
>> command submission, so I can't really see why we couldn't wait
>> before
>> trying to reserve here?
>>
>>> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
>>> reservation for same reason as ttm_bo_evict. It might be part of a
>>> ticketed reservation so really don't drop lock here.
>> Part of command submission and as such follows rule 2 above. If
>> we can
>> pipeline the move with the GPU, no need to wait (but needs to be
>> implemented, of course).
>>
>>> ttm_bo_synccpu_write_grab: the wait could be converted to be done
>>> afterwards, without  fence_lock. But in this case reservation could
>>> take the role of fence_lock too,
>>>
>>> so no separate fence_lock would be needed.
>> With the exception that reservation is more likely to be contended.
> True but rule 1.
>>> ttm_bo_swapout: see ttm_bo_evict.
>>>
>>> ttm/ttm_bo_util.c:
>>> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
>>> ttm_bo_move_buffer, can be called from that function.
>> Rule 2.
>>
>>> ttm/ttm_bo_vm.c
>>> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here,
>>> but
>>> you already had the reservation, so a similar optimization to
>>> ttm_bo_synccpu_write_grab could be done without requiring
>>> fence_lock.
>>> If you would write it like that, you would end up with a patch
>>> similar
>>> to drm/nouveau: add reservation to 

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

op 22-01-14 13:11, Thomas Hellstrom schreef:
> On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
>> op 22-01-14 11:27, Thomas Hellstrom schreef:
>>> On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
 op 22-01-14 10:40, Thomas Hellstrom schreef:
> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
>> op 21-01-14 18:44, Thomas Hellstrom schreef:
>>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
 Hey,

 op 21-01-14 16:17, Thomas Hellstrom schreef:
> Maarten, for this and the other patches in this series,
>
> I seem to recall we have this discussion before?
> IIRC I stated that reservation was a too heavy-weight lock to
> hold to
> determine whether a buffer was idle? It's a pretty nasty thing to
> build in.
>
 I've sent this patch after determining that this already didn't
 end up
 being heavyweight.
 Most places were already using the fence_lock and reservation, I
 just
 fixed up the few
 places that didn't hold a reservation while waiting. Converting the
 few places that didn't
 ended up being trivial, so I thought I'd submit it.
>>> Actually the only *valid* reason for holding a reservation when
>>> waiting
>>> for idle is
>>> 1) You want to block further command submission on the buffer.
>>> 2) You want to switch GPU engine and don't have access to gpu
>>> semaphores
>>> / barriers.
>>>
>>> Reservation has the nasty side effect that it blocks command
>>> submission
>>> and pins the buffer (in addition now makes the evict list traversals
>>> skip the buffer) which in general is *not* necessary for most wait
>>> cases, so we should instead actually convert the wait cases that
>>> don't
>>> fulfill 1) and 2) above in the other direction if we have
>>> performance
>>> and latency-reduction in mind. I can't see how a spinlock
>>> protecting a
>>> fence pointer or fence list is stopping you from using RW fences as
>>> long
>>> as the spinlock is held while manipulating the fence list?
>>>
>> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
>> patchset, though) and enumerate if they can be changed to work
>> without
>> reservation or not.
>>
>> ttm/ttm_bo.c
>> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
>> finish for the direct destroy fastpath, if either fails it needs
>> to be
>> queued. Cannot work without reservation.
> Doesn't block and no significant reservation contention expected.
>
>> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
>> doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
>> re-reserve is enough.
> Currently follows the above rules.
>
>> ttm_bo_evict: already has the reservation, cannot be dropped since
>> only trylock is allowed. Dropping reservation would cause badness,
>> cannot be converted.
> Follows rule 2 above. We're about to move the buffer and if that can't
> be pipelined using the GPU (which TTM currently doesn't allow), we
> need
> to wait. Although eviction should be low priority compared to new
> command submission, so I can't really see why we couldn't wait before
> trying to reserve here?
>
>> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
>> reservation for same reason as ttm_bo_evict. It might be part of a
>> ticketed reservation so really don't drop lock here.
> Part of command submission and as such follows rule 2 above. If we can
> pipeline the move with the GPU, no need to wait (but needs to be
> implemented, of course).
>
>> ttm_bo_synccpu_write_grab: the wait could be converted to be done
>> afterwards, without  fence_lock. But in this case reservation could
>> take the role of fence_lock too,
>>
>> so no separate fence_lock would be needed.
> With the exception that reservation is more likely to be contended.
 True but rule 1.
>> ttm_bo_swapout: see ttm_bo_evict.
>>
>> ttm/ttm_bo_util.c:
>> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
>> ttm_bo_move_buffer, can be called from that function.
> Rule 2.
>
>> ttm/ttm_bo_vm.c
>> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here,
>> but
>> you already had the reservation, so a similar optimization to
>> ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
>> If you would write it like that, you would end up with a patch
>> similar
>> to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I
>> think
>> we should do this, an
>>
>> Ok, so the core does NOT need fence_lock because we can never drop
>> reservations except in synccpu_write_grab and maybe
>> 

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

op 22-01-14 13:11, Thomas Hellstrom schreef:
> On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
>> op 22-01-14 11:27, Thomas Hellstrom schreef:
>>> On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
 op 22-01-14 10:40, Thomas Hellstrom schreef:
> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
>> op 21-01-14 18:44, Thomas Hellstrom schreef:
>>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
 Hey,

 op 21-01-14 16:17, Thomas Hellstrom schreef:
> Maarten, for this and the other patches in this series,
>
> I seem to recall we have this discussion before?
> IIRC I stated that reservation was a too heavy-weight lock to
> hold to
> determine whether a buffer was idle? It's a pretty nasty thing to
> build in.
>
 I've sent this patch after determining that this already didn't
 end up
 being heavyweight.
 Most places were already using the fence_lock and reservation, I
 just
 fixed up the few
 places that didn't hold a reservation while waiting. Converting the
 few places that didn't
 ended up being trivial, so I thought I'd submit it.
>>> Actually the only *valid* reason for holding a reservation when
>>> waiting
>>> for idle is
>>> 1) You want to block further command submission on the buffer.
>>> 2) You want to switch GPU engine and don't have access to gpu
>>> semaphores
>>> / barriers.
>>>
>>> Reservation has the nasty side effect that it blocks command
>>> submission
>>> and pins the buffer (in addition now makes the evict list traversals
>>> skip the buffer) which in general is *not* necessary for most wait
>>> cases, so we should instead actually convert the wait cases that
>>> don't
>>> fulfill 1) and 2) above in the other direction if we have
>>> performance
>>> and latency-reduction in mind. I can't see how a spinlock
>>> protecting a
>>> fence pointer or fence list is stopping you from using RW fences as
>>> long
>>> as the spinlock is held while manipulating the fence list?
>>>
>> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
>> patchset, though) and enumerate if they can be changed to work
>> without
>> reservation or not.
>>
>> ttm/ttm_bo.c
>> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
>> finish for the direct destroy fastpath, if either fails it needs
>> to be
>> queued. Cannot work without reservation.
> Doesn't block and no significant reservation contention expected.
>
>> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
>> doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
>> re-reserve is enough.
> Currently follows the above rules.
>
>> ttm_bo_evict: already has the reservation, cannot be dropped since
>> only trylock is allowed. Dropping reservation would cause badness,
>> cannot be converted.
> Follows rule 2 above. We're about to move the buffer and if that can't
> be pipelined using the GPU (which TTM currently doesn't allow), we
> need
> to wait. Although eviction should be low priority compared to new
> command submission, so I can't really see why we couldn't wait before
> trying to reserve here?
>
>> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
>> reservation for same reason as ttm_bo_evict. It might be part of a
>> ticketed reservation so really don't drop lock here.
> Part of command submission and as such follows rule 2 above. If we can
> pipeline the move with the GPU, no need to wait (but needs to be
> implemented, of course).
>
>> ttm_bo_synccpu_write_grab: the wait could be converted to be done
>> afterwards, without  fence_lock. But in this case reservation could
>> take the role of fence_lock too,
>>
>> so no separate fence_lock would be needed.
> With the exception that reservation is more likely to be contended.
 True but rule 1.
>> ttm_bo_swapout: see ttm_bo_evict.
>>
>> ttm/ttm_bo_util.c:
>> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
>> ttm_bo_move_buffer, can be called from that function.
> Rule 2.
>
>> ttm/ttm_bo_vm.c
>> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here,
>> but
>> you already had the reservation, so a similar optimization to
>> ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
>> If you would write it like that, you would end up with a patch
>> similar
>> to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I
>> think
>> we should do this, an
>>
>> Ok, so the core does NOT need fence_lock because we can never drop
>> reservations except in synccpu_write_grab and maybe
>> 

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #13 from Arek Ru?niak  ---
indeed, it's so embarrassing. someone in somehow had to do this to me, surely
it had to be the elves. sorry for that mess.

-- 
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/20140122/8a74e817/attachment.html>

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Rob Clark]

On Wed, Jan 22, 2014 at 12:23 PM, Takashi Iwai  wrote:
> At Wed, 22 Jan 2014 10:45:26 -0500,
> Rob Clark wrote:
>>
>> On Wed, Jan 22, 2014 at 10:20 AM, Daniel Vetter  wrote:
>> > On Wed, Jan 22, 2014 at 10:04:14AM -0500, Rob Clark wrote:
>> >> sorry to jump into this a bit late, so maybe this was covered already 
>> >> earlier..
>> >
>> > It just started, I've quoted everything when cc'ing dri-devel. But good to
>> > have examples outside of x86 (where things are mostly standardized by the
>> > Eye of Redmond).
>>
>> perhaps the arm/SoC stuff was standardized by the Eye of Cthulhu
>>
>> btw, added a few other SoC drm types who might be interested in the topic
>>
>> >> For drm/msm the hdmi code needs something along these lines from audio:
>> >>
>> >> int hdmi_audio_info_setup(struct platform_device *pdev, bool enabled,
>> >> uint32_t num_of_channels, uint32_t channel_allocation,
>> >> uint32_t level_shift, bool down_mix);
>> >> void hdmi_audio_set_sample_rate(struct platform_device *pdev, int rate);
>> >>
>> >> (former is mainly to setup avi audio infoframe, latter for clks)
>> >>
>> >> in addition to hotplug and ELD stuff
>> >
>> > Can you elaborate a bit on what you need for msm? On intel (and I think
>> > the other x86 platforms are similar) we have separate buffers in the hw
>> > for avi infoframes and audio infoframes, so the drm and alsa driver can
>> > bash the right stuff into the hardware on their own. I'm mostly confused
>> > since you say _AVI_ infoframe here, which is purely generated by the drm
>> > side of the code here. Or at least that's been my understanding.
>>
>> Sorry, typo, meant audio infoframe
>>
>> We could have the API such that the audio driver constructs the
>> infoframe.. that probably makes more sense and simplifies things.
>
> The HD-audio has a code for doing that, so if needed, it can be copied
> from there.  But, even AMD HD-audio codec doesn't use this scheme but
> just sets up a few verbs for channel-allocations, etc, so the complete
> audio infoframe isn't necessary in most cases, as it seems.
>
>>  But
>> the drm driver is the one that needs to bash that constructed buffer
>> into the hw.  Or, well, either that or both drivers ioremap the same
>> block of registers, but that seems somewhat lame.
>>
>> But I do need to know some basic things, like # of channels.. and
>> would kinda prefer not to have to parse the audio infoframe to get
>> that info.
>
> Yes, it makes things complex.  It's one of the reasons we'd like to
> have a more straightforward interface.
>
>> > The clocks are also funny really, but I'm not sure whether this fits. I'd
>> > have expected some DT-based generic clock source which the audio driver
>> > just grabs as part of his multi-device beast (maybe using Russell's new
>> > driver core code) and used directly. What's the reason that this has to go
>> > through the drm driverr?
>>
>> possibly it could be exposed to the audio driver as a 'struct clk'
>> that is implemented/registered/exported by the drm driver, I guess?
>
> Hrm, but I guess this is also purely optional?
> I'd like to start rather from a minimum set.

well, for anything where the video side of things does not need to
know (which would incl audio clock if this doesn't need to be setup by
display on some hw) would be optional, I think..

if you did need to configure audio clock on the display side of
things, it might be simpler just to have a set_rate() fxn ptr in the
struct, but the 'struct clk' approach seems more proper.  That said,
I'm not really sure how it works for the audio driver to find the clk
in a non-DT kernel.. if that was a problem, I'm not one to let
perfection be the enemy of improvement, so would be ok with the
simpler interface.

BR,
-R

>> fwiw, if curious, what I have on msm so far is at:
>>
>> https://github.com/freedreno/kernel-msm/commit/6ffd278d39a3ff8712c70b5fd98dc135bd6c7b8a
>>
>> It works on downstream qcom android kernel.. the API exported by drm
>> driver, called by audio driver, is basically just a clone of the hack
>> that was already there between fbdev and alsa.  I haven't tried to
>> clean that up at all yet.  It was enough work just untangling ION (!!)
>> from alsa in that kernel :-/
>
> Thanks for the pointer!
>
>
> Takashi
>
>
>>
>> BR,
>> -R
>>
>> > Cheers, Daniel
>> > --
>> > Daniel Vetter
>> > Software Engineer, Intel Corporation
>> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Thomas Hellstrom]

On 01/22/2014 11:58 AM, Maarten Lankhorst wrote:
> op 22-01-14 11:27, Thomas Hellstrom schreef:
>> On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
>>> op 22-01-14 10:40, Thomas Hellstrom schreef:
 On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
> op 21-01-14 18:44, Thomas Hellstrom schreef:
>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> op 21-01-14 16:17, Thomas Hellstrom schreef:
 Maarten, for this and the other patches in this series,

 I seem to recall we have this discussion before?
 IIRC I stated that reservation was a too heavy-weight lock to
 hold to
 determine whether a buffer was idle? It's a pretty nasty thing to
 build in.

>>> I've sent this patch after determining that this already didn't
>>> end up
>>> being heavyweight.
>>> Most places were already using the fence_lock and reservation, I
>>> just
>>> fixed up the few
>>> places that didn't hold a reservation while waiting. Converting the
>>> few places that didn't
>>> ended up being trivial, so I thought I'd submit it.
>> Actually the only *valid* reason for holding a reservation when
>> waiting
>> for idle is
>> 1) You want to block further command submission on the buffer.
>> 2) You want to switch GPU engine and don't have access to gpu
>> semaphores
>> / barriers.
>>
>> Reservation has the nasty side effect that it blocks command
>> submission
>> and pins the buffer (in addition now makes the evict list traversals
>> skip the buffer) which in general is *not* necessary for most wait
>> cases, so we should instead actually convert the wait cases that
>> don't
>> fulfill 1) and 2) above in the other direction if we have
>> performance
>> and latency-reduction in mind. I can't see how a spinlock
>> protecting a
>> fence pointer or fence list is stopping you from using RW fences as
>> long
>> as the spinlock is held while manipulating the fence list?
>>
> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
> patchset, though) and enumerate if they can be changed to work
> without
> reservation or not.
>
> ttm/ttm_bo.c
> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
> finish for the direct destroy fastpath, if either fails it needs
> to be
> queued. Cannot work without reservation.
 Doesn't block and no significant reservation contention expected.

> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
> doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
> re-reserve is enough.
 Currently follows the above rules.

> ttm_bo_evict: already has the reservation, cannot be dropped since
> only trylock is allowed. Dropping reservation would cause badness,
> cannot be converted.
 Follows rule 2 above. We're about to move the buffer and if that can't
 be pipelined using the GPU (which TTM currently doesn't allow), we
 need
 to wait. Although eviction should be low priority compared to new
 command submission, so I can't really see why we couldn't wait before
 trying to reserve here?

> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
> reservation for same reason as ttm_bo_evict. It might be part of a
> ticketed reservation so really don't drop lock here.
 Part of command submission and as such follows rule 2 above. If we can
 pipeline the move with the GPU, no need to wait (but needs to be
 implemented, of course).

> ttm_bo_synccpu_write_grab: the wait could be converted to be done
> afterwards, without  fence_lock. But in this case reservation could
> take the role of fence_lock too,
>
> so no separate fence_lock would be needed.
 With the exception that reservation is more likely to be contended.
>>> True but rule 1.
> ttm_bo_swapout: see ttm_bo_evict.
>
> ttm/ttm_bo_util.c:
> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
> ttm_bo_move_buffer, can be called from that function.
 Rule 2.

> ttm/ttm_bo_vm.c
> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here,
> but
> you already had the reservation, so a similar optimization to
> ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
> If you would write it like that, you would end up with a patch
> similar
> to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I
> think
> we should do this, an
>
> Ok, so the core does NOT need fence_lock because we can never drop
> reservations except in synccpu_write_grab and maybe
> ttm_bo_vm_fault_idle, but even in those cases reservation is done. So
> that could be used instead of fence_lock.
>
> nouveau_gem_ioctl_cpu_prep:
> Either 

[PATCH v2] backlight: turn backlight on/off when necessary

[Liu Ying]

Ping...

Regards,
Liu Ying

On 01/20/2014 12:52 PM, Liu Ying wrote:
> We don't have to turn backlight on/off everytime a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers. We
> don't hope blanking one of the framebuffers may turn the
> backlight off for all the other framebuffers, since they are
> likely being active to display something. This patch adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight should be turned on or off. To be more specific,
> only one unblank operation on a certain blanked framebuffer
> may increase the backlight device's use count by one, while
> one blank operation on a certain unblanked framebuffer may
> decrease the use count by one, because the userspace is
> likely to unblank a unblanked framebuffer or blank a blanked
> framebuffer.
> 
> Signed-off-by: Liu Ying 
> ---
> v1 can be found at https://lkml.org/lkml/2013/5/30/139
> 
> v1->v2:
> * Make the commit message be more specific about the condition
>   in which backlight device use count can be increased/decreased.
> * Correct the setting for bd->props.fb_blank.
> 
>  drivers/video/backlight/backlight.c |   28 +---
>  include/linux/backlight.h   |6 ++
>  2 files changed, 27 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index 5d0..42044be 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
>defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
>  /* This callback gets called when something important happens inside a
>   * framebuffer driver. We're looking if that important event is blanking,
> - * and if it is, we're switching backlight power as well ...
> + * and if it is and necessary, we're switching backlight power as well ...
>   */
>  static int fb_notifier_callback(struct notifier_block *self,
> unsigned long event, void *data)
>  {
> struct backlight_device *bd;
> struct fb_event *evdata = data;
> +   int node = evdata->info->node;
> +   int fb_blank = 0;
> 
> /* If we aren't interested in this event, skip it immediately ... */
> if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block 
> *self,
> if (bd->ops)
> if (!bd->ops->check_fb ||
> bd->ops->check_fb(bd, evdata->info)) {
> -   bd->props.fb_blank = *(int *)evdata->data;
> -   if (bd->props.fb_blank == FB_BLANK_UNBLANK)
> -   bd->props.state &= ~BL_CORE_FBBLANK;
> -   else
> -   bd->props.state |= BL_CORE_FBBLANK;
> -   backlight_update_status(bd);
> +   fb_blank = *(int *)evdata->data;
> +   if (fb_blank == FB_BLANK_UNBLANK &&
> +   !bd->fb_bl_on[node]) {
> +   bd->fb_bl_on[node] = true;
> +   if (!bd->use_count++) {
> +   bd->props.state &= ~BL_CORE_FBBLANK;
> +   bd->props.fb_blank = FB_BLANK_UNBLANK;
> +   backlight_update_status(bd);
> +   }
> +   } else if (fb_blank != FB_BLANK_UNBLANK &&
> +  bd->fb_bl_on[node]) {
> +   bd->fb_bl_on[node] = false;
> +   if (!(--bd->use_count)) {
> +   bd->props.state |= BL_CORE_FBBLANK;
> +   bd->props.fb_blank = 
> FB_BLANK_POWERDOWN;
> +   backlight_update_status(bd);
> +   }
> +   }
> }
> mutex_unlock(>ops_lock);
> return 0;
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 5f9cd96..7264742 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -9,6 +9,7 @@
>  #define _LINUX_BACKLIGHT_H
> 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -104,6 +105,11 @@ struct backlight_device {
> struct list_head entry;
> 
> struct device dev;
> +
> +   /* Multiple framebuffers may share one backlight device */
> +   bool fb_bl_on[FB_MAX];
> +
> +   int use_count;
>  };
> 
>  static inline void backlight_update_status(struct backlight_device *bd)
> --
> 1.7.9.5

Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Lin, Mengdong]

> -Original Message-
> From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On Behalf 
> Of
> Daniel Vetter
> Sent: Tuesday, January 21, 2014 9:11 PM
> To: Lin, Mengdong
> Cc: Takashi Iwai (tiwai at suse.de); Barnes, Jesse; Zanoni, Paulo R;
> alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org
> Subject: Re: Need your advice: Add a new communication inteface
> between HD-Audio and Gfx drivers for hotplug notification/ELD update
> 
> On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong 
> wrote:
> > Dear audio and gfx stakeholders,
> >
> >
> >
> > We hope to add a new interface between audio and gfx driver, for gfx
> > driver to notify audio about HDMI/DP hot-plug and ELD update.
> >
> > Would you please share some comments on the proposal below?
> >
> >
> >
> > Background of this issue: On Intel Haswell/Broadwell platforms, there
> > is a HW restriction that after the display HD-Audio controller is in
> > D3,
> >
> > it cannot be waken up by HDMI/DP hot-plug. Consequently, although the
> > gfx driver can still detect the HDMI/DP hot-plug,
> >
> > audio driver has no idea about this and cannot notify user space
> > whether the external HDMI/DP monitor is available for audio playback,
> >
> > because the audio controller cannot wake up to D0 and receive HW
> > unsolicited event about hot-plug from the audio codec.
> >
> > This limitation will affect user space to decide whether we can output
> > audio over HDMI/DP.
> >
> >
> >
> > To solve the above limitation, Takashi suggested to add a new
> > communication interface between audio and gfx driver: create a
> common
> > object
> >
> > containing the ops registered by both graphics and audio drivers, then
> > communicate through it, something like vga_switcheroo.
> >
> >
> >
> > Is it okay to create this kernel object in i915 driver?
> >
> >
> >
> > I915 can export an API like "display_register_audio_client" for audio
> > driver to register a client and hot-plug notification ops.
> >
> >
> >
> > I915 can also call some API like "display_register_gfx_client" itself
> > and register ops for audio driver to query monitor presence and ELD
> > info on a specific port.
> >
> > It would be faster for audio driver than quering ELD by
> > command/response over the HD-A bus, thus avoid delay in i915 mode
> set.
> >
> > This will also avoid waking up the audio devices unnecessarily if the
> > user space does not really want to use HDMI/DP for audio playback.
> >
> >
> >
> > Whenever i195 enables/disables audio on a port in modeset, it can call
> > some API like "display_set_audio_state()" on this kernel object and
> > trigger notifications to the audio driver.
> >
> >
> >
> > When the audio driver is probed (in the delayed probe stage), it can
> > request
> > i915 API symbol to register the audio client for this communication
> > kernel object.
> >
> > Since the 1st i915 mode set may happen before audio driver registers
> > the ops, we'll let audio driver check ELD once after registering the
> > audio client ops.
> >
> > And for the platforms which uses this communication interface, we can
> > disable unsolicited event for HDMI/DP hot-plug in the audio driver.
> >
> >
> >
> > We hope to hear your feedback and start to work out more details.

Thanks for your advice, Daniel!

> Yeah, I've discussed this at KS with Takashi and we've agreed that some
> common object to facilitate driver interactions. A few things
> though:
> - This should be common infrastructure useable by all alsa and drm
> drivers, not just i915 and snd-hda. Especially on embedded platforms this
> issue is fairly rampant ...

Agree. Where to put this common object? 
Is it okay to put it under /driver/gpu/drm, similar to vga_switchroo?
Shall we divide clients into audio and gfx categories, and define different ops 
for them? Since different info/request flow in different direction between 
audio and gfx.

> - While at it it should also encompass power management handling of the
> shared hw imo so that we can get rid of the hsw specific hacks for the
> power well code. Or at least we need to rework the power well code to
> reuse this new infrastructure, I don't really want to maintain a few copies
> of the lazy symbol_get logic this kind of stuff requires.

Sounds good.

> - I think the biggest problem is figuring out who should register these
> device nodes. I think it makes the most sense if we do this in the gfx driver,
> but that requires some trickery on the alsa side (probably with using
> -EPROBE_DEFER or something like that.

Can the new infrastructure allow audio driver to query whether gfx driver is 
ready?
Maybe audio can wait until gfx is ready. For HD-Audio driver, the most time 
consuming part is delayed after the probe stage, and actually we can wait in 
the delayed phase.

> - I agree that passing ELD and all the other information through this new
> structure makes lot more sense than the current mess we have with
> passing the ELD through some hardware 

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #12 from Marek Ol??k  ---
You have probably set R600_DEBUG=nohyperz globally and that's why it's disabled
if you don't set R600_DEBUG.

-- 
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/20140122/10b7b013/attachment.html>

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #11 from Arek Ru?niak  ---
I have almost forgotten about it. Sanctuary/heaven at latest git (mesa
git-6caf34b, llvm svn-199712) all these artifacts are gone. I don't know
who/where/when/how but i thint it's not real fix. 
It looks like hyperz is off by default. When i run sanctuary/heaven with
R600_DEBUG=whatever_you_want_except_nohyperz artifacts goes back and
performance goes high. I'll try not-involved apps like xonotic or lightsmark or
unigine-valley later.

-- 
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/20140122/d08214d4/attachment-0001.html>

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

op 22-01-14 11:27, Thomas Hellstrom schreef:
> On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
>> op 22-01-14 10:40, Thomas Hellstrom schreef:
>>> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
 op 21-01-14 18:44, Thomas Hellstrom schreef:
> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 21-01-14 16:17, Thomas Hellstrom schreef:
>>> Maarten, for this and the other patches in this series,
>>>
>>> I seem to recall we have this discussion before?
>>> IIRC I stated that reservation was a too heavy-weight lock to
>>> hold to
>>> determine whether a buffer was idle? It's a pretty nasty thing to
>>> build in.
>>>
>> I've sent this patch after determining that this already didn't
>> end up
>> being heavyweight.
>> Most places were already using the fence_lock and reservation, I just
>> fixed up the few
>> places that didn't hold a reservation while waiting. Converting the
>> few places that didn't
>> ended up being trivial, so I thought I'd submit it.
> Actually the only *valid* reason for holding a reservation when
> waiting
> for idle is
> 1) You want to block further command submission on the buffer.
> 2) You want to switch GPU engine and don't have access to gpu
> semaphores
> / barriers.
>
> Reservation has the nasty side effect that it blocks command
> submission
> and pins the buffer (in addition now makes the evict list traversals
> skip the buffer) which in general is *not* necessary for most wait
> cases, so we should instead actually convert the wait cases that don't
> fulfill 1) and 2) above in the other direction if we have performance
> and latency-reduction in mind. I can't see how a spinlock protecting a
> fence pointer or fence list is stopping you from using RW fences as
> long
> as the spinlock is held while manipulating the fence list?
>
 You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
 patchset, though) and enumerate if they can be changed to work without
 reservation or not.

 ttm/ttm_bo.c
 ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
 finish for the direct destroy fastpath, if either fails it needs to be
 queued. Cannot work without reservation.
>>> Doesn't block and no significant reservation contention expected.
>>>
 ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
 doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
 re-reserve is enough.
>>> Currently follows the above rules.
>>>
 ttm_bo_evict: already has the reservation, cannot be dropped since
 only trylock is allowed. Dropping reservation would cause badness,
 cannot be converted.
>>> Follows rule 2 above. We're about to move the buffer and if that can't
>>> be pipelined using the GPU (which TTM currently doesn't allow), we need
>>> to wait. Although eviction should be low priority compared to new
>>> command submission, so I can't really see why we couldn't wait before
>>> trying to reserve here?
>>>
 ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
 reservation for same reason as ttm_bo_evict. It might be part of a
 ticketed reservation so really don't drop lock here.
>>> Part of command submission and as such follows rule 2 above. If we can
>>> pipeline the move with the GPU, no need to wait (but needs to be
>>> implemented, of course).
>>>
 ttm_bo_synccpu_write_grab: the wait could be converted to be done
 afterwards, without  fence_lock. But in this case reservation could
 take the role of fence_lock too,

 so no separate fence_lock would be needed.
>>> With the exception that reservation is more likely to be contended.
>> True but rule 1.
 ttm_bo_swapout: see ttm_bo_evict.

 ttm/ttm_bo_util.c:
 ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
 ttm_bo_move_buffer, can be called from that function.
>>> Rule 2.
>>>
 ttm/ttm_bo_vm.c
 ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here, but
 you already had the reservation, so a similar optimization to
 ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
 If you would write it like that, you would end up with a patch similar
 to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I think
 we should do this, an

 Ok, so the core does NOT need fence_lock because we can never drop
 reservations except in synccpu_write_grab and maybe
 ttm_bo_vm_fault_idle, but even in those cases reservation is done. So
 that could be used instead of fence_lock.

 nouveau_gem_ioctl_cpu_prep:
 Either block on a global spinlock or a local reservation lock. Doesn't
 matter much which, I don't need the need to keep a global lock for
 this function...
 2 cases can happen in the trylock reservation failure 

[alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus

[Jean-Francois Moine]

On Wed, 22 Jan 2014 11:19:53 +0100
Jean-Francois Moine  wrote:

> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
> I wrote a tda998x CODEC which gets the audio ports from the DT and
> dynamically sets these ports and the audio type (i2s / spdif) on audio
> streaming start. I have not submitted yet this codec and the associated
> changes in tda998x, because I am waiting for a first patch series on the
> tda998x to be applied
> (http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).

Sorry, the last patch request is

http://lists.freedesktop.org/archives/dri-devel/2014-January/052201.html

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH v2] backlight: turn backlight on/off when necessary

[Jani Nikula]

On Mon, 20 Jan 2014, Liu Ying  wrote:
> We don't have to turn backlight on/off everytime a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers. We
> don't hope blanking one of the framebuffers may turn the
> backlight off for all the other framebuffers, since they are
> likely being active to display something. This patch adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight should be turned on or off. To be more specific,
> only one unblank operation on a certain blanked framebuffer
> may increase the backlight device's use count by one, while
> one blank operation on a certain unblanked framebuffer may
> decrease the use count by one, because the userspace is
> likely to unblank a unblanked framebuffer or blank a blanked
> framebuffer.
>
> Signed-off-by: Liu Ying 
> ---
> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>
> v1->v2:
> * Make the commit message be more specific about the condition
>   in which backlight device use count can be increased/decreased.
> * Correct the setting for bd->props.fb_blank.
>
>  drivers/video/backlight/backlight.c |   28 +---
>  include/linux/backlight.h   |6 ++
>  2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index 5d0..42044be 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
>  defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
>  /* This callback gets called when something important happens inside a
>   * framebuffer driver. We're looking if that important event is blanking,
> - * and if it is, we're switching backlight power as well ...
> + * and if it is and necessary, we're switching backlight power as well ...
>   */
>  static int fb_notifier_callback(struct notifier_block *self,
>   unsigned long event, void *data)
>  {
>   struct backlight_device *bd;
>   struct fb_event *evdata = data;
> + int node = evdata->info->node;
> + int fb_blank = 0;
>  
>   /* If we aren't interested in this event, skip it immediately ... */
>   if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block 
> *self,
>   if (bd->ops)
>   if (!bd->ops->check_fb ||
>   bd->ops->check_fb(bd, evdata->info)) {
> - bd->props.fb_blank = *(int *)evdata->data;
> - if (bd->props.fb_blank == FB_BLANK_UNBLANK)
> - bd->props.state &= ~BL_CORE_FBBLANK;
> - else
> - bd->props.state |= BL_CORE_FBBLANK;
> - backlight_update_status(bd);
> + fb_blank = *(int *)evdata->data;
> + if (fb_blank == FB_BLANK_UNBLANK &&
> + !bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = true;
> + if (!bd->use_count++) {
> + bd->props.state &= ~BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_UNBLANK;
> + backlight_update_status(bd);
> + }
> + } else if (fb_blank != FB_BLANK_UNBLANK &&
> +bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = false;
> + if (!(--bd->use_count)) {
> + bd->props.state |= BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> + backlight_update_status(bd);
> + }
> + }

Anything backlight worries me a little, and there are actually three
changes bundled into one patch here:

1. Changing bd->props.state and bd->props.fb_blank only when use_count
   changes from 0->1 or 1->0.

2. Calling backlight_update_status() only with the above change, and not
   on all notifier callbacks.

3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
   FB_BLANK_POWERDOWN instead of *(int *)evdata->data.

The rationale in the commit message seems plausible, and AFAICT the code
does what it says on the box, so for that (and for that alone) you can
have my

Reviewed-by: Jani Nikula 

*BUT* it would be laborous to figure out whether this change in
behaviour might regress some drivers. I'm just punting on that. And that
brings us back to the three changes above - in a bisect POV it might be
helpful to split the 

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Thomas Hellstrom]

On 01/22/2014 10:55 AM, Maarten Lankhorst wrote:
> op 22-01-14 10:40, Thomas Hellstrom schreef:
>> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
>>> op 21-01-14 18:44, Thomas Hellstrom schreef:
 On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 21-01-14 16:17, Thomas Hellstrom schreef:
>> Maarten, for this and the other patches in this series,
>>
>> I seem to recall we have this discussion before?
>> IIRC I stated that reservation was a too heavy-weight lock to
>> hold to
>> determine whether a buffer was idle? It's a pretty nasty thing to
>> build in.
>>
> I've sent this patch after determining that this already didn't
> end up
> being heavyweight.
> Most places were already using the fence_lock and reservation, I just
> fixed up the few
> places that didn't hold a reservation while waiting. Converting the
> few places that didn't
> ended up being trivial, so I thought I'd submit it.
 Actually the only *valid* reason for holding a reservation when
 waiting
 for idle is
 1) You want to block further command submission on the buffer.
 2) You want to switch GPU engine and don't have access to gpu
 semaphores
 / barriers.

 Reservation has the nasty side effect that it blocks command
 submission
 and pins the buffer (in addition now makes the evict list traversals
 skip the buffer) which in general is *not* necessary for most wait
 cases, so we should instead actually convert the wait cases that don't
 fulfill 1) and 2) above in the other direction if we have performance
 and latency-reduction in mind. I can't see how a spinlock protecting a
 fence pointer or fence list is stopping you from using RW fences as
 long
 as the spinlock is held while manipulating the fence list?

>>> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
>>> patchset, though) and enumerate if they can be changed to work without
>>> reservation or not.
>>>
>>> ttm/ttm_bo.c
>>> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
>>> finish for the direct destroy fastpath, if either fails it needs to be
>>> queued. Cannot work without reservation.
>> Doesn't block and no significant reservation contention expected.
>>
>>> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
>>> doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
>>> re-reserve is enough.
>> Currently follows the above rules.
>>
>>> ttm_bo_evict: already has the reservation, cannot be dropped since
>>> only trylock is allowed. Dropping reservation would cause badness,
>>> cannot be converted.
>> Follows rule 2 above. We're about to move the buffer and if that can't
>> be pipelined using the GPU (which TTM currently doesn't allow), we need
>> to wait. Although eviction should be low priority compared to new
>> command submission, so I can't really see why we couldn't wait before
>> trying to reserve here?
>>
>>> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
>>> reservation for same reason as ttm_bo_evict. It might be part of a
>>> ticketed reservation so really don't drop lock here.
>> Part of command submission and as such follows rule 2 above. If we can
>> pipeline the move with the GPU, no need to wait (but needs to be
>> implemented, of course).
>>
>>> ttm_bo_synccpu_write_grab: the wait could be converted to be done
>>> afterwards, without  fence_lock. But in this case reservation could
>>> take the role of fence_lock too,
>>>
>>> so no separate fence_lock would be needed.
>> With the exception that reservation is more likely to be contended.
> True but rule 1.
>>> ttm_bo_swapout: see ttm_bo_evict.
>>>
>>> ttm/ttm_bo_util.c:
>>> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
>>> ttm_bo_move_buffer, can be called from that function.
>> Rule 2.
>>
>>> ttm/ttm_bo_vm.c
>>> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here, but
>>> you already had the reservation, so a similar optimization to
>>> ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
>>> If you would write it like that, you would end up with a patch similar
>>> to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I think
>>> we should do this, an
>>>
>>> Ok, so the core does NOT need fence_lock because we can never drop
>>> reservations except in synccpu_write_grab and maybe
>>> ttm_bo_vm_fault_idle, but even in those cases reservation is done. So
>>> that could be used instead of fence_lock.
>>>
>>> nouveau_gem_ioctl_cpu_prep:
>>> Either block on a global spinlock or a local reservation lock. Doesn't
>>> matter much which, I don't need the need to keep a global lock for
>>> this function...
>>> 2 cases can happen in the trylock reservation failure case: buffer is
>>> not reserved, so it's not in the process of being evicted. buffer is
>>> reserved, which means it's being used in command submission 

[alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus

[Jyri Sarha]

On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> On Wed, 15 Jan 2014 13:27:21 +0200
> Jyri Sarha  wrote:
>
>>   From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
>> register statically to a value that works only with 4 byte samples.
>> According to my tests it is possible to support 3 and 2 byte samples too
>> by changing the CTS_N register value, but I am not sure if the
>> configuration can be changed on the fly. My data sheet of the nxp chip
>> is very vague about the register definitions, but I suppose the register
>> configures some clock divider on the chip. HDMI supports only upto 24bit
>> audio and the data sheet states that any extraneous least significant
>> bits are ignored.
>
> In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> not set).
>
> Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> formats are working well with I2S input at any rate.
>

Could you refer the kernel version (main line?) and the involved ASoC 
drivers so could take I a look if there is something I could do differently?

Best regards,
Jyri

[alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus

[Jean-Francois Moine]

On Wed, 22 Jan 2014 11:20:32 +0200
Jyri Sarha  wrote:

> On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> > On Wed, 15 Jan 2014 13:27:21 +0200
> > Jyri Sarha  wrote:
> >
> >>   From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> >> register statically to a value that works only with 4 byte samples.
> >> According to my tests it is possible to support 3 and 2 byte samples too
> >> by changing the CTS_N register value, but I am not sure if the
> >> configuration can be changed on the fly. My data sheet of the nxp chip
> >> is very vague about the register definitions, but I suppose the register
> >> configures some clock divider on the chip. HDMI supports only upto 24bit
> >> audio and the data sheet states that any extraneous least significant
> >> bits are ignored.
> >
> > In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> > not set).
> >
> > Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> > formats are working well with I2S input at any rate.
> >
> 
> Could you refer the kernel version (main line?) and the involved ASoC 
> drivers so could take I a look if there is something I could do differently?

Both drivers are in the kernel main line.

The ASoC is in sound/soc/kirkwood/. kirkwood-i2s.c defines the DAIs I2S
and S/PDIF outputs.

As both I2S and S/PDIF may be used for HDMI output in the Cubox,
I wrote a tda998x CODEC which gets the audio ports from the DT and
dynamically sets these ports and the audio type (i2s / spdif) on audio
streaming start. I have not submitted yet this codec and the associated
changes in tda998x, because I am waiting for a first patch series on the
tda998x to be applied
(http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH 3/6] drm/radeon: Use new drm debugfs file helper

[Christian König]

Am 21.01.2014 21:33, schrieb Ben Widawsky:
> The debugfs helper duplicates the functionality used by Armada, so let's
> just use that.
>
> WARNING: only compile tested
>
> Cc: Christian K?nig 
> Signed-off-by: Ben Widawsky 
> ---
>   drivers/gpu/drm/radeon/radeon.h |  5 -
>   drivers/gpu/drm/radeon/radeon_ttm.c | 43 
> ++---
>   2 files changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index c5519ca..ceec468 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -418,11 +418,6 @@ struct radeon_mman {
>   struct ttm_bo_devicebdev;
>   boolmem_global_referenced;
>   boolinitialized;
> -
> -#if defined(CONFIG_DEBUG_FS)
> - struct dentry   *vram;
> - struct dentry   *gtt;
> -#endif
>   };
>   
>   /* bo virtual address in a specific vm */
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 77f5b0c..cf7caf2 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -971,27 +971,34 @@ static const struct file_operations radeon_ttm_gtt_fops 
> = {
>   .llseek = default_llseek
>   };
>   
> +static const struct radeon_debugfs_files {
> + const char *name;
> + const struct file_operations *fops;
> +} radeon_debugfs_files[] = {
> + {"radeon_vram", _ttm_vram_fops},
> + {"radeon_gtt", _ttm_gtt_fops},
> +};
>   #endif
>   
>   static int radeon_ttm_debugfs_init(struct radeon_device *rdev)
>   {
>   #if defined(CONFIG_DEBUG_FS)
>   unsigned count;
> + int i, ret;
>   
>   struct drm_minor *minor = rdev->ddev->primary;
> - struct dentry *ent, *root = minor->debugfs_root;
> -
> - ent = debugfs_create_file("radeon_vram", S_IFREG | S_IRUGO, root,
> -   rdev, _ttm_vram_fops);
> - if (IS_ERR(ent))
> - return PTR_ERR(ent);
> - rdev->mman.vram = ent;
> -
> - ent = debugfs_create_file("radeon_gtt", S_IFREG | S_IRUGO, root,
> -   rdev, _ttm_gtt_fops);
> - if (IS_ERR(ent))
> - return PTR_ERR(ent);
> - rdev->mman.gtt = ent;
> + struct dentry *root = minor->debugfs_root;
> +
> + for (i = 0; i < ARRAY_SIZE(radeon_debugfs_files); i++) {
> + ret = drm_debugfs_create_file(root, minor,
> +   radeon_debugfs_files[i].name,
> +   radeon_debugfs_files[i].fops,
> +   S_IFREG | S_IWUSR);
> + if (ret) {
> + radeon_ttm_debugfs_fini(rdev);
> + return ret;
> + }
> + }
>   
>   count = ARRAY_SIZE(radeon_ttm_debugfs_list);
>   
> @@ -1010,11 +1017,13 @@ static int radeon_ttm_debugfs_init(struct 
> radeon_device *rdev)
>   static void radeon_ttm_debugfs_fini(struct radeon_device *rdev)
>   {
>   #if defined(CONFIG_DEBUG_FS)
> + int i;
>   
> - debugfs_remove(rdev->mman.vram);
> - rdev->mman.vram = NULL;
> + for (i = 0; i < ARRAY_SIZE(radeon_debugfs_files); i++) {
> + struct drm_info_list *info_list =
> + (struct drm_info_list *)_debugfs_files[i];
>   
> - debugfs_remove(rdev->mman.gtt);
> - rdev->mman.gtt = NULL;
> + drm_debugfs_remove_files(info_list, 1, rdev->ddev->primary);

This won't work correctly because info_ent doesn't contain this pointer 
but a pointer to the fops instead. Additional to that the fops might not 
be unique (you can use the same fops for different files) so they are 
probably not such a good choice as the key.

On the other hand why do the drm layer want to do this bookkeeping of 
all the created files in the first place? We could just use 
debugfs_remove_recursive instead and don't need to mess with this at all.

Regards,
Christian.

> + }
>   #endif
>   }

linux-next: manual merge of the drm-intel tree with the drm tree

[Daniel Vetter]

Hi Stephen,

On Wed, Jan 22, 2014 at 4:04 AM, Stephen Rothwell  
wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_irq.c between commit abca9e454498 ("drm: Pass
> 'flags' from the caller to .get_scanout_position()") from the drm tree
> and commit d59a63ad8234 ("drm/i915: Add intel_get_crtc_scanline()") from
> the drm-intel tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

Oops, this patch escaped - it's only for 3.15. I've shuffled my
branches around now for the merge window so this should not pop up in
your -next tree again until 3.15 starts.

Yours, Daniel

>
> --
> Cheers,
> Stephen Rothwellsfr at canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/i915_irq.c
> index 17d8fcb1b6f7,ffb56a9db9cc..
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@@ -649,8 -675,9 +649,9 @@@ static bool ilk_pipe_in_vblank_locked(s
>   }
>
>   static int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe,
>  -  int *vpos, int *hpos,
>  +  unsigned int flags, int *vpos, int *hpos,
> -   ktime_t *stime, ktime_t *etime)
> +   ktime_t *stime, ktime_t *etime,
> +   bool adjust)
>   {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> @@@ -788,6 -786,24 +791,24 @@@
> return ret;
>   }
>
> + static int i915_get_scanout_position(struct drm_device *dev, int pipe,
> +int *vpos, int *hpos,
> +ktime_t *stime, ktime_t *etime)
> + {
>  -  return i915_get_crtc_scanoutpos(dev, pipe, vpos, hpos,
> ++  return i915_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> +   stime, etime, true);
> + }
> +
> + int intel_get_crtc_scanline(struct drm_crtc *crtc)
> + {
> +   int vpos = 0, hpos = 0;
> +
>  -  i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe,
> ++  i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe, 0,
> +, , NULL, NULL, false);
> +
> +   return vpos;
> + }
> +
>   static int i915_get_vblank_timestamp(struct drm_device *dev, int pipe,
>   int *max_error,
>   struct timeval *vblank_time,



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

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

op 22-01-14 10:40, Thomas Hellstrom schreef:
> On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
>> op 21-01-14 18:44, Thomas Hellstrom schreef:
>>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
 Hey,

 op 21-01-14 16:17, Thomas Hellstrom schreef:
> Maarten, for this and the other patches in this series,
>
> I seem to recall we have this discussion before?
> IIRC I stated that reservation was a too heavy-weight lock to hold to
> determine whether a buffer was idle? It's a pretty nasty thing to
> build in.
>
 I've sent this patch after determining that this already didn't end up
 being heavyweight.
 Most places were already using the fence_lock and reservation, I just
 fixed up the few
 places that didn't hold a reservation while waiting. Converting the
 few places that didn't
 ended up being trivial, so I thought I'd submit it.
>>> Actually the only *valid* reason for holding a reservation when waiting
>>> for idle is
>>> 1) You want to block further command submission on the buffer.
>>> 2) You want to switch GPU engine and don't have access to gpu semaphores
>>> / barriers.
>>>
>>> Reservation has the nasty side effect that it blocks command submission
>>> and pins the buffer (in addition now makes the evict list traversals
>>> skip the buffer) which in general is *not* necessary for most wait
>>> cases, so we should instead actually convert the wait cases that don't
>>> fulfill 1) and 2) above in the other direction if we have performance
>>> and latency-reduction in mind. I can't see how a spinlock protecting a
>>> fence pointer or fence list is stopping you from using RW fences as long
>>> as the spinlock is held while manipulating the fence list?
>>>
>> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
>> patchset, though) and enumerate if they can be changed to work without
>> reservation or not.
>>
>> ttm/ttm_bo.c
>> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
>> finish for the direct destroy fastpath, if either fails it needs to be
>> queued. Cannot work without reservation.
> Doesn't block and no significant reservation contention expected.
>
>> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
>> doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
>> re-reserve is enough.
> Currently follows the above rules.
>
>> ttm_bo_evict: already has the reservation, cannot be dropped since
>> only trylock is allowed. Dropping reservation would cause badness,
>> cannot be converted.
> Follows rule 2 above. We're about to move the buffer and if that can't
> be pipelined using the GPU (which TTM currently doesn't allow), we need
> to wait. Although eviction should be low priority compared to new
> command submission, so I can't really see why we couldn't wait before
> trying to reserve here?
>
>> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
>> reservation for same reason as ttm_bo_evict. It might be part of a
>> ticketed reservation so really don't drop lock here.
> Part of command submission and as such follows rule 2 above. If we can
> pipeline the move with the GPU, no need to wait (but needs to be
> implemented, of course).
>
>> ttm_bo_synccpu_write_grab: the wait could be converted to be done
>> afterwards, without  fence_lock. But in this case reservation could
>> take the role of fence_lock too,
>>
>> so no separate fence_lock would be needed.
> With the exception that reservation is more likely to be contended.
True but rule 1.
>> ttm_bo_swapout: see ttm_bo_evict.
>>
>> ttm/ttm_bo_util.c:
>> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
>> ttm_bo_move_buffer, can be called from that function.
> Rule 2.
>
>> ttm/ttm_bo_vm.c
>> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here, but
>> you already had the reservation, so a similar optimization to
>> ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
>> If you would write it like that, you would end up with a patch similar
>> to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I think
>> we should do this, an
>>
>> Ok, so the core does NOT need fence_lock because we can never drop
>> reservations except in synccpu_write_grab and maybe
>> ttm_bo_vm_fault_idle, but even in those cases reservation is done. So
>> that could be used instead of fence_lock.
>>
>> nouveau_gem_ioctl_cpu_prep:
>> Either block on a global spinlock or a local reservation lock. Doesn't
>> matter much which, I don't need the need to keep a global lock for
>> this function...
>> 2 cases can happen in the trylock reservation failure case: buffer is
>> not reserved, so it's not in the process of being evicted. buffer is
>> reserved, which means it's being used in command submission right now,
>> or in one of the functions described above (eg not idle).
>>
>> nouveau_gem_pushbuf_reloc_apply:
>> has to call ttm_bo_wait with reservation, cannot be dropped.
>>
>> So for 

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Rob Clark]

On Wed, Jan 22, 2014 at 10:20 AM, Daniel Vetter  wrote:
> On Wed, Jan 22, 2014 at 10:04:14AM -0500, Rob Clark wrote:
>> sorry to jump into this a bit late, so maybe this was covered already 
>> earlier..
>
> It just started, I've quoted everything when cc'ing dri-devel. But good to
> have examples outside of x86 (where things are mostly standardized by the
> Eye of Redmond).

perhaps the arm/SoC stuff was standardized by the Eye of Cthulhu

btw, added a few other SoC drm types who might be interested in the topic

>> For drm/msm the hdmi code needs something along these lines from audio:
>>
>> int hdmi_audio_info_setup(struct platform_device *pdev, bool enabled,
>> uint32_t num_of_channels, uint32_t channel_allocation,
>> uint32_t level_shift, bool down_mix);
>> void hdmi_audio_set_sample_rate(struct platform_device *pdev, int rate);
>>
>> (former is mainly to setup avi audio infoframe, latter for clks)
>>
>> in addition to hotplug and ELD stuff
>
> Can you elaborate a bit on what you need for msm? On intel (and I think
> the other x86 platforms are similar) we have separate buffers in the hw
> for avi infoframes and audio infoframes, so the drm and alsa driver can
> bash the right stuff into the hardware on their own. I'm mostly confused
> since you say _AVI_ infoframe here, which is purely generated by the drm
> side of the code here. Or at least that's been my understanding.

Sorry, typo, meant audio infoframe

We could have the API such that the audio driver constructs the
infoframe.. that probably makes more sense and simplifies things.  But
the drm driver is the one that needs to bash that constructed buffer
into the hw.  Or, well, either that or both drivers ioremap the same
block of registers, but that seems somewhat lame.

But I do need to know some basic things, like # of channels.. and
would kinda prefer not to have to parse the audio infoframe to get
that info.

> The clocks are also funny really, but I'm not sure whether this fits. I'd
> have expected some DT-based generic clock source which the audio driver
> just grabs as part of his multi-device beast (maybe using Russell's new
> driver core code) and used directly. What's the reason that this has to go
> through the drm driverr?

possibly it could be exposed to the audio driver as a 'struct clk'
that is implemented/registered/exported by the drm driver, I guess?


fwiw, if curious, what I have on msm so far is at:

https://github.com/freedreno/kernel-msm/commit/6ffd278d39a3ff8712c70b5fd98dc135bd6c7b8a

It works on downstream qcom android kernel.. the API exported by drm
driver, called by audio driver, is basically just a clone of the hack
that was already there between fbdev and alsa.  I haven't tried to
clean that up at all yet.  It was enough work just untangling ION (!!)
from alsa in that kernel :-/

BR,
-R

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

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Thomas Hellstrom]

On 01/22/2014 09:19 AM, Maarten Lankhorst wrote:
> op 21-01-14 18:44, Thomas Hellstrom schreef:
>> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> op 21-01-14 16:17, Thomas Hellstrom schreef:
 Maarten, for this and the other patches in this series,

 I seem to recall we have this discussion before?
 IIRC I stated that reservation was a too heavy-weight lock to hold to
 determine whether a buffer was idle? It's a pretty nasty thing to
 build in.

>>> I've sent this patch after determining that this already didn't end up
>>> being heavyweight.
>>> Most places were already using the fence_lock and reservation, I just
>>> fixed up the few
>>> places that didn't hold a reservation while waiting. Converting the
>>> few places that didn't
>>> ended up being trivial, so I thought I'd submit it.
>> Actually the only *valid* reason for holding a reservation when waiting
>> for idle is
>> 1) You want to block further command submission on the buffer.
>> 2) You want to switch GPU engine and don't have access to gpu semaphores
>> / barriers.
>>
>> Reservation has the nasty side effect that it blocks command submission
>> and pins the buffer (in addition now makes the evict list traversals
>> skip the buffer) which in general is *not* necessary for most wait
>> cases, so we should instead actually convert the wait cases that don't
>> fulfill 1) and 2) above in the other direction if we have performance
>> and latency-reduction in mind. I can't see how a spinlock protecting a
>> fence pointer or fence list is stopping you from using RW fences as long
>> as the spinlock is held while manipulating the fence list?
>>
> You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the
> patchset, though) and enumerate if they can be changed to work without
> reservation or not.
>
> ttm/ttm_bo.c
> ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to
> finish for the direct destroy fastpath, if either fails it needs to be
> queued. Cannot work without reservation.

Doesn't block and no significant reservation contention expected.

> ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait,
> doesn't need to re-acquire. Simply reordering ttm_bo_wait until after
> re-reserve is enough.

Currently follows the above rules.

> ttm_bo_evict: already has the reservation, cannot be dropped since
> only trylock is allowed. Dropping reservation would cause badness,
> cannot be converted.

Follows rule 2 above. We're about to move the buffer and if that can't
be pipelined using the GPU (which TTM currently doesn't allow), we need
to wait. Although eviction should be low priority compared to new
command submission, so I can't really see why we couldn't wait before
trying to reserve here?

>
> ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop
> reservation for same reason as ttm_bo_evict. It might be part of a
> ticketed reservation so really don't drop lock here.

Part of command submission and as such follows rule 2 above. If we can
pipeline the move with the GPU, no need to wait (but needs to be
implemented, of course).

>
> ttm_bo_synccpu_write_grab: the wait could be converted to be done
> afterwards, without  fence_lock. But in this case reservation could
> take the role of fence_lock too,
>
> so no separate fence_lock would be needed.

With the exception that reservation is more likely to be contended.

> ttm_bo_swapout: see ttm_bo_evict.
>
> ttm/ttm_bo_util.c:
> ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see
> ttm_bo_move_buffer, can be called from that function.

Rule 2.

>
> ttm/ttm_bo_vm.c
> ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here, but
> you already had the reservation, so a similar optimization to
> ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
> If you would write it like that, you would end up with a patch similar
> to drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I think
> we should do this, an
>
> Ok, so the core does NOT need fence_lock because we can never drop
> reservations except in synccpu_write_grab and maybe
> ttm_bo_vm_fault_idle, but even in those cases reservation is done. So
> that could be used instead of fence_lock.
>
> nouveau_gem_ioctl_cpu_prep:
> Either block on a global spinlock or a local reservation lock. Doesn't
> matter much which, I don't need the need to keep a global lock for
> this function...
> 2 cases can happen in the trylock reservation failure case: buffer is
> not reserved, so it's not in the process of being evicted. buffer is
> reserved, which means it's being used in command submission right now,
> or in one of the functions described above (eg not idle).
>
> nouveau_gem_pushbuf_reloc_apply:
> has to call ttm_bo_wait with reservation, cannot be dropped.
>
> So for core ttm and nouveau the fence_lock is never needed, radeon has
> only 1 function that calls ttm_bo_wait which uses a reservation too.
> It doesn't need the 

[GIT PULL v2] exynos-drm-next for 3.14

[Inki Dae]

Hi Dave,

   This second pull request just adds some fixup and cleanup patches.

   We are waiting for the next version of refactoring patch set but
   it seems that they wouldn't be posted this time.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit f5395ba35f2ae52eb5839f8046e4aeef6df7f357:

  Merge branch 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux into 
drm-next (2014-01-22 09:13:13 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-next

for you to fetch changes up to 1fa7a25c0d87f40a30756316bb80a9f7e6bd43c5:

  drm/exynos: Fix trivial typo (2014-01-22 09:53:31 +0900)


Sachin Kamat (3):
  drm/exynos: Fix freeing issues in exynos_drm_drv.c
  drm/exynos: Remove unnecessary semicolon
  drm/exynos: Fix trivial typo

Tushar Behera (1):
  drm/exynos: Fix multiplatform breakage for ipp/gsc

 drivers/gpu/drm/exynos/Kconfig  |4 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   14 --
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |3 +--
 4 files changed, 12 insertions(+), 11 deletions(-)

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Rob Clark]

On Wed, Jan 22, 2014 at 9:18 AM, Daniel Vetter  wrote:
> On Wed, Jan 22, 2014 at 12:48:04PM +, Lin, Mengdong wrote:
>> > -Original Message-
>> > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On 
>> > Behalf Of
>> > Daniel Vetter
>> > Sent: Tuesday, January 21, 2014 9:11 PM
>> > To: Lin, Mengdong
>> > Cc: Takashi Iwai (tiwai at suse.de); Barnes, Jesse; Zanoni, Paulo R;
>> > alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org
>> > Subject: Re: Need your advice: Add a new communication inteface
>> > between HD-Audio and Gfx drivers for hotplug notification/ELD update
>> >
>> > On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong 
>> > wrote:
>> > > Dear audio and gfx stakeholders,
>> > >
>> > >
>> > >
>> > > We hope to add a new interface between audio and gfx driver, for gfx
>> > > driver to notify audio about HDMI/DP hot-plug and ELD update.
>> > >
>> > > Would you please share some comments on the proposal below?
>> > >
>> > >
>> > >
>> > > Background of this issue: On Intel Haswell/Broadwell platforms, there
>> > > is a HW restriction that after the display HD-Audio controller is in
>> > > D3,
>> > >
>> > > it cannot be waken up by HDMI/DP hot-plug. Consequently, although the
>> > > gfx driver can still detect the HDMI/DP hot-plug,
>> > >
>> > > audio driver has no idea about this and cannot notify user space
>> > > whether the external HDMI/DP monitor is available for audio playback,
>> > >
>> > > because the audio controller cannot wake up to D0 and receive HW
>> > > unsolicited event about hot-plug from the audio codec.
>> > >
>> > > This limitation will affect user space to decide whether we can output
>> > > audio over HDMI/DP.
>> > >
>> > >
>> > >
>> > > To solve the above limitation, Takashi suggested to add a new
>> > > communication interface between audio and gfx driver: create a
>> > common
>> > > object
>> > >
>> > > containing the ops registered by both graphics and audio drivers, then
>> > > communicate through it, something like vga_switcheroo.
>> > >
>> > >
>> > >
>> > > Is it okay to create this kernel object in i915 driver?
>> > >
>> > >
>> > >
>> > > I915 can export an API like "display_register_audio_client" for audio
>> > > driver to register a client and hot-plug notification ops.
>> > >
>> > >
>> > >
>> > > I915 can also call some API like "display_register_gfx_client" itself
>> > > and register ops for audio driver to query monitor presence and ELD
>> > > info on a specific port.
>> > >
>> > > It would be faster for audio driver than quering ELD by
>> > > command/response over the HD-A bus, thus avoid delay in i915 mode
>> > set.
>> > >
>> > > This will also avoid waking up the audio devices unnecessarily if the
>> > > user space does not really want to use HDMI/DP for audio playback.
>> > >
>> > >
>> > >
>> > > Whenever i195 enables/disables audio on a port in modeset, it can call
>> > > some API like "display_set_audio_state()" on this kernel object and
>> > > trigger notifications to the audio driver.
>> > >
>> > >
>> > >
>> > > When the audio driver is probed (in the delayed probe stage), it can
>> > > request
>> > > i915 API symbol to register the audio client for this communication
>> > > kernel object.
>> > >
>> > > Since the 1st i915 mode set may happen before audio driver registers
>> > > the ops, we'll let audio driver check ELD once after registering the
>> > > audio client ops.
>> > >
>> > > And for the platforms which uses this communication interface, we can
>> > > disable unsolicited event for HDMI/DP hot-plug in the audio driver.
>> > >
>> > >
>> > >
>> > > We hope to hear your feedback and start to work out more details.
>>
>> Thanks for your advice, Daniel!
>>
>> > Yeah, I've discussed this at KS with Takashi and we've agreed that some
>> > common object to facilitate driver interactions. A few things
>> > though:
>> > - This should be common infrastructure useable by all alsa and drm
>> > drivers, not just i915 and snd-hda. Especially on embedded platforms this
>> > issue is fairly rampant ...
>>
>> Agree. Where to put this common object?
>> Is it okay to put it under /driver/gpu/drm, similar to vga_switchroo?
>> Shall we divide clients into audio and gfx categories, and define
>> different ops for them? Since different info/request flow in different
>> direction between audio and gfx.
>
> I guess we could place them into drivers/gpu, yeah. For a name I'd suggest
> avsink or something like that, to make it clear that it's the combination
> of audio+video. For the actual interfaces I guess we just need one object
> in the device model, but the interface should be split into things called
> from the audio side only, functions for the video driver side only and
> stuff which can be called from both sides. This matters mostly just so we
> don't end up with deadlocks since we need a lock to protect the avsink
> state itself (e.g. the EDL or the audio_output_connected state).

sorry to jump into this a bit late, so maybe this 

[PATCH v3] ACPI / video: Add systems that should favor native backlight interface

[Aaron Lu]

On 01/21/2014 08:11 PM, Matthew Garrett wrote:
> On Tue, 2014-01-21 at 13:32 +0800, Aaron Lu wrote:
>> On 01/21/2014 11:17 AM, Matthew Garrett wrote:
>>> We know that Windows 8 graphics drivers don't use the ACPI interface,
>>> and that systems change their behaviour as a result, in some cases with
>>> absolutely no way for the ACPI interface could possibly work. I haven't
>>> seen any cases where that's obviously true for any non-Windows 8
>>
>> Perhaps I'm not clear, I didn't mean non-Windows 8 systems will all favor
>> GPU's interface, I just meant for one specific win7 laptop I could re-use
>> the existing code to make the GPU's interface as the only one left. And to
>> achieve this, the Win8 OSI check in acpi_video_verify_backlight_support
>> has to be gone.
> 
> We could do that, but why do we think that's the correct fix? The plan
> is to remove the native list entirely and do this for all Windows 8

What do you mean by native list, systems that are Win8 based but don't
work with the GPU's backlight interface?
If so, it doesn't seem we have such a native list now and if we don't
make use_native_backlight=1 by default, we couldn't generate such a
list to start with...

BTW, it doesn't seem everyone agrees with this plan. May I ask, Rafael
and Daniel, what's your opinion please? We need to agree with something
to move things forward.

[patch 1/3] drm/fb-helper: don't sleep for screen unblank when an oops is in progress

[Daniel Vetter]

On Tue, Jan 21, 2014 at 11:34 PM,   wrote:
> From: Daniel Vetter 
> Subject: drm/fb-helper: don't sleep for screen unblank when an oops is in 
> progress
>
> Otherwise the system will burn even brighter and worse, leave the user
> wondering what's going on exactly.
>
> Since we already have a panic handler which will (try) to restore the
> entire fbdev console mode, we can just bail out.  Inspired by a patch from
> Konstantin Khlebnikov.  The callchain leading to this, cut from
> Konstantin's original patch:
>
> callstack:
> panic()
> bust_spinlocks(1)
> unblank_screen()
> vc->vc_sw->con_blank()
> fbcon_blank()
> fb_blank()
> info->fbops->fb_blank()
> drm_fb_helper_blank()
> drm_fb_helper_dpms()
> drm_modeset_lock_all()
> mutex_lock(>mode_config.mutex)
>
> Note that the entire locking in the fb helper around panic/sysrq and kdbg
> is ...  non-existant.  So we have a decent change of blowing up
> everything.  But since reworking this ties in with funny concepts like the
> fbdev notifier chain or the impressive things which happen around
> console_lock while oopsing, I'll leave that as an exercise for braver
> souls than me.
>
> Signed-off-by: Daniel Vetter 
> Cc: Konstantin Khlebnikov 
> Cc: Dave Airlie 
> Reviewed-by: Rob Clark 
> Signed-off-by: Andrew Morton 

We've merged this twic already in 1b1d5397058f06b and
928c2f0c006bf7f381f58 and then had to take out the superflous hunk
again in ecc7e6f3bb8ad56764

For some oddball reason git/patch _really_ gets confused here and
loves to readd that hunk a few more times (iirc one of my own trees
once even ended up with 3 copies ...). No idea what's going on, but we
can drop this on here ;-)

Or what exactly was the point of this patch submission, I didn't spot
a "dropped from -mm" or similar note, and it doesn't seem to be cc'ed
to lists.

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

[PATCH 2/5] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

[Maarten Lankhorst]

op 21-01-14 18:44, Thomas Hellstrom schreef:
> On 01/21/2014 04:29 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 21-01-14 16:17, Thomas Hellstrom schreef:
>>> Maarten, for this and the other patches in this series,
>>>
>>> I seem to recall we have this discussion before?
>>> IIRC I stated that reservation was a too heavy-weight lock to hold to
>>> determine whether a buffer was idle? It's a pretty nasty thing to
>>> build in.
>>>
>> I've sent this patch after determining that this already didn't end up
>> being heavyweight.
>> Most places were already using the fence_lock and reservation, I just
>> fixed up the few
>> places that didn't hold a reservation while waiting. Converting the
>> few places that didn't
>> ended up being trivial, so I thought I'd submit it.
> Actually the only *valid* reason for holding a reservation when waiting
> for idle is
> 1) You want to block further command submission on the buffer.
> 2) You want to switch GPU engine and don't have access to gpu semaphores
> / barriers.
>
> Reservation has the nasty side effect that it blocks command submission
> and pins the buffer (in addition now makes the evict list traversals
> skip the buffer) which in general is *not* necessary for most wait
> cases, so we should instead actually convert the wait cases that don't
> fulfill 1) and 2) above in the other direction if we have performance
> and latency-reduction in mind. I can't see how a spinlock protecting a
> fence pointer or fence list is stopping you from using RW fences as long
> as the spinlock is held while manipulating the fence list?
>
You wish. Fine I'll enumerate all cases of ttm_bo_wait (with the patchset, 
though) and enumerate if they can be changed to work without reservation or not.

ttm/ttm_bo.c
ttm_bo_cleanup_refs_or_queue: needs reservation and ttm_bo_wait to finish for 
the direct destroy fastpath, if either fails it needs to be queued. Cannot work 
without reservation.
ttm_bo_cleanup_refs_and_unlock: already drops reservation to wait, doesn't need 
to re-acquire. Simply reordering ttm_bo_wait until after re-reserve is enough.
ttm_bo_evict: already has the reservation, cannot be dropped since only trylock 
is allowed. Dropping reservation would cause badness, cannot be converted.
ttm_bo_move_buffer: called from ttm_bo_validate, cannot drop reservation for 
same reason as ttm_bo_evict. It might be part of a ticketed reservation so 
really don't drop lock here.
ttm_bo_synccpu_write_grab: the wait could be converted to be done afterwards, 
without  fence_lock. But in this case reservation could take the role of 
fence_lock too,
so no separate fence_lock would be needed.
ttm_bo_swapout: see ttm_bo_evict.

ttm/ttm_bo_util.c:
ttm_bo_move_accel_cleanup: calls ttm_bo_wait, cannot drop lock, see 
ttm_bo_move_buffer, can be called from that function.

ttm/ttm_bo_vm.c
ttm_bo_vm_fault_idle: I guess you COULD drop the reservation here, but you 
already had the reservation, so a similar optimization to 
ttm_bo_synccpu_write_grab could be done without requiring fence_lock.
If you would write it like that, you would end up with a patch similar to 
drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep. I think we should 
do this, an

Ok, so the core does NOT need fence_lock because we can never drop reservations 
except in synccpu_write_grab and maybe ttm_bo_vm_fault_idle, but even in those 
cases reservation is done. So that could be used instead of fence_lock.

nouveau_gem_ioctl_cpu_prep:
Either block on a global spinlock or a local reservation lock. Doesn't matter 
much which, I don't need the need to keep a global lock for this function...
2 cases can happen in the trylock reservation failure case: buffer is not 
reserved, so it's not in the process of being evicted. buffer is reserved, 
which means it's being used in command submission right now, or in one of the 
functions described above (eg not idle).

nouveau_gem_pushbuf_reloc_apply:
has to call ttm_bo_wait with reservation, cannot be dropped.

So for core ttm and nouveau the fence_lock is never needed, radeon has only 1 
function that calls ttm_bo_wait which uses a reservation too. It doesn't need 
the fence_lock either.

~Maarten

[Bug 69196] gpu lockup and full crash when starting some games in wine

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

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

--- Comment #5 from Alexander Tsoy  ---
(In reply to comment #4)
> (In reply to comment #1)
> > Same issue when running Unigine Heaven 3.0 on Cape Verde PRO.
> 
> Please file your own report for that. Although the symptoms are similar, the
> cause may be different.

I just figured out that my issue is caused by dpm. If I disable dpm, Unigine
Heaven works fine (damn slow, but do not cause lockups). I'll recheck with a
newer kernel (>=3.13) and will file a new bug if the issue is reproducible with
it.

-- 
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/20140122/1f0f5174/attachment.html>

[Bug 69196] gpu lockup and full crash when starting some games in wine

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/radeonsi

--- Comment #4 from Michel D?nzer  ---
(In reply to comment #1)
> Same issue when running Unigine Heaven 3.0 on Cape Verde PRO.

Please file your own report for that. Although the symptoms are similar, the
cause may be different.

Both of you please also attach the /var/log/Xorg.0.log file.

BTW, in particular when running Wine, assuming you're running a 64-bit distro,
make sure the 32-bit Mesa stack is up to date as well.

-- 
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/20140122/608118e9/attachment.html>

[Bug 45290] [bisected r200] fdo23670-drawpix_stencil fails and crashes

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

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

Ian Romanick  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Romanick  ---
This test seems to work fine 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/20140122/d679319d/attachment.html>

[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash

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

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

--- Comment #21 from Hohahiu  ---
Created attachment 122971
  --> https://bugzilla.kernel.org/attachment.cgi?id=122971=edit
Xorg.0.log

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

[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash

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

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

--- Comment #20 from Hohahiu  ---
Created attachment 122961
  --> https://bugzilla.kernel.org/attachment.cgi?id=122961=edit
dmesg

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

[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash

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

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

Hohahiu  changed:

   What|Removed |Added

 CC||rakothedin at gmail.com

--- Comment #19 from Hohahiu  ---
I have similar trouble with vgaswitcheroo. My GPUs are Intel hd4000 + Amd
mobility radeon 7750M:
/sbin/lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Chelsea LP [Radeon HD 7730M] (rev ff)

If I don't set anything during the boot my dGPU is powered down successfully:
cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::00:02.0
1:DIS: :DynOff::01:00.0

But in the meantime:
xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x4a cap: 0xb, Source Output, Sink Output, Sink Offload crtcs:
4 outputs: 7 associated providers: 0 name:Intel

So I cannot access my discrete GPU.

If after the boot I use
xrandr --setprovideroffloadsink radeon Intel
then dGPU never switches off.

Truly speaking runpm never worked for me even with Alex's early patches.

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

[Bug 6009] libdri.so fails to load when built with '--disable-xinerama'

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

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

Ian Romanick  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Ian Romanick  ---
noPanoramXExtension doesn't appear in the code base any longer.  I don't think
this is an issue.

-- 
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/20140122/45ff6d3a/attachment-0001.html>