[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
2015-04-30 2:31 GMT+09:00 Kevin Hilman : > Krzysztof Kozlowski writes: > >> After adding display power domain for Exynos5250 in commit >> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the >> display on Chromebook Snow and others stopped working after boot. >> >> The reason for this suggested Andrzej Hajda: the DP clock was disabled. >> This clock is required by Display Port and is enabled by bootloader. >> However when FIMD driver probing was deferred, the display power domain >> was turned off. This effectively reset the value of DP clock enable >> register. >> >> When exynos-dp is later probed, the clock is not enabled and display is >> not properly configured: >> >> exynos-dp 145b.dp-controller: Timeout of video streamclk ok >> exynos-dp 145b.dp-controller: unable to config video >> >> Signed-off-by: Krzysztof Kozlowski >> Reported-by: Javier Martinez Canillas >> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") >> Cc: >> >> --- >> >> This should fix issue reported by Javier [1][2]. >> >> Tested on Chromebook Snow (Exynos 5250). More testing would be great, >> especially on other Exynos 5xxx products. > > I hoped to try this on my exynos5 boards, but it doesn't seem to apply > to linux-next or to Linus' master branch. > > Are there some other dependencies here? It is already applied: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc Best regards, Krzysztof
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #18 from Kevin --- Tom, thank you for your help! I'm new to testing patches so this is what I did. I am using Arch and used the mesa-git in the AUR to build mesa from git. I did the following and got this message so I did not attempt to compile. cd ~/builds/mesa-git/src/mesa $ patch -pl < ~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch patch: strip count l is not a number -- 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/20150430/813c4c6b/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #19 from Kevin --- OK, I now see that I am dumb and I typed -pl instead of p1. I downloaded mesa-10.5.4.tar.gz from ftp://ftp.freedesktop.org/pub/mesa/10.5.4/ and unpacked it. I then tried to patch but it seems the file needed is missing. Sorry for my noobness, I am trying to learn. $ patch -p1 < ~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch can't find file to patch at input line 16 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |From 36d89bfaa834151adbc56315c771e1ba7fa12c7f Mon Sep 17 00:00:00 2001 |From: Tom Stellard |Date: Tue, 31 Mar 2015 17:52:24 + |Subject: [PATCH] R600/SI: Add VCC as an implict def of SI_KILL | |When SI_KILL has a register operand, its lowered form writes to vcc. |--- | lib/Target/R600/SIInstructions.td | 9 ++--- | test/CodeGen/R600/llvm.AMDGPU.kill.ll | 16 | 2 files changed, 22 insertions(+), 3 deletions(-) | |diff --git a/lib/Target/R600/SIInstructions.td b/lib/Target/R600/SIInstructions.td |index 95b2470..d1db4ab 100644 |--- a/lib/Target/R600/SIInstructions.td |+++ b/lib/Target/R600/SIInstructions.td -- File to patch: ^C -- 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/20150430/41597b40/attachment-0001.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #20 from Kevin --- OK, so I just realized this patch needs to be applied against llvm...so I have downloaded 3.6.0 from http://llvm.org/releases/download.html#3.6.0 and applied your patch. I am now attempting to compile. $ patch -p1 < ~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch patching file lib/Target/R600/SIInstructions.td Hunk #1 succeeded at 1809 (offset -86 lines). Hunk #2 succeeded at 1867 (offset -86 lines). patching file test/CodeGen/R600/llvm.AMDGPU.kill.ll Hunk #1 succeeded at 15 (offset -1 lines). -- 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/20150430/313b929f/attachment.html>
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #38 from Erik --- I patched a 4.0.1 kernel on a Debian 8 for testing . i will test it with several movies :) -- 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/20150430/e5e9e58f/attachment-0001.html>
[Bug 96351] System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 --- Comment #30 from Michel Dänzer --- Commit 1a81b94d4fc8470848eb80e39a6001c48cc3fc29 is specific to the c6x architecture, so it can't be the cause of your problem. Looks like something went wrong during the bisection. Most likely, you incorrectly declared a commit as 'good' which was actually bad, because the problem doesn't happen every time even with (some) bad commits. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90202] Firefox nightly hangs with accelerated layers and latest r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=90202 --- Comment #6 from Michel Dänzer --- (In reply to Ernst Sjöstrand from comment #5) > The backtraces are when using DRI2. What do you mean by that? As you pointed out yourself in comment #3, that backtrace is clearly from running with DRI3 enabled. -- 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/20150430/e66d0d5f/attachment.html>
[Bug 90221] Triangle boundary artifact on Shadow Warrior game
https://bugs.freedesktop.org/show_bug.cgi?id=90221 Michel Dänzer changed: What|Removed |Added Attachment #115419|text/plain |image/jpeg mime type|| -- 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/20150430/2074d7f5/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #21 from Kevin --- Alright, so I think I did this correctly, but it did not help. This is what I did... cd ~/Downloads/llvm-3.6.0.src/ patch -p1 < ~/Downloads/0001-R600-SI-Add-VCC-as-an-implict-def-of-SI_KILL.patch cd ~/Downloads/llvm-cmake/ cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=prefix=/usr/local ~/Downloads/llvm-3.6.0.src/ make sudo make install Then I rebooted and ran Dota 2 and tried to view Morphling in the loadout screen and my system froze the same as before. So I am thinking since Steam runs everything in 32-bit, that perhaps I need to apply this patch somehow to lib32-llvm? Sorry again for not knowing how to do this properly. -- 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/20150430/237fdb73/attachment.html>
[Bug 90221] Triangle boundary artifact on Shadow Warrior game
https://bugs.freedesktop.org/show_bug.cgi?id=90221 --- Comment #1 from Michel Dänzer --- (In reply to Lucas from comment #0) > Some special effects trigger a visible artifact on triangle primitive > boundaries, probably, see screenshot attached. Looks like bug 88642, which is fixed in current LLVM. > Running with the following env var (otherwise the game is unplayable slow on > current video settings): > R600_DEBUG=sb That environment variable has no effect with the radeonsi driver. -- 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/20150430/4728a1d5/attachment.html>
[PATCH 3/8] drivers/mfd: Add lookup table for Panel Control as GPIO signal
On 04/29/2015 07:57 PM, Lee Jones wrote: > On Wed, 29 Apr 2015, Shobhit Kumar wrote: > >> On some Intel SoC platforms, the panel enable/disable signals are >> controlled by CRC PMIC. Add those control as a new GPIO in a lookup >> table for gpio-crystalcove chip during CRC driver load >> >> v2: Make the lookup table static (Thierry) >> Remove the lookup table during driver remove (Thierry) >> >> CC: Samuel Ortiz >> Cc: Linus Walleij >> Cc: Alexandre Courbot >> Cc: Thierry Reding >> Signed-off-by: Shobhit Kumar >> --- >> drivers/mfd/intel_soc_pmic_core.c | 17 + >> 1 file changed, 17 insertions(+) > > I have no idea what this stuff is, but it looks plausible. The CRC PMIC controls the panel enable/disable signal using one of GPIO like lines. It was agreed by Linus Walleij to go this way. The matching crystalcove gpio changes are already merged in Linux next as - http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e189ca56d91bbf1d3fe2f88ab6858bf919d42adf This just adds a consumer lookup table for the gpio. Since we do not have a DT or board files, and since this was part of CRC driver, just added the lookup table during CRC driver load itself. Same is done for PWM in a later patch. Regards Shobhit > > For my own reference: > Acked-by: Lee Jones > >> diff --git a/drivers/mfd/intel_soc_pmic_core.c >> b/drivers/mfd/intel_soc_pmic_core.c >> index 7b50b6b..f3d918e 100644 >> --- a/drivers/mfd/intel_soc_pmic_core.c >> +++ b/drivers/mfd/intel_soc_pmic_core.c >> @@ -24,8 +24,19 @@ >> #include >> #include >> #include >> +#include >> #include "intel_soc_pmic_core.h" >> >> +/* Lookup table for the Panel Enable/Disable line as GPIO signals */ >> +static struct gpiod_lookup_table panel_gpio_table = { >> +/* Intel GFX is consumer */ >> +.dev_id = ":00:02.0", >> +.table = { >> +/* Panel EN/DISABLE */ >> +GPIO_LOOKUP("gpio_crystalcove", 94, "panel", GPIO_ACTIVE_HIGH), >> +}, >> +}; >> + >> static int intel_soc_pmic_find_gpio_irq(struct device *dev) >> { >> struct gpio_desc *desc; >> @@ -85,6 +96,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c, >> if (ret) >> dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret); >> >> +/* Add lookup table binding for Panel Control to the GPIO Chip */ >> +gpiod_add_lookup_table(&panel_gpio_table); >> + >> ret = mfd_add_devices(dev, -1, config->cell_dev, >>config->n_cell_devs, NULL, 0, >>regmap_irq_get_domain(pmic->irq_chip_data)); >> @@ -104,6 +118,9 @@ static int intel_soc_pmic_i2c_remove(struct i2c_client >> *i2c) >> >> regmap_del_irq_chip(pmic->irq, pmic->irq_chip_data); >> >> +/* Remove lookup table for Panel Control from the GPIO Chip */ >> +gpiod_remove_lookup_table(&panel_gpio_table); >> + >> mfd_remove_devices(&i2c->dev); >> >> return 0; >
[GIT PULL] drm/rockchip: fixes and be rockchip/drm maintainer
Hi Dave, Am Montag, 20. April 2015, 09:30:06 schrieb Mark yao: > Hi Dave > I'm interesting to maintain the rockchip drm, so add entry for > Rockchip drm. > and some fixes. can you consider these as fixes for 4.1? Thanks Heiko > > Can you land them? > > The following changes since commit aa219a0dd7774e2454a5687e7d38e947a131cdee: > >Merge tag 'drm-intel-next-fixes-2015-04-15' of > git://anongit.freedesktop.org/drm-intel into drm-next (2015-04-16 > 08:34:51 +1000) > > are available in the git repository at: > > >https://github.com/markyzq/kernel-drm-rockchip.git drm-next0420 > > for you to fetch changes up to 3ea68922fc4148abc97557df43d4ba9a136b1c8d: > >drm/rockchip: fix error check when getting irq (2015-04-20 09:02:31 > +0800) > > > Heiko Stuebner (2): >MAINTAINERS: add entry for Rockchip drm drivers >drm/rockchip: fix error check when getting irq > > MAINTAINERS |7 +++ > drivers/gpu/drm/rockchip/rockchip_drm_vop.c |9 + > 2 files changed, 12 insertions(+), 4 deletions(-)
[Bug 96351] System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 --- Comment #31 from George Cheban --- Compiled a new kernel v4.1: # git checkout -b v4.1 # git revert 1a81b94... /* 30 minutes to find out how to quit from VIM :D */ # make oldconfig # make -j3 && make modules_install && make install # reboot Working with 4.1.0-rc1+ about 5 hours. Tried everything: Full HD Videos on both monitors (1st Firefox, 2nd - Chrome, which is really impressive, because Chrome in 90% of situations makes my system hang up) + compiling new kernel + downloading videos via browser + downloading via torrent + writing to flashdrive 10 gb of videos + playing video from another flash + copying some files from 3rd flashdrive >>> All this in the same time. System works fine. Don't have any ideas how to make it hang up. Attaching screenshot for you to see. What to do next? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 96351] System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 --- Comment #32 from George Cheban --- Created attachment 175331 --> https://bugzilla.kernel.org/attachment.cgi?id=175331&action=edit Screenshot -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 96351] System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 --- Comment #33 from George Cheban --- Sorry guys, made it hang up by opening player fullscreen and by grabbing it to top of working space. For now can't even boot to any kernel because of "Minimal Bash-like line editing is supported". Will try to bisect again T_T. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 97561] New: Regression: Issue with ATI HD 6570 (possibly others) HDMI output Purple Line
https://bugzilla.kernel.org/show_bug.cgi?id=97561 Bug ID: 97561 Summary: Regression: Issue with ATI HD 6570 (possibly others) HDMI output Purple Line Product: Drivers Version: 2.5 Kernel Version: 4.0 and above Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: fr0 at bitservices.org.uk Regression: No Hi, First ever kernel bug report so apologies for possibly getting it wrong. Both Linux version 4.0 and 4.1-rc now display a vertical purple line on the far left hand side of the screen. This only happens when using HDMI output and seems to be related to HDMI audio. Happens with MESA 10.5 and MESA 10.6 devel, happens on both Arch Linux and Linux Mint (using a mainline kernel). Problem does NOT happen on Linux 3.19.3 and earlier. Image of problem: https://lh3.googleusercontent.com/-i_dXYiwJNBE/VUE1pbSid4I/Eus/uAfOCER4PSE/s912/IMG_20150429_203014.jpg Very similar bug: https://bugzilla.kernel.org/show_bug.cgi?id=43154 (resolved, but appears to be happening again). lspci: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550] Giving this command resolves the problem - hence I think it is related to the audio output part of the dri driver and is very similar to the bug linked too above: xrandr --output HDMI-0 --auto --set audio off I am happy to provide logs of anything - please let me know what you need. I don't want to take a wild guess and provide everything. Thanks ! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #257 from Maciej Gluszek --- @Guram Savinov: I also tried setting DPM + high performance for my HD3650 and it worked but the fan was still running too loud (not overheating just loud). Then i installed Kernel 4.0, removed "high performance" settings and it works great now. I still have DPM set during boot but no more setting the card to be running on high performance. Couple of days and no lockups. I'm on Ubuntu. -- 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/20150430/d38bf5cc/attachment.html>
[Bug 95911] Recursive error in radeon device driver module after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=95911 Michel Dänzer changed: What|Removed |Added CC||christian.koenig at amd.com --- Comment #8 from Michel Dänzer --- Can you attach the kernel log from before and across suspend/resume as well? Christian, any ideas? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 95911] Recursive error in radeon device driver module after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=95911 --- Comment #9 from gitne at excite.co.jp --- (In reply to Michel Dänzer from comment #8) > Can you attach the kernel log from before and across suspend/resume as well? I can try but there seems to be nothing worth noting before resume. Is there any kernel boot parameter or a radeon module parameter that I can tune to get a more verbose kernel log? I'll try running on my latest F21 kernel version 3.19.5 but I doubt I'll see any improvement, judging by the changelog. Best regards -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] libgencec: Add userspace library for the generic CEC kernel interface
Hi Emil, From: linux-media-ow...@vger.kernel.org [mailto:linux-media- owner at vger.kernel.org] On Behalf Of Emil Velikov Sent: Wednesday, April 29, 2015 5:00 PM > > Hi Kamil, > > Allow me to put a few suggestions: > > On 29 April 2015 at 11:02, Kamil Debski wrote: > > This is the first version of the libGenCEC library. It was designed > to > > act as an interface between the generic CEC kernel API and userspace > > applications. It provides a simple interface for applications and an > > example application that can be used to test the CEC functionality. > > > > signed-off-by: Kamil Debski > > --- > > AUTHORS |1 + > > INSTALL |9 + > > LICENSE | 202 > > Makefile.am |4 + > > README | 22 ++ > > configure.ac | 24 ++ > > doc/index.html | 345 +++ > > examples/Makefile.am |4 + > > examples/cectest.c | 631 > ++ > > include/gencec.h | 255 > > src/Makefile.am |4 + > > src/gencec.c | 445 +++ > > 12 files changed, 1946 insertions(+) > > create mode 100644 AUTHORS > > create mode 100644 INSTALL > > create mode 100644 LICENSE > > create mode 100644 Makefile.am > > create mode 100644 README > > create mode 100644 configure.ac > > create mode 100644 doc/index.html > > create mode 100644 examples/Makefile.am create mode 100644 > > examples/cectest.c create mode 100644 include/gencec.h create mode > > 100644 m4/.gitkeep create mode 100644 src/Makefile.am create mode > > 100644 src/gencec.c > > > > diff --git a/AUTHORS b/AUTHORS > > new file mode 100644 > > index 000..e4b7117 > > --- /dev/null > > +++ b/AUTHORS > > @@ -0,0 +1 @@ > > +Kamil Debski > > diff --git a/INSTALL b/INSTALL > > new file mode 100644 > > index 000..aac6101 > > --- /dev/null > > +++ b/INSTALL > > @@ -0,0 +1,9 @@ > > +To install libgencec run following commands: > > + > > +autoreconf -i > You might want add --force in here, otherwise the files will stay as-is > if you update libtool and friends "mid-flight". > Many projects include autogen.sh like the following. Feel free to add > it to libgencec. Thanks, I'll include this in the next version. > $cat autogen.sh > #! /bin/sh > > srcdir=`dirname "$0"` > test -z "$srcdir" && srcdir=. > > ORIGDIR=`pwd` > cd "$srcdir" > > autoreconf --force --verbose --install || exit 1 cd "$ORIGDIR" || exit > $? > > if test -z "$NOCONFIGURE"; then > "$srcdir"/configure "$@" > fi > > > > > --- /dev/null > > +++ b/configure.ac > > @@ -0,0 +1,24 @@ > > You can save yourself some headaches if you restrict old and/or buggy > autoconf versions which don't work with the project. > If I have to guess 2.60 should be ok. > AC_PREREQ([XXX]) Good suggestion, thanks. > > > +AC_INIT([libgencec], [0.1], [k.debski at samsung.com]) > > +AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > > + > > +AC_PROG_CC > > +AM_PROG_AR > > +AC_CONFIG_MACRO_DIR([m4]) > > +AC_DEFINE([_GNU_SOURCE], [], [Use GNU extensions]) > > + > > Same for libtool - 2.2 perhaps ? > LT_PREREQ([XXX]) I agree. > > > +LT_INIT > > + > > +# Checks for typedefs, structures, and compiler characteristics. > > +AC_C_INLINE > > +AC_TYPE_SIZE_T > > +AC_TYPE_UINT16_T > > +AC_TYPE_UINT32_T > > +AC_TYPE_UINT8_T > > + > > +#AC_CHECK_LIB([c], [malloc]) > > +# Checks for library functions. > > +#AC_FUNC_MALLOC > > +l > > +AC_CONFIG_FILES([Makefile src/Makefile examples/Makefile]) > Would be nice if the library provides libgencec.pc file. This way any > users can avoid the explicit header/library check, amongst other useful > bits. Thanks for the suggestion, I'll look into this. > > --- /dev/null > > +++ b/examples/Makefile.am > > @@ -0,0 +1,4 @@ > > +bin_PROGRAMS = cectest > > +cectest_SOURCES = cectest.c > > +AM_CPPFLAGS=-I$(top_srcdir)/include/ > > +AM_LDFLAGS=-L../src/ -lgencec > The following seems more common (in the projects I've seen at least) > cectest_LDADD = $(top_builddir)/src/libgencec.la > > > diff --git a/m4/.gitkeep b/m4/.gitkeep new file mode 100644 index > > 000..e69de29 > Haven't seen any projects doing this. Curious what the benefits of > keeping and empty folder might be ? When I run autoreconf -i it complained about missing m4 folder, hence I added this filler file such that the folder is created. Any suggestion on how to do this better? > > > diff --git a/src/Makefile.am b/src/Makefile.am new file mode 100644 > > index 000..cb024f0 > > --- /dev/null > > +++ b/src/Makefile.am > > @@ -0,0 +1,4 @@ > > +lib_LTLIBRARIES = libgencec.la > > +libgencec_la_SOURCES = gencec.c > > +libgencec_la_LDFLAGS = -version-info 0:1:0 > You might want to add -no-undefined in order to prevent having a > library with unresolved symbols. > > Hope you find the above useful :-) Thank you so much for your review. It is my first real approach at autotools, so your co
[PULL] drm-intel-fixes
Hi Dave, just one fix for v4.1-rc2. Plenty of travel last week all around, I'm sure we'll find more to worry about... BR, Jani. The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031: Linux 4.1-rc1 (2015-04-26 17:59:10 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-04-30 for you to fetch changes up to a04f90a33fab74789b91fc973012f11022d1: drm/i915/chv: Implement WaDisableShadowRegForCpd (2015-04-28 17:31:29 +0300) Deepak S (1): drm/i915/chv: Implement WaDisableShadowRegForCpd drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_uncore.c | 8 2 files changed, 10 insertions(+) -- Jani Nikula, Intel Open Source Technology Center
[Bug 95911] Recursive error in radeon device driver module after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=95911 Christian König changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment #10 from Christian König --- (In reply to Michel Dänzer from comment #8) > Can you attach the kernel log from before and across suspend/resume as well? > > Christian, any ideas? Only possibility I can see is a bug in the BOs reference counting or a race between closing the handle and suspending. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69301] no screen on update from 3.12.0
https://bugzilla.kernel.org/show_bug.cgi?id=69301 Jan Outhuis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #21 from Jan Outhuis --- I'm changing the status of this bug to 'resolved'. I've moved on to kernel 4.0. And somewhere down the line from 3.13.0 to 4.0 the issue with radeon.dpm disappeared. So I could remove Radeon.dpm=0 from the kernel commandline, I'm not quite sure, but I would say since kernel 3.15.0. Apparently the support for dpm got implemented in the Radeon_si video driver. I'm on Debian 8 now. Greetings Jan -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #39 from Nicola Mori --- (In reply to Christian König from comment #37) > Created attachment 115398 [details] [review] > Something to test > > Just an idea I had recently what this issue could be. Please test the > attached patch and see if it works or not. The patch made things on my system even worse. Before, playing a movie with VLC and VDPAU enabled resulted in random screen freezes after some time, while with the patched kernel the freeze happens immediately as I start playing, all the times. Tested with Mobility Radeon HD3400 (RV620) on ArchLinux 64 bit with linux-ck 4.0.1, mesa 10.5.4, mesa-vdpau 10.5.4 and libvdpau 1.1. -- 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/20150430/a1fb4212/attachment.html>
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #40 from Erik --- I got a black screen at the beggining, and console show this: Radeon :01:05.0 ring 5 stalled for more than .secs -- 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/20150430/fb92aac9/attachment.html>
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 Christian König changed: What|Removed |Added Attachment #115398|0 |1 is obsolete|| CC||deathsimple at vodafone.de --- Comment #41 from Christian König --- Created attachment 115475 --> https://bugs.freedesktop.org/attachment.cgi?id=115475&action=edit More to test. Interesting, attached is another patch you could test. It just disables using UVD semaphores for now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/b5ace94b/attachment.html>
[patch] drm/i915: checking IS_ERR() instead of NULL
We switched from calling i915_gem_alloc_context_obj() to calling i915_gem_alloc_object() so the error handling needs to be updated to check for NULL instead of IS_ERR(). Fixes: 149c86e74fe4 ('drm/i915: Allocate context objects from stolen') Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 732fd63..0fa9209 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1895,10 +1895,9 @@ int intel_lr_context_deferred_create(struct intel_context *ctx, context_size = round_up(get_lr_context_size(ring), 4096); ctx_obj = i915_gem_alloc_object(dev, context_size); - if (IS_ERR(ctx_obj)) { - ret = PTR_ERR(ctx_obj); - DRM_DEBUG_DRIVER("Alloc LRC backing obj failed: %d\n", ret); - return ret; + if (!ctx_obj) { + DRM_DEBUG_DRIVER("Alloc LRC backing obj failed.\n"); + return -ENOMEM; } if (is_global_default_ctx) {
[PATCH] drm: panel: simple-panel: remove useless drm_mode_set_name
drm_display_mode_from_videomode() is already calling drm_mode_set_name() on the provided mode. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 30904a9..d14b904 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -112,7 +112,6 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) } drm_display_mode_from_videomode(&vm, mode); - drm_mode_set_name(mode); drm_mode_probed_add(connector, mode); num++; -- 1.9.1
[PATCH] drm: panel: simple-panel: set appropriate mode type
All modes exposed by simple panels should be tagged as driver defined modes. Moreover, if a panel supports only one mode, this mode is obviously the preferred one. Doing this also fix a problem occurring when a 'video=' parameter is passed on the kernel cmdline. In some cases the user provided mode is preferred over the simple panel ones, which might result in unpredictable behavior. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index d14b904..95ae390 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -111,6 +111,10 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) continue; } + mode->type |= DRM_MODE_TYPE_DRIVER; + if (panel->desc->num_modes == 1) + mode->type |= DRM_MODE_TYPE_PREFERRED; + drm_display_mode_from_videomode(&vm, mode); drm_mode_probed_add(connector, mode); @@ -127,6 +131,10 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) continue; } + mode->type |= DRM_MODE_TYPE_DRIVER; + if (panel->desc->num_modes == 1) + mode->type |= DRM_MODE_TYPE_PREFERRED; + drm_mode_set_name(mode); drm_mode_probed_add(connector, mode); -- 1.9.1
[PATCH] drm/msm/dsi: Fix a couple more 64-bit build warnings
Avoid such errors at compilation time: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' Signed-off-by: Stephane Viau --- drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index fdc54e3..1e3cd30 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -1023,7 +1023,7 @@ static int dsi_short_read1_resp(u8 *buf, const struct mipi_dsi_msg *msg) *data = buf[1]; /* strip out dcs type */ return 1; } else { - pr_err("%s: read data does not match with rx_buf len %d\n", + pr_err("%s: read data does not match with rx_buf len %zu\n", __func__, msg->rx_len); return -EINVAL; } @@ -1040,7 +1040,7 @@ static int dsi_short_read2_resp(u8 *buf, const struct mipi_dsi_msg *msg) data[1] = buf[2]; return 2; } else { - pr_err("%s: read data does not match with rx_buf len %d\n", + pr_err("%s: read data does not match with rx_buf len %zu\n", __func__, msg->rx_len); return -EINVAL; } -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[patch] drm/i915: checking IS_ERR() instead of NULL
On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote: > We switched from calling i915_gem_alloc_context_obj() to calling > i915_gem_alloc_object() so the error handling needs to be updated to > check for NULL instead of IS_ERR(). I had a patch to change i915_gem_alloc_object() to report the correct error rather than NULL - which can come in surprisingly handy at times... -Chris -- Chris Wilson, Intel Open Source Technology Centre
[patch] drm/i915: checking IS_ERR() instead of NULL
On Thu, Apr 30, 2015 at 03:43:02PM +0100, Chris Wilson wrote: > On Thu, Apr 30, 2015 at 05:30:50PM +0300, Dan Carpenter wrote: > > We switched from calling i915_gem_alloc_context_obj() to calling > > i915_gem_alloc_object() so the error handling needs to be updated to > > check for NULL instead of IS_ERR(). > > I had a patch to change i915_gem_alloc_object() to report the correct > error rather than NULL - which can come in surprisingly handy at > times... That also works, of course. Send it. :) regards, dan carpenter
[RFC] drm/exynos: rework layer blending setup
Hello, here's the rework of the layer blending setup that I discussed with Joonyoung in the past days. There's still some TODOs in the code, but more or less it does what it's supposed to do. What still bothers me a bit is that I currently call blending reconfig in mixer_cfg_layer(). It would be nice if this could be reduced to one call per "frame" (so with the last win_{commit,disable} call). Maybe atomic provides such an infrastructure? With best wishes, Tobias
[RFC 1/5] drm/exynos: mixer: refactor layer setup
First step in allowing a more generic way to setup complex blending for the different layers. Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 74 +-- 1 file changed, 63 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 4155f43..a06b8e2 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -63,6 +63,12 @@ struct mixer_resources { struct clk *mout_mixer; }; +struct layer_config { + unsigned int index; + unsigned int priority; + u32 cfg; +}; + enum mixer_version_id { MXR_VER_0_0_0_16, MXR_VER_16_0_33_0, @@ -75,6 +81,8 @@ struct mixer_context { struct drm_device *drm_dev; struct exynos_drm_crtc *crtc; struct exynos_drm_plane planes[MIXER_WIN_NR]; + const struct layer_config *layer_config; + unsigned int num_layer; int pipe; boolinterlace; boolpowered; @@ -95,6 +103,40 @@ struct mixer_drv_data { boolhas_sclk; }; +/* + * The default layer priorities. A higher priority means that + * the layer is at the top of layer stack. + * The current configuration assumes the following usage scenario: + * layer1: OSD [top] + * layer0: main framebuffer + * video layer: video overlay [bottom] + * Note that the video layer is only usable when the + * video processor is available. + */ + +static const struct layer_config default_layer_config[] = { + { + .index = 0, .priority = 1, /* layer0 */ + .cfg = MXR_LAYER_CFG_GRP0_VAL(1) + }, { + .index = 1, .priority = 2, /* layer1 */ + .cfg = MXR_LAYER_CFG_GRP1_VAL(2) + } +}; + +static const struct layer_config vp_layer_config[] = { + { + .index = 2, .priority = 1, /* video layer */ + .cfg = MXR_LAYER_CFG_VP_VAL(1) + }, { + .index = 0, .priority = 2, /* layer0 */ + .cfg = MXR_LAYER_CFG_GRP0_VAL(2) + }, { + .index = 1, .priority = 3, /* layer1 */ + .cfg = MXR_LAYER_CFG_GRP1_VAL(3) + } +}; + static const u8 filter_y_horiz_tap8[] = { 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources *res) filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4)); } +static void mixer_layer_priority(struct mixer_context *ctx) +{ + u32 val = 0; + unsigned int i; + + for (i = 0; i < ctx->num_layer; ++i) + val |= ctx->layer_config[i].cfg; + + mixer_reg_write(&ctx->mixer_res, MXR_LAYER_CFG, val); +} + static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable) { struct mixer_resources *res = &ctx->mixer_res; @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx) mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST, MXR_STATUS_BURST_MASK); - /* setting default layer priority: layer1 > layer0 > video -* because typical usage scenario would be -* layer1 - OSD -* layer0 - framebuffer -* video - video overlay -*/ - val = MXR_LAYER_CFG_GRP1_VAL(3); - val |= MXR_LAYER_CFG_GRP0_VAL(2); - if (ctx->vp_enabled) - val |= MXR_LAYER_CFG_VP_VAL(1); - mixer_reg_write(res, MXR_LAYER_CFG, val); + mixer_layer_priority(ctx); /* setting background color */ mixer_reg_write(res, MXR_BG_COLOR0, 0x008080); @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev) ctx->vp_enabled = drv->is_vp_enabled; ctx->has_sclk = drv->has_sclk; ctx->mxr_ver = drv->version; + + if (drv->is_vp_enabled) { + ctx->layer_config = vp_layer_config; + ctx->num_layer = ARRAY_SIZE(vp_layer_config); + } else { + ctx->layer_config = default_layer_config; + ctx->num_layer = ARRAY_SIZE(default_layer_config); + } + init_waitqueue_head(&ctx->wait_vsync_queue); atomic_set(&ctx->wait_vsync_event, 0); -- 2.0.5
[RFC 2/5] drm/exynos: mixer: introduce mixer_layer_blending()
This analyses the current layer configuration (which layers are enabled, which have alpha-pixelformat, etc.) and setups blending accordingly. We currently disable all kinds of blending for the bottom-most layer, since configuration of the mixer background is not yet exposed. Also blending is only enabled when the layer has a pixelformat with alpha attached. Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 101 ++ drivers/gpu/drm/exynos/regs-mixer.h | 1 + 2 files changed, 102 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index a06b8e2..ff1168d 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -166,6 +166,18 @@ static const u8 filter_cr_horiz_tap4[] = { 70, 59, 48, 37, 27, 19, 11, 5, }; +static inline bool is_alpha_format(const struct mixer_context* ctx, unsigned int win) +{ + switch (ctx->planes[win].pixel_format) { + case DRM_FORMAT_ARGB: + case DRM_FORMAT_ARGB1555: + case DRM_FORMAT_ARGB: + return true; + default: + return false; + } +} + static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id) { return readl(res->vp_regs + reg_id); @@ -306,6 +318,95 @@ static void mixer_layer_priority(struct mixer_context *ctx) mixer_reg_write(&ctx->mixer_res, MXR_LAYER_CFG, val); } +/* Configure blending for bottom-most layer. */ +static void mixer_bottom_layer(struct mixer_context *ctx, + const struct layer_config *cfg) +{ + u32 val; + struct mixer_resources *res = &ctx->mixer_res; + + if (cfg->index == 2) { + val = 0; /* use defaults for video layer */ + mixer_reg_write(res, MXR_VIDEO_CFG, val); + } else { + val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */ + + /* Don't blend bottom-most layer onto the mixer background. */ + mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index), + val, MXR_GRP_CFG_MISC_MASK); + } +} + +static void mixer_general_layer(struct mixer_context *ctx, + const struct layer_config *cfg) +{ + u32 val; + struct mixer_resources *res = &ctx->mixer_res; + + if (is_alpha_format(ctx, cfg->index)) { + val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */ + val |= MXR_GRP_CFG_BLEND_PRE_MUL; + val |= MXR_GRP_CFG_PIXEL_BLEND_EN; + + /* The video layer never has an alpha pixelformat. */ + mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index), + val, MXR_GRP_CFG_MISC_MASK); + } else { + if (cfg->index == 2) { + // TODO + } else { + val = MXR_GRP_CFG_COLOR_KEY_DISABLE; + mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index), + val, MXR_GRP_CFG_MISC_MASK); + } + } +} + +static void mixer_layer_blending(struct mixer_context *ctx, unsigned int enable_state) +{ + const struct layer_config *cfg; + unsigned int i = 0; + unsigned int index; + + /* Find bottom-most enabled layer. */ + cfg = NULL; + while (i < ctx->num_layer) { + index = ctx->layer_config[i].index; + ++i; + + if (enable_state & (1 << index)) { + cfg = &ctx->layer_config[i-1]; + break; + } + } + + /* No enabled layers found, nothing to do. */ + if (!cfg) + return; + + mixer_bottom_layer(ctx, cfg); + + while (1) { + /* Find the next layer. */ + cfg = NULL; + while (i < ctx->num_layer) { + index = ctx->layer_config[i].index; + ++i; + + if (enable_state & (1 << index)) { + cfg = &ctx->layer_config[i-1]; + break; + } + } + + /* No more enabled layers found. */ + if (!cfg) + return; + + mixer_general_layer(ctx, cfg); + } +} + static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable) { struct mixer_resources *res = &ctx->mixer_res; diff --git a/drivers/gpu/drm/exynos/regs-mixer.h b/drivers/gpu/drm/exynos/regs-mixer.h index ac60260..118872e 100644 --- a/drivers/gpu/drm/exynos/regs-mixer.h +++ b/drivers/gpu/drm/exynos/regs-mixer.h @@ -113,6 +113,7 @@ #define MXR_GRP_CFG_BLEND_PRE_MUL (1 << 20) #define MXR_GRP_CFG_WIN_BLEND_EN (1 << 17) #define MXR_GRP_CFG_PIXEL_BLEND_EN (1 << 16) +#define MXR_GRP_CFG_MISC_MASK ((3 <
[RFC 3/5] drm/exynos: mixer: remove all static blending setup
Previously blending setup was static and most of it was done in mixer_win_reset(). Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 22 -- 1 file changed, 22 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ff1168d..3eec9ce 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -504,11 +504,6 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int win, bool enable) vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON); mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_VP_ENABLE); - - /* control blending of graphic layer 0 */ - mixer_reg_writemask(res, MXR_GRAPHIC_CFG(0), val, - MXR_GRP_CFG_BLEND_PRE_MUL | - MXR_GRP_CFG_PIXEL_BLEND_EN); } break; } @@ -816,23 +811,6 @@ static void mixer_win_reset(struct mixer_context *ctx) mixer_reg_write(res, MXR_BG_COLOR1, 0x008080); mixer_reg_write(res, MXR_BG_COLOR2, 0x008080); - /* setting graphical layers */ - val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */ - val |= MXR_GRP_CFG_WIN_BLEND_EN; - val |= MXR_GRP_CFG_ALPHA_VAL(0xff); /* non-transparent alpha */ - - /* Don't blend layer 0 onto the mixer background */ - mixer_reg_write(res, MXR_GRAPHIC_CFG(0), val); - - /* Blend layer 1 into layer 0 */ - val |= MXR_GRP_CFG_BLEND_PRE_MUL; - val |= MXR_GRP_CFG_PIXEL_BLEND_EN; - mixer_reg_write(res, MXR_GRAPHIC_CFG(1), val); - - /* setting video layers */ - val = MXR_GRP_CFG_ALPHA_VAL(0); - mixer_reg_write(res, MXR_VIDEO_CFG, val); - if (ctx->vp_enabled) { /* configuration of Video Processor Registers */ vp_win_reset(ctx); -- 2.0.5
[RFC 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()
This updates the blending setup when the layer configuration changes (triggered by mixer_win_{commit,disable}). Extra care has to be taken for the layer that is currently being enabled/disabled. Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 3eec9ce..809f840 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -178,6 +178,18 @@ static inline bool is_alpha_format(const struct mixer_context* ctx, unsigned int } } +static inline unsigned int layer_bitmask(const struct mixer_context* ctx) +{ + unsigned int i, mask = 0; + + for (i = 0; i < MIXER_WIN_NR; ++i) { + if (ctx->planes[i].enabled) + mask |= (1 << i); + } + + return mask; +} + static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id) { return readl(res->vp_regs + reg_id); @@ -490,6 +502,7 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx, unsigned int height) static void mixer_cfg_layer(struct mixer_context *ctx, int win, bool enable) { struct mixer_resources *res = &ctx->mixer_res; + unsigned int enable_state; u32 val = enable ? ~0 : 0; switch (win) { @@ -507,6 +520,16 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int win, bool enable) } break; } + + /* Determine the current enabled/disabled state of the layers. */ + enable_state = layer_bitmask(ctx); + if (enable) + enable_state |= (1 << win); + else + enable_state &= ~(1 << win); + + /* Layer configuration has changed, update blending setup. */ + mixer_layer_blending(ctx, enable_state); } static void mixer_run(struct mixer_context *ctx) -- 2.0.5
[RFC 5/5] drm/exynos: mixer: also allow ARGB1555 and ARGB4444
Signed-off-by: Tobias Jakobi --- 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 809f840..5a435aa 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -701,10 +701,12 @@ static void mixer_graph_buffer(struct mixer_context *ctx, int win) switch (plane->pixel_format) { case DRM_FORMAT_XRGB: + case DRM_FORMAT_ARGB: fmt = MXR_FORMAT_ARGB; break; case DRM_FORMAT_XRGB1555: + case DRM_FORMAT_ARGB1555: fmt = MXR_FORMAT_ARGB1555; break; -- 2.0.5
[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote: > Krzysztof Kozlowski writes: > >> 2015-04-30 2:31 GMT+09:00 Kevin Hilman : >>> Krzysztof Kozlowski writes: >>> After adding display power domain for Exynos5250 in commit 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the display on Chromebook Snow and others stopped working after boot. The reason for this suggested Andrzej Hajda: the DP clock was disabled. This clock is required by Display Port and is enabled by bootloader. However when FIMD driver probing was deferred, the display power domain was turned off. This effectively reset the value of DP clock enable register. When exynos-dp is later probed, the clock is not enabled and display is not properly configured: exynos-dp 145b.dp-controller: Timeout of video streamclk ok exynos-dp 145b.dp-controller: unable to config video Signed-off-by: Krzysztof Kozlowski Reported-by: Javier Martinez Canillas Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") Cc: --- This should fix issue reported by Javier [1][2]. Tested on Chromebook Snow (Exynos 5250). More testing would be great, especially on other Exynos 5xxx products. >>> >>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply >>> to linux-next or to Linus' master branch. >>> >>> Are there some other dependencies here? >> >> It is already applied: >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc > > Er, yup. That would explain it. ;) > > Sorry for the noise, Well, noise or not, Exynos is still broken in mainline and was broken on -next for so long in different ways that bisecting it is a futile exercise in frustration. It doesn't seem to show up with a trivial boot using only ramdisk, but when booting a real distro from disk, it certainly does. For example: http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html Disabling CONFIG_DRM makes it boot reliably. Arndale doesn't show it for me, but it also doesn't have working graphics. -Olof
[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas wrote: > Hello Olof, > > On 04/30/2015 05:57 PM, Olof Johansson wrote: >> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote: >>> Krzysztof Kozlowski writes: >> >> This should fix issue reported by Javier [1][2]. >> >> Tested on Chromebook Snow (Exynos 5250). More testing would be great, >> especially on other Exynos 5xxx products. > > I hoped to try this on my exynos5 boards, but it doesn't seem to apply > to linux-next or to Linus' master branch. > > Are there some other dependencies here? It is already applied: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc >>> >>> Er, yup. That would explain it. ;) >>> >>> Sorry for the noise, >> >> Well, noise or not, Exynos is still broken in mainline and was broken >> on -next for so long in different ways that bisecting it is a futile >> exercise in frustration. >> >> It doesn't seem to show up with a trivial boot using only ramdisk, but >> when booting a real distro from disk, it certainly does. >> >> For example: >> >> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html >> >> Disabling CONFIG_DRM makes it boot reliably. >> >> Arndale doesn't show it for me, but it also doesn't have working graphics. >> > > Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix > for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1 > power domain on Exynos5420" patch that was posted a long time ago. I have > pinged Kukjin several times about this patch and he said that he will pick > it this weekend [0]. > > It is indeed very frustrating how many Exynos patches seems to be falling > through the crack, even important fixes like these ones that allow boards > to boot again. > > Kevin suggested that Krzysztof could collect and queue patches [1] to help > Kukjin and start acting as a co-maintatiner which I think it's a very good > idea and Krzysztof already did for some patches during the 4.1 cycle. Yes, that's a much needed improvement. I suggest starting out by collecting critical fixes like these, and we'd be happy to merge them directly if going through Kukjin will add latency. Krzysztof, if you can, make sure you get a PGP key setup and start collecting signatures from kernel developers. -Olof
[PATCH] drm/msm/mdp5: Fix iteration on INTF config array
The current iteration in get_dsi_id_from_intf() is wrong: instead of iterating until hw_cfg->intf.count, we need to iterate until MDP5_INTF_NUM_MAX here. Let's take the example of msm8x16: hw_cfg->intf.count = 1 intfs[0] = INTF_Disabled intfs[1] = INTF_DSI If we stop iterating once i reaches hw_cfg->intf.count (== 1), we will miss the test for intfs[1]. Actually, this hw_cfg->intf.count entry is quite confusing and is not (or *should not be*) used anywhere else; let's remove it. Signed-off-by: Stephane Viau --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 34 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 9 ++--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 12 ++-- 3 files changed, 29 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c index 8bcd177..9ff25a3 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c @@ -72,14 +72,13 @@ const struct mdp5_cfg_hw msm8x74_config = { .base = { 0x12d00, 0x12e00, 0x12f00 }, }, .intf = { - .count = 4, .base = { 0x12500, 0x12700, 0x12900, 0x12b00 }, - }, - .intfs = { - [0] = INTF_eDP, - [1] = INTF_DSI, - [2] = INTF_DSI, - [3] = INTF_HDMI, + .connect = { + [0] = INTF_eDP, + [1] = INTF_DSI, + [2] = INTF_DSI, + [3] = INTF_HDMI, + }, }, .max_clk = 2, }; @@ -142,14 +141,13 @@ const struct mdp5_cfg_hw apq8084_config = { .base = { 0x12f00, 0x13000, 0x13100, 0x13200 }, }, .intf = { - .count = 5, .base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 }, - }, - .intfs = { - [0] = INTF_eDP, - [1] = INTF_DSI, - [2] = INTF_DSI, - [3] = INTF_HDMI, + .connect = { + [0] = INTF_eDP, + [1] = INTF_DSI, + [2] = INTF_DSI, + [3] = INTF_HDMI, + }, }, .max_clk = 32000, }; @@ -196,10 +194,12 @@ const struct mdp5_cfg_hw msm8x16_config = { }, .intf = { - .count = 1, /* INTF_1 */ - .base = { 0x6B800 }, + .base = { 0x0, 0x6b800 }, + .connect = { + [0] = INTF_DISABLED, + [1] = INTF_DSI, + }, }, - /* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented */ .max_clk = 32000, }; diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h index 3a551b0..69349ab 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h @@ -59,6 +59,11 @@ struct mdp5_smp_block { #define MDP5_INTF_NUM_MAX 5 +struct mdp5_intf_block { + uint32_t base[MAX_BASES]; + u32 connect[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */ +}; + struct mdp5_cfg_hw { char *name; @@ -72,9 +77,7 @@ struct mdp5_cfg_hw { struct mdp5_sub_block dspp; struct mdp5_sub_block ad; struct mdp5_sub_block pp; - struct mdp5_sub_block intf; - - u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */ + struct mdp5_intf_block intf; uint32_t max_clk; }; diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c index 02ef86b..f6c5896 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c @@ -208,8 +208,8 @@ static struct drm_encoder *construct_encoder(struct mdp5_kms *mdp5_kms, static int get_dsi_id_from_intf(const struct mdp5_cfg_hw *hw_cfg, int intf_num) { - const int intf_cnt = hw_cfg->intf.count; - const u32 *intfs = hw_cfg->intfs; + const enum mdp5_intf_type *intfs = hw_cfg->intf.connect; + const int intf_cnt = ARRAY_SIZE(hw_cfg->intf.connect); int id = 0, i; for (i = 0; i < intf_cnt; i++) { @@ -230,7 +230,7 @@ static int modeset_init_intf(struct mdp5_kms *mdp5_kms, int intf_num) struct msm_drm_private *priv = dev->dev_private; const struct mdp5_cfg_hw *hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg); - enum mdp5_intf_type intf_type = hw_cfg->intfs[intf_num]; + enum mdp5_intf_type intf_type = hw_cfg->intf.connect[intf_num]; struct drm_encoder *encoder; int ret = 0; @@ -367,7 +367,7 @@ static int modeset_init(struct mdp5_kms *mdp5_kms) /* Construct encoders and modeset initialize connector devices * for each external display interface. */ - for (i = 0; i < ARRAY_SIZE(hw_cfg->intfs)
[PATCH 2/5] drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6
2015-04-22 17:20 GMT-03:00 Alex Deucher : > On Tue, Apr 21, 2015 at 2:09 PM, Todd Previte wrote: >> Displayport compliance test 4.2.2.6 requires that a source device be capable >> of >> detecting a corrupt EDID. The test specification states that the sink device >> sets up the EDID with an invalid checksum. To do this, the sink sets up an >> invalid EDID header, expecting the source device to generate the checksum and >> compare it to the value stored in the last byte of the block data. >> >> Unfortunately, the DRM EDID reading and parsing functions are actually too >> good >> in this case; the header is fixed before the checksum is computed and thus >> the >> test never sees the invalid checksum. This results in a failure to pass the >> compliance test. >> >> To correct this issue, when the EDID code detects that the header is invalid, >> a flag is set to indicate that the EDID is corrupted. In this case, it sets >> edid_corrupt flag and continues with its fix-up code. This flag is also set >> in >> the case of a more seriously damaged header (fixup score less than the >> threshold). For consistency, the edid_corrupt flag is also set when the >> checksum is invalid as well. >> >> V2: >> - Removed the static bool global >> - Added a bool to the drm_connector struct to reaplce the static one for >> holding the status of raw edid header corruption detection >> - Modified the function signature of the is_valid function to take an >> additional parameter to store the corruption detected value >> - Fixed the other callers of the above is_valid function >> V3: >> - Updated the commit message to be more clear about what and why this >> patch does what it does. >> - Added comment in code to clarify the operations there >> - Removed compliance variable and check_link_status update; those >> have been moved to a later patch >> - Removed variable assignment from the bottom of the test handler >> V4: >> - Removed i915 tag from subject line as the patch is not i915-specific >> V5: >> - Moved code causing a compilation error to this patch where the variable >> is actually declared >> - Maintained blank lines / spacing so as to not contaminate the patch >> V6: >> - Removed extra debug messages >> - Added documentation to for the added parameter on drm_edid_block_valid >> - Fixed more whitespace issues in check_link_status >> - Added a clear of the header_corrupt flag to the end of the test handler >> in intel_dp.c >> - Changed the usage of the new function prototype in several places to use >> NULL where it is not needed by compliance testing >> V7: >> - Updated to account for long_pulse flag propagation >> V8: >> - Removed clearing of header_corrupt flag from the test handler in intel_dp.c >> - Added clearing of header_corrupt flag in the drm_edid_block_valid function >> V9: >> - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its >> value and purpose >> - Updated commit message >> V10: >> - Updated for versioning and patch swizzle >> - Revised the title to more accurately reflect the nature and contents of >> the patch >> - Fixed formatting/whitespace problems >> - Added set flag when computed checksum is invalid >> >> Signed-off-by: Todd Previte >> Cc: dri-devel at lists.freedesktop.org > > Seems reasonable. > > Reviewed-by: Alex Deucher Reviewed-by: Paulo Zanoni (since I made comments on the previous versions, this is my documentation that the patch looks fine to me now) > >> --- >> drivers/gpu/drm/drm_edid.c | 32 ++-- >> drivers/gpu/drm/drm_edid_load.c | 7 +-- >> include/drm/drm_crtc.h | 8 +++- >> 3 files changed, 38 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c >> index 53bc7a6..be6713c 100644 >> --- a/drivers/gpu/drm/drm_edid.c >> +++ b/drivers/gpu/drm/drm_edid.c >> @@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int >> length) >> * @raw_edid: pointer to raw EDID block >> * @block: type of block to validate (0 for base, extension otherwise) >> * @print_bad_edid: if true, dump bad EDID blocks to the console >> + * @edid_corrupt: if true, the header or checksum is invalid >> * >> * Validate a base or extension EDID block and optionally dump bad blocks to >> * the console. >> * >> * Return: True if the block is valid, false otherwise. >> */ >> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid) >> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid, >> + bool *edid_corrupt) >> { >> u8 csum; >> struct edid *edid = (struct edid *)raw_edid; >> @@ -1060,11 +1062,22 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, >> bool print_bad_edid) >> >> if (block == 0) { >> int score = drm_edid_header_is_valid(raw_edid); >> - if (score == 8) ; >> - else if (score >= edid_fixup) { >> +
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #42 from Erik --- Works like a charm :) -- 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/20150430/6b51a40f/attachment.html>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #15 from Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> --- Created attachment 115486 --> https://bugs.freedesktop.org/attachment.cgi?id=115486&action=edit R600_DEBUG=ps,gs,vs for Tera Online I am having the same crash with another Unreal Engine 3 game, Tera Online. I am also using wine with gallium nine. Pure wine works but is slow. I have attached the whole output of R600_DEBUG=ps,gs,vs before the crash. Gpu: radeon r7 250x Software: Archlinux linux 4.0.1-1-ARCH x86_64 mesa 10.5.4-1 llvm-libs 3.6.0-5 xorg-server 1.17.1-5 -- 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/20150430/488db785/attachment.html>
[RFC 1/5] drm/exynos: mixer: refactor layer setup
Hi Tobias, 2015-04-30 Tobias Jakobi : > First step in allowing a more generic way to setup complex > blending for the different layers. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 74 > +-- > 1 file changed, 63 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index 4155f43..a06b8e2 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -63,6 +63,12 @@ struct mixer_resources { > struct clk *mout_mixer; > }; > > +struct layer_config { > + unsigned int index; > + unsigned int priority; > + u32 cfg; > +}; I don't see why you are creating this struct, index and priority are never used in this patch series. > + > enum mixer_version_id { > MXR_VER_0_0_0_16, > MXR_VER_16_0_33_0, > @@ -75,6 +81,8 @@ struct mixer_context { > struct drm_device *drm_dev; > struct exynos_drm_crtc *crtc; > struct exynos_drm_plane planes[MIXER_WIN_NR]; > + const struct layer_config *layer_config; > + unsigned int num_layer; > int pipe; > boolinterlace; > boolpowered; > @@ -95,6 +103,40 @@ struct mixer_drv_data { > boolhas_sclk; > }; > > +/* > + * The default layer priorities. A higher priority means that > + * the layer is at the top of layer stack. > + * The current configuration assumes the following usage scenario: > + * layer1: OSD [top] > + * layer0: main framebuffer > + * video layer: video overlay [bottom] > + * Note that the video layer is only usable when the > + * video processor is available. > + */ > + > +static const struct layer_config default_layer_config[] = { > + { > + .index = 0, .priority = 1, /* layer0 */ > + .cfg = MXR_LAYER_CFG_GRP0_VAL(1) > + }, { > + .index = 1, .priority = 2, /* layer1 */ > + .cfg = MXR_LAYER_CFG_GRP1_VAL(2) > + } > +}; > + > +static const struct layer_config vp_layer_config[] = { > + { > + .index = 2, .priority = 1, /* video layer */ > + .cfg = MXR_LAYER_CFG_VP_VAL(1) > + }, { > + .index = 0, .priority = 2, /* layer0 */ > + .cfg = MXR_LAYER_CFG_GRP0_VAL(2) > + }, { > + .index = 1, .priority = 3, /* layer1 */ > + .cfg = MXR_LAYER_CFG_GRP1_VAL(3) > + } > +}; > + > static const u8 filter_y_horiz_tap8[] = { > 0, -1, -1, -1, -1, -1, -1, -1, > -1, -1, -1, -1, -1, 0, 0, 0, > @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources > *res) > filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4)); > } > > +static void mixer_layer_priority(struct mixer_context *ctx) > +{ > + u32 val = 0; > + unsigned int i; > + > + for (i = 0; i < ctx->num_layer; ++i) > + val |= ctx->layer_config[i].cfg; > + > + mixer_reg_write(&ctx->mixer_res, MXR_LAYER_CFG, val); > +} > + > static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable) > { > struct mixer_resources *res = &ctx->mixer_res; > @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx) > mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST, > MXR_STATUS_BURST_MASK); > > - /* setting default layer priority: layer1 > layer0 > video > - * because typical usage scenario would be > - * layer1 - OSD > - * layer0 - framebuffer > - * video - video overlay > - */ > - val = MXR_LAYER_CFG_GRP1_VAL(3); > - val |= MXR_LAYER_CFG_GRP0_VAL(2); > - if (ctx->vp_enabled) > - val |= MXR_LAYER_CFG_VP_VAL(1); > - mixer_reg_write(res, MXR_LAYER_CFG, val); I would move this exaclty piece of code into mixer_layer_priority(). > + mixer_layer_priority(ctx); > > /* setting background color */ > mixer_reg_write(res, MXR_BG_COLOR0, 0x008080); > @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev) > ctx->vp_enabled = drv->is_vp_enabled; > ctx->has_sclk = drv->has_sclk; > ctx->mxr_ver = drv->version; > + > + if (drv->is_vp_enabled) { > + ctx->layer_config = vp_layer_config; > + ctx->num_layer = ARRAY_SIZE(vp_layer_config); > + } else { > + ctx->layer_config = default_layer_config; > + ctx->num_layer = ARRAY_SIZE(default_layer_config); > + } Then this piece of code is useless. Gustavo
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #16 from Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> --- Created attachment 115487 --> https://bugs.freedesktop.org/attachment.cgi?id=115487&action=edit Tera Online dmesg errors Parts of dmesg showing the errors. -- 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/20150430/6bb62176/attachment.html>
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #43 from Daniele --- I confirm that your last patch makes things work here too -- 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/20150430/4ec70621/attachment.html>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #17 from John --- I haven't tried Tom's comment yet, as I need my PC to be stable till the rest of the day, but I've extensively played Tera Online, so I doubt the issue is related. Plus I get my issue both with nine and without it (just more often with nine). -- 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/20150430/2878e4ee/attachment.html>
[RFC 1/5] drm/exynos: mixer: refactor layer setup
Hello Gustavo! Gustavo Padovan wrote: > Hi Tobias, > > 2015-04-30 Tobias Jakobi : > >> First step in allowing a more generic way to setup complex >> blending for the different layers. >> >> Signed-off-by: Tobias Jakobi >> --- >> drivers/gpu/drm/exynos/exynos_mixer.c | 74 >> +-- >> 1 file changed, 63 insertions(+), 11 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c >> b/drivers/gpu/drm/exynos/exynos_mixer.c >> index 4155f43..a06b8e2 100644 >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c >> @@ -63,6 +63,12 @@ struct mixer_resources { >> struct clk *mout_mixer; >> }; >> >> +struct layer_config { >> +unsigned int index; >> +unsigned int priority; >> +u32 cfg; >> +}; > > I don't see why you are creating this struct, index and priority are > never used in this patch series. Good catch about 'priority'. But 'index' is used, see the second patch. > >> + >> enum mixer_version_id { >> MXR_VER_0_0_0_16, >> MXR_VER_16_0_33_0, >> @@ -75,6 +81,8 @@ struct mixer_context { >> struct drm_device *drm_dev; >> struct exynos_drm_crtc *crtc; >> struct exynos_drm_plane planes[MIXER_WIN_NR]; >> +const struct layer_config *layer_config; >> +unsigned int num_layer; >> int pipe; >> boolinterlace; >> boolpowered; >> @@ -95,6 +103,40 @@ struct mixer_drv_data { >> boolhas_sclk; >> }; >> >> +/* >> + * The default layer priorities. A higher priority means that >> + * the layer is at the top of layer stack. >> + * The current configuration assumes the following usage scenario: >> + * layer1: OSD [top] >> + * layer0: main framebuffer >> + * video layer: video overlay [bottom] >> + * Note that the video layer is only usable when the >> + * video processor is available. >> + */ >> + >> +static const struct layer_config default_layer_config[] = { >> +{ >> +.index = 0, .priority = 1, /* layer0 */ >> +.cfg = MXR_LAYER_CFG_GRP0_VAL(1) >> +}, { >> +.index = 1, .priority = 2, /* layer1 */ >> +.cfg = MXR_LAYER_CFG_GRP1_VAL(2) >> +} >> +}; >> + >> +static const struct layer_config vp_layer_config[] = { >> +{ >> +.index = 2, .priority = 1, /* video layer */ >> +.cfg = MXR_LAYER_CFG_VP_VAL(1) >> +}, { >> +.index = 0, .priority = 2, /* layer0 */ >> +.cfg = MXR_LAYER_CFG_GRP0_VAL(2) >> +}, { >> +.index = 1, .priority = 3, /* layer1 */ >> +.cfg = MXR_LAYER_CFG_GRP1_VAL(3) >> +} >> +}; >> + >> static const u8 filter_y_horiz_tap8[] = { >> 0, -1, -1, -1, -1, -1, -1, -1, >> -1, -1, -1, -1, -1, 0, 0, 0, >> @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources >> *res) >> filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4)); >> } >> >> +static void mixer_layer_priority(struct mixer_context *ctx) >> +{ >> +u32 val = 0; >> +unsigned int i; >> + >> +for (i = 0; i < ctx->num_layer; ++i) >> +val |= ctx->layer_config[i].cfg; >> + >> +mixer_reg_write(&ctx->mixer_res, MXR_LAYER_CFG, val); >> +} >> + >> static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable) >> { >> struct mixer_resources *res = &ctx->mixer_res; >> @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx) >> mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST, >> MXR_STATUS_BURST_MASK); >> >> -/* setting default layer priority: layer1 > layer0 > video >> - * because typical usage scenario would be >> - * layer1 - OSD >> - * layer0 - framebuffer >> - * video - video overlay >> - */ >> -val = MXR_LAYER_CFG_GRP1_VAL(3); >> -val |= MXR_LAYER_CFG_GRP0_VAL(2); >> -if (ctx->vp_enabled) >> -val |= MXR_LAYER_CFG_VP_VAL(1); >> -mixer_reg_write(res, MXR_LAYER_CFG, val); > > I would move this exaclty piece of code into mixer_layer_priority(). Then we end up with the same static/hardcoded setup as before. That's something I want to move away from. The entire information about layer ordering should be stored in 'layer_config'. >> +mixer_layer_priority(ctx); >> >> /* setting background color */ >> mixer_reg_write(res, MXR_BG_COLOR0, 0x008080); >> @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev) >> ctx->vp_enabled = drv->is_vp_enabled; >> ctx->has_sclk = drv->has_sclk; >> ctx->mxr_ver = drv->version; >> + >> +if (drv->is_vp_enabled) { >> +ctx->layer_config = vp_layer_config; >> +ctx->num_layer = ARRAY_SIZE(vp_layer_config); >> +} else { >> +ctx->layer_config = default_layer_config; >> +ctx->num_layer = ARR
[PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote: > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > +config PWM_CRC > + bool "Intel Crystalcove (CRC) PWM support" > + depends on X86 && INTEL_SOC_PMIC > + help > + Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM > + control. > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module. (If I'm wrong, and that object file can actually be part of a module, you can stop reading here.) > --- /dev/null > +++ b/drivers/pwm/pwm-crc.c > +#include Perhaps this include is not needed. > +static const struct pwm_ops crc_pwm_ops = { > + .config = crc_pwm_config, > + .enable = crc_pwm_enable, > + .disable = crc_pwm_disable, > + .owner = THIS_MODULE, For built-in only code THIS_MODULE is basically equivalent to NULL (see include/linux/export.h). So I guess this line can be dropped. > +}; > +static struct platform_driver crystalcove_pwm_driver = { > + .probe = crystalcove_pwm_probe, > + .remove = crystalcove_pwm_remove, > + .driver = { > + .name = "crystal_cove_pwm", > + }, > +}; > + > +module_platform_driver(crystalcove_pwm_driver); Speaking from memory: for built-in only code this is equivalent to calling platform_driver_register(&crystalcove_pwm_driver); from a wrapper, and marking that wrapper with device_initcall(). > +MODULE_AUTHOR("Shobhit Kumar "); > +MODULE_DESCRIPTION("Intel Crystal Cove PWM Driver"); > +MODULE_LICENSE("GPL v2"); These macros will be effectively preprocessed away for built-in only code. Paul Bolle
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #14 from Tom Stellard --- Created attachment 115488 --> https://bugs.freedesktop.org/attachment.cgi?id=115488&action=edit Possible fix Can you try this applying this patch only? -- 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/20150430/35e82543/attachment.html>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> changed: What|Removed |Added Attachment #115487|0 |1 is obsolete|| --- Comment #18 from Macera <15gl8m+gcblm6z9ie2mkf at sharklasers.com> --- Created attachment 115489 --> https://bugs.freedesktop.org/attachment.cgi?id=115489&action=edit Tera Online dmesg errors (fixed) The last file had a line missing at the end. Well just in case it matters, I only get the crash sometimes when using the warrior combo attack skill. -- 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/20150430/ecf09403/attachment.html>
drm/exynos: Add atomic modesetting support
Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. v2: fixes comments by Joonyoung - remove unused var in patch 09 - use ->disable instead of outdated ->dpms in hdmi code - remove WARN_ON from crtc enable/disable v3: fixes comment by Joonyoung - move the removal of drm_helper_disable_unused_functions() to separated patch v4: add patches that remove unnecessary calls to disable_plane() Gustavo --- Gustavo Padovan (12): drm/exynos: atomic phase 1: use drm_plane_helper_update() drm/exynos: atomic phase 1: use drm_plane_helper_disable() drm/exynos: atomic phase 1: add .mode_set_nofb() callback drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy() drm/exynos: atomic phase 2: keep track of framebuffer pointer drm/exynos: atomic phase 3: atomic updates of planes drm/exynos: atomic phase 3: use atomic .set_config helper drm/exynos: atomic phase 3: convert page flips drm/exynos: remove exported functions from exynos_drm_plane drm/exynos: don't disable unused functions at init drm/exynos: atomic dpms support drm/exynos: remove unnecessary calls to disable_plane() drivers/gpu/drm/bridge/ps8622.c | 6 +- drivers/gpu/drm/bridge/ptn3460.c| 6 +- drivers/gpu/drm/exynos/exynos_dp_core.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 215 +-- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 35 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 12 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 - drivers/gpu/drm/exynos/exynos_drm_plane.c | 115 + drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c| 6 +- drivers/gpu/drm/exynos/exynos_hdmi.c| 10 +- 15 files changed, 178 insertions(+), 265 deletions(-)
[PATCH v4 01/12] drm/exynos: atomic phase 1: use drm_plane_helper_update()
From: Gustavo Padovan Rip out the check from exynos_update_plane() and create exynos_check_plane() for the check phase enabling use to use the atomic helpers to call our check and update phases when updating planes. Update all users of exynos_update_plane() accordingly to call exynos_check_plane() before. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 29 drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++- drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 +- 3 files changed, 43 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index eb49195..1c0d936 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -116,6 +116,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, struct drm_framebuffer *fb = crtc->primary->fb; unsigned int crtc_w; unsigned int crtc_h; + int ret; /* when framebuffer changing is requested, crtc's dpms should be on */ if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) { @@ -123,11 +124,16 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, return -EPERM; } + ret = exynos_check_plane(crtc->primary, fb); + if (ret) + return ret; + crtc_w = fb->width - x; crtc_h = fb->height - y; + exynos_update_plane(crtc->primary, crtc, fb, 0, 0, + crtc_w, crtc_h, x, y, crtc_w, crtc_h); - return exynos_update_plane(crtc->primary, crtc, fb, 0, 0, - crtc_w, crtc_h, x, y, crtc_w, crtc_h); + return 0; } static void exynos_drm_crtc_disable(struct drm_crtc *crtc) @@ -164,7 +170,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, { struct drm_device *dev = crtc->dev; struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); - struct drm_framebuffer *old_fb = crtc->primary->fb; unsigned int crtc_w, crtc_h; int ret; @@ -183,6 +188,10 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, goto out; } + ret = exynos_check_plane(crtc->primary, fb); + if (ret) + goto out; + ret = drm_vblank_get(dev, exynos_crtc->pipe); if (ret) { DRM_DEBUG("failed to acquire vblank counter\n"); @@ -201,17 +210,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, crtc->primary->fb = fb; crtc_w = fb->width - crtc->x; crtc_h = fb->height - crtc->y; - ret = exynos_update_plane(crtc->primary, crtc, fb, 0, 0, - crtc_w, crtc_h, crtc->x, crtc->y, - crtc_w, crtc_h); - if (ret) { - crtc->primary->fb = old_fb; - spin_lock_irq(&dev->event_lock); - exynos_crtc->event = NULL; - drm_vblank_put(dev, exynos_crtc->pipe); - spin_unlock_irq(&dev->event_lock); - return ret; - } + exynos_update_plane(crtc->primary, crtc, fb, 0, 0, + crtc_w, crtc_h, crtc->x, crtc->y, + crtc_w, crtc_h); return 0; diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index 13ea334..d7a046a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -144,21 +144,15 @@ void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc, plane->crtc = crtc; } -int +void exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, struct drm_framebuffer *fb, int crtc_x, int crtc_y, unsigned int crtc_w, unsigned int crtc_h, uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h) { - struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); - int ret; - - ret = exynos_check_plane(plane, fb); - if (ret < 0) - return ret; exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y, crtc_w, crtc_h, src_x >> 16, src_y >> 16, @@ -166,8 +160,6 @@ exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, if (exynos_crtc->ops->win_commit) exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos); - - return 0; } static int exynos_disable_plane(struct drm_plane *plane) @@ -183,11 +175,34 @@ static int exynos_disable_plane(struct drm_plane *plane) } static struct drm_plane_funcs exynos_plane_funcs = { - .update_plane = exynos_update_plane, + .update_plane = drm_plane_helper_update, .disable_plane = exyn
[PATCH v4 02/12] drm/exynos: atomic phase 1: use drm_plane_helper_disable()
From: Gustavo Padovan The atomic helper to disable planes also uses the optional .atomic_disable() helper. The unique operation it does is calling .win_disable() exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 26 +- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 929cb03..8a38eb7 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb) exynos_fb = to_exynos_fb(fb); - return exynos_fb->buf_cnt; + return exynos_fb ? exynos_fb->buf_cnt : 0; } struct drm_framebuffer * diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index d7a046a..ca93ad8 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -162,21 +162,9 @@ exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos); } -static int exynos_disable_plane(struct drm_plane *plane) -{ - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); - struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc); - - if (exynos_crtc && exynos_crtc->ops->win_disable) - exynos_crtc->ops->win_disable(exynos_crtc, - exynos_plane->zpos); - - return 0; -} - static struct drm_plane_funcs exynos_plane_funcs = { .update_plane = drm_plane_helper_update, - .disable_plane = exynos_disable_plane, + .disable_plane = drm_plane_helper_disable, .destroy= drm_plane_cleanup, }; @@ -198,9 +186,21 @@ static void exynos_plane_atomic_update(struct drm_plane *plane, state->src_w >> 16, state->src_h >> 16); } +static void exynos_plane_atomic_disable(struct drm_plane *plane, + struct drm_plane_state *old_state) +{ + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(old_state->crtc); + + if (exynos_crtc->ops->win_disable) + exynos_crtc->ops->win_disable(exynos_crtc, + exynos_plane->zpos); +} + static const struct drm_plane_helper_funcs plane_helper_funcs = { .atomic_check = exynos_plane_atomic_check, .atomic_update = exynos_plane_atomic_update, + .atomic_disable = exynos_plane_atomic_disable, }; static void exynos_plane_attach_zpos_property(struct drm_plane *plane, -- 2.1.0
[PATCH v4 03/12] drm/exynos: atomic phase 1: add .mode_set_nofb() callback
From: Gustavo Padovan The new atomic infrastructure needs the .mode_set_nofb() callback to update CRTC timings before setting any plane. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +--- 1 file changed, 9 insertions(+), 51 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 1c0d936..35f101f 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -81,59 +81,16 @@ exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc, return true; } -static int -exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode, int x, int y, - struct drm_framebuffer *old_fb) -{ - struct drm_framebuffer *fb = crtc->primary->fb; - unsigned int crtc_w; - unsigned int crtc_h; - int ret; - - /* -* copy the mode data adjusted by mode_fixup() into crtc->mode -* so that hardware can be seet to proper mode. -*/ - memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode)); - - ret = exynos_check_plane(crtc->primary, fb); - if (ret < 0) - return ret; - - crtc_w = fb->width - x; - crtc_h = fb->height - y; - exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0, - crtc_w, crtc_h, x, y, crtc_w, crtc_h); - - return 0; -} - -static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, - struct drm_framebuffer *old_fb) +static void +exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc) { struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); - struct drm_framebuffer *fb = crtc->primary->fb; - unsigned int crtc_w; - unsigned int crtc_h; - int ret; - /* when framebuffer changing is requested, crtc's dpms should be on */ - if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) { - DRM_ERROR("failed framebuffer changing request.\n"); - return -EPERM; - } - - ret = exynos_check_plane(crtc->primary, fb); - if (ret) - return ret; - - crtc_w = fb->width - x; - crtc_h = fb->height - y; - exynos_update_plane(crtc->primary, crtc, fb, 0, 0, - crtc_w, crtc_h, x, y, crtc_w, crtc_h); + if (WARN_ON(!crtc->state)) + return; - return 0; + if (exynos_crtc->ops->commit) + exynos_crtc->ops->commit(exynos_crtc); } static void exynos_drm_crtc_disable(struct drm_crtc *crtc) @@ -158,8 +115,9 @@ static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = { .prepare= exynos_drm_crtc_prepare, .commit = exynos_drm_crtc_commit, .mode_fixup = exynos_drm_crtc_mode_fixup, - .mode_set = exynos_drm_crtc_mode_set, - .mode_set_base = exynos_drm_crtc_mode_set_base, + .mode_set = drm_helper_crtc_mode_set, + .mode_set_nofb = exynos_drm_crtc_mode_set_nofb, + .mode_set_base = drm_helper_crtc_mode_set_base, .disable= exynos_drm_crtc_disable, }; -- 2.1.0
[PATCH v4 04/12] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy()
From: Gustavo Padovan Set CRTC, planes and connectors to use the default implementations from the atomic helper library. The helpers will work to keep track of state for each DRM object. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/bridge/ps8622.c | 4 drivers/gpu/drm/bridge/ptn3460.c | 4 drivers/gpu/drm/exynos/exynos_dp_core.c | 4 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_dpi.c | 4 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 drivers/gpu/drm/exynos/exynos_hdmi.c | 4 10 files changed, 40 insertions(+) diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c index e895aa7..b604326 100644 --- a/drivers/gpu/drm/bridge/ps8622.c +++ b/drivers/gpu/drm/bridge/ps8622.c @@ -31,6 +31,7 @@ #include "drmP.h" #include "drm_crtc.h" #include "drm_crtc_helper.h" +#include "drm_atomic_helper.h" /* Brightness scale on the Parade chip */ #define PS8622_MAX_BRIGHTNESS 0xff @@ -502,6 +503,9 @@ static const struct drm_connector_funcs ps8622_connector_funcs = { .fill_modes = drm_helper_probe_single_connector_modes, .detect = ps8622_detect, .destroy = ps8622_connector_destroy, + .reset = drm_atomic_helper_connector_reset, + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, }; static int ps8622_attach(struct drm_bridge *bridge) diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c index 9d2f053..8ed3617 100644 --- a/drivers/gpu/drm/bridge/ptn3460.c +++ b/drivers/gpu/drm/bridge/ptn3460.c @@ -27,6 +27,7 @@ #include "drm_crtc.h" #include "drm_crtc_helper.h" +#include "drm_atomic_helper.h" #include "drm_edid.h" #include "drmP.h" @@ -263,6 +264,9 @@ static struct drm_connector_funcs ptn3460_connector_funcs = { .fill_modes = drm_helper_probe_single_connector_modes, .detect = ptn3460_detect, .destroy = ptn3460_connector_destroy, + .reset = drm_atomic_helper_connector_reset, + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, }; static int ptn3460_bridge_attach(struct drm_bridge *bridge) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 1dbfba5..59f2ca5 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -958,6 +959,9 @@ static struct drm_connector_funcs exynos_dp_connector_funcs = { .fill_modes = drm_helper_probe_single_connector_modes, .detect = exynos_dp_detect, .destroy = exynos_dp_connector_destroy, + .reset = drm_atomic_helper_connector_reset, + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, }; static int exynos_dp_get_modes(struct drm_connector *connector) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 35f101f..44e73d0 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -14,6 +14,8 @@ #include #include +#include +#include #include "exynos_drm_crtc.h" #include "exynos_drm_drv.h" @@ -194,8 +196,12 @@ static struct drm_crtc_funcs exynos_crtc_funcs = { .set_config = drm_crtc_helper_set_config, .page_flip = exynos_drm_crtc_page_flip, .destroy= exynos_drm_crtc_destroy, + .reset = drm_atomic_helper_crtc_reset, + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, }; + struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev, struct drm_plane *plane, int pipe, diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index 37678cf..ced5c23 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -13,6 +13,7 @@ #include #include #include +#include #include @@ -63,6 +64,9 @@ static struct drm_connector_funcs exynos_dpi_connector_funcs = { .detect = exynos_dpi_detect, .fill_modes = drm_helper_probe_single_connector_modes, .destroy = exynos_dpi_connector_destroy, + .reset = drm_atomic_helper_connector_reset, + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_connec
[PATCH v4 05/12] drm/exynos: atomic phase 2: keep track of framebuffer pointer
From: Gustavo Padovan Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep track of the framebuffer pointer and reference. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 44e73d0..b080e83 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -174,6 +174,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, crtc_w, crtc_h, crtc->x, crtc->y, crtc_w, crtc_h); + if (crtc->primary->state) + drm_atomic_set_fb_for_plane(crtc->primary->state, fb); + return 0; out: -- 2.1.0
[PATCH v4 06/12] drm/exynos: atomic phase 3: atomic updates of planes
From: Gustavo Padovan Now that phase 1 and 2 are complete we can switch the update/disable_plane callbacks to their atomic version. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 8a38eb7..dcda496 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include "exynos_drm_drv.h" @@ -305,6 +306,8 @@ static void exynos_drm_output_poll_changed(struct drm_device *dev) static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = { .fb_create = exynos_user_fb_create, .output_poll_changed = exynos_drm_output_poll_changed, + .atomic_check = drm_atomic_helper_check, + .atomic_commit = drm_atomic_helper_commit, }; void exynos_drm_mode_config_init(struct drm_device *dev) diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index d53dc44..7d42e09 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -164,8 +164,8 @@ exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, } static struct drm_plane_funcs exynos_plane_funcs = { - .update_plane = drm_plane_helper_update, - .disable_plane = drm_plane_helper_disable, + .update_plane = drm_atomic_helper_update_plane, + .disable_plane = drm_atomic_helper_disable_plane, .destroy= drm_plane_cleanup, .reset = drm_atomic_helper_plane_reset, .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state, -- 2.1.0
[PATCH v4 07/12] drm/exynos: atomic phase 3: use atomic .set_config helper
From: Gustavo Padovan Now that phase 1 and 2 are complete switch .set_config helper to use the atomic one. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b080e83..b0888d4 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -196,7 +196,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc) } static struct drm_crtc_funcs exynos_crtc_funcs = { - .set_config = drm_crtc_helper_set_config, + .set_config = drm_atomic_helper_set_config, .page_flip = exynos_drm_crtc_page_flip, .destroy= exynos_drm_crtc_destroy, .reset = drm_atomic_helper_crtc_reset, -- 2.1.0
[PATCH v4 08/12] drm/exynos: atomic phase 3: convert page flips
From: Gustavo Padovan PageFlips now use the atomic helper to work through the atomic modesetting API. Async page flips are not supported yet. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +--- drivers/gpu/drm/exynos/exynos_drm_fb.c | 9 - 2 files changed, 9 insertions(+), 63 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b0888d4..0db7b91 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -123,67 +123,6 @@ static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = { .disable= exynos_drm_crtc_disable, }; -static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc, -struct drm_framebuffer *fb, -struct drm_pending_vblank_event *event, -uint32_t page_flip_flags) -{ - struct drm_device *dev = crtc->dev; - struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); - unsigned int crtc_w, crtc_h; - int ret; - - /* when the page flip is requested, crtc's dpms should be on */ - if (exynos_crtc->dpms > DRM_MODE_DPMS_ON) { - DRM_ERROR("failed page flip request.\n"); - return -EINVAL; - } - - if (!event) - return -EINVAL; - - spin_lock_irq(&dev->event_lock); - if (exynos_crtc->event) { - ret = -EBUSY; - goto out; - } - - ret = exynos_check_plane(crtc->primary, fb); - if (ret) - goto out; - - ret = drm_vblank_get(dev, exynos_crtc->pipe); - if (ret) { - DRM_DEBUG("failed to acquire vblank counter\n"); - goto out; - } - - exynos_crtc->event = event; - spin_unlock_irq(&dev->event_lock); - - /* -* the pipe from user always is 0 so we can set pipe number -* of current owner to event. -*/ - event->pipe = exynos_crtc->pipe; - - crtc->primary->fb = fb; - crtc_w = fb->width - crtc->x; - crtc_h = fb->height - crtc->y; - exynos_update_plane(crtc->primary, crtc, fb, 0, 0, - crtc_w, crtc_h, crtc->x, crtc->y, - crtc_w, crtc_h); - - if (crtc->primary->state) - drm_atomic_set_fb_for_plane(crtc->primary->state, fb); - - return 0; - -out: - spin_unlock_irq(&dev->event_lock); - return ret; -} - static void exynos_drm_crtc_destroy(struct drm_crtc *crtc) { struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); @@ -197,7 +136,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc) static struct drm_crtc_funcs exynos_crtc_funcs = { .set_config = drm_atomic_helper_set_config, - .page_flip = exynos_drm_crtc_page_flip, + .page_flip = drm_atomic_helper_page_flip, .destroy= exynos_drm_crtc_destroy, .reset = drm_atomic_helper_crtc_reset, .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c index dcda496..d5141af 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c @@ -303,11 +303,18 @@ static void exynos_drm_output_poll_changed(struct drm_device *dev) exynos_drm_fbdev_init(dev); } +static int exynos_atomic_commit(struct drm_device *dev, + struct drm_atomic_state *state, + bool async) +{ + return drm_atomic_helper_commit(dev, state, false); +} + static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = { .fb_create = exynos_user_fb_create, .output_poll_changed = exynos_drm_output_poll_changed, .atomic_check = drm_atomic_helper_check, - .atomic_commit = drm_atomic_helper_commit, + .atomic_commit = exynos_atomic_commit, }; void exynos_drm_mode_config_init(struct drm_device *dev) -- 2.1.0
[PATCH v4 09/12] drm/exynos: remove exported functions from exynos_drm_plane
From: Gustavo Padovan Now that no one is using the functions exported by exynos_drm_plane due to the atomic conversion we can make remove some of the them or make them static. v2: remove unused exynos_drm_crtc Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_plane.c | 90 +-- drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 2 files changed, 37 insertions(+), 64 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c b/drivers/gpu/drm/exynos/exynos_drm_plane.c index 7d42e09..8bad40e 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c @@ -62,35 +62,12 @@ static int exynos_plane_get_size(int start, unsigned length, unsigned last) return size; } -int exynos_check_plane(struct drm_plane *plane, struct drm_framebuffer *fb) -{ - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); - int nr; - int i; - - nr = exynos_drm_fb_get_buf_cnt(fb); - for (i = 0; i < nr; i++) { - struct exynos_drm_gem_buf *buffer = exynos_drm_fb_buffer(fb, i); - - if (!buffer) { - DRM_DEBUG_KMS("buffer is null\n"); - return -EFAULT; - } - - exynos_plane->dma_addr[i] = buffer->dma_addr; - - DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n", - i, (unsigned long)exynos_plane->dma_addr[i]); - } - - return 0; -} - -void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc, - struct drm_framebuffer *fb, int crtc_x, int crtc_y, - unsigned int crtc_w, unsigned int crtc_h, - uint32_t src_x, uint32_t src_y, - uint32_t src_w, uint32_t src_h) +static void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc, + struct drm_framebuffer *fb, + int crtc_x, int crtc_y, + unsigned int crtc_w, unsigned int crtc_h, + uint32_t src_x, uint32_t src_y, + uint32_t src_w, uint32_t src_h) { struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); unsigned int actual_w; @@ -145,24 +122,6 @@ void exynos_plane_mode_set(struct drm_plane *plane, struct drm_crtc *crtc, plane->crtc = crtc; } -void -exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, -struct drm_framebuffer *fb, int crtc_x, int crtc_y, -unsigned int crtc_w, unsigned int crtc_h, -uint32_t src_x, uint32_t src_y, -uint32_t src_w, uint32_t src_h) -{ - struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); - - exynos_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y, - crtc_w, crtc_h, src_x >> 16, src_y >> 16, - src_w >> 16, src_h >> 16); - - if (exynos_crtc->ops->win_commit) - exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos); -} - static struct drm_plane_funcs exynos_plane_funcs = { .update_plane = drm_atomic_helper_update_plane, .disable_plane = drm_atomic_helper_disable_plane, @@ -175,19 +134,44 @@ static struct drm_plane_funcs exynos_plane_funcs = { static int exynos_plane_atomic_check(struct drm_plane *plane, struct drm_plane_state *state) { - return exynos_check_plane(plane, state->fb); + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); + int nr; + int i; + + nr = exynos_drm_fb_get_buf_cnt(state->fb); + for (i = 0; i < nr; i++) { + struct exynos_drm_gem_buf *buffer = + exynos_drm_fb_buffer(state->fb, i); + + if (!buffer) { + DRM_DEBUG_KMS("buffer is null\n"); + return -EFAULT; + } + + exynos_plane->dma_addr[i] = buffer->dma_addr; + + DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n", + i, (unsigned long)exynos_plane->dma_addr[i]); + } + + return 0; } static void exynos_plane_atomic_update(struct drm_plane *plane, struct drm_plane_state *old_state) { struct drm_plane_state *state = plane->state; + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(state->crtc); + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); - exynos_update_plane(plane, state->crtc, state->fb, - state->crtc_x, state->crtc_y, - state->crtc_w, state->crtc_h, - state->src_x >> 16,
[PATCH v4 10/12] drm/exynos: don't disable unused functions at init
From: Gustavo Padovan Everything starts disabled so we don't really need to disable anything. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index e71e331..e0b085b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -275,9 +275,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev) } - /* disable all the possible outputs/crtcs before entering KMS mode */ - drm_helper_disable_unused_functions(dev); - ret = drm_fb_helper_initial_config(helper, PREFERRED_BPP); if (ret < 0) { DRM_ERROR("failed to set up hw configuration.\n"); -- 2.1.0
[PATCH v4 11/12] drm/exynos: atomic dpms support
From: Gustavo Padovan Run dpms operations through the atomic intefaces. This basically removes the .dpms() callback from econders and crtcs and use .disable() and .enable() to turn the crtc on and off. v2: Address comments by Joonyoung: - make hdmi code call ->disable() instead of ->dpms() - do not use WARN_ON on crtc enable/disable v3: - Fix build failure after the hdmi change in v2 - Change dpms helper of ptn3460 bridge Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/bridge/ps8622.c | 2 +- drivers/gpu/drm/bridge/ptn3460.c| 2 +- drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 99 - drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++-- drivers/gpu/drm/exynos/exynos_drm_vidi.c| 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c| 6 +- 10 files changed, 71 insertions(+), 77 deletions(-) diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c index b604326..d686235 100644 --- a/drivers/gpu/drm/bridge/ps8622.c +++ b/drivers/gpu/drm/bridge/ps8622.c @@ -499,7 +499,7 @@ static void ps8622_connector_destroy(struct drm_connector *connector) } static const struct drm_connector_funcs ps8622_connector_funcs = { - .dpms = drm_helper_connector_dpms, + .dpms = drm_atomic_helper_connector_dpms, .fill_modes = drm_helper_probe_single_connector_modes, .detect = ps8622_detect, .destroy = ps8622_connector_destroy, diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c index 8ed3617..260bc9f 100644 --- a/drivers/gpu/drm/bridge/ptn3460.c +++ b/drivers/gpu/drm/bridge/ptn3460.c @@ -260,7 +260,7 @@ static void ptn3460_connector_destroy(struct drm_connector *connector) } static struct drm_connector_funcs ptn3460_connector_funcs = { - .dpms = drm_helper_connector_dpms, + .dpms = drm_atomic_helper_connector_dpms, .fill_modes = drm_helper_probe_single_connector_modes, .detect = ptn3460_detect, .destroy = ptn3460_connector_destroy, diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 59f2ca5..d468637 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -955,7 +955,7 @@ static void exynos_dp_connector_destroy(struct drm_connector *connector) } static struct drm_connector_funcs exynos_dp_connector_funcs = { - .dpms = drm_helper_connector_dpms, + .dpms = drm_atomic_helper_connector_dpms, .fill_modes = drm_helper_probe_single_connector_modes, .detect = exynos_dp_detect, .destroy = exynos_dp_connector_destroy, diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 0db7b91..519c569 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -22,51 +22,57 @@ #include "exynos_drm_encoder.h" #include "exynos_drm_plane.h" -static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode) +static void exynos_drm_crtc_enable(struct drm_crtc *crtc) { struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); + struct exynos_drm_plane *exynos_plane = to_exynos_plane(crtc->primary); - DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode); - - if (exynos_crtc->dpms == mode) { - DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n"); + if (exynos_crtc->enabled) return; - } - - if (mode > DRM_MODE_DPMS_ON) { - /* wait for the completion of page flip. */ - if (!wait_event_timeout(exynos_crtc->pending_flip_queue, - (exynos_crtc->event == NULL), HZ/20)) - exynos_crtc->event = NULL; - drm_crtc_vblank_off(crtc); - } if (exynos_crtc->ops->dpms) - exynos_crtc->ops->dpms(exynos_crtc, mode); + exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_ON); - exynos_crtc->dpms = mode; + exynos_crtc->enabled = true; - if (mode == DRM_MODE_DPMS_ON) - drm_crtc_vblank_on(crtc); -} + drm_crtc_vblank_on(crtc); -static void exynos_drm_crtc_prepare(struct drm_crtc *crtc) -{ - /* drm framework doesn't check NULL. */ + if (exynos_crtc->ops->win_commit) + exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos); + + if (exynos_crtc->ops->commit) + exynos_crtc->ops->commit(exynos_crtc); } -static void exynos_drm_crtc_commit(struct drm_crtc *crtc) +static void exynos_drm_crtc_disable(struct drm_crtc *crtc) { struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); - struct exynos_drm_plane *exynos
[PATCH v4 12/12] drm/exynos: remove unnecessary calls to disable_plane()
From: Gustavo Padovan The planes are already disabled by the drm_atomic_helper_commit() code so we don't need to disable the in these two places. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 --- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 8 2 files changed, 19 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index 519c569..9bf25ff 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -47,8 +47,6 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc) static void exynos_drm_crtc_disable(struct drm_crtc *crtc) { struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc); - struct drm_plane *plane; - int ret; if (!exynos_crtc->enabled) return; @@ -64,15 +62,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc) exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_OFF); exynos_crtc->enabled = false; - - drm_for_each_legacy_plane(plane, &crtc->dev->mode_config.plane_list) { - if (plane->crtc != crtc) - continue; - - ret = plane->funcs->disable_plane(plane); - if (ret) - DRM_ERROR("Failed to disable plane %d\n", ret); - } } static bool diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c b/drivers/gpu/drm/exynos/exynos_drm_encoder.c index 0648ba4..7b89fd5 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c @@ -81,17 +81,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder *encoder) { struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder); struct exynos_drm_display *display = exynos_encoder->display; - struct drm_plane *plane; - struct drm_device *dev = encoder->dev; if (display->ops->dpms) display->ops->dpms(display, DRM_MODE_DPMS_OFF); - - /* all planes connected to this encoder should be also disabled. */ - drm_for_each_legacy_plane(plane, &dev->mode_config.plane_list) { - if (plane->crtc && (plane->crtc == encoder->crtc)) - plane->funcs->disable_plane(plane); - } } static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = { -- 2.1.0
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #15 from Andy Furniss --- (In reply to Tom Stellard from comment #14) > Created attachment 115488 [details] [review] > Possible fix > > Can you try this applying this patch only? This fixes 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/20150430/4793b765/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #258 from Guram Savinov --- (In reply to Maciej Gluszek from comment #257) > @Guram Savinov: I also tried setting DPM + high performance for my HD3650 > and it worked but the fan was still running too loud (not overheating just > loud). > > Then i installed Kernel 4.0, removed "high performance" settings and it > works great now. I still have DPM set during boot but no more setting the > card to be running on high performance. Couple of days and no lockups. > > I'm on Ubuntu. Maybe turning off DPM (do not set radeon.dpm=1 in kernel parameters) is better than using DPM with high performance? What Ubuntu release do you use? How you installed kernel 4.0? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150430/364805e1/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #259 from Maciej Gluszek --- Sorry, I was wrong after all. After 2 days i got a lockup again and went back to the old method. When i don't set DPM at boot GPU is overheating and the fan goes crazy. When setting performance to something other than "high" - lockups happen. I'm on Ubuntu 14.04 and using kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ -- 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/20150430/47c9dda5/attachment.html>
[Bug 76130] Radeon HD 4570 set dpm state fails after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=76130 --- Comment #13 from Adrien Prost-Boucle --- I tried with option radeon.dpm=0 and yes the message disappears at resume from sleep. But on my machine I never noticed graphics slowdown (at least with vlank_mode=0 glxgears). I'm not a consumer of fancy graphics or games. However what I noticed without that option was buggy scrolling in Firefox (and only Firefox). Sometimes all new tabs took like 5 seconds to unfreeze, and once unfreezed each tab remained responsive. Rather strange. I'll use the laptop for a few days to be sure it no longer happens. -- 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/20150430/1a11f798/attachment.html>
[PATCH] drm: panel: simple-panel: set appropriate mode type
Le 30/04/2015 16:39, Boris Brezillon a écrit : > All modes exposed by simple panels should be tagged as driver defined > modes. > Moreover, if a panel supports only one mode, this mode is obviously the > preferred one. > > Doing this also fix a problem occurring when a 'video=' parameter is passed > on the kernel cmdline. In some cases the user provided mode is preferred > over the simple panel ones, which might result in unpredictable behavior. > > Signed-off-by: Boris Brezillon Tested-by: Nicolas Ferre On Atmel sama5d3xek board. > --- > drivers/gpu/drm/panel/panel-simple.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index d14b904..95ae390 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -111,6 +111,10 @@ static int panel_simple_get_fixed_modes(struct > panel_simple *panel) > continue; > } > > + mode->type |= DRM_MODE_TYPE_DRIVER; > + if (panel->desc->num_modes == 1) > + mode->type |= DRM_MODE_TYPE_PREFERRED; > + > drm_display_mode_from_videomode(&vm, mode); > > drm_mode_probed_add(connector, mode); > @@ -127,6 +131,10 @@ static int panel_simple_get_fixed_modes(struct > panel_simple *panel) > continue; > } > > + mode->type |= DRM_MODE_TYPE_DRIVER; > + if (panel->desc->num_modes == 1) > + mode->type |= DRM_MODE_TYPE_PREFERRED; > + > drm_mode_set_name(mode); > > drm_mode_probed_add(connector, mode); > -- Nicolas Ferre
[PATCH v2 0/2] clk: adapt ->round_rate()/->determine_rate() prototypes
Hello, As previously discussed in this thread [1], this series is changing clk_ops' ->round_rate()/->determine_rate() prototypes to avoid long overflows when the returned rate is exceeding 2Ghz. Most of those changes have been compile-tested, but none of them have been tested on real hardware (the changes are quite simple though). Best Regards, Boris [1]https://lkml.org/lkml/2015/4/14/528 Changes since v1: - fix an 'uninitialized variable' bug reported by Heiko - rebased on clk-next CC: Jonathan Corbet CC: Shawn Guo CC: ascha Hauer CC: David Brown CC: Daniel Walker CC: Bryan Huntsman CC: Tony Lindgren CC: Paul Walmsley CC: Liviu Dudau CC: Sudeep Holla CC: Lorenzo Pieralisi CC: Ralf Baechle CC: Max Filippov CC: Heiko Stuebner CC: Sylwester Nawrocki CC: Tomasz Figa CC: Barry Song CC: Viresh Kumar CC: "Emilio López" CC: Maxime Ripard CC: Peter De Schrijver CC: Prashant Gaikwad CC: Stephen Warren CC: Thierry Reding CC: Alexandre Courbot CC: Tero Kristo CC: Ulf Hansson CC: Michal Simek CC: Philipp Zabel CC: linux-doc at vger.kernel.org CC: linux-kernel at vger.kernel.org CC: linux-arm-kernel at lists.infradead.org CC: linux-arm-msm at vger.kernel.org CC: linux-omap at vger.kernel.org CC: linux-mips at linux-mips.org CC: patches at opensource.wolfsonmicro.com CC: linux-rockchip at lists.infradead.org CC: linux-samsung-soc at vger.kernel.org CC: spear-devel at list.st.com CC: linux-tegra at vger.kernel.org CC: dri-devel at lists.freedesktop.org CC: linux-media at vger.kernel.org CC: rtc-linux at googlegroups.com Boris Brezillon (2): clk: change clk_ops' ->round_rate() prototype clk: change clk_ops' ->determine_rate() prototype Documentation/clk.txt| 8 +-- arch/arm/mach-imx/clk-busy.c | 2 +- arch/arm/mach-imx/clk-cpu.c | 12 +++- arch/arm/mach-imx/clk-fixup-div.c| 2 +- arch/arm/mach-imx/clk-pfd.c | 11 ++-- arch/arm/mach-imx/clk-pllv2.c| 8 ++- arch/arm/mach-imx/clk-pllv3.c| 46 +++-- arch/arm/mach-msm/clock-pcom.c | 4 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++-- arch/arm/mach-omap2/clkt_clksel.c| 6 +- arch/arm/mach-omap2/clkt_dpll.c | 21 +++--- arch/arm/mach-omap2/clock.h | 4 +- arch/arm/mach-omap2/dpll3xxx.c | 45 - arch/arm/mach-omap2/dpll44xx.c | 44 +++-- arch/arm/mach-vexpress/spc.c | 11 +++- arch/mips/alchemy/common/clock.c | 76 ++ drivers/clk/at91/clk-h32mx.c | 24 --- drivers/clk/at91/clk-peripheral.c| 31 + drivers/clk/at91/clk-pll.c | 14 ++-- drivers/clk/at91/clk-plldiv.c| 22 --- drivers/clk/at91/clk-programmable.c | 28 drivers/clk/at91/clk-smd.c | 24 --- drivers/clk/at91/clk-usb.c | 42 ++-- drivers/clk/bcm/clk-kona.c | 24 --- drivers/clk/clk-axi-clkgen.c | 5 +- drivers/clk/clk-cdce706.c| 46 ++--- drivers/clk/clk-composite.c | 27 drivers/clk/clk-divider.c| 16 +++-- drivers/clk/clk-fixed-factor.c | 7 +- drivers/clk/clk-fractional-divider.c | 16 +++-- drivers/clk/clk-highbank.c | 18 +++--- drivers/clk/clk-si5351.c | 96 ++-- drivers/clk/clk-si570.c | 14 ++-- drivers/clk/clk-u300.c | 65 ++- drivers/clk/clk-vt8500.c | 27 drivers/clk/clk-wm831x.c | 11 ++-- drivers/clk/clk-xgene.c | 11 ++-- drivers/clk/clk.c| 72 +++-- drivers/clk/hisilicon/clk-hi3620.c | 22 +++ drivers/clk/mmp/clk-frac.c | 14 ++-- drivers/clk/mmp/clk-mix.c| 17 ++--- drivers/clk/mvebu/clk-corediv.c | 7 +- drivers/clk/mvebu/clk-cpu.c | 9 +-- drivers/clk/mxs/clk-div.c| 4 +- drivers/clk/mxs/clk-frac.c | 11 ++-- drivers/clk/mxs/clk-ref.c| 11 ++-- drivers/clk/qcom/clk-pll.c | 12 ++-- drivers/clk/qcom/clk-rcg.c | 32 +- drivers/clk/qcom/clk-rcg2.c | 54 +--- drivers/clk/qcom/clk-regmap-divider.c| 4 +- drivers/clk/rockchip/clk-pll.c | 13 ++-- drivers/clk/samsung/clk-pll.c| 13 ++-- drivers/clk/shmobile/clk-div6.c | 7 +- drivers/clk/shmobile/clk-rcar-gen2.c | 9 +-- drivers/clk/sirf/clk-common.c| 18 +++--- drivers/clk/spear/clk-aux-synth.c| 10 ++- drivers/clk/spear/cl
[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
Clock rates are stored in an unsigned long field, but ->round_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change ->round_rate() prototype to return 0 or an error code, and pass the requested rate as a pointer so that it can be adjusted depending on hardware capabilities. Signed-off-by: Boris Brezillon Tested-by: Heiko Stuebner Tested-by: Mikko Perttunen Reviewed-by: Heiko Stuebner --- CC: Jonathan Corbet CC: Shawn Guo CC: ascha Hauer CC: David Brown CC: Daniel Walker CC: Bryan Huntsman CC: Tony Lindgren CC: Paul Walmsley CC: Liviu Dudau CC: Sudeep Holla CC: Lorenzo Pieralisi CC: Ralf Baechle CC: Max Filippov CC: Heiko Stuebner CC: Sylwester Nawrocki CC: Tomasz Figa CC: Barry Song CC: Viresh Kumar CC: "Emilio López" CC: Maxime Ripard CC: Peter De Schrijver CC: Prashant Gaikwad CC: Stephen Warren CC: Thierry Reding CC: Alexandre Courbot CC: Tero Kristo CC: Ulf Hansson CC: Michal Simek CC: Philipp Zabel CC: linux-doc at vger.kernel.org CC: linux-kernel at vger.kernel.org CC: linux-arm-kernel at lists.infradead.org CC: linux-arm-msm at vger.kernel.org CC: linux-omap at vger.kernel.org CC: linux-mips at linux-mips.org CC: patches at opensource.wolfsonmicro.com CC: linux-rockchip at lists.infradead.org CC: linux-samsung-soc at vger.kernel.org CC: spear-devel at list.st.com CC: linux-tegra at vger.kernel.org CC: dri-devel at lists.freedesktop.org CC: linux-media at vger.kernel.org CC: rtc-linux at googlegroups.com Documentation/clk.txt| 4 +- arch/arm/mach-imx/clk-busy.c | 2 +- arch/arm/mach-imx/clk-cpu.c | 12 +++- arch/arm/mach-imx/clk-fixup-div.c| 2 +- arch/arm/mach-imx/clk-pfd.c | 11 ++-- arch/arm/mach-imx/clk-pllv2.c| 8 ++- arch/arm/mach-imx/clk-pllv3.c| 46 +++-- arch/arm/mach-msm/clock-pcom.c | 4 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 13 ++-- arch/arm/mach-omap2/clkt_clksel.c| 6 +- arch/arm/mach-omap2/clkt_dpll.c | 21 +++--- arch/arm/mach-omap2/clock.h | 4 +- arch/arm/mach-omap2/dpll3xxx.c | 27 +--- arch/arm/mach-omap2/dpll44xx.c | 26 +--- arch/arm/mach-vexpress/spc.c | 11 +++- arch/mips/alchemy/common/clock.c | 13 ++-- drivers/clk/at91/clk-h32mx.c | 24 --- drivers/clk/at91/clk-peripheral.c| 31 + drivers/clk/at91/clk-pll.c | 14 ++-- drivers/clk/at91/clk-plldiv.c| 22 --- drivers/clk/at91/clk-smd.c | 24 --- drivers/clk/at91/clk-usb.c | 16 +++-- drivers/clk/clk-axi-clkgen.c | 5 +- drivers/clk/clk-cdce706.c| 46 ++--- drivers/clk/clk-composite.c | 23 --- drivers/clk/clk-divider.c| 16 +++-- drivers/clk/clk-fixed-factor.c | 7 +- drivers/clk/clk-fractional-divider.c | 16 +++-- drivers/clk/clk-highbank.c | 18 +++--- drivers/clk/clk-si5351.c | 96 ++-- drivers/clk/clk-si570.c | 14 ++-- drivers/clk/clk-u300.c | 65 ++- drivers/clk/clk-vt8500.c | 27 drivers/clk/clk-wm831x.c | 11 ++-- drivers/clk/clk-xgene.c | 11 ++-- drivers/clk/clk.c| 14 ++-- drivers/clk/mmp/clk-frac.c | 14 ++-- drivers/clk/mvebu/clk-corediv.c | 7 +- drivers/clk/mvebu/clk-cpu.c | 9 +-- drivers/clk/mxs/clk-div.c| 4 +- drivers/clk/mxs/clk-frac.c | 11 ++-- drivers/clk/mxs/clk-ref.c| 11 ++-- drivers/clk/qcom/clk-regmap-divider.c| 4 +- drivers/clk/rockchip/clk-pll.c | 13 ++-- drivers/clk/samsung/clk-pll.c| 13 ++-- drivers/clk/shmobile/clk-div6.c | 7 +- drivers/clk/shmobile/clk-rcar-gen2.c | 9 +-- drivers/clk/sirf/clk-common.c| 18 +++--- drivers/clk/spear/clk-aux-synth.c| 10 ++- drivers/clk/spear/clk-frac-synth.c | 10 ++- drivers/clk/spear/clk-gpt-synth.c| 10 ++- drivers/clk/spear/clk-vco-pll.c | 20 -- drivers/clk/st/clk-flexgen.c | 11 ++-- drivers/clk/st/clkgen-fsyn.c | 21 +++--- drivers/clk/st/clkgen-mux.c | 2 +- drivers/clk/sunxi/clk-factors.c | 14 ++-- drivers/clk/tegra/clk-audio-sync.c | 8 +-- drivers/clk/tegra/clk-divider.c | 19 -- drivers/clk/tegra/clk-periph.c | 4 +- drivers/cl
[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
Hello Olof, On 04/30/2015 05:57 PM, Olof Johansson wrote: > On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote: >> Krzysztof Kozlowski writes: > > This should fix issue reported by Javier [1][2]. > > Tested on Chromebook Snow (Exynos 5250). More testing would be great, > especially on other Exynos 5xxx products. I hoped to try this on my exynos5 boards, but it doesn't seem to apply to linux-next or to Linus' master branch. Are there some other dependencies here? >>> >>> It is already applied: >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc >> >> Er, yup. That would explain it. ;) >> >> Sorry for the noise, > > Well, noise or not, Exynos is still broken in mainline and was broken > on -next for so long in different ways that bisecting it is a futile > exercise in frustration. > > It doesn't seem to show up with a trivial boot using only ramdisk, but > when booting a real distro from disk, it certainly does. > > For example: > > http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html > > Disabling CONFIG_DRM makes it boot reliably. > > Arndale doesn't show it for me, but it also doesn't have working graphics. > Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420" patch that was posted a long time ago. I have pinged Kukjin several times about this patch and he said that he will pick it this weekend [0]. It is indeed very frustrating how many Exynos patches seems to be falling through the crack, even important fixes like these ones that allow boards to boot again. Kevin suggested that Krzysztof could collect and queue patches [1] to help Kukjin and start acting as a co-maintatiner which I think it's a very good idea and Krzysztof already did for some patches during the 4.1 cycle. > > -Olof > Best regards, Javier [0]: https://lkml.org/lkml/2015/4/29/781 [1]: https://lkml.org/lkml/2015/4/30/576 [2]: https://lkml.org/lkml/2015/3/11/403
[RFC 1/5] drm/exynos: mixer: refactor layer setup
2015-04-30 Tobias Jakobi : > Hello Gustavo! > > > Gustavo Padovan wrote: > > Hi Tobias, > > > > 2015-04-30 Tobias Jakobi : > > > >> First step in allowing a more generic way to setup complex > >> blending for the different layers. > >> > >> Signed-off-by: Tobias Jakobi > >> --- > >> drivers/gpu/drm/exynos/exynos_mixer.c | 74 > >> +-- > >> 1 file changed, 63 insertions(+), 11 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > >> b/drivers/gpu/drm/exynos/exynos_mixer.c > >> index 4155f43..a06b8e2 100644 > >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c > >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > >> @@ -63,6 +63,12 @@ struct mixer_resources { > >>struct clk *mout_mixer; > >> }; > >> > >> +struct layer_config { > >> + unsigned int index; > >> + unsigned int priority; > >> + u32 cfg; > >> +}; > > > > I don't see why you are creating this struct, index and priority are > > never used in this patch series. > Good catch about 'priority'. But 'index' is used, see the second patch. > > > > > > >> + > >> enum mixer_version_id { > >>MXR_VER_0_0_0_16, > >>MXR_VER_16_0_33_0, > >> @@ -75,6 +81,8 @@ struct mixer_context { > >>struct drm_device *drm_dev; > >>struct exynos_drm_crtc *crtc; > >>struct exynos_drm_plane planes[MIXER_WIN_NR]; > >> + const struct layer_config *layer_config; > >> + unsigned int num_layer; > >>int pipe; > >>boolinterlace; > >>boolpowered; > >> @@ -95,6 +103,40 @@ struct mixer_drv_data { > >>boolhas_sclk; > >> }; > >> > >> +/* > >> + * The default layer priorities. A higher priority means that > >> + * the layer is at the top of layer stack. > >> + * The current configuration assumes the following usage scenario: > >> + * layer1: OSD [top] > >> + * layer0: main framebuffer > >> + * video layer: video overlay [bottom] > >> + * Note that the video layer is only usable when the > >> + * video processor is available. > >> + */ > >> + > >> +static const struct layer_config default_layer_config[] = { > >> + { > >> + .index = 0, .priority = 1, /* layer0 */ > >> + .cfg = MXR_LAYER_CFG_GRP0_VAL(1) > >> + }, { > >> + .index = 1, .priority = 2, /* layer1 */ > >> + .cfg = MXR_LAYER_CFG_GRP1_VAL(2) > >> + } > >> +}; > >> + > >> +static const struct layer_config vp_layer_config[] = { > >> + { > >> + .index = 2, .priority = 1, /* video layer */ > >> + .cfg = MXR_LAYER_CFG_VP_VAL(1) > >> + }, { > >> + .index = 0, .priority = 2, /* layer0 */ > >> + .cfg = MXR_LAYER_CFG_GRP0_VAL(2) > >> + }, { > >> + .index = 1, .priority = 3, /* layer1 */ > >> + .cfg = MXR_LAYER_CFG_GRP1_VAL(3) > >> + } > >> +}; > >> + > >> static const u8 filter_y_horiz_tap8[] = { > >>0, -1, -1, -1, -1, -1, -1, -1, > >>-1, -1, -1, -1, -1, 0, 0, 0, > >> @@ -253,6 +295,17 @@ static void vp_default_filter(struct mixer_resources > >> *res) > >>filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4)); > >> } > >> > >> +static void mixer_layer_priority(struct mixer_context *ctx) > >> +{ > >> + u32 val = 0; > >> + unsigned int i; > >> + > >> + for (i = 0; i < ctx->num_layer; ++i) > >> + val |= ctx->layer_config[i].cfg; > >> + > >> + mixer_reg_write(&ctx->mixer_res, MXR_LAYER_CFG, val); > >> +} > >> + > >> static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable) > >> { > >>struct mixer_resources *res = &ctx->mixer_res; > >> @@ -655,17 +708,7 @@ static void mixer_win_reset(struct mixer_context *ctx) > >>mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST, > >>MXR_STATUS_BURST_MASK); > >> > >> - /* setting default layer priority: layer1 > layer0 > video > >> - * because typical usage scenario would be > >> - * layer1 - OSD > >> - * layer0 - framebuffer > >> - * video - video overlay > >> - */ > >> - val = MXR_LAYER_CFG_GRP1_VAL(3); > >> - val |= MXR_LAYER_CFG_GRP0_VAL(2); > >> - if (ctx->vp_enabled) > >> - val |= MXR_LAYER_CFG_VP_VAL(1); > >> - mixer_reg_write(res, MXR_LAYER_CFG, val); > > > > I would move this exaclty piece of code into mixer_layer_priority(). > Then we end up with the same static/hardcoded setup as before. That's > something I want to move away from. The entire information about layer > ordering should be stored in 'layer_config'. > > > > >> + mixer_layer_priority(ctx); > >> > >>/* setting background color */ > >>mixer_reg_write(res, MXR_BG_COLOR0, 0x008080); > >> @@ -1274,6 +1317,15 @@ static int mixer_probe(struct platform_device *pdev) > >>ctx->vp_enabled = drv->is_vp_enabled; > >>ctx->has_sclk = drv->has_sclk; > >>ctx->mxr_ver = drv->version; > >> + > >> + if (drv->is_vp_enabled) { > >> + ctx->layer_con
[RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
Krzysztof Kozlowski writes: > 2015-04-30 2:31 GMT+09:00 Kevin Hilman : >> Krzysztof Kozlowski writes: >> >>> After adding display power domain for Exynos5250 in commit >>> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the >>> display on Chromebook Snow and others stopped working after boot. >>> >>> The reason for this suggested Andrzej Hajda: the DP clock was disabled. >>> This clock is required by Display Port and is enabled by bootloader. >>> However when FIMD driver probing was deferred, the display power domain >>> was turned off. This effectively reset the value of DP clock enable >>> register. >>> >>> When exynos-dp is later probed, the clock is not enabled and display is >>> not properly configured: >>> >>> exynos-dp 145b.dp-controller: Timeout of video streamclk ok >>> exynos-dp 145b.dp-controller: unable to config video >>> >>> Signed-off-by: Krzysztof Kozlowski >>> Reported-by: Javier Martinez Canillas >>> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") >>> Cc: >>> >>> --- >>> >>> This should fix issue reported by Javier [1][2]. >>> >>> Tested on Chromebook Snow (Exynos 5250). More testing would be great, >>> especially on other Exynos 5xxx products. >> >> I hoped to try this on my exynos5 boards, but it doesn't seem to apply >> to linux-next or to Linus' master branch. >> >> Are there some other dependencies here? > > It is already applied: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc Er, yup. That would explain it. ;) Sorry for the noise, Kevin
[PATCH 2/9] mm: Provide new get_vaddr_pfns() helper
On Tue, Mar 17, 2015 at 12:56:32PM +0100, Jan Kara wrote: > Provide new function get_vaddr_pfns(). This function maps virtual > addresses from given start and fills given array with page frame numbers of > the corresponding pages. If given start belongs to a normal vma, the function > grabs reference to each of the pages to pin them in memory. If start > belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller > should make sure pfns aren't reused for anything else while he is using > them. > > This function is created for various drivers to simplify handling of > their buffers. > > Signed-off-by: Jan Kara > --- > include/linux/mm.h | 38 +++ > mm/gup.c | 180 > + > 2 files changed, 218 insertions(+) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 47a93928b90f..a5045df92454 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1279,6 +1279,44 @@ long get_user_pages_unlocked(struct task_struct *tsk, > struct mm_struct *mm, > int write, int force, struct page **pages); > int get_user_pages_fast(unsigned long start, int nr_pages, int write, > struct page **pages); > + > +/* Container for pinned pfns / pages */ > +struct pinned_pfns { > + unsigned int nr_allocated_pfns; /* Number of pfns we have space for */ > + unsigned int nr_pfns; /* Number of pfns stored in pfns array > */ > + unsigned int got_ref:1; /* Did we pin pfns by getting page ref? > */ > + unsigned int is_pages:1;/* Does array contain pages or pfns? */ The bit field is probably overkill as I expect it'll get padded out for pointer alignment anyway. Just use bools. is_pfns is less ambiguous than is_pages but not very important. The naming is not great in general. Only struct pages are pinned in the traditional meaning of the word. The raw PFNs are not so there is no such thing as a "pinned pfns". It might be better just to call it frame_vectors and document that it's either raw PFNs that the caller should be responsible for or struct pages that are pinned. > + void *ptrs[0]; /* Array of pinned pfns / pages. > + * Use pfns_vector_pages() or > + * pfns_vector_pfns() for access */ > +}; > + > +struct pinned_pfns *pfns_vector_create(int nr_pfns); > +void pfns_vector_destroy(struct pinned_pfns *pfns); > +int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force, > +struct pinned_pfns *pfns); It's not critical but I generally prefer to see bools for new APIs like this. unsigned int for nr_pfns. > +void put_vaddr_pfns(struct pinned_pfns *pfns); > +int pfns_vector_to_pages(struct pinned_pfns *pfns); > + > +static inline int pfns_vector_count(struct pinned_pfns *pfns) > +{ > + return pfns->nr_pfns; > +} should return unsigned int. > + > +static inline struct page **pfns_vector_pages(struct pinned_pfns *pfns) > +{ > + if (!pfns->is_pages) > + return NULL; > + return (struct page **)(pfns->ptrs); > +} > + > +static inline unsigned long *pfns_vector_pfns(struct pinned_pfns *pfns) > +{ > + if (pfns->is_pages) > + return NULL; > + return (unsigned long *)(pfns->ptrs); > +} > + > struct kvec; > int get_kernel_pages(const struct kvec *iov, int nr_pages, int write, > struct page **pages); > diff --git a/mm/gup.c b/mm/gup.c > index a6e24e246f86..63903913ab04 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -819,6 +819,186 @@ long get_user_pages(struct task_struct *tsk, struct > mm_struct *mm, > EXPORT_SYMBOL(get_user_pages); > > /** > + * get_vaddr_pfns() - map virtual addresses to pfns > + * @start: starting user address > + * @nr_pfns: number of pfns from start to map > + * @write: whether pages will be written to by the caller > + * @force: whether to force write access even if user mapping is > + * readonly. This will result in the page being COWed even > + * in MAP_SHARED mappings. You do not want this. > + * @pfns:structure which receives pfns of the pages mapped. > + * It should have space for at least nr_pfns pfns. > + * > + * This function maps virtual addresses from @start and fills @pfns structure > + * with page frame numbers of corresponding pages. If @start belongs to a > + * normal vma, the function grabs reference to each of the pages to pin them > in > + * memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page > + * structures. Caller should make sure pfns aren't reused for anything else > + * while he is using them. > + * > + * This function takes care of grabbing mmap_sem as necessary. > + */ > +int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force, > +struct pinned_pfns *pfns) > +{ > + struct mm_struct *mm = current->mm; > + struct vm_are
[PATCH 04/11] drivers/gpu: include for modular rockchip code
These files are built off of a tristate Kconfig option and also contain modular function calls so they should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Cc: David Airlie Cc: Mark Yao Cc: dri-devel at lists.freedesktop.org Signed-off-by: Paul Gortmaker --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 3962176ee713..01b558fe3695 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index ccb0ce073ef2..38155215efcd 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -19,6 +19,7 @@ #include #include +#include #include #include #include -- 2.2.1