[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 23.06.2014 21:46, schrieb Dieter N?tzel:
> Am 23.06.2014 11:34, schrieb Michel D?nzer:
>> On 18.06.2014 18:14, Christian K?nig wrote:
>>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
 
 Looking into these issues has got me thinking about the use of the 
 page
 flip interrupt: If the page flip interrupt arrives before the
 corresponding
 vertical blank interrupt, the DRM vblank counter will be lower than
 expected by 1 in drm_send_vblank_event(). I suspect this is the 
 cause of
 
   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
 completion
 event has impossible msc [x-1] < target_msc [x]
 
 messages in the X log file which have been popping up in bug reports
 lately.
 This also results in 0s being returned to the client for the MSC and
 timestamp of the swap completion, which could cause all kinds of bad
 behaviour.
>>> First of all thanks for looking into it. Are you getting this on 3.16 
>>> or
>>> 3.15?
>> 
>> I haven't actually run into this myself yet. I thought I'd seen it in
>> several bug reports, but right now I can only find
>> https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems 
>> to
>> include the page flipping changes from 3.16.
> 
> With 3.16-rc2 I get it now on my RV730 AGP as in the above bug report.
> But only the lines in Xorg.0.log.
> NO signs of any damage/error in use.
> 
> Since 3.15 and 3.16 (rc2 only) my system is rock solid.
> 
> I've tried 3.15-rc7 + Christian's pflip rework (did some little 
> handwork), too.
> It was solid but I saw the reported flip/black distortion in the below
> part during Kwin 4.13 cube screen effect (rotation). Your fix for
> 3.16-rc1 fixed that.
> 
> Before 3.15/3.16-rcX I got some hangs from time to time during system 
> boot.
> Nothing in the logs but SSD RAID1 rebuild. Maybe it was MD related an
> NOT r600/DRM.
> 
> 3.16-rcX (3.15-rc7+pflip patches) seems to be more responsive that 
> 3.15, for me.
> 
> First and latest attchments from bug #80141
> https://bugs.freedesktop.org/attachment.cgi?id=101605
> show same.
> 
> Where should I add/send my Xorg.0.log?
> 
> Cheers,
>   Dieter

Addendum:

I can reliable generate such lines in Xorg.0.log with KWin cube desktop 
effect.

Rotate screens with mouse wheel or screen switcher => new entry in 
Xorg.0.log. If it happens I notice ('see') flip delay.

[  9893.183] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 594382 < target_msc 594383
[ 10859.753] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 652497 < target_msc 652498
[ 10915.719] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 655863 < target_msc 655864
[ 10916.817] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 655929 < target_msc 655930
[ 10925.843] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 656472 < target_msc 656473
[ 10926.774] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 656528 < target_msc 656529
[ 10965.519] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 658859 < target_msc 658860
[ 11081.878] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
completion event has impossible msc 665846 < target_msc 665847

>>> I don't think that the pflip irq is thrown earlier than the vblank, 
>>> but
>>> on 3.16 it might actually be that we program the flip so fast into 
>>> the
>>> hardware that we do it one frame earlier than planned.
>> 
>> So userspace is notified of the previous vertical blank period and 
>> calls
>> the page flip ioctl in response, which then manages to program the
>> scanout address update into the hardware before the scanout address
>> update is latched during the previous vertical blank period?
>> 
>> To avoid that scenario, one possibility might be to check if we're in
>> vertical blank before calling radeon_page_flip(), and if so sleep for
>> 1ms or so before trying again? That might unnecessarily delay flips on
>> other CRTCs though...
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

unparseable, undocumented /sys/class/drm/.../pstate

[Pavel Machek]

Hi!

> >> >> > I guess better interface would be something like
> >> >> >
> >> >> > pstate/07/core_clock_min
> >> >> >   core_clock_max
> >> >> >   memory_clock_min
> >> >> >   memory_clock_max
> >> >> >
> >> >> > and then pstate/active containing just the number of active state?
> >
> >> Could we just say that the format of this file is one-per-line of
> >>
> >> level: information-for-the-user
> >
> > But it is not.
> 
> But it is...
> 
> > Management tools will want to parse it, sooner or
> > later.  What is wrong with solution described above?
> 
> It is complex and annoying to the people that will actually use it.

grep -r . pstate/ is actually not that bad...

And yes, some kind of utility to select right performance level would
be nice in future... Or maybe not. Perhaps in not so distant future
kernel will use right performance level for given load...?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #74 from Konstantin  ---
First, sorry for being away so long.

(In reply to comment #69)
> First of all, let me remind both of you to make sure si_get_backend_mask()
> gets the information from the kernel, and to use my patch which disables
> tiling as much as possible for now.
Ok, but how do I make sure that si_get_backend_mask() gets information from the
kernel ?

(In reply to comment #69)
> Also, might be worth testing with R600_DEBUG=nodma for now, to prevent the
> userspace code from using the asynchronous DMA engine.
Will do that.

(In reply to comment #69)
> That's all it's supposed to do, FWIW. :)
I guessed as much :-) I actually was quite excited that it worked.

(In reply to comment #69)
> Does it work if you add EGL_DRIVER=egl_dri2 ?
Unfortunately that didn't work. As output I get (note best driver is DRI2
instead of gallium):
# EGL_LOG_LEVEL=debug EGL_PLATFORM=drm EGL_DRIVER=egl_dri2 ./egltri_screen
libEGL debug: Native platform type: drm (environment overwrite)
libEGL debug: EGL search path is /usr/lib64/egl
libEGL debug: added egl_dri2 to module array
libEGL debug: the best driver is DRI2
EGL_VERSION = 1.4 (DRI2)
libEGL debug: attribute 0x3033 has an invalid value 0x8
libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChooseConfig
EGLUT: failed to choose a config

But on recent mesa it works again without EGL_DRIVER.

(In reply to comment #69)
> I'm afraid it's still too early to test in X. Even without -retro, the GPU
> is probably used for some operations via glamor, e.g. for the cursor image.
Well, I just tested again on yesterdays mesa (2014-06-22) and vanilla kernel
3.16-rc2 (no patches, cause I had problems on rc1). egltri_screen still works
once, then I get garbage, that now looks different (lots of small dots).

I also tried eglgears_screen, but that segfaults. I guess it's a problem in
llvm - and unfortunately llvm refuses to build for about 2 weeks now.
Output is:

LLVM triggered Diagnostic Handler: unsupported call to function
llvm.AMDGPU.rsq. in main
[  621.798733] traps: eglgears_screen[431] general protection ip:7f0cb3ae51d8
sp:7fffe17cfa10 error:0 in libLLVM-3.5svn.so[7f0cb2b35000+1af1000]
Segmentation fault

Next I'll try to get the kernel patches for disabling tiling running again and
use R600_DEBUG=nodma. Do I have to do anything about si_get_backend_mask() ?

-- 
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/20140623/fe61e2e7/attachment.html>

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Dieter Nützel]

Am 23.06.2014 11:34, schrieb Michel D?nzer:
> On 18.06.2014 18:14, Christian K?nig wrote:
>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>> 
>>> Looking into these issues has got me thinking about the use of the 
>>> page
>>> flip interrupt: If the page flip interrupt arrives before the
>>> corresponding
>>> vertical blank interrupt, the DRM vblank counter will be lower than
>>> expected by 1 in drm_send_vblank_event(). I suspect this is the cause 
>>> of
>>> 
>>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion
>>> event has impossible msc [x-1] < target_msc [x]
>>> 
>>> messages in the X log file which have been popping up in bug reports
>>> lately.
>>> This also results in 0s being returned to the client for the MSC and
>>> timestamp of the swap completion, which could cause all kinds of bad
>>> behaviour.
>> First of all thanks for looking into it. Are you getting this on 3.16 
>> or
>> 3.15?
> 
> I haven't actually run into this myself yet. I thought I'd seen it in
> several bug reports, but right now I can only find
> https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems to
> include the page flipping changes from 3.16.

With 3.16-rc2 I get it now on my RV730 AGP as in the above bug report.
But only the lines in Xorg.0.log.
NO signs of any damage/error in use.

Since 3.15 and 3.16 (rc2 only) my system is rock solid.

I've tried 3.15-rc7 + Christian's pflip rework (did some little 
handwork), too.
It was solid but I saw the reported flip/black distortion in the below 
part during Kwin 4.13 cube screen effect (rotation). Your fix for 
3.16-rc1 fixed that.

Before 3.15/3.16-rcX I got some hangs from time to time during system 
boot.
Nothing in the logs but SSD RAID1 rebuild. Maybe it was MD related an 
NOT r600/DRM.

3.16-rcX (3.15-rc7+pflip patches) seems to be more responsive that 3.15, 
for me.

First and latest attchments from bug #80141
https://bugs.freedesktop.org/attachment.cgi?id=101605
show same.

Where should I add/send my Xorg.0.log?

Cheers,
   Dieter

>> I don't think that the pflip irq is thrown earlier than the vblank, 
>> but
>> on 3.16 it might actually be that we program the flip so fast into the
>> hardware that we do it one frame earlier than planned.
> 
> So userspace is notified of the previous vertical blank period and 
> calls
> the page flip ioctl in response, which then manages to program the
> scanout address update into the hardware before the scanout address
> update is latched during the previous vertical blank period?
> 
> To avoid that scenario, one possibility might be to check if we're in
> vertical blank before calling radeon_page_flip(), and if so sleep for
> 1ms or so before trying again? That might unnecessarily delay flips on
> other CRTCs though...

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #44 from Alex Deucher  ---
(In reply to andre+kernel from comment #43)
> I'm experiencing the same problem with a XFX Radeon HD 7870 GHz Edition. 
> I've tried both appending radeon.audio=0 to the kernel parameters and
> blacklisting snd_hda_codec_hdmi to no avail.  Currently, I'm on 3.15.1, but
> I remember it happening on 3.14, too.

You have different hardware.  This bug is specific to BTC parts.  You have an
SI part.  Please file a new bug.

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

[PATCH] drm/exynos: disable unused windows on apply

[Inki Dae]

On 2014? 06? 23? 21:12, Andrzej Hajda wrote:
> Gently ping.


Oops, sorry. Applied.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
> On 06/09/2014 04:10 PM, Andrzej Hajda wrote:
>> The patch disables non-enabled HW windows on applying
>> configuration, it will allow to clear windows enabled
>> by bootloader.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index bb45ab2..33161ad 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -741,6 +741,8 @@ static void fimd_apply(struct exynos_drm_manager *mgr)
>>  win_data = >win_data[i];
>>  if (win_data->enabled)
>>  fimd_win_commit(mgr, i);
>> +else
>> +fimd_win_disable(mgr, i);
>>  }
>>  
>>  fimd_commit(mgr);
> 
> 

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

[Guido Martínez]

Hi Rob,

On Tue, Jun 17, 2014 at 11:17:02AM -0300, Guido Mart?nez wrote:
> The tilcdc driver could be compiled as a module, but was severely broken
> and could not be used as such. This patchset attempts to fix the issues
> preventing a proper load/unload of the module.
> 
> Issues included dangling sysfs nodes, dangling devices, memory leaks and
> a double kfree.
> 
> It now seems to be working ok. We have tested this by loading and
> unloading the driver repeteadly, with both panel and slave connectors
> and found no flaws.
> 
> There is still one warning left on tilcdc_crtc_destroy, caused by
> destroying the connector while still in an ON status. We don't know why
> this happens or why it's an issue, so we did not fix it.
> 
> The first 7 patches are bug fixes which and should probably be applied
> in the stable trees. The last two are clean-ups.
>

Any comment on this patchset?

Thanks!

> 
> Resending this since I got no replies.
> 
> 
> Guido Mart?nez (9):
>   drm/i2c: tda998x: move drm_i2c_encoder_destroy call
>   drm/tilcdc: panel: fix dangling sysfs connector node
>   drm/tilcdc: slave: fix dangling sysfs connector node
>   drm/tilcdc: tfp410: fix dangling sysfs connector node
>   drm/tilcdc: panel: fix leak when unloading the module
>   drm/tilcdc: fix release order on exit
>   drm/tilcdc: fix double kfree
>   drm/tilcdc: remove submodule destroy calls
>   drm/tilcdc: replace late_initcall with module_init
> 
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
>  drivers/gpu/drm/tilcdc/Module.symvers  |  0
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 
> +-
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
>  7 files changed, 59 insertions(+), 60 deletions(-)
>  create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
> 
> -- 
> 2.0.0
> 

-- 
Guido Mart?nez, VanguardiaSur
www.vanguardiasur.com.ar

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

andre+kernel at ramaciotti.com changed:

   What|Removed |Added

 CC||andre+kernel at ramaciotti.com

--- Comment #43 from andre+kernel at ramaciotti.com ---
I'm experiencing the same problem with a XFX Radeon HD 7870 GHz Edition.  I've
tried both appending radeon.audio=0 to the kernel parameters and blacklisting
snd_hda_codec_hdmi to no avail.  Currently, I'm on 3.15.1, but I remember it
happening on 3.14, too.

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

unparseable, undocumented /sys/class/drm/.../pstate

[Martin Peres]

Le 23/06/2014 19:56, Ilia Mirkin a ?crit :
> On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres  wrote:
>> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
>>>
>>> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:

 On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
 A list of valid "values" that a file can be in is fine if you just then
 write one value back to that file.  That's the one exception, but a
 minor one given the huge number of sysfs files.  Other than that, if you
>>>
>>>
>>> Which is pretty much what the pstate file is. Would it make things
>>> better if we removed the descriptive info while leaving the pstate
>>> file in place?
>>
>>
>> This means we should also create a new sysfs file per performance level too,
>> right? Is there another way for a driver to expose a list in sysfs?
>>
>> Since NVIDIA gives different names to performance levels depending on the
>> card family, we may need to abstract the name away in order to provide some
>> consistency and make listing performance levels easier from a program (may
>> it use readdir() or stat()).
>>
>> Moving the file to debugfs would "fix" the one-value-per-file rule but it
>> would also require users to mount debugfs at boot time in order to write the
>> default configuration they want for PM instead of just changing
>> /etc/sysctl.d/nouveau.conf... On the other hand, I'm not sure we can commit
>> on having a stable ABI on the way we display clocks (unless people take them
>> as a single value and do not try to parse them) as new hardware will alter
>> the semantics of each clock domain, if not drop/split some of them!
>>
>> Whatever we do, it doesn't look like we can find a nice solution that fits
>> every use cases unless we write a userspace program to access this data, but
>> this seems highly overkill...
>
> I was thinking just having the list of level ids in the pstate file,
> and then stick the current file into debugfs. That way people retain
> the ability to see things, as well as use pstate directly for a
> configured system.

In this case, would we still use the * to indicate the current perflvl?

Also, are we supposed to output the current perflvl or the current 
configuration in use? Right now, we configure it to either auto (WIP), 
perflvl X at all time or perflvl X when on battery and Y when on sector.
However, when we read pstate, we only get the current perflvl if my 
memory serves me right. Maybe we should create a r-o file that outputs 
the current perflvl and keep pstate for storing the configuration.

unparseable, undocumented /sys/class/drm/.../pstate

[Martin Peres]

Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:
>> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
>> A list of valid "values" that a file can be in is fine if you just then
>> write one value back to that file.  That's the one exception, but a
>> minor one given the huge number of sysfs files.  Other than that, if you
>
> Which is pretty much what the pstate file is. Would it make things
> better if we removed the descriptive info while leaving the pstate
> file in place?

This means we should also create a new sysfs file per performance level 
too, right? Is there another way for a driver to expose a list in sysfs?

Since NVIDIA gives different names to performance levels depending on 
the card family, we may need to abstract the name away in order to 
provide some consistency and make listing performance levels easier from 
a program (may it use readdir() or stat()).

Moving the file to debugfs would "fix" the one-value-per-file rule but 
it would also require users to mount debugfs at boot time in order to 
write the default configuration they want for PM instead of just 
changing /etc/sysctl.d/nouveau.conf... On the other hand, I'm not sure 
we can commit on having a stable ABI on the way we display clocks 
(unless people take them as a single value and do not try to parse them) 
as new hardware will alter the semantics of each clock domain, if not 
drop/split some of them!

Whatever we do, it doesn't look like we can find a nice solution that 
fits every use cases unless we write a userspace program to access this 
data, but this seems highly overkill...

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Rahul Sharma]

Hi Ajay, Inki,

I tested this series for Exynos5420 based peach-pit board,
Exynos5800 based Peach-pi board and Exynos5250 based
Snow board. I verified with the chrome test environment and
able to see upto Login Screen. DPMS on/off functionality and
S2R is also working fine for Display. therefore:

Tested-by: Rahul Sharma 

Regards,
Rahul Sharma.

On 20 June 2014 21:21, Inki Dae  wrote:
> 2014-06-20 17:06 GMT+09:00 Ajay kumar :
>> ping.
>
> I will have a review soon but I'm afraid that I cannot have a test yet
> because I have no any board with panel based on eDP and LVDS so wait
> for until I get a board.
> Otherwise, can anyone give me tested-by? and I'd happy to give me
> reviewed-by so that I can pick this patch series up.
>
> Thanks,
> Inki Dae
>
>>
>> On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar  
>> wrote:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>
>>> This patchset also consolidates various inputs from the drm community
>>> regarding the bridge chaining concept:
>>> (1) [RFC V2 0/3] drm/bridge: panel and chaining
>>> http://www.spinics.net/lists/linux-samsung-soc/msg30160.html
>>> (2) [RFC V3 0/3] drm/bridge: panel and chaining
>>> http://www.spinics.net/lists/linux-samsung-soc/msg30507.html
>>>
>>> Changes since V2:
>>> -- Address comments from Jingoo Han for ps8622 driver
>>> -- Address comments from Daniel, Rob and Thierry regarding
>>>bridge chaining
>>> -- Address comments from Thierry regarding the names for
>>>new drm_panel functions
>>>
>>> Changes since V3:
>>> -- Remove hotplug based initialization of exynos_dp
>>> -- Make exynos_dp work directly with drm_panel, remove
>>>dependency on panel_binder
>>> -- Minor cleanups in panel_binder and panel_lvds driver
>>>
>>> The following patches can be divided into 2 groups:
>>> patches 1 to 4: add drm_panel support to exynos_dp(peach-pi)
>>> patches 5 to 10: chaining of bridges and drm_panel(snow and 
>>> peach-pit)
>>>
>>> Ajay Kumar (8):
>>>   [PATCH V4 1/10] drm/exynos: Move DP setup out of hotplug workqueue
>>>   [PATCH V4 2/10] drm/panel: add prepare and unprepare routines
>>>   [PATCH V4 3/10] drm/exynos: dp: modify driver to support drm_panel
>>>   [PATCH V4 4/10] drm/panel: Add driver for lvds/edp based panels
>>>   [PATCH V4 5/10] drm/bridge: add helper functions to support bridge chain
>>>   [PATCH V4 6/10] drm/bridge: Add a driver which binds drm_bridge with 
>>> drm_panel
>>>   [PATCH V4 7/10] drm/bridge: ptn3460: Support bridge chaining
>>>   [PATCH V4 8/10] drm/exynos: dp: create bridge chain using ptn3460 and
>>>   panel_binder
>>>
>>> Vincent Palatin (1):
>>>   [PATCH V4 9/10] drm/bridge: Add ps8622/ps8625 bridge driver
>>>
>>> Rahul Sharma (1):
>>>   [PATCH V4 10/10] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
>>>
>>>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>>>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 +++
>>>  .../devicetree/bindings/video/exynos_dp.txt|2 +
>>>  drivers/gpu/drm/bridge/Kconfig |   15 +
>>>  drivers/gpu/drm/bridge/Makefile|2 +
>>>  drivers/gpu/drm/bridge/panel_binder.c  |  193 
>>>  drivers/gpu/drm/bridge/ps8622.c|  475 
>>> 
>>>  drivers/gpu/drm/bridge/ptn3460.c   |  136 +-
>>>  drivers/gpu/drm/exynos/Kconfig |1 +
>>>  drivers/gpu/drm/exynos/exynos_dp_core.c|   87 +++-
>>>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
>>>  drivers/gpu/drm/panel/Kconfig  |   10 +
>>>  drivers/gpu/drm/panel/Makefile |1 +
>>>  drivers/gpu/drm/panel/panel-lvds.c |  262 +++
>>>  include/drm/bridge/panel_binder.h  |   44 ++
>>>  include/drm/bridge/ps8622.h|   41 ++
>>>  include/drm/bridge/ptn3460.h   |   15 +-
>>>  include/drm/drm_crtc.h |   72 +++
>>>  include/drm/drm_panel.h|   18 +
>>>  19 files changed, 1309 insertions(+), 138 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>>>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>>>  create mode 100644 drivers/gpu/drm/bridge/panel_binder.c
>>>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>>>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>>  create mode 100644 include/drm/bridge/panel_binder.h
>>>  create mode 100644 include/drm/bridge/ps8622.h
>>>
>>> --
>>> 1.7.9.5
>>>
>> --
>> To unsubscribe from this list: send the 

[PATCH 3/3] drm/radeon: enable bapm by default on desktop TN/RL boards

[Lucas Stach]

Am Mittwoch, den 18.06.2014, 16:25 -0400 schrieb Alex Deucher:
> bapm enabled the GPU and CPU to share TDP headroom.  It was
> disabled by default since some laptops hung when it was enabled
> in conjunction with dpm.  It seems to be stable on desktop
> boards and fixes hangs on boot with dpm enabled on certain
> boards, so enable it by default on desktop boards.
> 
Do you have any idea on why it fails on mobile parts? If there is any
hint I can retest on my failing laptop. It would be nice to be able to
enbale this on the mobile parts, too.

Regards,
Lucas

> bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=72921
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/trinity_dpm.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/trinity_dpm.c 
> b/drivers/gpu/drm/radeon/trinity_dpm.c
> index 2a2822c..20da6ff 100644
> --- a/drivers/gpu/drm/radeon/trinity_dpm.c
> +++ b/drivers/gpu/drm/radeon/trinity_dpm.c
> @@ -1874,7 +1874,15 @@ int trinity_dpm_init(struct radeon_device *rdev)
>   for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++)
>   pi->at[i] = TRINITY_AT_DFLT;
>  
> - pi->enable_bapm = false;
> + /* There are stability issues reported on latops with
> +  * bapm installed when switching between AC and battery
> +  * power.  At the same time, some desktop boards hang
> +  * if it's not enabled and dpm is enabled.
> +  */
> + if (rdev->flags & RADEON_IS_MOBILITY)
> + pi->enable_bapm = false;
> + else
> + pi->enable_bapm = true;
>   pi->enable_nbps_policy = true;
>   pi->enable_sclk_ds = true;
>   pi->enable_gfx_power_gating = true;

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

[PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Christian Gmeiner]

Hi


2014-06-11 20:27 GMT+02:00 Ajay Kumar :
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/LVDS panels.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BACKLIGHT_EN pin to
> enable/ disable the backlight.
> Sometimes, we can have LCD_EN switches as well.
>
> The routines in this driver can be used to control
> panel power sequence on such boards.
>
> Signed-off-by: Ajay Kumar 
> Signed-off-by: Rahul Sharma 
> ---
>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>  drivers/gpu/drm/panel/Kconfig  |   10 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-lvds.c |  262 
> 
>  4 files changed, 323 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>
> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> new file mode 100644
> index 000..7cb6084
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> @@ -0,0 +1,50 @@
> +panel interface for eDP/lvds panels
> +
> +Required properties:
> +  - compatible: "panel-lvds"
> +
> +Optional properties:
> +   -lcd-en-gpio:
> +   panel LCD poweron GPIO.
> +   Indicates which GPIO needs to be powered up as output
> +   to powerup/enable the switch to the LCD panel.
> +   -led-en-gpio:
> +   panel LED enable GPIO.
> +   Indicates which GPIO needs to be powered up as output
> +   to enable the backlight.
> +   -panel-prepare-delay:
> +   delay value in ms required for panel_prepare process
> +   Delay in ms needed for the panel LCD unit to
> +   powerup completely.
> +   ex: delay needed till eDP panel throws HPD.
> +   delay needed so that we cans tart reading edid.
> +   -panel-enable-delay:
> +   delay value in ms required for panel_enable process
> +   Delay in ms needed for the panel backlight/LED unit
> +   to powerup, and delay needed between video_enable and
> +   backlight_enable.
> +   -panel-disable-delay:
> +   delay value in ms required for panel_disable process
> +   Delay in ms needed for the panel backlight/LED unit
> +   powerdown, and delay needed between backlight_disable
> +   and video_disable.
> +   -panel-unprepare-delay:
> +   delay value in ms required for panel_post_disable process
> +   Delay in ms needed for the panel LCD unit to
> +   to powerdown completely, and the minimum delay needed
> +   before powering it on again.
> +   -panel-width-mm: physical panel width [mm]
> +   -panel-height-mm: physical panel height [mm]
> +

For what are these two properties are needed?

If I find some time I will give this patch a try as I need something
like this for an imx6d based device.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[Bug 80141] Fails to page flip multiple time, queue overflows waiting for one to finish that never does crashing entire system.

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

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

Aaron B  changed:

   What|Removed |Added

 Attachment #101236|0   |1
is obsolete||
 Attachment #101374|0   |1
is obsolete||
 Attachment #101543|0   |1
is obsolete||

--- Comment #6 from Aaron B  ---
Created attachment 101605
  --> https://bugs.freedesktop.org/attachment.cgi?id=101605=edit
New crash with XOrg backtrace.

Xorg error reporting file, has a backtrace of the fault.

-- 
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/20140623/a50ce423/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

theamazingjanet at googlemail.com changed:

   What|Removed |Added

Summary|XCOM: Enemy Known Causes|XCOM: Enemy Unknown Causes
   |lockup  |lockup

-- 
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/20140623/6fd1662f/attachment.html>

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Michel Dänzer]

On 18.06.2014 18:14, Christian K?nig wrote:
> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>
>> Looking into these issues has got me thinking about the use of the page
>> flip interrupt: If the page flip interrupt arrives before the
>> corresponding
>> vertical blank interrupt, the DRM vblank counter will be lower than
>> expected by 1 in drm_send_vblank_event(). I suspect this is the cause of
>>
>>   (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion
>> event has impossible msc [x-1] < target_msc [x]
>>
>> messages in the X log file which have been popping up in bug reports
>> lately.
>> This also results in 0s being returned to the client for the MSC and
>> timestamp of the swap completion, which could cause all kinds of bad
>> behaviour.
> First of all thanks for looking into it. Are you getting this on 3.16 or
> 3.15?

I haven't actually run into this myself yet. I thought I'd seen it in
several bug reports, but right now I can only find
https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems to
include the page flipping changes from 3.16.


> I don't think that the pflip irq is thrown earlier than the vblank, but
> on 3.16 it might actually be that we program the flip so fast into the
> hardware that we do it one frame earlier than planned.

So userspace is notified of the previous vertical blank period and calls
the page flip ioctl in response, which then manages to program the
scanout address update into the hardware before the scanout address
update is latched during the previous vertical blank period?

To avoid that scenario, one possibility might be to check if we're in
vertical blank before calling radeon_page_flip(), and if so sleep for
1ms or so before trying again? That might unnecessarily delay flips on
other CRTCs though...


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

[Bug 80419] New: XCOM: Enemy Known Causes lockup

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

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

  Priority: medium
Bug ID: 80419
  Assignee: dri-devel at lists.freedesktop.org
   Summary: XCOM: Enemy Known Causes lockup
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: theamazingjanet at googlemail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Running the recently released XCOM: Enemy Unknown, after a few minutes of
playing the game will lockup the display completely. Mouse movement still shows
but nothing is responsive. Occurs for the whole display, evidenced by running
the game in windowed mode. Keyboard input is also unresponsive, forcing a hard
reset.

Ubuntu 14.04
AMD HD7770 2GB
Mesa 10.1.3

Only response from Feral on the issue was to use Catalyst.

-- 
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/20140623/4dc7a25b/attachment-0001.html>

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Javier Martinez Canillas]

Hello,

On Fri, Jun 20, 2014 at 5:51 PM, Inki Dae  wrote:
> 2014-06-20 17:06 GMT+09:00 Ajay kumar :
>> ping.
>
> I will have a review soon but I'm afraid that I cannot have a test yet
> because I have no any board with panel based on eDP and LVDS so wait
> for until I get a board.
> Otherwise, can anyone give me tested-by? and I'd happy to give me
> reviewed-by so that I can pick this patch series up.
>
> Thanks,
> Inki Dae
>

I've also tested this series on an Exynos5420 Peach pit board and LVDS
display was working for me.

Tested-by: Javier Martinez Canillas 

Best regards,
Javier

>>
>> On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar  
>> wrote:
>>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>>
>>> I have tested this after adding few DT changes for exynos5250-snow,
>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>>>
>>> This patchset also consolidates various inputs from the drm community
>>> regarding the bridge chaining concept:
>>> (1) [RFC V2 0/3] drm/bridge: panel and chaining
>>> http://www.spinics.net/lists/linux-samsung-soc/msg30160.html
>>> (2) [RFC V3 0/3] drm/bridge: panel and chaining
>>> http://www.spinics.net/lists/linux-samsung-soc/msg30507.html
>>>
>>> Changes since V2:
>>> -- Address comments from Jingoo Han for ps8622 driver
>>> -- Address comments from Daniel, Rob and Thierry regarding
>>>bridge chaining
>>> -- Address comments from Thierry regarding the names for
>>>new drm_panel functions
>>>
>>> Changes since V3:
>>> -- Remove hotplug based initialization of exynos_dp
>>> -- Make exynos_dp work directly with drm_panel, remove
>>>dependency on panel_binder
>>> -- Minor cleanups in panel_binder and panel_lvds driver
>>>
>>> The following patches can be divided into 2 groups:
>>> patches 1 to 4: add drm_panel support to exynos_dp(peach-pi)
>>> patches 5 to 10: chaining of bridges and drm_panel(snow and 
>>> peach-pit)
>>>
>>> Ajay Kumar (8):
>>>   [PATCH V4 1/10] drm/exynos: Move DP setup out of hotplug workqueue
>>>   [PATCH V4 2/10] drm/panel: add prepare and unprepare routines
>>>   [PATCH V4 3/10] drm/exynos: dp: modify driver to support drm_panel
>>>   [PATCH V4 4/10] drm/panel: Add driver for lvds/edp based panels
>>>   [PATCH V4 5/10] drm/bridge: add helper functions to support bridge chain
>>>   [PATCH V4 6/10] drm/bridge: Add a driver which binds drm_bridge with 
>>> drm_panel
>>>   [PATCH V4 7/10] drm/bridge: ptn3460: Support bridge chaining
>>>   [PATCH V4 8/10] drm/exynos: dp: create bridge chain using ptn3460 and
>>>   panel_binder
>>>
>>> Vincent Palatin (1):
>>>   [PATCH V4 9/10] drm/bridge: Add ps8622/ps8625 bridge driver
>>>
>>> Rahul Sharma (1):
>>>   [PATCH V4 10/10] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
>>>
>>>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>>>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 +++
>>>  .../devicetree/bindings/video/exynos_dp.txt|2 +
>>>  drivers/gpu/drm/bridge/Kconfig |   15 +
>>>  drivers/gpu/drm/bridge/Makefile|2 +
>>>  drivers/gpu/drm/bridge/panel_binder.c  |  193 
>>>  drivers/gpu/drm/bridge/ps8622.c|  475 
>>> 
>>>  drivers/gpu/drm/bridge/ptn3460.c   |  136 +-
>>>  drivers/gpu/drm/exynos/Kconfig |1 +
>>>  drivers/gpu/drm/exynos/exynos_dp_core.c|   87 +++-
>>>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
>>>  drivers/gpu/drm/panel/Kconfig  |   10 +
>>>  drivers/gpu/drm/panel/Makefile |1 +
>>>  drivers/gpu/drm/panel/panel-lvds.c |  262 +++
>>>  include/drm/bridge/panel_binder.h  |   44 ++
>>>  include/drm/bridge/ps8622.h|   41 ++
>>>  include/drm/bridge/ptn3460.h   |   15 +-
>>>  include/drm/drm_crtc.h |   72 +++
>>>  include/drm/drm_panel.h|   18 +
>>>  19 files changed, 1309 insertions(+), 138 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>>>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>>>  create mode 100644 drivers/gpu/drm/bridge/panel_binder.c
>>>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>>>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>>  create mode 100644 include/drm/bridge/panel_binder.h
>>>  create mode 100644 include/drm/bridge/ps8622.h
>>>
>>> --
>>> 1.7.9.5
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  

[PATCH V4 09/10] drm/bridge: Add ps8622/ps8625 bridge driver

[Javier Martinez Canillas]

Hello Ajay,

On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar  wrote:
> From: Vincent Palatin 
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>  drivers/gpu/drm/bridge/Kconfig |8 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/ps8622.c|  475 
> 
>  include/drm/bridge/ps8622.h|   41 ++
>  5 files changed, 546 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>  create mode 100644 include/drm/bridge/ps8622.h
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt 
> b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> new file mode 100644
> index 000..1afbd9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> @@ -0,0 +1,21 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> +   - compatible: "parade,ps8622"
> +   - reg: first i2c address of the bridge
> +   - sleep-gpio: OF device-tree gpio specification
> +   - reset-gpio: OF device-tree gpio specification
> +
> +Optional properties:
> +   - lane-count: number of DP lanes to use
> +   - use-external-pwm: backlight will be controlled by an external PWM
> +
> +Example:
> +   ps8622-bridge at 48 {
> +   compatible = "parade,ps8622";
> +   reg = <0x48>;
> +   sleep-gpio = < 6 1 0 0>;
> +   reset-gpio = < 1 1 0 0>;
> +   display-timings = <_display_timings>;
> +   lane-count = <1>
> +   };
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e3fb487..7b843c8 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
> select DRM_KMS_HELPER
> select DRM_PANEL
> ---help---
> +
> +config DRM_PS8622
> +   tristate "Parade eDP/LVDS bridge"
> +   depends on DRM
> +   select DRM_KMS_HELPER
> +   select BACKLIGHT_LCD_SUPPORT
> +   select BACKLIGHT_CLASS_DEVICE
> +   ---help---
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index ba8b5b8..b494d4b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
>
>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
>  obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..387d332
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -0,0 +1,475 @@
> +/*
> + * Parade PS8622 eDP/LVDS bridge driver
> + *
> + * Copyright (C) 2014 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "drmP.h"
> +#include "drm_crtc.h"
> +#include "drm_crtc_helper.h"
> +
> +struct ps8622_bridge {
> +   struct drm_bridge *bridge;
> +   struct drm_encoder *encoder;
> +   struct i2c_client *client;
> +   struct regulator *v12;
> +   struct backlight_device *bl;
> +   struct mutex enable_mutex;
> +
> +   int gpio_slp_n;
> +   int gpio_rst_n;
> +
> +   u8 max_lane_count;
> +   u8 lane_count;
> +
> +   bool enabled;
> +};
> +
> +struct ps8622_device_data {
> +   u8 max_lane_count;
> +};
> +
> +static const struct ps8622_device_data ps8622_data = {
> +   .max_lane_count = 1,
> +};
> +
> +static const struct ps8622_device_data ps8625_data = {
> +   .max_lane_count = 2,
> +};
> +
> +/* Brightness scale on the Parade chip */
> +#define PS8622_MAX_BRIGHTNESS 0xff
> +
> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
> +#define PS8622_POWER_RISE_T1_MIN_US 10
> +#define PS8622_POWER_RISE_T1_MAX_US 1
> +#define PS8622_RST_HIGH_T2_MIN_US 3000
> +#define PS8622_RST_HIGH_T2_MAX_US 3
> +#define PS8622_PWMO_END_T12_MS 200
> +#define PS8622_POWER_FALL_T16_MAX_US 1
> +#define PS8622_POWER_OFF_T17_MS 500
> +
> +#if 

[PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Javier Martinez Canillas]

Hello Ajay,

Not an extensive review since I'm not familiar with the graphics stack
but a few things I noticed are commented below.

On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar  wrote:
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/LVDS panels.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BACKLIGHT_EN pin to
> enable/ disable the backlight.
> Sometimes, we can have LCD_EN switches as well.
>
> The routines in this driver can be used to control
> panel power sequence on such boards.
>
> Signed-off-by: Ajay Kumar 
> Signed-off-by: Rahul Sharma 
> ---
>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>  drivers/gpu/drm/panel/Kconfig  |   10 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-lvds.c |  262 
> 
>  4 files changed, 323 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>
> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> new file mode 100644
> index 000..7cb6084
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> @@ -0,0 +1,50 @@
> +panel interface for eDP/lvds panels
> +
> +Required properties:
> +  - compatible: "panel-lvds"
> +
> +Optional properties:
> +   -lcd-en-gpio:
> +   panel LCD poweron GPIO.
> +   Indicates which GPIO needs to be powered up as output
> +   to powerup/enable the switch to the LCD panel.
> +   -led-en-gpio:
> +   panel LED enable GPIO.
> +   Indicates which GPIO needs to be powered up as output
> +   to enable the backlight.
> +   -panel-prepare-delay:
> +   delay value in ms required for panel_prepare process
> +   Delay in ms needed for the panel LCD unit to
> +   powerup completely.
> +   ex: delay needed till eDP panel throws HPD.
> +   delay needed so that we cans tart reading edid.
> +   -panel-enable-delay:
> +   delay value in ms required for panel_enable process
> +   Delay in ms needed for the panel backlight/LED unit
> +   to powerup, and delay needed between video_enable and
> +   backlight_enable.
> +   -panel-disable-delay:
> +   delay value in ms required for panel_disable process
> +   Delay in ms needed for the panel backlight/LED unit
> +   powerdown, and delay needed between backlight_disable
> +   and video_disable.
> +   -panel-unprepare-delay:
> +   delay value in ms required for panel_post_disable process
> +   Delay in ms needed for the panel LCD unit to
> +   to powerdown completely, and the minimum delay needed
> +   before powering it on again.
> +   -panel-width-mm: physical panel width [mm]
> +   -panel-height-mm: physical panel height [mm]
> +
> +Example:
> +
> +   panel-lvds {
> +   compatible = "panel-lvds";
> +   led-en-gpio = < 0 1>;
> +   panel-prepare-delay = <40>;
> +   panel-enable-delay = <20>;
> +   panel-disable-delay = <20>;
> +   panel-unprepare-delay = <30>;
> +   panel-width-mm = <256>;
> +   panel-height-mm = <144>;
> +   };

Recently it's considered a good practice to have the DT binding
documentation in a separate patch.

> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..8fe7ee5 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,14 @@ config DRM_PANEL_S6E8AA0
> select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_EDP_LVDS
> +   tristate "support for eDP/LVDS panels"
> +   depends on OF && DRM_PANEL
> +   select VIDEOMODE_HELPERS
> +   help
> + DRM panel driver for direct eDP panels or LVDS connected
> + via DP bridges, that need at most a regulator for LCD unit,
> + a regulator for LED unit and/or enable GPIOs for LCD or LED units.
> + Delay values can also be specified to support powerup and
> + powerdown process.
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 8b92921..eaafa01 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>  

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 19.06.2014 18:45, Christian K?nig wrote:
> Am 19.06.2014 03:48, schrieb Michel D?nzer:
>> On 15.06.2014 21:48, Christian K?nig wrote:
>>>
>>> No idea what goes wrong when Marek runs piglit, but 3.15.0+"stop
>>> poisoning the GART TLB"+"force_gtt" is rock solid here.
>> FWIW, 3.15 doesn't survive piglit on my Bonaire either, but 3.14 is
>> fine. 3.15 seems stable on Kaveri though, but I haven't tried the
>> force_gtt patch on that yet.
> 
> Yeah, I think it's just me who has a stable system with 3.15 and that
> annoys me quite a bit.

FWIW though, my Kaveri doesn't always survive piglit either, e.g. this
morning it didn't once again, then did after a reboot. (That's using
SDMA; Kaveri was never switched back to CPDMA)


> No idea what's the difference. What versions of LLVM/Mesa/Piglit are you
> using for the test?

Current Git of everything.


>> There have also been a number of bug reports about stability regressions
>> in 3.15 on various SI and CIK cards. It seems likely that at least some
>> of those are related to this issue as well.
>>
>> If we can't figure out the problem soon, we probably need to revert the
>> 'Use normal BOs for page tables' and dependent changes at least for
>> 3.15.y?
> 
> I thought about this for the whole 3.15 release cycle, but decided
> against it. But what we could do is applying the attached trivial patch,
> it pins down the page tables and so pretty much reverts to the old
> behavior.

This patch applied on top of 3.15 + stop poisoning the GART TLB doesn't
seem to help on my Bonaire, unfortunately.


> I think even when we revert to the old code we have a couple of unsolved
> problems with the VM support or in the driver in general where we should
> try to understand the underlying reason for it instead of applying more
> workarounds.

I'm not suggesting applying more workarounds but going back to a known
more stable state. It seems like we've maneuvered ourselves to a rather
uncomfortable position from there, with no clear way to a better place.
But if we basically started from the 3.14 state again, we have a few
known hurdles like mine and Marek's Bonaire etc. which we know any
further improvements will have to pass before they can be considered for
general consumption.


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

[PATCH] drm: Change link order to load modules first

[Thierry Reding]

On Sun, Jun 22, 2014 at 10:14:36PM -0300, Ezequiel Garcia wrote:
> Given panels and I2C-connected encoders are required by DRM drivers,
> we need to change the link order so these are probed first. This commit
> moves all the i2c, panel and bridge helper drivers so they are probed
> before the DRM drivers.

No. We don't need to change the link order. What we need to do is make
sure that modules deal properly with situations where their resources
aren't available yet (i.e. EPROBE_DEFER). There are factors other than
link order that influence probe ordering.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140623/f0ec452e/attachment.sig>

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Tomasz Figa]

Hi Rahul,

On 23.06.2014 15:58, Rahul Sharma wrote:
> Hi Ajay, Inki,
> 
> I tested this series for Exynos5420 based peach-pit board,
> Exynos5800 based Peach-pi board and Exynos5250 based
> Snow board. I verified with the chrome test environment and
> able to see upto Login Screen. DPMS on/off functionality and
> S2R is also working fine for Display. therefore:

What tree did you apply this patches onto? I don't see S2R support for
Exynos5420 or 5800 in current linux-next (e.g. there are no PMU tables
present for these SoCs).

Best regards,
Tomasz

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 4:26 PM, Greg KH  wrote:
> On Mon, Jun 23, 2014 at 04:18:39PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek  wrote:
>> > Hi!
>> >
>> >> >> >> > I guess better interface would be something like
>> >> >> >> >
>> >> >> >> > pstate/07/core_clock_min
>> >> >> >> >   core_clock_max
>> >> >> >> >   memory_clock_min
>> >> >> >> >   memory_clock_max
>> >> >> >> >
>> >> >> >> > and then pstate/active containing just the number of active state?
>> >> >
>> >> >> Could we just say that the format of this file is one-per-line of
>> >> >>
>> >> >> level: information-for-the-user
>> >> >
>> >> > But it is not.
>> >>
>> >> But it is...
>> >>
>> >> > Management tools will want to parse it, sooner or
>> >> > later.  What is wrong with solution described above?
>> >>
>> >> It is complex and annoying to the people that will actually use it.
>> >
>> > grep -r . pstate/ is actually not that bad...
>>
>> While that's a clever trick that anyone who's done a bunch of stuff
>> with sysfs knows, I doubt the average linux user could come up with
>> that on their own. I know I didn't.
>
> That's fine, why would an "average" Linux user ever need to poke around
> in sysfs?  Again, please describe what you are wanting to have exported
> to userspace, and what userspace is supposed to do with that
> information, before worrying about the actual sysfs file layout.

It would be nice to allow the end-user to switch between performance
levels on the card.

A particular card exposes some number of levels (well, a particular
card's VBIOS), identified by a value between 0-254 (usually identified
as a 2-char hex string). Each level has various information associated
with it, like timing parameters for various bits of the card, as well
as some more user-friendly concepts like "memory clock speed" etc.

The card's current state may or may not correspond to one of the
predefined levels; often-times the VBIOS initializes the card into
some non-level state. This state may also be of some interest to the
user.

We can't switch to arbitrary speeds, only the defined ones (because of
the various other timing parameters). The level ids don't carry too
much semantic value (higher usually means faster though), so it would
additionally be nice to tell the user some of the more user-friendly
information about each level. Different hardware versions will be able
to expose different types of information (but always in   pairs).

  -ilia

unparseable, undocumented /sys/class/drm/.../pstate

[Greg KH]

On Mon, Jun 23, 2014 at 04:18:39PM -0400, Ilia Mirkin wrote:
> On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek  wrote:
> > Hi!
> >
> >> >> >> > I guess better interface would be something like
> >> >> >> >
> >> >> >> > pstate/07/core_clock_min
> >> >> >> >   core_clock_max
> >> >> >> >   memory_clock_min
> >> >> >> >   memory_clock_max
> >> >> >> >
> >> >> >> > and then pstate/active containing just the number of active state?
> >> >
> >> >> Could we just say that the format of this file is one-per-line of
> >> >>
> >> >> level: information-for-the-user
> >> >
> >> > But it is not.
> >>
> >> But it is...
> >>
> >> > Management tools will want to parse it, sooner or
> >> > later.  What is wrong with solution described above?
> >>
> >> It is complex and annoying to the people that will actually use it.
> >
> > grep -r . pstate/ is actually not that bad...
> 
> While that's a clever trick that anyone who's done a bunch of stuff
> with sysfs knows, I doubt the average linux user could come up with
> that on their own. I know I didn't.

That's fine, why would an "average" Linux user ever need to poke around
in sysfs?  Again, please describe what you are wanting to have exported
to userspace, and what userspace is supposed to do with that
information, before worrying about the actual sysfs file layout.

greg k-h

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek  wrote:
> Hi!
>
>> >> >> > I guess better interface would be something like
>> >> >> >
>> >> >> > pstate/07/core_clock_min
>> >> >> >   core_clock_max
>> >> >> >   memory_clock_min
>> >> >> >   memory_clock_max
>> >> >> >
>> >> >> > and then pstate/active containing just the number of active state?
>> >
>> >> Could we just say that the format of this file is one-per-line of
>> >>
>> >> level: information-for-the-user
>> >
>> > But it is not.
>>
>> But it is...
>>
>> > Management tools will want to parse it, sooner or
>> > later.  What is wrong with solution described above?
>>
>> It is complex and annoying to the people that will actually use it.
>
> grep -r . pstate/ is actually not that bad...

While that's a clever trick that anyone who's done a bunch of stuff
with sysfs knows, I doubt the average linux user could come up with
that on their own. I know I didn't.

>
> And yes, some kind of utility to select right performance level would
> be nice in future... Or maybe not. Perhaps in not so distant future
> kernel will use right performance level for given load...?

Eventually yes. Currently switching between levels varies from
unsupported to unreliable depending on the hardware (as in, hangs the
card, or does otherwise-not-great things). Automatic switching
requires regular switching to be reliable :) [And the performance
counters that are presently being worked on to be able to tell the
card load.]

  -ilia

unparseable, undocumented /sys/class/drm/.../pstate

[Pavel Machek]

On Sun 2014-06-22 22:12:14, Ilia Mirkin wrote:
> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  wrote:
> >> > Hi!
> >> >
> >> > AFAICT, pstate file will contain something like
> >> >
> >> > 07: core 100 MHz memory 123 MHz *
> >> > 08: core 100-200 MHz memory 123 MHz
> >> >
> >> > ...which does not look exactly like one-value-per-file, and I'm pretty
> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
> >> > don't see required documentation in Documentation/ABI.
> >> >
> >> > Should we disable it for now, so that userspace does not start
> >> > depending on it and we'll not have to maintain it forever?
> >> >
> >> > I guess better interface would be something like
> >> >
> >> > pstate/07/core_clock_min
> >> >   core_clock_max
> >> >   memory_clock_min
> >> >   memory_clock_max
> >> >
> >> > and then pstate/active containing just the number of active state?

> Could we just say that the format of this file is one-per-line of
> 
> level: information-for-the-user

But it is not. Management tools will want to parse it, sooner or
later.  What is wrong with solution described above?

> And you can echo a level into it to switch to that level? That seems
> like a reasonable ABI to have... would be happy to throw it into a
> file somewhere... not sure where though.

Documentation/ABI/testing/

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Bug 78661] GPU sometimes locks up after boot and/or resume

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #2 from Alex Deucher  ---
Does booting with radeon.dpm=0 on the kernel command line in grub help?  Please
attach your full dmesg output.

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

[PATCH 00/22] Add and use pci_zalloc_consistent

[David Miller]

From: Joe Perches 
Date: Mon, 23 Jun 2014 06:41:28 -0700

> Adding the helper reduces object code size as well as overall
> source size line count.
> 
> It's also consistent with all the various zalloc mechanisms
> in the kernel.
> 
> Done with a simple cocci script and some typing.

For networking bits:

Acked-by: David S. Miller 

[PATCH 1/2] Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"

[Christian König]

Am 23.06.2014 11:34, schrieb Michel D?nzer:
> On 18.06.2014 18:14, Christian K?nig wrote:
>> Am 18.06.2014 07:53, schrieb Michel D?nzer:
>>> Looking into these issues has got me thinking about the use of the page
>>> flip interrupt: If the page flip interrupt arrives before the
>>> corresponding
>>> vertical blank interrupt, the DRM vblank counter will be lower than
>>> expected by 1 in drm_send_vblank_event(). I suspect this is the cause of
>>>
>>>(WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion
>>> event has impossible msc [x-1] < target_msc [x]
>>>
>>> messages in the X log file which have been popping up in bug reports
>>> lately.
>>> This also results in 0s being returned to the client for the MSC and
>>> timestamp of the swap completion, which could cause all kinds of bad
>>> behaviour.
>> First of all thanks for looking into it. Are you getting this on 3.16 or
>> 3.15?
> I haven't actually run into this myself yet. I thought I'd seen it in
> several bug reports, but right now I can only find
> https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems to
> include the page flipping changes from 3.16.
>
>
>> I don't think that the pflip irq is thrown earlier than the vblank, but
>> on 3.16 it might actually be that we program the flip so fast into the
>> hardware that we do it one frame earlier than planned.
> So userspace is notified of the previous vertical blank period and calls
> the page flip ioctl in response, which then manages to program the
> scanout address update into the hardware before the scanout address
> update is latched during the previous vertical blank period?

Yes correct. That at least sounds like the most likely explanation to me.

> To avoid that scenario, one possibility might be to check if we're in
> vertical blank before calling radeon_page_flip(), and if so sleep for
> 1ms or so before trying again? That might unnecessarily delay flips on
> other CRTCs though...

It won't delay the other CRTCs because each CRTC has it's own kernel 
thread, but it won't be optimal either.

Going to try to reproduce the bug with 3.16,
Christian.

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

--- Comment #8 from Alex Deucher  ---
Created attachment 140721
  --> https://bugzilla.kernel.org/attachment.cgi?id=140721=edit
patch 2/2

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

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

--- Comment #7 from Alex Deucher  ---
Created attachment 140711
  --> https://bugzilla.kernel.org/attachment.cgi?id=140711=edit
patch 1/2

Does this patch set help?

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

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #27 from Alex Deucher  ---
(In reply to comment #26)
> Should this be marked as fixed or is there any other types of testing needed?

I need to push the patches upstream, but I'll be ding that this week.

-- 
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/20140623/c6211319/attachment.html>

[PATCH] drm/exynos: disable unused windows on apply

[Andrzej Hajda]

Gently ping.

Regards
Andrzej

On 06/09/2014 04:10 PM, Andrzej Hajda wrote:
> The patch disables non-enabled HW windows on applying
> configuration, it will allow to clear windows enabled
> by bootloader.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bb45ab2..33161ad 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -741,6 +741,8 @@ static void fimd_apply(struct exynos_drm_manager *mgr)
>   win_data = >win_data[i];
>   if (win_data->enabled)
>   fimd_win_commit(mgr, i);
> + else
> + fimd_win_disable(mgr, i);
>   }
>  
>   fimd_commit(mgr);

unparseable, undocumented /sys/class/drm/.../pstate

[Greg KH]

On Mon, Jun 23, 2014 at 07:46:03PM +0200, Martin Peres wrote:
> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
> >On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:
> >>On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
> >>A list of valid "values" that a file can be in is fine if you just then
> >>write one value back to that file.  That's the one exception, but a
> >>minor one given the huge number of sysfs files.  Other than that, if you
> >
> >Which is pretty much what the pstate file is. Would it make things
> >better if we removed the descriptive info while leaving the pstate
> >file in place?
> 
> This means we should also create a new sysfs file per performance level too,
> right? Is there another way for a driver to expose a list in sysfs?

What exactly are you wanting to export to userspace?  What will
userspace do with this information?  Why export anything at all?

Start with defining that, and go from there.

thanks,

greg k-h

unparseable, undocumented /sys/class/drm/.../pstate

[Greg KH]

On Mon, Jun 23, 2014 at 12:40:43PM -0400, Ilia Mirkin wrote:
> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:
> > On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
> >> On Mon, Jun 23, 2014 at 12:07 PM, Greg KH  wrote:
> >> > On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
> >> >> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
> >> >> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
> >> >> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  
> >> >> >> wrote:
> >> >> >> > Hi!
> >> >> >> >
> >> >> >> > AFAICT, pstate file will contain something like
> >> >> >> >
> >> >> >> > 07: core 100 MHz memory 123 MHz *
> >> >> >> > 08: core 100-200 MHz memory 123 MHz
> >> >> >> >
> >> >> >> > ...which does not look exactly like one-value-per-file, and I'm 
> >> >> >> > pretty
> >> >> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
> >> >> >> > don't see required documentation in Documentation/ABI.
> >> >> >> >
> >> >> >> > Should we disable it for now, so that userspace does not start
> >> >> >> > depending on it and we'll not have to maintain it forever?
> >> >> >> >
> >> >> >> > I guess better interface would be something like
> >> >> >> >
> >> >> >> > pstate/07/core_clock_min
> >> >> >> >   core_clock_max
> >> >> >> >   memory_clock_min
> >> >> >> >   memory_clock_max
> >> >> >> >
> >> >> >> > and then pstate/active containing just the number of active state?
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > 
> >> >> >> > Pavel
> >> >> >> >
> >> >> >> > PS: I have no nvidia, got the news at
> >> >> >> >
> >> >> >> > http://www.phoronix.com/scan.php?page=article=nouveau_try_linux316=2
> >> >> >>
> >> >> >> FTR, this file has been in place since 3.13, and there was a 
> >> >> >> different
> >> >> >> file before it (performance_levels), with a comparable format since
> >> >> >> much earlier (definitely 3.8, probably earlier). I think it's meant a
> >> >> >> lot more for people looking at it and echo'ing stuff to it to modify
> >> >> >> the levels (where supported), than for programs parsing it. Perhaps
> >> >> >> sysfs is the wrong place for this -- what is the right place? 
> >> >> >> debugfs?
> >> >> >
> >> >> > Yes, please move it to debugfs.
> >> >>
> >> >> Could we just say that the format of this file is one-per-line of
> >> >>
> >> >> level: information-for-the-user
> >> >>
> >> >> And you can echo a level into it to switch to that level? That seems
> >> >> like a reasonable ABI to have... would be happy to throw it into a
> >> >> file somewhere... not sure where though.
> >> >
> >> > sysfs files are "one value per file", that's it.  Do anything other than
> >> > that, and it can not be in sysfs, sorry.
> >>
> >> I think that's a little inconsistent. There are *tons* of files in
> >> sysfs with multiple values. For example "local_cpulist" which contains
> >> the string "0-3" for me, the per-connector "modes" file which has a
> >> list of modes supported, and a "resource" file which has a list of hex
> >> values (which probably have something to do with PCI resources?). [I
> >> purposely picked values coming from different parts of the kernel not
> >> to focus on one subsystem...]
> >
> > A list of valid "values" that a file can be in is fine if you just then
> > write one value back to that file.  That's the one exception, but a
> > minor one given the huge number of sysfs files.  Other than that, if you
> 
> Which is pretty much what the pstate file is. Would it make things
> better if we removed the descriptive info while leaving the pstate
> file in place?
> 
> > know of exceptions to that rule, please point them out and I will be
> > glad to yell at the developers.
> >
> > PCI device resources are binary sysfs files, which are just pass-through
> > files from the firmware/device to userspace, with no parsing done in the
> > kernel.  So that's just a single 'value' as well.
> 
> $ cat /sys/class/drm/card0/device/resource
> 0xf000 0xf03f 0x00140204
> 0x 0x 0x
> 
> Doesn't seem like "binary" in the true sense, but perhaps that's close enough.

It's "close enough" :)

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 2:00 PM, Martin Peres  wrote:
> Le 23/06/2014 19:56, Ilia Mirkin a ?crit :
>
>> On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres 
>> wrote:
>>>
>>> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :


 On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:
>
>
> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
> A list of valid "values" that a file can be in is fine if you just then
> write one value back to that file.  That's the one exception, but a
> minor one given the huge number of sysfs files.  Other than that, if
> you



 Which is pretty much what the pstate file is. Would it make things
 better if we removed the descriptive info while leaving the pstate
 file in place?
>>>
>>>
>>>
>>> This means we should also create a new sysfs file per performance level
>>> too,
>>> right? Is there another way for a driver to expose a list in sysfs?
>>>
>>> Since NVIDIA gives different names to performance levels depending on the
>>> card family, we may need to abstract the name away in order to provide
>>> some
>>> consistency and make listing performance levels easier from a program
>>> (may
>>> it use readdir() or stat()).
>>>
>>> Moving the file to debugfs would "fix" the one-value-per-file rule but it
>>> would also require users to mount debugfs at boot time in order to write
>>> the
>>> default configuration they want for PM instead of just changing
>>> /etc/sysctl.d/nouveau.conf... On the other hand, I'm not sure we can
>>> commit
>>> on having a stable ABI on the way we display clocks (unless people take
>>> them
>>> as a single value and do not try to parse them) as new hardware will
>>> alter
>>> the semantics of each clock domain, if not drop/split some of them!
>>>
>>> Whatever we do, it doesn't look like we can find a nice solution that
>>> fits
>>> every use cases unless we write a userspace program to access this data,
>>> but
>>> this seems highly overkill...
>>
>>
>> I was thinking just having the list of level ids in the pstate file,
>> and then stick the current file into debugfs. That way people retain
>> the ability to see things, as well as use pstate directly for a
>> configured system.
>
>
> In this case, would we still use the * to indicate the current perflvl?

That would only be in debugfs. pstate would just list the available
levels and let you set one. (or 'auto', as you point out below)

>
> Also, are we supposed to output the current perflvl or the current
> configuration in use? Right now, we configure it to either auto (WIP),
> perflvl X at all time or perflvl X when on battery and Y when on sector.
> However, when we read pstate, we only get the current perflvl if my memory
> serves me right. Maybe we should create a r-o file that outputs the current
> perflvl and keep pstate for storing the configuration.

Yeah, we could do something like that... ugh, the battery/ac stuff is
a complication. Unclear whether that belongs in the kernel in the
first place... but I guess other drivers do it?

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

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

Gustavo Lopes  changed:

   What|Removed |Added

Summary|No output after radeon  |Hang during boot when DPM
   |module is loaded (R9 270X)  |is on (R9 270X)

-- 
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/20140623/eaf019de/attachment-0001.html>

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres  wrote:
> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
>>
>> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:
>>>
>>> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
>>> A list of valid "values" that a file can be in is fine if you just then
>>> write one value back to that file.  That's the one exception, but a
>>> minor one given the huge number of sysfs files.  Other than that, if you
>>
>>
>> Which is pretty much what the pstate file is. Would it make things
>> better if we removed the descriptive info while leaving the pstate
>> file in place?
>
>
> This means we should also create a new sysfs file per performance level too,
> right? Is there another way for a driver to expose a list in sysfs?
>
> Since NVIDIA gives different names to performance levels depending on the
> card family, we may need to abstract the name away in order to provide some
> consistency and make listing performance levels easier from a program (may
> it use readdir() or stat()).
>
> Moving the file to debugfs would "fix" the one-value-per-file rule but it
> would also require users to mount debugfs at boot time in order to write the
> default configuration they want for PM instead of just changing
> /etc/sysctl.d/nouveau.conf... On the other hand, I'm not sure we can commit
> on having a stable ABI on the way we display clocks (unless people take them
> as a single value and do not try to parse them) as new hardware will alter
> the semantics of each clock domain, if not drop/split some of them!
>
> Whatever we do, it doesn't look like we can find a nice solution that fits
> every use cases unless we write a userspace program to access this data, but
> this seems highly overkill...

I was thinking just having the list of level ids in the pstate file,
and then stick the current file into debugfs. That way people retain
the ability to see things, as well as use pstate directly for a
configured system.

  -ilia

[PATCH 3/3] drm/radeon: enable bapm by default on desktop TN/RL boards

[Alex Deucher]

On Mon, Jun 23, 2014 at 12:57 PM, Lucas Stach  wrote:
> Am Mittwoch, den 18.06.2014, 16:25 -0400 schrieb Alex Deucher:
>> bapm enabled the GPU and CPU to share TDP headroom.  It was
>> disabled by default since some laptops hung when it was enabled
>> in conjunction with dpm.  It seems to be stable on desktop
>> boards and fixes hangs on boot with dpm enabled on certain
>> boards, so enable it by default on desktop boards.
>>
> Do you have any idea on why it fails on mobile parts? If there is any
> hint I can retest on my failing laptop. It would be nice to be able to
> enbale this on the mobile parts, too.

The problem seems to be related to switching between battery and AC.
There is code in the driver to en/disable bapm on plug/unplug events,
but it only fixed it for some users.

Alex


>
> Regards,
> Lucas
>
>> bug:
>> https://bugs.freedesktop.org/show_bug.cgi?id=72921
>>
>> Signed-off-by: Alex Deucher 
>> ---
>>  drivers/gpu/drm/radeon/trinity_dpm.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/trinity_dpm.c 
>> b/drivers/gpu/drm/radeon/trinity_dpm.c
>> index 2a2822c..20da6ff 100644
>> --- a/drivers/gpu/drm/radeon/trinity_dpm.c
>> +++ b/drivers/gpu/drm/radeon/trinity_dpm.c
>> @@ -1874,7 +1874,15 @@ int trinity_dpm_init(struct radeon_device *rdev)
>>   for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++)
>>   pi->at[i] = TRINITY_AT_DFLT;
>>
>> - pi->enable_bapm = false;
>> + /* There are stability issues reported on latops with
>> +  * bapm installed when switching between AC and battery
>> +  * power.  At the same time, some desktop boards hang
>> +  * if it's not enabled and dpm is enabled.
>> +  */
>> + if (rdev->flags & RADEON_IS_MOBILITY)
>> + pi->enable_bapm = false;
>> + else
>> + pi->enable_bapm = true;
>>   pi->enable_nbps_policy = true;
>>   pi->enable_sclk_ds = true;
>>   pi->enable_gfx_power_gating = true;
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions   | http://www.pengutronix.de/  |
>

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 12:36 PM, Greg KH  wrote:
> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 12:07 PM, Greg KH  wrote:
>> > On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
>> >> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
>> >> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
>> >> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  wrote:
>> >> >> > Hi!
>> >> >> >
>> >> >> > AFAICT, pstate file will contain something like
>> >> >> >
>> >> >> > 07: core 100 MHz memory 123 MHz *
>> >> >> > 08: core 100-200 MHz memory 123 MHz
>> >> >> >
>> >> >> > ...which does not look exactly like one-value-per-file, and I'm 
>> >> >> > pretty
>> >> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
>> >> >> > don't see required documentation in Documentation/ABI.
>> >> >> >
>> >> >> > Should we disable it for now, so that userspace does not start
>> >> >> > depending on it and we'll not have to maintain it forever?
>> >> >> >
>> >> >> > I guess better interface would be something like
>> >> >> >
>> >> >> > pstate/07/core_clock_min
>> >> >> >   core_clock_max
>> >> >> >   memory_clock_min
>> >> >> >   memory_clock_max
>> >> >> >
>> >> >> > and then pstate/active containing just the number of active state?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Pavel
>> >> >> >
>> >> >> > PS: I have no nvidia, got the news at
>> >> >> >
>> >> >> > http://www.phoronix.com/scan.php?page=article=nouveau_try_linux316=2
>> >> >>
>> >> >> FTR, this file has been in place since 3.13, and there was a different
>> >> >> file before it (performance_levels), with a comparable format since
>> >> >> much earlier (definitely 3.8, probably earlier). I think it's meant a
>> >> >> lot more for people looking at it and echo'ing stuff to it to modify
>> >> >> the levels (where supported), than for programs parsing it. Perhaps
>> >> >> sysfs is the wrong place for this -- what is the right place? debugfs?
>> >> >
>> >> > Yes, please move it to debugfs.
>> >>
>> >> Could we just say that the format of this file is one-per-line of
>> >>
>> >> level: information-for-the-user
>> >>
>> >> And you can echo a level into it to switch to that level? That seems
>> >> like a reasonable ABI to have... would be happy to throw it into a
>> >> file somewhere... not sure where though.
>> >
>> > sysfs files are "one value per file", that's it.  Do anything other than
>> > that, and it can not be in sysfs, sorry.
>>
>> I think that's a little inconsistent. There are *tons* of files in
>> sysfs with multiple values. For example "local_cpulist" which contains
>> the string "0-3" for me, the per-connector "modes" file which has a
>> list of modes supported, and a "resource" file which has a list of hex
>> values (which probably have something to do with PCI resources?). [I
>> purposely picked values coming from different parts of the kernel not
>> to focus on one subsystem...]
>
> A list of valid "values" that a file can be in is fine if you just then
> write one value back to that file.  That's the one exception, but a
> minor one given the huge number of sysfs files.  Other than that, if you

Which is pretty much what the pstate file is. Would it make things
better if we removed the descriptive info while leaving the pstate
file in place?

> know of exceptions to that rule, please point them out and I will be
> glad to yell at the developers.
>
> PCI device resources are binary sysfs files, which are just pass-through
> files from the firmware/device to userspace, with no parsing done in the
> kernel.  So that's just a single 'value' as well.

$ cat /sys/class/drm/card0/device/resource
0xf000 0xf03f 0x00140204
0x 0x 0x

Doesn't seem like "binary" in the true sense, but perhaps that's close enough.

  -ilia

unparseable, undocumented /sys/class/drm/.../pstate

[Greg KH]

On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
> On Mon, Jun 23, 2014 at 12:07 PM, Greg KH  wrote:
> > On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
> >> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
> >> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
> >> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  wrote:
> >> >> > Hi!
> >> >> >
> >> >> > AFAICT, pstate file will contain something like
> >> >> >
> >> >> > 07: core 100 MHz memory 123 MHz *
> >> >> > 08: core 100-200 MHz memory 123 MHz
> >> >> >
> >> >> > ...which does not look exactly like one-value-per-file, and I'm pretty
> >> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
> >> >> > don't see required documentation in Documentation/ABI.
> >> >> >
> >> >> > Should we disable it for now, so that userspace does not start
> >> >> > depending on it and we'll not have to maintain it forever?
> >> >> >
> >> >> > I guess better interface would be something like
> >> >> >
> >> >> > pstate/07/core_clock_min
> >> >> >   core_clock_max
> >> >> >   memory_clock_min
> >> >> >   memory_clock_max
> >> >> >
> >> >> > and then pstate/active containing just the number of active state?
> >> >> >
> >> >> > Thanks,
> >> >> > Pavel
> >> >> >
> >> >> > PS: I have no nvidia, got the news at
> >> >> >
> >> >> > http://www.phoronix.com/scan.php?page=article=nouveau_try_linux316=2
> >> >>
> >> >> FTR, this file has been in place since 3.13, and there was a different
> >> >> file before it (performance_levels), with a comparable format since
> >> >> much earlier (definitely 3.8, probably earlier). I think it's meant a
> >> >> lot more for people looking at it and echo'ing stuff to it to modify
> >> >> the levels (where supported), than for programs parsing it. Perhaps
> >> >> sysfs is the wrong place for this -- what is the right place? debugfs?
> >> >
> >> > Yes, please move it to debugfs.
> >>
> >> Could we just say that the format of this file is one-per-line of
> >>
> >> level: information-for-the-user
> >>
> >> And you can echo a level into it to switch to that level? That seems
> >> like a reasonable ABI to have... would be happy to throw it into a
> >> file somewhere... not sure where though.
> >
> > sysfs files are "one value per file", that's it.  Do anything other than
> > that, and it can not be in sysfs, sorry.
> 
> I think that's a little inconsistent. There are *tons* of files in
> sysfs with multiple values. For example "local_cpulist" which contains
> the string "0-3" for me, the per-connector "modes" file which has a
> list of modes supported, and a "resource" file which has a list of hex
> values (which probably have something to do with PCI resources?). [I
> purposely picked values coming from different parts of the kernel not
> to focus on one subsystem...]

A list of valid "values" that a file can be in is fine if you just then
write one value back to that file.  That's the one exception, but a
minor one given the huge number of sysfs files.  Other than that, if you
know of exceptions to that rule, please point them out and I will be
glad to yell at the developers.

PCI device resources are binary sysfs files, which are just pass-through
files from the firmware/device to userspace, with no parsing done in the
kernel.  So that's just a single 'value' as well.

greg k-h

[PATCH] drm: Change link order to load modules first

[Ezequiel Garcia]

Hi Thierry,

Thanks for looking at this.

On 23 Jun 04:58 PM, Thierry Reding wrote:
> On Sun, Jun 22, 2014 at 10:14:36PM -0300, Ezequiel Garcia wrote:
> > Given panels and I2C-connected encoders are required by DRM drivers,
> > we need to change the link order so these are probed first. This commit
> > moves all the i2c, panel and bridge helper drivers so they are probed
> > before the DRM drivers.
> 
> No. We don't need to change the link order.

Could you clarify why? I guess you have some case in mind where changing
the link order breaks things or makes something mis-behave.

> What we need to do is make
> sure that modules deal properly with situations where their resources
> aren't available yet (i.e. EPROBE_DEFER). There are factors other than
> link order that influence probe ordering.
> 

While I understand defering is more robust, it would be systematically
defering the probe when the DRM driver needs an I2C encoder.

Just to name one example, the tilcdc, armada and others requiring TDA998x
encoder will always defered the probe of the DRM, and then re-probe() once
the encoder is ready.

So, unless we have a good reason not to do this, it sounds a bit silly to me.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 12:07 PM, Greg KH  wrote:
> On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
>> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
>> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
>> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  wrote:
>> >> > Hi!
>> >> >
>> >> > AFAICT, pstate file will contain something like
>> >> >
>> >> > 07: core 100 MHz memory 123 MHz *
>> >> > 08: core 100-200 MHz memory 123 MHz
>> >> >
>> >> > ...which does not look exactly like one-value-per-file, and I'm pretty
>> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
>> >> > don't see required documentation in Documentation/ABI.
>> >> >
>> >> > Should we disable it for now, so that userspace does not start
>> >> > depending on it and we'll not have to maintain it forever?
>> >> >
>> >> > I guess better interface would be something like
>> >> >
>> >> > pstate/07/core_clock_min
>> >> >   core_clock_max
>> >> >   memory_clock_min
>> >> >   memory_clock_max
>> >> >
>> >> > and then pstate/active containing just the number of active state?
>> >> >
>> >> > Thanks,
>> >> > Pavel
>> >> >
>> >> > PS: I have no nvidia, got the news at
>> >> >
>> >> > http://www.phoronix.com/scan.php?page=article=nouveau_try_linux316=2
>> >>
>> >> FTR, this file has been in place since 3.13, and there was a different
>> >> file before it (performance_levels), with a comparable format since
>> >> much earlier (definitely 3.8, probably earlier). I think it's meant a
>> >> lot more for people looking at it and echo'ing stuff to it to modify
>> >> the levels (where supported), than for programs parsing it. Perhaps
>> >> sysfs is the wrong place for this -- what is the right place? debugfs?
>> >
>> > Yes, please move it to debugfs.
>>
>> Could we just say that the format of this file is one-per-line of
>>
>> level: information-for-the-user
>>
>> And you can echo a level into it to switch to that level? That seems
>> like a reasonable ABI to have... would be happy to throw it into a
>> file somewhere... not sure where though.
>
> sysfs files are "one value per file", that's it.  Do anything other than
> that, and it can not be in sysfs, sorry.

I think that's a little inconsistent. There are *tons* of files in
sysfs with multiple values. For example "local_cpulist" which contains
the string "0-3" for me, the per-connector "modes" file which has a
list of modes supported, and a "resource" file which has a list of hex
values (which probably have something to do with PCI resources?). [I
purposely picked values coming from different parts of the kernel not
to focus on one subsystem...]

  -ilia

[PATCH 00/22] Add and use pci_zalloc_consistent

[Joe Perches]

On Mon, 2014-06-23 at 10:25 -0700, Luis R. Rodriguez wrote:
> On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
> > Adding the helper reduces object code size as well as overall
> > source size line count.
> > 
> > It's also consistent with all the various zalloc mechanisms
> > in the kernel.
> > 
> > Done with a simple cocci script and some typing.
> 
> Awesome, any chance you can paste in the SmPL? Also any chance
> we can get this added to a make coccicheck so that maintainers
> moving forward can use that to ensure that no new code is
> added that uses the old school API?

Not many of these are recent.

Arnd Bergmann reasonably suggested that the pci_alloc_consistent
api be converted the the more widely used dma_alloc_coherent.

https://lkml.org/lkml/2014/6/23/513

> Shouldn't these drivers just use the normal dma-mapping API now?

and I replied:

https://lkml.org/lkml/2014/6/23/525

> Maybe.  I wouldn't mind.
> They do seem to have a trivial bit of unnecessary overhead for 
> hwdev == NULL ? NULL : >dev

Anyway, here's the little script.
I'm not sure it's worthwhile to add it though.

$ cat ./scripts/coccinelle/api/alloc/pci_zalloc_consistent.cocci
///
/// Use pci_zalloc_consistent rather than
/// pci_alloc_consistent followed by memset with 0
///
/// This considers some simple cases that are common and easy to validate
/// Note in particular that there are no ...s in the rule, so all of the
/// matched code has to be contiguous
///
/// Blatantly cribbed from: scripts/coccinelle/api/alloc/kzalloc-simple.cocci

@@
type T, T2;
expression x;
expression E1,E2,E3;
statement S;
@@

- x = (T)pci_alloc_consistent(E1,E2,E3);
+ x = pci_zalloc_consistent(E1,E2,E3);
  if ((x==NULL) || ...) S
- memset((T2)x,0,E2);

unparseable, undocumented /sys/class/drm/.../pstate

[Greg KH]

On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  wrote:
> >> > Hi!
> >> >
> >> > AFAICT, pstate file will contain something like
> >> >
> >> > 07: core 100 MHz memory 123 MHz *
> >> > 08: core 100-200 MHz memory 123 MHz
> >> >
> >> > ...which does not look exactly like one-value-per-file, and I'm pretty
> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
> >> > don't see required documentation in Documentation/ABI.
> >> >
> >> > Should we disable it for now, so that userspace does not start
> >> > depending on it and we'll not have to maintain it forever?
> >> >
> >> > I guess better interface would be something like
> >> >
> >> > pstate/07/core_clock_min
> >> >   core_clock_max
> >> >   memory_clock_min
> >> >   memory_clock_max
> >> >
> >> > and then pstate/active containing just the number of active state?
> >> >
> >> > Thanks,
> >> > Pavel
> >> >
> >> > PS: I have no nvidia, got the news at
> >> >
> >> > http://www.phoronix.com/scan.php?page=article=nouveau_try_linux316=2
> >>
> >> FTR, this file has been in place since 3.13, and there was a different
> >> file before it (performance_levels), with a comparable format since
> >> much earlier (definitely 3.8, probably earlier). I think it's meant a
> >> lot more for people looking at it and echo'ing stuff to it to modify
> >> the levels (where supported), than for programs parsing it. Perhaps
> >> sysfs is the wrong place for this -- what is the right place? debugfs?
> >
> > Yes, please move it to debugfs.
> 
> Could we just say that the format of this file is one-per-line of
> 
> level: information-for-the-user
> 
> And you can echo a level into it to switch to that level? That seems
> like a reasonable ABI to have... would be happy to throw it into a
> file somewhere... not sure where though.

sysfs files are "one value per file", that's it.  Do anything other than
that, and it can not be in sysfs, sorry.

greg k-h

[PATCH] drm: fix uninitialized acquire_ctx fields (v2)

[Jani Nikula]

On Wed, 18 Jun 2014, Ville Syrj?l?  wrote:
> On Sat, Jun 07, 2014 at 10:55:39AM -0400, Rob Clark wrote:
>> The acquire ctx will typically be declared on the stack, which means we
>> could have garbage values for any uninitialized field.  In this case, it
>> was triggering WARN_ON()s because 'contended' had garbage value.
>> 
>> Go ahead and use memset() to be more future-proof.
>> 
>> v2: now with extra brown paper bag
>> 
>> Reported-by: Ville Syrj?l? 
>> Signed-off-by: Rob Clark 
>
> I thought I already gave these. Well here they are again:
> Reviewed-by: Ville Syrj?l? 
> Tested-by: Ville Syrj?l? 

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

>
>> ---
>>  drivers/gpu/drm/drm_modeset_lock.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
>> b/drivers/gpu/drm/drm_modeset_lock.c
>> index 7c2497d..0dc57d5 100644
>> --- a/drivers/gpu/drm/drm_modeset_lock.c
>> +++ b/drivers/gpu/drm/drm_modeset_lock.c
>> @@ -64,6 +64,7 @@
>>  void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
>>  uint32_t flags)
>>  {
>> +memset(ctx, 0, sizeof(*ctx));
>>  ww_acquire_init(>ww_ctx, _ww_class);
>>  INIT_LIST_HEAD(>locked);
>>  }
>> -- 
>> 1.9.3
>
> -- 
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Christian König]

Am 23.06.2014 10:15, schrieb Michel D?nzer:
> On 19.06.2014 18:45, Christian K?nig wrote:
>> Am 19.06.2014 03:48, schrieb Michel D?nzer:
>>> On 15.06.2014 21:48, Christian K?nig wrote:
>>>> No idea what goes wrong when Marek runs piglit, but 3.15.0+"stop
>>>> poisoning the GART TLB"+"force_gtt" is rock solid here.
>>> FWIW, 3.15 doesn't survive piglit on my Bonaire either, but 3.14 is
>>> fine. 3.15 seems stable on Kaveri though, but I haven't tried the
>>> force_gtt patch on that yet.
>> Yeah, I think it's just me who has a stable system with 3.15 and that
>> annoys me quite a bit.
> FWIW though, my Kaveri doesn't always survive piglit either, e.g. this
> morning it didn't once again, then did after a reboot. (That's using
> SDMA; Kaveri was never switched back to CPDMA)
>
>
>> No idea what's the difference. What versions of LLVM/Mesa/Piglit are you
>> using for the test?
> Current Git of everything.
>
>
>>> There have also been a number of bug reports about stability regressions
>>> in 3.15 on various SI and CIK cards. It seems likely that at least some
>>> of those are related to this issue as well.
>>>
>>> If we can't figure out the problem soon, we probably need to revert the
>>> 'Use normal BOs for page tables' and dependent changes at least for
>>> 3.15.y?
>> I thought about this for the whole 3.15 release cycle, but decided
>> against it. But what we could do is applying the attached trivial patch,
>> it pins down the page tables and so pretty much reverts to the old
>> behavior.
> This patch applied on top of 3.15 + stop poisoning the GART TLB doesn't
> seem to help on my Bonaire, unfortunately.

That's unfortunately what I already expected. Making the page tables 
movable isn't really the cause of the problem, it must be rather 
something else which is a bit more subtle. Like incorrect aligning 
somewhere or something like this.

>
>> I think even when we revert to the old code we have a couple of unsolved
>> problems with the VM support or in the driver in general where we should
>> try to understand the underlying reason for it instead of applying more
>> workarounds.
> I'm not suggesting applying more workarounds but going back to a known
> more stable state. It seems like we've maneuvered ourselves to a rather
> uncomfortable position from there, with no clear way to a better place.
> But if we basically started from the 3.14 state again, we have a few
> known hurdles like mine and Marek's Bonaire etc. which we know any
> further improvements will have to pass before they can be considered for
> general consumption.

Yeah agree, especially on the uncomfortable position.

Please try with the two attached patches applied on top of 3.15 and 
retest. They should revert back to the old implementation.

Thanks for the help,
Christian.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-Revert-drop-non-blocking-allocations-from.patch
Type: text/x-diff
Size: 3502 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140623/f30892fd/attachment-0002.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-radeon-Revert-use-normal-BOs-for-the-page-tables.patch
Type: text/x-diff
Size: 28349 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140623/f30892fd/attachment-0003.patch>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #22 from darkbasic  ---
It happened on 3.16-rc1 too while doing a video call with skype.

-- 
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/20140623/2ae119ac/attachment.html>

[PATCH v2] drm/exynos: defer hdmi probe when fail to get regulators

[Rahul Sharma]

HDMI probe proceeds with dummy regulators when the regulators
are not provided in DT node or regulator provider has not get
probed or failed to register the regulators.

This patch modify hdmi driver to defer the probe in case the
regulators are not available.

Signed-off-by: Rahul Sharma 
---
v2: Return Error code from devm_regulator_get_optional (as it is).

Based on exynos-drm-fixes branch in Inki dae's tree.
 drivers/gpu/drm/exynos/exynos_hdmi.c |   69 --
 1 file changed, 50 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index c104d0c..d05da3b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -83,7 +83,7 @@ struct hdmi_resources {
struct clk  *sclk_pixel;
struct clk  *sclk_hdmiphy;
struct clk  *mout_hdmi;
-   struct regulator_bulk_data  *regul_bulk;
+   struct regulator**regulators;
int regul_count;
 };

@@ -2022,6 +2022,36 @@ static void hdmi_commit(struct exynos_drm_display 
*display)
hdmi_conf_apply(hdata);
 }

+int hdmi_regulator_enable(struct hdmi_context *hdata)
+{
+   struct hdmi_resources *res = >res;
+   int i, ret;
+
+   for (i = 0; i < res->regul_count; ++i) {
+   ret = regulator_enable(res->regulators[i]);
+   if (ret < 0) {
+   DRM_ERROR("fail to enable regulators.\n");
+   return ret;
+   }
+   }
+   return 0;
+}
+
+int hdmi_regulator_disable(struct hdmi_context *hdata)
+{
+   struct hdmi_resources *res = >res;
+   int i, ret;
+
+   for (i = 0; i < res->regul_count; ++i) {
+   ret = regulator_disable(res->regulators[i]);
+   if (ret < 0) {
+   DRM_ERROR("fail to disable regulators.\n");
+   return ret;
+   }
+   }
+   return 0;
+}
+
 static void hdmi_poweron(struct exynos_drm_display *display)
 {
struct hdmi_context *hdata = display->ctx;
@@ -2039,8 +2069,8 @@ static void hdmi_poweron(struct exynos_drm_display 
*display)

pm_runtime_get_sync(hdata->dev);

-   if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
-   DRM_DEBUG_KMS("failed to enable regulator bulk\n");
+   if (hdmi_regulator_enable(hdata))
+   DRM_DEBUG_KMS("failed to enable regulators\n");

/* set pmu hdmiphy control bit to enable hdmiphy */
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
@@ -2077,7 +2107,8 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);

-   regulator_bulk_disable(res->regul_count, res->regul_bulk);
+   if (hdmi_regulator_disable(hdata))
+   DRM_DEBUG_KMS("failed to disable regulators\n");

pm_runtime_put_sync(hdata->dev);

@@ -2192,24 +2223,24 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)

clk_set_parent(res->mout_hdmi, res->sclk_pixel);

-   res->regul_bulk = devm_kzalloc(dev, ARRAY_SIZE(supply) *
-   sizeof(res->regul_bulk[0]), GFP_KERNEL);
-   if (!res->regul_bulk) {
-   ret = -ENOMEM;
-   goto fail;
-   }
+   res->regul_count = ARRAY_SIZE(supply);
+
+   res->regulators = devm_kzalloc(dev, res->regul_count *
+   sizeof(res->regulators[0]), GFP_KERNEL);
+   if (!res->regulators)
+   return -ENOMEM;
+
for (i = 0; i < ARRAY_SIZE(supply); ++i) {
-   res->regul_bulk[i].supply = supply[i];
-   res->regul_bulk[i].consumer = NULL;
-   }
-   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), res->regul_bulk);
-   if (ret) {
-   DRM_ERROR("failed to get regulators\n");
-   return ret;
+   res->regulators[i] =
+   devm_regulator_get_optional(dev, supply[i]);
+   if (IS_ERR(res->regulators[i])) {
+   DRM_ERROR("fail to get regulator: %s.\n",
+   supply[i]);
+   return PTR_ERR(res->regulators[i]);
+   }
}
-   res->regul_count = ARRAY_SIZE(supply);

-   return ret;
+   return 0;
 fail:
DRM_ERROR("HDMI resource init - failed\n");
return ret;
-- 
1.7.9.5

[PATCH 5/5 v2] drm/exynos: enable vsync interrupt while waiting for vblank

[Rahul Sharma]

mixer_wait_for_vblank function expects that the upcoming
vsync interrupt handler routine will clear the
wait_vsync_event atomic variable.

For this to happen, interrupts should be enabled and
disabled properly.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6f18581..7529946 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1019,6 +1019,8 @@ static void mixer_wait_for_vblank(struct 
exynos_drm_manager *mgr)
}
mutex_unlock(_ctx->mixer_mutex);

+   drm_vblank_get(mgr->crtc->dev, mixer_ctx->pipe);
+
atomic_set(_ctx->wait_vsync_event, 1);

/*
@@ -1029,6 +1031,8 @@ static void mixer_wait_for_vblank(struct 
exynos_drm_manager *mgr)
!atomic_read(_ctx->wait_vsync_event),
HZ/20))
DRM_DEBUG_KMS("vblank wait timed out.\n");
+
+   drm_vblank_put(mgr->crtc->dev, mixer_ctx->pipe);
 }

 static void mixer_window_suspend(struct exynos_drm_manager *mgr)
-- 
1.7.9.5

[PATCH 4/5 v2] drm/exynos: soft reset mixer before reconfigure after power-on

[Rahul Sharma]

Mixer soft reset is a recommended step before reconfiguring
the mixer after power on. Mixer looses the previous state of
DMAs if soft reset. This is the recommendation from the
hardware team.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6773b03..6f18581 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1085,6 +1085,8 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
ctx->powered = true;
mutex_unlock(>mixer_mutex);

+   mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
+
mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
mixer_win_reset(ctx);

-- 
1.7.9.5

[PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer

[Rahul Sharma]

Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx, int 
win)
 static void mixer_layer_update(struct mixer_context *ctx)
 {
struct mixer_resources *res = >mixer_res;
-   u32 val;
-
-   val = mixer_reg_read(res, MXR_CFG);

-   /* allow one update per vsync only */
-   if (!(val & MXR_CFG_LAYER_UPDATE_COUNT_MASK))
-   mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+   mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
 }

 static void mixer_graph_buffer(struct mixer_context *ctx, int win)
-- 
1.7.9.5

[PATCH 2/5 v2] drm/exynos: stop mixer before gating clocks during poweroff

[Rahul Sharma]

Mixer should be power gated only after it is gracefully stopped.
The recommended sequence is to Stop the mixer and wait till
it enters to IDLE state before gating the clocks and power to
the mixer.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   15 +++
 drivers/gpu/drm/exynos/regs-mixer.h   |1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c00abbe..d359501 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -377,6 +377,20 @@ static void mixer_run(struct mixer_context *ctx)
mixer_regs_dump(ctx);
 }

+static void mixer_stop(struct mixer_context *ctx)
+{
+   struct mixer_resources *res = >mixer_res;
+   int timeout = 20;
+
+   mixer_reg_writemask(res, MXR_STATUS, 0, MXR_STATUS_REG_RUN);
+
+   while (!(mixer_reg_read(res, MXR_STATUS) & MXR_STATUS_REG_IDLE) &&
+   --timeout)
+   usleep_range(1, 12000);
+
+   mixer_regs_dump(ctx);
+}
+
 static void vp_video_buffer(struct mixer_context *ctx, int win)
 {
struct mixer_resources *res = >mixer_res;
@@ -1094,6 +1108,7 @@ static void mixer_poweroff(struct exynos_drm_manager *mgr)
}
mutex_unlock(>mixer_mutex);

+   mixer_stop(ctx);
mixer_window_suspend(mgr);

ctx->int_en = mixer_reg_read(res, MXR_INT_EN);
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
b/drivers/gpu/drm/exynos/regs-mixer.h
index 4537026..5f32e1a 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -78,6 +78,7 @@
 #define MXR_STATUS_BIG_ENDIAN  (1 << 3)
 #define MXR_STATUS_ENDIAN_MASK (1 << 3)
 #define MXR_STATUS_SYNC_ENABLE (1 << 2)
+#define MXR_STATUS_REG_IDLE(1 << 1)
 #define MXR_STATUS_REG_RUN (1 << 0)

 /* bits for MXR_CFG */
-- 
1.7.9.5

[PATCH 1/5 v2] drm/exynos: set power state variable after enabling clocks and power

[Rahul Sharma]

Power state variable holds the state of the mixer device.
Power on and power off functions are toggling these variable
at wrong place.

State variable should be changed to true only after Runtime
PM and clocks are enabled. Else it may result to a situation
where mixer registers are accessed with device power enabled.
Similar logic for poweroff sequence.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c5aed7..c00abbe 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1061,7 +1061,7 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
mutex_unlock(>mixer_mutex);
return;
}
-   ctx->powered = true;
+
mutex_unlock(>mixer_mutex);

pm_runtime_get_sync(ctx->dev);
@@ -1072,6 +1072,10 @@ static void mixer_poweron(struct exynos_drm_manager *mgr)
clk_prepare_enable(res->sclk_mixer);
}

+   mutex_lock(>mixer_mutex);
+   ctx->powered = true;
+   mutex_unlock(>mixer_mutex);
+
mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
mixer_win_reset(ctx);

@@ -1084,14 +1088,20 @@ static void mixer_poweroff(struct exynos_drm_manager 
*mgr)
struct mixer_resources *res = >mixer_res;

mutex_lock(>mixer_mutex);
-   if (!ctx->powered)
-   goto out;
+   if (!ctx->powered) {
+   mutex_unlock(>mixer_mutex);
+   return;
+   }
mutex_unlock(>mixer_mutex);

mixer_window_suspend(mgr);

ctx->int_en = mixer_reg_read(res, MXR_INT_EN);

+   mutex_lock(>mixer_mutex);
+   ctx->powered = false;
+   mutex_unlock(>mixer_mutex);
+
clk_disable_unprepare(res->mixer);
if (ctx->vp_enabled) {
clk_disable_unprepare(res->vp);
@@ -1099,12 +1109,6 @@ static void mixer_poweroff(struct exynos_drm_manager 
*mgr)
}

pm_runtime_put_sync(ctx->dev);
-
-   mutex_lock(>mixer_mutex);
-   ctx->powered = false;
-
-out:
-   mutex_unlock(>mixer_mutex);
 }

 static void mixer_dpms(struct exynos_drm_manager *mgr, int mode)
-- 
1.7.9.5

[PATCH 0/5 v2] drm/exynos: fix for misc issues related to exynos mixer

[Rahul Sharma]

Fixes for various issues which are to Power On/Off sequence,
Layer update, waiting for vblank in exynos mixer driver.

v2: 1) Repalce mixer_enable_vblank with drm_vblank_get.

This series is based on exynos-drm-fixes branch in Inki dae's tree.

Rahul Sharma (5):
  drm/exynos: set power state variable after enabling clocks and power
  drm/exynos: stop mixer before gating clocks during poweroff
  drm/exynos: allow mulitple layer updates per vsync for mixer
  drm/exynos: soft reset mixer before reconfigure after power-on
  drm/exynos: enable vsync interrupt while waiting for vblank

 drivers/gpu/drm/exynos/exynos_mixer.c |   50 +++--
 drivers/gpu/drm/exynos/regs-mixer.h   |1 +
 2 files changed, 36 insertions(+), 15 deletions(-)

-- 
1.7.9.5

[REPOST PATCH 4/8] android: convert sync to fence api, v5

[Maarten Lankhorst]

Hey,

op 20-06-14 22:52, Thierry Reding schreef:
> On Thu, Jun 19, 2014 at 02:28:14PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding
>>  wrote:
> With these changes, can we pull the android sync logic out of
> drivers/staging/ now?
 Afaik the google guys never really looked at this and acked it. So I'm not
 sure whether they'll follow along. The other issue I have as the
 maintainer of gfx driver is that I don't want to implement support for two
 different sync object primitives (once for dma-buf and once for android
 syncpts), and my impression thus far has been that even with this we're
 not there.

 I'm trying to get our own android guys to upstream their i915 syncpts
 support, but thus far I haven't managed to convince them to throw people's
 time at this.
>>> This has been discussed a fair bit internally recently and some of our
>>> GPU experts have raised concerns that this may result in seriously
>>> degraded performance in our proprietary graphics stack. Now I don't care
>>> very much for the proprietary graphics stack, but by extension I would
>>> assume that the same restrictions are relevant for any open-source
>>> driver as well.
>>>
>>> I'm still trying to fully understand all the implications and at the
>>> same time get some of the people who raised concerns to join in this
>>> discussion. As I understand it the concern is mostly about explicit vs.
>>> implicit synchronization and having this mechanism in the kernel will
>>> implicitly synchronize all accesses to these buffers even in cases where
>>> it's not needed (read vs. write locks, etc.). In one particular instance
>>> it was even mentioned that this kind of implicit synchronization can
>>> lead to deadlocks in some use-cases (this was mentioned for Android
>>> compositing, but I suspect that the same may happen for Wayland or X
>>> compositors).
>> Well the implicit fences here actually can't deadlock. That's the
>> entire point behind using ww mutexes. I've also heard tons of
>> complaints about implicit enforced syncing (especially from opencl
>> people), but in the end drivers and always expose unsynchronized
>> access for specific cases. We do that in i915 for upload buffers and
>> other fun stuff. This is about shared stuff across different drivers
>> and different processes.
> Tegra K1 needs to share buffers across different drivers even for very
> basic use-cases since the GPU and display drivers are separate. So while
> I agree that the GPU driver can still use explicit synchronization for
> internal work, things aren't that simple in general.
>
> Let me try to reconstruct the use-case that caused the lock on Android:
> the compositor uses a hardware overlay to display an image. The system
> detects that there's little activity and instructs the compositor to put
> everything into one image and scan out only that (for power efficiency).
> Now with implicit locking the display driver has a lock on the image, so
> the GPU (used for compositing) needs to wait for it before it can
> composite everything into one image. But the display driver cannot
> release the lock on the image until the final image has been composited
> and can be displayed instead.
>
> This may not be technically a deadlock, but it's still a stalemate.
> Unless I'm missing something fundamental about DMA fences and ww mutexes
> I don't see how you can get out of this situation.
This sounds like a case for implicit shared fences. ;-) Reading and scanning 
out would
only wait for the last 'exclusive' fence, not on each other.

But in drivers/drm I can encounter a similar issue, people expect to be able to
overwrite the contents of the currently displayed buffer, so I 'solved' it by 
not adding
a fence on the buffer, only by waiting for buffer idle before page flipping.
The rationale is that the buffer is pinned internally, and the backing storage 
cannot
go away until dma_buf_unmap_attachment is called. So when you render to the
current front buffer without queuing a page flip you get exactly what you 
expect. ;-)

> Explicit vs. implicit synchronization may also become more of an issue
> as buffers are imported from other sources (such as cameras).
Yeah, but the kernel space primitives would in both cases be the same, so 
drivers don't need to implement 2 separate fencing mechanisms for that. :-)

~Maarten

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #21 from agapito  ---
It happened again. In this case with 3.16.rc2, resizing a firefox windows with
flash content (vdpau on).

-- 
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/20140623/645f4b68/attachment.html>

[PATCH 00/22] Add and use pci_zalloc_consistent

[Luis R. Rodriguez]

On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
> Adding the helper reduces object code size as well as overall
> source size line count.
> 
> It's also consistent with all the various zalloc mechanisms
> in the kernel.
> 
> Done with a simple cocci script and some typing.

Awesome, any chance you can paste in the SmPL? Also any chance
we can get this added to a make coccicheck so that maintainers
moving forward can use that to ensure that no new code is
added that uses the old school API?

  Luis

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

Collin  changed:

   What|Removed |Added

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

--- Comment #26 from Collin  ---
Should this be marked as fixed or is there any other types of testing needed?

-- 
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/20140623/7ab32f58/attachment.html>

unparseable, undocumented /sys/class/drm/.../pstate

[Ilia Mirkin]

On Mon, Jun 23, 2014 at 9:02 AM, Pavel Machek  wrote:
> On Sun 2014-06-22 22:12:14, Ilia Mirkin wrote:
>> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH  wrote:
>> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
>> >> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek  wrote:
>> >> > Hi!
>> >> >
>> >> > AFAICT, pstate file will contain something like
>> >> >
>> >> > 07: core 100 MHz memory 123 MHz *
>> >> > 08: core 100-200 MHz memory 123 MHz
>> >> >
>> >> > ...which does not look exactly like one-value-per-file, and I'm pretty
>> >> > sure userspace will get it wrong if it tries to parse it. Plus, I
>> >> > don't see required documentation in Documentation/ABI.
>> >> >
>> >> > Should we disable it for now, so that userspace does not start
>> >> > depending on it and we'll not have to maintain it forever?
>> >> >
>> >> > I guess better interface would be something like
>> >> >
>> >> > pstate/07/core_clock_min
>> >> >   core_clock_max
>> >> >   memory_clock_min
>> >> >   memory_clock_max
>> >> >
>> >> > and then pstate/active containing just the number of active state?
>
>> Could we just say that the format of this file is one-per-line of
>>
>> level: information-for-the-user
>
> But it is not.

But it is...

> Management tools will want to parse it, sooner or
> later.  What is wrong with solution described above?

It is complex and annoying to the people that will actually use it.

>
>> And you can echo a level into it to switch to that level? That seems
>> like a reasonable ABI to have... would be happy to throw it into a
>> file somewhere... not sure where though.
>
> Documentation/ABI/testing/

Yes, I got that far. And then I became confused.

  -ilia

[PATCH 06/22] i810: Use pci_zalloc_consistent

[Joe Perches]

Remove the now unnecessary memset too.

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/i810/i810_dma.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index e88bac1..bae897d 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -393,15 +393,14 @@ static int i810_dma_initialize(struct drm_device *dev,

/* Program Hardware Status Page */
dev_priv->hw_status_page =
-   pci_alloc_consistent(dev->pdev, PAGE_SIZE,
-_priv->dma_status_page);
+   pci_zalloc_consistent(dev->pdev, PAGE_SIZE,
+ _priv->dma_status_page);
if (!dev_priv->hw_status_page) {
dev->dev_private = (void *)dev_priv;
i810_dma_cleanup(dev);
DRM_ERROR("Can not allocate hardware status page\n");
return -ENOMEM;
}
-   memset(dev_priv->hw_status_page, 0, PAGE_SIZE);
DRM_DEBUG("hw status page @ %p\n", dev_priv->hw_status_page);

I810_WRITE(0x02080, dev_priv->dma_status_page);
-- 
1.8.1.2.459.gbcd45b4.dirty

[PATCH 00/22] Add and use pci_zalloc_consistent

[Joe Perches]

Adding the helper reduces object code size as well as overall
source size line count.

It's also consistent with all the various zalloc mechanisms
in the kernel.

Done with a simple cocci script and some typing.

Joe Perches (22):
  pci-dma-compat: Add pci_zalloc_consistent helper
  atm: Use pci_zalloc_consistent
  block: Use pci_zalloc_consistent
  crypto: Use pci_zalloc_consistent
  infiniband: Use pci_zalloc_consistent
  i810: Use pci_zalloc_consistent
  media: Use pci_zalloc_consistent
  amd: Use pci_zalloc_consistent
  atl1e: Use pci_zalloc_consistent
  enic: Use pci_zalloc_consistent
  sky2: Use pci_zalloc_consistent
  micrel: Use pci_zalloc_consistent
  qlogic: Use pci_zalloc_consistent
  irda: Use pci_zalloc_consistent
  ipw2100: Use pci_zalloc_consistent
  mwl8k: Use pci_zalloc_consistent
  rtl818x: Use pci_zalloc_consistent
  rtlwifi: Use pci_zalloc_consistent
  scsi: Use pci_zalloc_consistent
  staging: Use pci_zalloc_consistent
  synclink_gt: Use pci_zalloc_consistent
  vme: bridges: Use pci_zalloc_consistent

 drivers/atm/he.c   | 31 -
 drivers/atm/idt77252.c | 15 
 drivers/block/DAC960.c | 18 +-
 drivers/block/cciss.c  | 11 +++---
 drivers/block/skd_main.c   | 25 +-
 drivers/crypto/hifn_795x.c |  5 ++-
 drivers/gpu/drm/i810/i810_dma.c|  5 ++-
 drivers/infiniband/hw/amso1100/c2.c|  6 ++--
 drivers/infiniband/hw/nes/nes_hw.c | 12 +++
 drivers/infiniband/hw/nes/nes_verbs.c  |  5 ++-
 drivers/media/common/saa7146/saa7146_core.c| 15 
 drivers/media/common/saa7146/saa7146_fops.c|  5 +--
 drivers/media/pci/bt8xx/bt878.c| 16 +++--
 drivers/media/pci/ngene/ngene-core.c   |  7 ++--
 drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c  | 11 ++
 drivers/media/usb/ttusb-dec/ttusb_dec.c| 11 ++
 drivers/net/ethernet/amd/pcnet32.c | 16 -
 drivers/net/ethernet/atheros/atl1e/atl1e_main.c|  7 ++--
 drivers/net/ethernet/cisco/enic/vnic_dev.c |  8 ++---
 drivers/net/ethernet/marvell/sky2.c|  5 ++-
 drivers/net/ethernet/micrel/ksz884x.c  |  7 ++--
 .../net/ethernet/qlogic/netxen/netxen_nic_ctx.c|  4 +--
 drivers/net/ethernet/qlogic/qlge/qlge_main.c   | 11 +++---
 drivers/net/irda/vlsi_ir.c |  4 +--
 drivers/net/wireless/ipw2x00/ipw2100.c | 16 +++--
 drivers/net/wireless/mwl8k.c   |  6 ++--
 drivers/net/wireless/rtl818x/rtl8180/dev.c | 11 +++---
 drivers/net/wireless/rtlwifi/pci.c | 17 +++--
 drivers/scsi/3w-sas.c  |  5 ++-
 drivers/scsi/a100u2w.c |  8 ++---
 drivers/scsi/be2iscsi/be_main.c| 10 +++---
 drivers/scsi/be2iscsi/be_mgmt.c|  3 +-
 drivers/scsi/csiostor/csio_wr.c|  8 +
 drivers/scsi/eata.c|  5 ++-
 drivers/scsi/hpsa.c|  8 ++---
 drivers/scsi/megaraid/megaraid_mbox.c  | 16 -
 drivers/scsi/megaraid/megaraid_sas_base.c  |  8 ++---
 drivers/scsi/mesh.c|  6 ++--
 drivers/scsi/mvumi.c   |  9 ++---
 drivers/scsi/pm8001/pm8001_sas.c   |  5 ++-
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c   | 15 +++-
 drivers/staging/rtl8192ee/pci.c| 37 +++-
 drivers/staging/rtl8821ae/pci.c| 36 +++
 drivers/staging/slicoss/slicoss.c  |  9 ++---
 drivers/staging/vt6655/device_main.c   | 40 +++---
 drivers/tty/synclink_gt.c  |  5 ++-
 drivers/vme/bridges/vme_ca91cx42.c |  6 ++--
 drivers/vme/bridges/vme_tsi148.c   |  6 ++--
 include/asm-generic/pci-dma-compat.h   |  8 +
 49 files changed, 209 insertions(+), 354 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

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

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

Raul Fernandes  changed:

   What|Removed |Added

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

--- Comment #8 from Raul Fernandes  ---
I will open another bug to cover the crash when I have more info about that.
For now, the artifacts are fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: