unparseable, undocumented /sys/class/drm/.../pstate
On Sat 2014-06-21 14:22:59, 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. ... > > 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 According to the article, it is only starting to work now. I know articles can be wrong, but I don't have that hardware... Sorry if it is the case. > 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? debugfs would work, yes. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[Bug 80311] 3D acceleration is broken with recent llvm and git
https://bugs.freedesktop.org/show_bug.cgi?id=80311 Will H changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Will H --- Indeed, it is fixed for me now :). Thanks. -- 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/20140621/3288f681/attachment.html>
unparseable, undocumented /sys/class/drm/.../pstate
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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
unparseable, undocumented /sys/class/drm/.../pstate
On Sat, Jun 21, 2014 at 2:50 PM, Pavel Machek wrote: > On Sat 2014-06-21 14:22:59, 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. > ... >> >> 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 > > According to the article, it is only starting to work now. I know > articles can be wrong, but I don't have that hardware... Sorry if it > is the case. Commit 26fdd78cce3f51a49e1f2d3ad27ee893a28d220e introduced this particular one. Commit 330c5988ee78045e6a731c3693251aaa5b0d14e3 had introduced the former version, which was removed in 3.13, replaced with the new one. > >> 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? > > debugfs would work, yes. > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
unparseable, undocumented /sys/class/drm/.../pstate
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? -ilia
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #20 from agapito --- OK forget it. It's not a firmware related problem. I had this bug with old firmware on kernel 3.15.1. I resized a flash video window (vdpau accelerated) and lost my screen. -- 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/20140621/d064008a/attachment.html>
unparseable, undocumented /sys/class/drm/.../pstate
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. greg k-h
[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750
https://bugs.freedesktop.org/show_bug.cgi?id=80235 --- Comment #7 from Raul Fernandes --- Yes, it fixes the artifacts with drm-fixes-3.16, but the reboots are still there. I will see if Xorg.0.log or dmesg show any error. I will have to use another computer to do it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140621/56a09bb7/attachment.html>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #42 from kilobug at kilobug.org --- I tried with audio=0 with 3.14 and 3.15-rc8, and it's slightly better, but there are still freezes. X doesn't crash at startup anymore even with hyperz enabled, but using an OpenGL game or playing a HD movie with mplayer ends up with a system freeze after a while, with hyperz enabled or disabled. -- 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?)
https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #5 from t3st3r at mail.ru --- Will try that since that bug is nasty enough. Can take some time. As initial investigation when looking on commit log and matching encounters of bugs, it appears stability issues were fixed at result of commit 0a4ae727d6aa459247b027387edb6ff99f657792 (appears between 3.15-rc8 -> 3.15 release). So all 3.15 RCs were not stable on R9 270. However, 3.15 release is okay due to these last-minute fixes. Yet 0a4ae727d6aa459247b027387edb6ff99f657792 seems to be composed of few commits, lets chew a bit more on it. Most likely it comes down to 91b0275c0ecd1870c5f8bfb73e2da2d6c29414b3. I think I would try little experiment first: return CPDMA as it was in 3.15 last minute fix and see if stability returns to 3.16-rc1 with R9 270. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80311] 3D acceleration is broken with recent llvm and git
https://bugs.freedesktop.org/show_bug.cgi?id=80311 --- Comment #1 from Ilia Mirkin --- You probably need: http://cgit.freedesktop.org/mesa/mesa/commit/?id=93b6b1fa83a2000f7a60ca12df54c2dd808a87a8 -- 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/20140621/66526c26/attachment-0001.html>
[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support
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 line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
