[PATCH 1/2] video: of: display_timing: correct display-timings node finding
of_get_display_timing(s) use of_find_node_by_name
to get child node, this is incorrect, of_get_child_by_name
should be used instead. The patch fixes it.
Small typo is also corrected.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/video/of_display_timing.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
index 171821d..ba5b40f 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -120,7 +120,7 @@ int of_get_display_timing(struct device_node *np, const
char *name,
return -EINVAL;
}
- timing_np = of_find_node_by_name(np, name);
+ timing_np = of_get_child_by_name(np, name);
if (!timing_np) {
pr_err("%s: could not find node '%s'\n",
of_node_full_name(np), name);
@@ -143,11 +143,11 @@ struct display_timings *of_get_display_timings(struct
device_node *np)
struct display_timings *disp;
if (!np) {
- pr_err("%s: no devicenode given\n", of_node_full_name(np));
+ pr_err("%s: no device node given\n", of_node_full_name(np));
return NULL;
}
- timings_np = of_find_node_by_name(np, "display-timings");
+ timings_np = of_get_child_by_name(np, "display-timings");
if (!timings_np) {
pr_err("%s: could not find display-timings node\n",
of_node_full_name(np));
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] video: of: display_timing: remove broken of_display_timings_exist
of_display_timings_exist is implemented incorrectly.
It tries to find property instead of node.
The function is not used anyway so the patch removes it.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/video/of_display_timing.c | 20
include/video/of_display_timing.h | 1 -
2 files changed, 21 deletions(-)
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
index ba5b40f..b423bb9 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -247,23 +247,3 @@ dispfail:
return NULL;
}
EXPORT_SYMBOL_GPL(of_get_display_timings);
-
-/**
- * of_display_timings_exist - check if a display-timings node is provided
- * @np: device_node with the timing
- **/
-int of_display_timings_exist(struct device_node *np)
-{
- struct device_node *timings_np;
-
- if (!np)
- return -EINVAL;
-
- timings_np = of_parse_phandle(np, "display-timings", 0);
- if (!timings_np)
- return -EINVAL;
-
- of_node_put(timings_np);
- return 1;
-}
-EXPORT_SYMBOL_GPL(of_display_timings_exist);
diff --git a/include/video/of_display_timing.h
b/include/video/of_display_timing.h
index 79e6697..16cde75 100644
--- a/include/video/of_display_timing.h
+++ b/include/video/of_display_timing.h
@@ -18,6 +18,5 @@ struct display_timings;
int of_get_display_timing(struct device_node *np, const char *name,
struct display_timing *dt);
struct display_timings *of_get_display_timings(struct device_node *np);
-int of_display_timings_exist(struct device_node *np);
#endif
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
REGRESSION from 3.8.0 to 3.8.1: Mirroring display works only with 1024x768 (4:3) whereas my laptop has 1366x768 (16:9) & external monitor 1920x1080 (16:9)
I have a laptop with an internal 1366x768 (16:9) display and I have connected and external 1920x1080 (16:9) monitor via HDMI. By default the display gets mirrored with only 1024x768 (4:3) because this is the highest common resolution of the two reported by xrandr. I can switch to a large desktop formed by the two screens with the System Settings application with each screen using its native resolution. I have observed it with kernel 3.10.x and 3.11.x and with further investigation I found out that this is a kernel regression from 3.8.0 to 3.8.1. I can mirror with a higher resolution running the commands: xrandr --addmode HDMI1 1366x768 xrandr --output HDMI1 --mode 1366x768 xrandr --output HDMI1 --mode 1366x768 --same-as LVDS1 This is rather awkward when using a projector. The problem also persists when connecting the external screen to the Mini DisplayPort (with adapter) instead of to the HDMI. The output of "xrandr --prop" with both screens connected in large-desktop-over-both-screens mode (no mirroring): Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 32767 x 32767 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm EDID: 000030e47a03 00160103801c10780adce5975a559227 1d50540001010101010101010101 010101010101241d56d4500016303020 2500159c101b 00fe004c 4720446973706c61790a202000fe 004c503132355748322d534c54310025 BACKLIGHT: 1054 (0x041e) range: (0,1054) Backlight: 1054 (0x041e) range: (0,1054) scaling mode: Full aspect supported: None Full Center Full aspect 1366x768 59.8*+ 1360x768 59.8 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 287mm EDID: 000015c3692001010101 2d14010380331d78eaee95a3544c9926 0f5054a1080081808140b30081c00101 010101010101023a801871382d40582c 4500fe1f111e00ff00353732 32393131300a2020202000fc0045 563233570a202020202000fd 003b3d1f440f000a2020202020200153 02031b41468102031112042309070783 0167030c001300881e8c0ad08a20 e02d10103e9600040300188c0ad0 8a20e02d10103e9600100900188c 0ad090204031200c405500040300 188c0ad090204031200c405500100900 18011d007251d01e206e28550010 09001e5c Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 720x576 50.0 720x480 59.9 640x480 60.0 59.9 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on HDMI2 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on DP2 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on Original bug report to Ubuntu - https://bugs.launchpad.net/bugs/1167301 Testing of older kernels I have tried several mainline kernels from 3.8.1 to 3.11: 3.11.0-rc3, 3.11.0, and also 3.10.0, 3.9.0, 3.8.1. They all show the problem. Mainline kernel 3.8.0 is the newest where the problem does not occur. Bisect result on upstream kernel Then I have done a bisect based on git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git finding that the following patch is the culprit: till@till-twist:~/kernel/linux-stable$ git bisect good 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 is the first bad commit commit 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 Author: Paulo Zanoni Date: Fri Feb 15 13:36:27 2013 -0200 drm: don't add inferred modes for monitors that don't support them commit 196e077dc165a307efbd9e7569f81bbdbcf18f65 upstream. If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher Reviewed-by: Adam Jackson Signed-off-by: Paulo Zanoni Signed-off-by: Dave Airlie Signed-off-b
Re: Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Wed, Sep 25, 2013 at 09:56:52AM +0200, Daniel Vetter wrote: > On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote: > > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin > > wrote: > > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: > > >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: > > >> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] > > >> > > > >> > Hi, > > >> > > > >> > saw your posting in [1]... can you try the patches below? > > >> > Not sure if they apply. > > >> > Did you try v3.11-rc6(+)... or drm-intel-nightly? > > >> > > > >> > Regards, > > >> > - Sedat - > > >> > > > >> > [1] > > >> > http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html > > >> > > >> Same thing observed with v3.11-rc7. > > > > > > I still see this with 3.11. > > > Following this message, my VGA monitor goes blank and > > > shows an error suggesting a wrong resolution or frequency are set. > > > Anyone? > > > > Daniel, Jesse? > > > > still ongoing I think. > > Yeah, I've dismissed it since the original issue in this thread is > resolved. But it's something else. > > Note to bug reporters: Please don't me-too, but start a new thread/report > - almost every gfx bug is different, even if it superficially looks the > same. > > Michael, can you please boot with drm.debug=0xe, reproduce the problem and > then attach the complete dmesg? Please make sure dmesg contains everything > since boot-up, if not please increase the dmesg buffer size with > log_buf_len=4M. > > Also please test the latest drm-intel-fixes release to check that we > haven't just forgotten to send the patch to stable (there's at least one > flags mismatch fix already in-flight to 3.11 stable kernels). > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch Will do. Holidays starting now so expect some reports next week. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 Video driver: i915 FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 acpi_backlight=video works. Jörg 2013/9/24 Igor Gnatenko > On Tue, 2013-09-24 at 17:47 +0800, Aaron Lu wrote: > > v3: > > 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; > > 2 Remove unnecessary function acpi_video_unregister introduced in > > patch 2/3 as pointed out by Jani Nikula. > > > > v2: > > v1 has the subject of "Rework ACPI video driver" and is posted here: > > http://lkml.org/lkml/2013/9/9/74 > > Since the objective is really to fix Win8 backlight issues, I changed > > the subject in this version, sorry about that. > > > > This patchset has three patches, the first introduced a new API named > > backlight_device_registered in backlight layer that can be used for > > backlight interface provider module to check if a specific type backlight > > interface has been registered, see changelog for patch 1/3 for details. > > Then patch 2/3 does the cleanup to sepeate the backlight control and > > event delivery functionality in the ACPI video module and patch 3/3 > > solves some Win8 backlight control problems by avoiding register ACPI > > video's backlight interface if: > > 1 Kernel cmdline option acpi_backlight=video is not given; > > 2 This is a Win8 system; > > 3 Native backlight control interface exists. > > > > Technically, patch 2/3 is not required to fix the issue here. So if you > > think it is not necessary, I can remove it from the series. > > > > Aaron Lu (4): > > backlight: introduce backlight_device_registered > > ACPI / video: seperate backlight control and event interface > > ACPI / video: Do not register backlight if win8 and native interface > > exists > > thinkpad-acpi: fix handle locate for video and query of _BCL > > > > drivers/acpi/internal.h | 5 +- > > drivers/acpi/video.c | 442 > --- > > drivers/acpi/video_detect.c | 14 +- > > drivers/platform/x86/thinkpad_acpi.c | 31 ++- > > drivers/video/backlight/backlight.c | 31 +++ > > include/acpi/video.h | 2 + > > include/linux/backlight.h| 4 + > > 7 files changed, 324 insertions(+), 205 deletions(-) > > > > Excellent! I've tested this patch-set on ThinkPad X230 and backlight > issue is exhausted. > > Thanks. > > -- > Igor Gnatenko > Fedora release 20 (Heisenbug) > Linux 3.11.1-300.fc20.x86_64 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: > Backlight can't be modified with this patch set - neither with function > keys nor > with the gui. It is a step backward to v3.11-rc1 Thanks for the test. Please check /sys/class/backlight, is there only one link file intel_backlight? If so, please cd inside and try modify the brightness file using echo with some values in the range of 0 - max_brightness, does the backlight level change when you echo a new value? I guess it doesn't, or you wouldn't notice problem. If indeed so, perhaps file a bug at http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani and Daniel can help fix your problem. Thanks, Aaron > > Video driver: i915 > FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 > > acpi_backlight=video works. > > Jörg > > > 2013/9/24 Igor Gnatenko > > > On Tue, 2013-09-24 at 17:47 +0800, Aaron Lu wrote: > > > v3: > > > 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; > > > 2 Remove unnecessary function acpi_video_unregister introduced in > > > patch 2/3 as pointed out by Jani Nikula. > > > > > > v2: > > > v1 has the subject of "Rework ACPI video driver" and is posted here: > > > http://lkml.org/lkml/2013/9/9/74 > > > Since the objective is really to fix Win8 backlight issues, I changed > > > the subject in this version, sorry about that. > > > > > > This patchset has three patches, the first introduced a new API named > > > backlight_device_registered in backlight layer that can be used for > > > backlight interface provider module to check if a specific type backlight > > > interface has been registered, see changelog for patch 1/3 for details. > > > Then patch 2/3 does the cleanup to sepeate the backlight control and > > > event delivery functionality in the ACPI video module and patch 3/3 > > > solves some Win8 backlight control problems by avoiding register ACPI > > > video's backlight interface if: > > > 1 Kernel cmdline option acpi_backlight=video is not given; > > > 2 This is a Win8 system; > > > 3 Native backlight control interface exists. > > > > > > Technically, patch 2/3 is not required to fix the issue here. So if you > > > think it is not necessary, I can remove it from the series. > > > > > > Aaron Lu (4): > > > backlight: introduce backlight_device_registered > > > ACPI / video: seperate backlight control and event interface > > > ACPI / video: Do not register backlight if win8 and native interface > > > exists > > > thinkpad-acpi: fix handle locate for video and query of _BCL > > > > > > drivers/acpi/internal.h | 5 +- > > > drivers/acpi/video.c | 442 > > --- > > > drivers/acpi/video_detect.c | 14 +- > > > drivers/platform/x86/thinkpad_acpi.c | 31 ++- > > > drivers/video/backlight/backlight.c | 31 +++ > > > include/acpi/video.h | 2 + > > > include/linux/backlight.h| 4 + > > > 7 files changed, 324 insertions(+), 205 deletions(-) > > > > > > > Excellent! I've tested this patch-set on ThinkPad X230 and backlight > > issue is exhausted. > > > > Thanks. > > > > -- > > Igor Gnatenko > > Fedora release 20 (Heisenbug) > > Linux 3.11.1-300.fc20.x86_64 > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] video: of: display_timing: fixes
Hi, Those two independent patches fixes DT display_timings related code. The first patch replaces of_find_node_by_name by of_get_child_by_name. Usage of of_find_node_by_name in such context is incorrect: - we need only direct child, and this function looks for following nodes on implementation internal list regardless of the hierarchy, - there is no warranty that child nodes are after parent nodes in this search order, it happens to be true for DT created from FDT, but it is not true for dynamic DT. The second patch just removes unused/broken function. Regards Andrzej Andrzej Hajda (2): video: of: display_timing: correct display-timings node finding video: of: display_timing: remove broken of_display_timings_exist drivers/video/of_display_timing.c | 26 +++--- include/video/of_display_timing.h | 1 - 2 files changed, 3 insertions(+), 24 deletions(-) -- 1.8.1.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On Wed, 25 Sep 2013 06:32:10 +0200 Mario Kleiner wrote: > I assume if a spin_lock_irqsave doesn't really disable interrupts on a > RT kernel with normal spinlocks then local_irq_disable won't really > disable interrupts either? > That is incorrect. On PREEMPT_RT, you are right about spin_lock_irqsave() not disabling interrupts, but local_irq_disable() does indeed disable interrupts. Open coded local_irq_disable() usually ends up being a bug as it does nothing to synchronize interrupts from other CPUs. But most of those bugs have been removed, and there are some very legit reasons for using local_irq_disable(). PREEMPT_RT honors those. The reason PREEMPT_RT does not disable interrupts for spin_lock_irqsave(), is because that's usually used for when a interrupt uses the same spinlock. You need the irqsave() part in order to prevent a deadlock, if the code that has the spinlock gets preempted by the interrupt and that interrupt tries to grab the same lock. Because PREEMPT_RT runs interrupts as threads, we don't have that issue, because if the interrupt preempts the holder of the lock and it tries to grab the same lock, it will just block like any other thread trying to grab that lock. That is, spinlocks turn into mutexes on PREEMPT_RT. -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: sleeping function called from invalid context on 3.10.10-rt7
Sorry for the late reply, I was at Linux Plumbers, and had a bunch of stuff to catch up on when I returned. On Sat, 21 Sep 2013 00:07:36 +0200 Mario Kleiner wrote: > Steven, would it then be acceptable to convert that "faster" lock into a > raw_spinlock_t or is this unacceptable? If so, the preempt_disable() > could stay, right? If a spinlock is tight (not held for more than 2us on todays processors), and has little contention, than I would be fine with converting it to raw. And if that's the only lock held you could do the preempt_disable() call. In fact, if you want, you can leave the preempt_disable() out of mainline, and send a patch to us that uses "preempt_disable_rt()" and add a comment to it. In the -rt patch, preempt_disable_rt() is a nop when PREEMPT_RT is not set, and is preempt_disable() when it is. -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On Wed, 25 Sep 2013 10:49:36 +0300 Ville Syrjälä wrote: > The preempt_disable/enable is not needed. The spinlock serves the same > purpose already. As stated, that was only for the -rt patch, as spin_lock_irqsave does not disable preemption nor does it even disable interrupts. But I agree, the added preempt_disable() should be sent to us to keep in the -rt patch itself. We really appreciate that you are thinking about us :-) But something like this will just confuse the mainline folks. Having a "preempt_disable_rt()" would make a lot more sense (which exists in the -rt patch). > > As far as ktime_get(), I've used it from spinlocked/irq disabled sections > and so far haven't seen it do bad things. But would be nice to get some > official statement to that effect. It's just a read seqlock. It may do a few loops to get the correct time, but it's fine to have in a preempt/irq disabled section. -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> But given the new situation, your proposal is great! If we push the
> clock readouts into the get_scanoutpos routine, we can make this robust
> without causing grief for the rt people and without the need for a new
> separate lock for display regs in intel-kms.
>
> E.g., for intel-kms:
>
> i915_get_crtc_scanoutpos(..., ktime_t *stime, ktime_t *etime)
> {
>...
>spin_lock_irqsave(...uncore.lock);
>preempt_disable();
>*stime = ktime_get();
>position = __raw_i915_read32(dev_priv, PIPEDSL(pipe));
>*etime = ktime_get();
>preempt_enable();
>spin_unlock_irqrestore(...uncore.lock)
>...
> }
>
> With your patchset to reduce the amount of register reads needed in that
> function, and given that forcewake handling isn't needed for these
> registers, this should make it robust again and wouldn't need new locks.
>
> Unless ktime_get is also a bad thing to do in a preempt disabled section?
ktime_get() works fine in preempt_disable sections, although it may add
some latencies, but you shouldn't need to worry about it.
I like this solution the best too, but if it does go in, I would ask to
send us the patch for adding the preempt_disable() and we can add the
preempt_disable_rt() to it. Why make mainline have a little more
overhead?
-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
2013/9/25 Jani Nikula : > On Wed, 25 Sep 2013, Aaron Lu wrote: >> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: >>> Backlight can't be modified with this patch set - neither with >>> function keys nor with the gui. It is a step backward to v3.11-rc1 > > So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? In v3.11-rc1 it didn't work. Since a later rc (I don't remember exactly which) it did work. In v3.12-rc1/2 it does work. In v3.12-rc2 + Aaron's patch set it again doesn't work. > >> Thanks for the test. >> >> Please check /sys/class/backlight, is there only one link file >> intel_backlight? > > Indeed, are there others? fujitsu-laptop perhaps? If yes, try > CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. > > Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? There is only one intel_backlight link. Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y > Embarrassingly there was a bug in i915 fixed just recently where the > backlight device wasn't registered for > CONFIG_BACKLIGHT_CLASS_DEVICE=m... > >> If so, please cd inside and try modify the brightness file using echo >> with some values in the range of 0 - max_brightness, does the >> backlight level change when you echo a new value? I guess it doesn't, >> or you wouldn't notice problem. If indeed so, perhaps file a bug at >> http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani >> and Daniel can help fix your problem. > > Yup, please check the above, and report back. - echo 0..max_brightness > brightness does not work. >>> >>> Video driver: i915 >>> FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 >>> >>> acpi_backlight=video works. Jörg ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix up usage of SHRINK_STOP
On Wed, Sep 25, 2013 at 02:00:02PM +0200, Daniel Vetter wrote: > In > > commit 81e49f811404f428a9d9a63295a0c267e802fa12 > Author: Glauber Costa > Date: Wed Aug 28 10:18:13 2013 +1000 > > i915: bail out earlier when shrinker cannot acquire mutex > > SHRINK_STOP was added to tell the core shrinker code to bail out and > go to the next shrinker since the i915 shrinker couldn't acquire > required locks. But the SHRINK_STOP return code was added to the > ->count_objects callback and not the ->scan_objects callback as it > should have been, resulting in tons of dmesg noise like > > shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete > nr=-x > > Fix discusssed with Dave Chinner. Acked-by: Dave Chinner Cheers, Dave. -- Dave Chinner da...@fromorbit.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Wed, Sep 25, 2013 at 04:58:39PM -0300, Henrique de Moraes Holschuh wrote: > On Tue, 24 Sep 2013, Aaron Lu wrote: > > locate handle for ACPI video by HID, the problem is, ACPI video node > > doesn't really have HID defined(i.e. no _HID control method is defined > > ACPI video is supposed to attach a virtual HID node (ACPI_VIDEO_HID) to ACPI > video devices so as to keep the non-trivial video device detection logic in > just one place instead of reinventing the wheel in every driver (which is > always a recipe for disaster). > > When did that break? I checked the git log for the commit to use tpacpi_acpi_handle_locate to locate video controller's ACPI handle, it's: commit 122f26726b5e16174bf8a707df14be1d93c49d62 Author: Henrique de Moraes Holschuh Date: Mon Aug 9 23:48:18 2010 -0300 thinkpad-acpi: find ACPI video device by synthetic HID So I checked out that commit and found that it shouldn't work either, since it has the same problem of the current code. The ACPI video controller device is given an id of ACPI_VIDEO_HID, but it's only known to Linux ACPI, not ACPICA, so the function provided by ACPICA acpi_get_devices will not work in this case, as that function will really check the control method of _HID under the handle, which does not exist no matter if Linux ACPI has added an id to its device structure or not. OTOH, the function provided by Linux ACPI acpi_device_hid will see the added id. In a word, the add of the HID will not affect the ASL namespace layout of the device node(thus, no _HID control method will be added to the device node). It seems that this problem has been found previously by: commit ff413195e830541afeae469fc866ecd0319abd7e Author: Alex Hung Date: Tue Apr 24 16:40:52 2012 +0800 thinkpad-acpi: fix issuing duplicated key events for brightness up/down The tp_features.bright_acpimode will not be set correctly for brightness control because ACPI_VIDEO_HID will not be located in ACPI. As a result, a duplicated key event will always be sent. acpi_video_backlight_support() is sufficient to detect standard ACPI brightness control. Signed-off-by: Alex Hung Signed-off-by: Matthew Garrett Thanks, Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
I urgently request your partnership in a transaction.
I urgently request your partnership in a transaction. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm close"
On Tue, Sep 24, 2013 at 01:41:00PM +0900, Inki Dae wrote: > I can't see to hold ->mmap_sem when it calls find_vma() anywhere else. Er... What, in your opinion, would protect the result of find_vma(), if not that? E.g. if another thread does munmap() on that area... vma isn't refcounted; there are only two things that can prevent its freeing - mmap_sem being held and the lack of anybody else seeing the address of mm_struct it belongs to (basically, when we are killing mm_struct off or when we are populating a fresh mm_struct; in the latter case the parent is locked, but the child doesn't need to). Look at page fault handlers - they grab mmap_sem (shared) before looking for vma. And anything modifying the list of vmas (vm_mmap(), etc.) grabs it exclusive... > > to caller) and clones it manually, regardless of whether that vma allows > > to clone itself or not. Quite a few drivers rely on that not happening... > > > > I think that has no any problem because exynos_gem_get_vma() takes a > reference to vma, and also v4l2 side is using same way. I and v4l2 guys > might be missing something what you are concerning. So Could you give us > more comments? vb2_get_vma()/vb2_put_userptr() is also buggy. At the very least, it should refuse to handle ones with VM_DONTCOPY in flags. Again, there are drivers that seriously rely on VM_DONTCOPY being honoured. BTW, what do you expect exynos_gem_get_pages_from_userptr() to do if the area has been unmapped in the meanwhile? Or, for that matter, if that has been followed by mmap() of something with VM_IO on the same range of addresses... ->open() does *NOT* prevent any of that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] deadlock in "drm/exynos: fix wrong pointer access at vm close"
On Wed, Sep 25, 2013 at 01:34:30PM +0900, Inki Dae wrote: > It seems that we can use a new anon file instead of using drm file to > resolve the issue. Could you describe what are you trying to achieve with that ioctl() and what semantics do you want from normal mmap()? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] ACPI / video: Do not register backlight if win8 and native interface exists
On Wed, Sep 25, 2013 at 07:53:13PM +0200, Rafael J. Wysocki wrote: > On Tuesday, September 24, 2013 05:47:31 PM Aaron Lu wrote: > > According to Matthew Garrett, "Windows 8 leaves backlight control up > > to individual graphics drivers rather than making ACPI calls itself. > > There's plenty of evidence to suggest that the Intel driver for > > Windows [8] doesn't use the ACPI interface, including the fact that > > it's broken on a bunch of machines when the OS claims to support > > Windows 8. The simplest thing to do appears to be to disable the > > ACPI backlight interface on these systems". > > > > So for Win8 systems, if there is native backlight control interface > > registered by GPU driver, ACPI video will not register its own. For > > users who prefer to keep ACPI video's backlight interface, the existing > > kernel cmdline option acpi_backlight=video can be used. > > I think the idea is to use the aggressive default for now and we can switch > the > default back to the current behavior before the merge window in case there are > too many problems with it? Yes I think so. Thanks, Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: "ring test failed" on PA-RISC Linux
Let's go futher.
25.09.2013, 22:58, "Alex Ivanov" :
> 25.09.2013, 21:28, "Konrad Rzeszutek Wilk" :
>> I took a look at the arch/parisc/kernel/pci-dma.c and I see that
>> is mostly a flat platform. That is bus addresses == physical addresses.
>> Unless it is an pclx or pclx2 CPU type (huh?) - if its it that
>> then any calls to dma_alloc_coherent will map memory out of a pool.
>> In essence it will look like a SWIOTLB bounce buffer.
> arch/parisc/kernel/pci-dma.c:
> ** PARISC 1.1 Dynamic DMA mapping support.
> ** This implementation is for PA-RISC platforms that do not support
> ** I/O TLBs (aka DMA address translation hardware).
>
> That's very old. PA-RISC 2.0 came into the game circa 1996.
> PA-RISC 1.1 is 32-bit only and i even not sure whether these machines
> had PCI bus.
>
> Only old boxes (PA7200 CPU and lower) cannot use dma_alloc_coherent()
> (and forced to do syncs iirc). That's not our case.
> And PA-RISC configs have 'Discontiguous Memory' choosen.
>> But interestingly enough there is a lot of 'flush_kernel_dcache_range'
>> call for every DMA operation.
>> And I think the you need to do
>> dma_sync_for_cpu call in the radeon_test_writeback for it to
>> use the flush_kernel_dcache_range.
I was correct regarding syncs.
In our case (SBA IOMMU) dma_sync* calls are no-ops:
sba_iommu.c:
static struct hppa_dma_ops sba_ops = {
...
.dma_sync_single_for_cpu = NULL,
.dma_sync_single_for_device = NULL,
.dma_sync_sg_for_cpu = NULL,
.dma_sync_sg_for_device = NULL,
}
dma-mapping.h:
dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction direction)
{
if(hppa_dma_ops->dma_sync_single_for_cpu)
flush_kernel_dcache_range((unsigned long)vaddr, size);
}
So i'll skip doing the flush_kernel_dcache_range().
>> I don't know what the
>> flush_kernel_dcache_range does thought so I could be wrong.
> D-cache is a CPU cache (if they meant it).
> Seems to be L1-level. There is an I-cache at same level.
>> You are missing a translation here (you were comparing the virtual address
>> to the bus address). I was thinking something along this:
> Yes, this confused me. I've translated your suggestion literally :\
>> unsigned int pfn = page_to_pfn(ttm->pages[i]);
>> dma_addr_t bus = gtt->ttm.dma_address[i];
>> void *va_bus, *va, *va_pfn;
>>
>> if ((pfn << PAGE_SHIFT) != bus)
>> printk("Bus 0x%lx != PFN 0x%lx, bus, pfn <<
>> PAGE_SHIFT); /* OK, that means
>> bus addresses are different */
>>
>> va_bus = bus_to_virt(gtt->ttm.dma_address[i]);
>> va_pfn = __va(pfn << PAGE_SHIFT);
>>
>> if (!virt_addr_valid(va_bus))
>> printk("va_bus (0x%lx) not good!\n", va_bus);
>> if (!virt_addr_valid(va_pfn))
>> printk("va_pfn (0x%lx) not good!\n", va_pfn);
>>
>> /* We got VA for both bus -> va, and pfn -> va. Should be
>> the
>> same if bus and physical addresses are on the same
>> namespace. */
>> if (va_bus != va_pfn)
>> printk("va bus:%lx != va pfn: %lx\n", va_bus,
>> va_pfn);
>>
>> /* Now that we have bus -> pa -> va (va_bus) try to go
>> va_bus -> bus address.
>> The bus address should be the same */
>> if (gtt->tmm.dma_address[i] != virt_to_bus(va_bus))
>> printk("bus->pa->va:%lx != bus->pa->va->ba:
>> %lx\n", gtt->tmm.dma_address[i],virt_to_bus(va_bus));
Ok, slightly modified:
struct page *page = ttm->pages[i];
unsigned long pfn = page_to_pfn(page);
dma_addr_t bus = gtt->ttm.dma_address[i];
void *va_bus, *va, *va_pfn;
BUG_ON(!pfn_valid(pfn));
//BUG_ON(!page_mapping(page)); // Leads to a kernel BUG
/* Avoid floodage */
if (i % 100 == 0) {
if ((pfn << PAGE_SHIFT) != bus)
printk("Bus 0x%lx != PFN 0x%lx\n", bus, pfn << PAGE_SHIFT); /*
OK, that means bus addresses are different */
va_bus = bus_to_virt(bus);
va_pfn = __va(pfn << PAGE_SHIFT);
if (!virt_addr_valid(va_bus))
printk("va_bus (0x%lx) not good!\n", va_bus);
if (!virt_addr_valid(va_pfn))
printk("va_pfn (0x%lx) not good!\n", va_pfn);
/* We got VA for both bus -> va, and pfn -> va. Should be the
same if bus and physical addresses are on the same namespace. */
if (va_bus != va_pfn)
printk("va bus: %lx != va pfn: %lx\n", va_bus, va_pfn);
/* Now that we have bus -> pa -> va (va_bus) try to go va_bus -> bus
address.
The bus address should be the same */
if (bus != virt_to_bus(va_bus))
[PULL] drm-intel-next
Hi Dave, Just a few fixes for regressions and other serious stuff. Two fix state tracking mismatches, together with an additional patch that I've submitted to stable (somehow forgotten to tag it) we should have them fixed now (I hope). Cheers, Daniel The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-09-26 for you to fetch changes up to d32270460fee83e22ee9e6b1bfd7b486263eeb1d: drm/i915: Fix up usage of SHRINK_STOP (2013-09-26 00:31:51 +0200) Chris Wilson (1): drm/i915: Use a temporary va_list for two-pass string handling Daniel Vetter (3): drm/i915/tv: clear adjusted_mode.flags drm/i915: preserve pipe A quirk in i9xx_set_pipeconf drm/i915: Fix up usage of SHRINK_STOP Jani Nikula (1): drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER drivers/gpu/drm/i915/i915_gem.c | 8 drivers/gpu/drm/i915/i915_gpu_error.c | 6 -- drivers/gpu/drm/i915/intel_display.c | 4 drivers/gpu/drm/i915/intel_dp.c | 13 - drivers/gpu/drm/i915/intel_tv.c | 8 5 files changed, 32 insertions(+), 7 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Upstreaming the stereo v6 series
On Wed, Sep 25, 2013 at 05:47:48PM +0100, Damien Lespiau wrote: > Hi, > > So this series looks like a good candidate to be merged in one tree. > > Beside the new 3d flags added to the mode structure, the other new API > is the SET_CLIENT_CAP ioctl. It seems that this new ioctl could already > be potentially useful for user space to tell us they want the "primary" > plane explosed as a DRM plane. > > The i915 bits depend on the lastest drm-intel(-next-queued) so it'd be > simpler to merge this series in drm-intel rather than drm-next. Options > are: > > - merge it through drm-intel (yey!) > > - merge it through drm-next once the current drm-intel has been merged > (will probably need a rebase because of the crtc_clock addition) > > - merge the drm patches through drm-next and the drm/i915 ones through > drm-intel, but that'll likely need me to rebase the i915 patches as > well. > > All in all, it'd be much easier to merge it through drm-intel (if people > are happy with the current state of the series, of course). As quickly discussed with Dave on irc I've merged the entire patch pile into drm-intel. Thanks for the patches and review. One thing I've noticed is that using flags to enumerate the 3d modes is a bit error-prone - we've already had tons of fun with the sync flags where two bits each represent one logical bool. I think we should fix this up while we still can like this: diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index bafe612..08caf92 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -58,14 +58,16 @@ #define DRM_MODE_FLAG_PIXMUX (1<<11) #define DRM_MODE_FLAG_DBLCLK (1<<12) #define DRM_MODE_FLAG_CLKDIV2 (1<<13) +#define DRM_MODE_FLAG_3D_NONE (0<<14) #define DRM_MODE_FLAG_3D_FRAME_PACKING (1<<14) -#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (1<<15) -#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (1<<16) -#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (1<<17) -#define DRM_MODE_FLAG_3D_L_DEPTH (1<<18) -#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (1<<19) -#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(1<<20) -#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (1<<21) +#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (2<<14) +#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14) +#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (4<<14) +#define DRM_MODE_FLAG_3D_L_DEPTH (5<<14) +#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (6<<14) +#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(7<<14) +#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14) +#define DRM_MODE_FLAG_3D_MAX (9<<14) /* DPMS flags */ /* bit compatible with the xorg definitions. */ Care to supply this little fixup (plus adjusted _MASK and userspace input checks ofc). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #24 from Paul Bodenbenner --- (In reply to comment #23) > (In reply to comment #22) > > Bad news. On 3.12rc2 those patches don't work anymore. Same problem like at > > starting this crq. HDMI audio seems to be totally disabled... > > In 3.12 you can enable audio on the fly with xrandr. E.g., > > xrandr --output HDMI-0 --set audio auto Perfect, that did the trick. So everything is working like a charm with those both patches. Thanks for your good and fast work! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Thursday 26 September 2013 04:25 PM, Russell King - ARM Linux wrote:
On Thu, Sep 26, 2013 at 04:21:36PM +0530, Archit Taneja wrote:
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King
---
drivers/ata/pata_ixp4xx_cf.c |5 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev);
+ int ret;
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
/* acquire resources and fill host */
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000);
data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ int ret;
+
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
return drm_platform_init(&exynos_drm_driver, pdev);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* set dma mask for device */
- /* NOTE: this is a workaround for the hwmod not initializing properly */
- dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto fail;
Tested with omapdrm on omap4 panda es board.
Just wish to make sure - that's code for:
Tested-by: Archit Taneja
to be added?
Sure :)
Thanks,
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #14 from Bruno Wolff III --- After a bit of learning, I believe I am on my way to bisecting for the problem commit. I can only do 2 tests a day (maybe 3 on weekends) and will probably finish on Monday. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #13 from Andy Furniss --- (In reply to comment #9) > (In reply to comment #1) > > IIRC it was the XBMC people that wanted the ntsc variants in the first place > > as their player defaults to sync to video exactly and would need to resample > > sound at 24Hz because of this (blu-ray are 24/1.001). > > > > Sure? The source material is 24 Hz, and wasn't the whole point of 24p to get > away from NTSC conversions? TV shows might be a different matter though... Well I guess my blu-ray collection of 2 may not be very representitive, but they are both films rather than TV, were bought in the UK with PAL DVDs in the same case and both ffmpeg and mediainfo show them as being 23.976. > > Does it claim CEA compliance? > > > > I would assume so. But it's not really something blingy enough to brag about > on the box. There are specs here: Oh, OK it was just a thought posted before all the other detail about the mode appeared. > > The old mode is the first one listed by xrandr - can't you just avoid the > > ntsc ones rather than needing them to be removed? > > If I can, I don't know how. It is xbmc that's my use case, and it tends to > pick that mode. Besides, we shouldn't have modes listed that don't work > properly. :) Hopefully it can be fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: add a connector property for dither
Allows you to enable dither in the display hardware
when the monitor supports lower a lower bpc than the
current framebuffer format.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 13 +++-
drivers/gpu/drm/radeon/evergreen.c | 11 ++
drivers/gpu/drm/radeon/r600.c | 11 ++
drivers/gpu/drm/radeon/radeon_connectors.c | 33 ++
drivers/gpu/drm/radeon/radeon_display.c| 12 +++
drivers/gpu/drm/radeon/radeon_mode.h | 8
drivers/gpu/drm/radeon/rs600.c | 11 ++
7 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ccd0871..6e3c098 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7427,10 +7427,13 @@ void dce8_program_fmt(struct drm_encoder *encoder)
struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
int bpc = 0;
u32 tmp = 0;
- bool dither = false;
+ enum radeon_connector_dither dither = RADEON_FMT_DITHER_DISABLE;
- if (connector)
+ if (connector) {
+ struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
bpc = radeon_get_monitor_bpc(connector);
+ dither = radeon_connector->dither;
+ }
/* LVDS/eDP FMT is set up by atom */
if (radeon_encoder->devices & ATOM_DEVICE_LCD_SUPPORT)
@@ -7446,7 +7449,7 @@ void dce8_program_fmt(struct drm_encoder *encoder)
switch (bpc) {
case 6:
- if (dither)
+ if (dither == RADEON_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
FMT_SPATIAL_DITHER_EN |
FMT_SPATIAL_DITHER_DEPTH(0));
@@ -7454,7 +7457,7 @@ void dce8_program_fmt(struct drm_encoder *encoder)
tmp |= (FMT_TRUNCATE_EN | FMT_TRUNCATE_DEPTH(0));
break;
case 8:
- if (dither)
+ if (dither == RADEON_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
FMT_RGB_RANDOM_ENABLE |
@@ -7463,7 +7466,7 @@ void dce8_program_fmt(struct drm_encoder *encoder)
tmp |= (FMT_TRUNCATE_EN | FMT_TRUNCATE_DEPTH(1));
break;
case 10:
- if (dither)
+ if (dither == RADEON_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
FMT_RGB_RANDOM_ENABLE |
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index feedfcc..52fa3be 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1202,10 +1202,13 @@ void dce4_program_fmt(struct drm_encoder *encoder)
struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
int bpc = 0;
u32 tmp = 0;
- bool dither = false;
+ enum radeon_connector_dither dither = RADEON_FMT_DITHER_DISABLE;
- if (connector)
+ if (connector) {
+ struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
bpc = radeon_get_monitor_bpc(connector);
+ dither = radeon_connector->dither;
+ }
/* LVDS/eDP FMT is set up by atom */
if (radeon_encoder->devices & ATOM_DEVICE_LCD_SUPPORT)
@@ -1221,7 +1224,7 @@ void dce4_program_fmt(struct drm_encoder *encoder)
switch (bpc) {
case 6:
- if (dither)
+ if (dither == RADEON_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
FMT_SPATIAL_DITHER_EN);
@@ -1229,7 +1232,7 @@ void dce4_program_fmt(struct drm_encoder *encoder)
tmp |= FMT_TRUNCATE_EN;
break;
case 8:
- if (dither)
+ if (dither == RADEON_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
FMT_RGB_RANDOM_ENABLE |
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index bdf4b80..af922e2 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -133,10 +133,13 @@ void dce3_program_fmt(struct drm_encoder *encoder)
struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
int
[Bug 69805] flightgear crashes on r600 (rs880) with llvm backend
https://bugs.freedesktop.org/show_bug.cgi?id=69805 --- Comment #7 from Tom Stellard --- At first glance, this looks to me like a bug I've run into before where the IfConverter merges two ALU clauses and ends up creating one that is too big. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: Add support for programming the FMT blocks
The FMT blocks control how data is sent from the backend
of the display pipe to to monitor. Proper set up of the
FMT blocks are required for 30bpp formats. Additionally,
dithering can be enabled on for better display with 18 and
24bpp displays. The exception is LVDS/eDP which atom
takes care of in the SelectCRTC_Source table. For now
just enable truncation until we test dithering more.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 9 +
drivers/gpu/drm/radeon/cik.c | 61 ++
drivers/gpu/drm/radeon/cikd.h | 33
drivers/gpu/drm/radeon/evergreen.c | 53 ++
drivers/gpu/drm/radeon/evergreend.h| 32
drivers/gpu/drm/radeon/r600.c | 50
drivers/gpu/drm/radeon/r600d.h | 28 ++
drivers/gpu/drm/radeon/radeon_mode.h | 6 +++
drivers/gpu/drm/radeon/rs600.c | 61 ++
9 files changed, 333 insertions(+)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 32923d2..e55d27b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2392,6 +2392,15 @@ static void radeon_atom_encoder_prepare(struct
drm_encoder *encoder)
/* this is needed for the pll/ss setup to work correctly in some cases
*/
atombios_set_encoder_crtc_source(encoder);
+ /* set up the FMT blocks */
+ if (ASIC_IS_DCE8(rdev))
+ dce8_program_fmt(encoder);
+ else if (ASIC_IS_DCE4(rdev))
+ dce4_program_fmt(encoder);
+ else if (ASIC_IS_DCE3(rdev))
+ dce3_program_fmt(encoder);
+ else if (ASIC_IS_AVIVO(rdev))
+ avivo_program_fmt(encoder);
}
static void radeon_atom_encoder_commit(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index d02fd1c..ccd0871 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7418,6 +7418,67 @@ void cik_fini(struct radeon_device *rdev)
rdev->bios = NULL;
}
+void dce8_program_fmt(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder->dev;
+ struct radeon_device *rdev = dev->dev_private;
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
+ struct drm_connector *connector =
radeon_get_connector_for_encoder(encoder);
+ int bpc = 0;
+ u32 tmp = 0;
+ bool dither = false;
+
+ if (connector)
+ bpc = radeon_get_monitor_bpc(connector);
+
+ /* LVDS/eDP FMT is set up by atom */
+ if (radeon_encoder->devices & ATOM_DEVICE_LCD_SUPPORT)
+ return;
+
+ /* not needed for analog */
+ if ((radeon_encoder->encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC1) ||
+ (radeon_encoder->encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2))
+ return;
+
+ if (bpc == 0)
+ return;
+
+ switch (bpc) {
+ case 6:
+ if (dither)
+ /* XXX sort out optimal dither settings */
+ tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
+ FMT_SPATIAL_DITHER_EN |
FMT_SPATIAL_DITHER_DEPTH(0));
+ else
+ tmp |= (FMT_TRUNCATE_EN | FMT_TRUNCATE_DEPTH(0));
+ break;
+ case 8:
+ if (dither)
+ /* XXX sort out optimal dither settings */
+ tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
+ FMT_RGB_RANDOM_ENABLE |
+ FMT_SPATIAL_DITHER_EN |
FMT_SPATIAL_DITHER_DEPTH(1));
+ else
+ tmp |= (FMT_TRUNCATE_EN | FMT_TRUNCATE_DEPTH(1));
+ break;
+ case 10:
+ if (dither)
+ /* XXX sort out optimal dither settings */
+ tmp |= (FMT_FRAME_RANDOM_ENABLE |
FMT_HIGHPASS_RANDOM_ENABLE |
+ FMT_RGB_RANDOM_ENABLE |
+ FMT_SPATIAL_DITHER_EN |
FMT_SPATIAL_DITHER_DEPTH(2));
+ else
+ tmp |= (FMT_TRUNCATE_EN | FMT_TRUNCATE_DEPTH(2));
+ break;
+ default:
+ /* not needed */
+ break;
+ }
+
+ WREG32(FMT_BIT_DEPTH_CONTROL + radeon_crtc->crtc_offset, tmp);
+}
+
/* display watermark setup */
/**
* dce8_line_buffer_adjust - Set up the line buffer
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 203d2a0..74172cc 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -906,6 +906,39 @@
#defi
Re: [PULL] drm-intel-next^Wdrm-intel-fixes
Wrong subject, I need to fix my script ;-) -Daniel On Thu, Sep 26, 2013 at 10:48 AM, Daniel Vetter wrote: > Hi Dave, > > Just a few fixes for regressions and other serious stuff. > > Two fix state tracking mismatches, together with an additional patch that > I've submitted to stable (somehow forgotten to tag it) we should have them > fixed now (I hope). > > Cheers, Daniel > > > The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: > > Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm-intel > tags/drm-intel-fixes-2013-09-26 > > for you to fetch changes up to d32270460fee83e22ee9e6b1bfd7b486263eeb1d: > > drm/i915: Fix up usage of SHRINK_STOP (2013-09-26 00:31:51 +0200) > > > Chris Wilson (1): > drm/i915: Use a temporary va_list for two-pass string handling > > Daniel Vetter (3): > drm/i915/tv: clear adjusted_mode.flags > drm/i915: preserve pipe A quirk in i9xx_set_pipeconf > drm/i915: Fix up usage of SHRINK_STOP > > Jani Nikula (1): > drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER > > drivers/gpu/drm/i915/i915_gem.c | 8 > drivers/gpu/drm/i915/i915_gpu_error.c | 6 -- > drivers/gpu/drm/i915/intel_display.c | 4 > drivers/gpu/drm/i915/intel_dp.c | 13 - > drivers/gpu/drm/i915/intel_tv.c | 8 > 5 files changed, 32 insertions(+), 7 deletions(-) > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers
On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote: > Hi, > > sorry for the lat response, as I've been traveling in the last weeks. > > At Thu, 19 Sep 2013 22:53:02 +0100, > Russell King wrote: > > > > This code sequence is unsafe in modules: > > > > static u64 mask = DMA_BIT_MASK(something); > > ... > > if (!dev->dma_mask) > > dev->dma_mask = &mask; > > > > as if a module is reloaded, the mask will be pointing at the original > > module's mask address, and this can lead to oopses. Moreover, they > > all follow this with: > > > > if (!dev->coherent_dma_mask) > > dev->coherent_dma_mask = mask; > > > > where 'mask' is the same value as the statically defined mask, and this > > bypasses the architecture's check on whether the DMA mask is possible. > > > > Fix these issues by using the new dma_coerce_coherent_and_mask() > > function. > > > > Signed-off-by: Russell King > > Applied with Mark's ack now. Which is a very stupid thing to do because you won't have dma_coerce_coherent_and_mask() in your tree, so all these drivers will fail to build for you. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] video: of: display_timing: remove broken of_display_timings_exist
On 25/09/13 14:51, Andrzej Hajda wrote: > of_display_timings_exist is implemented incorrectly. > It tries to find property instead of node. > The function is not used anyway so the patch removes it. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Kyungmin Park > --- > drivers/video/of_display_timing.c | 20 > include/video/of_display_timing.h | 1 - > 2 files changed, 21 deletions(-) Fix by removal? =). Wouldn't it be better to fix the function? It's not used currently, but the whole display-timings stuff is still quite new. One could use of_get_display_timings() to check for the existence of timings, but that function will print an error if no timings are found. Then again, what would be the case where you want to check if the timings exist... I'd presume that there either has to be timings or there are no timings. So, I don't know. Any else has opinions whether to remove or fix the function? Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Thu, Sep 26, 2013 at 04:21:36PM +0530, Archit Taneja wrote:
> Hi,
>
> On Friday 20 September 2013 04:41 AM, Russell King wrote:
>> The correct way for a driver to specify the coherent DMA mask is
>> not to directly access the field in the struct device, but to use
>> dma_set_coherent_mask(). Only arch and bus code should access this
>> member directly.
>>
>> Convert all direct write accesses to using the correct API.
>>
>> Signed-off-by: Russell King
>> ---
>> drivers/ata/pata_ixp4xx_cf.c |5 -
>> drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
>> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
>> 3 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
>> index 1ec53f8..ddf470c 100644
>> --- a/drivers/ata/pata_ixp4xx_cf.c
>> +++ b/drivers/ata/pata_ixp4xx_cf.c
>> @@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device
>> *pdev)
>> struct ata_host *host;
>> struct ata_port *ap;
>> struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev);
>> +int ret;
>>
>> cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> @@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device
>> *pdev)
>> return -ENOMEM;
>>
>> /* acquire resources and fill host */
>> -pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>> +if (ret)
>> +return ret;
>>
>> data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000);
>> data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000);
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index bb82ef7..81192d0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
>>
>> static int exynos_drm_platform_probe(struct platform_device *pdev)
>> {
>> -pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +int ret;
>> +
>> +ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>> +if (ret)
>> +return ret;
>>
>> return drm_platform_init(&exynos_drm_driver, pdev);
>> }
>> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> index acf6678..701c4c1 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> @@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
>> }
>>
>> /* set dma mask for device */
>> -/* NOTE: this is a workaround for the hwmod not initializing properly */
>> -dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
>> +if (ret)
>> +goto fail;
>
> Tested with omapdrm on omap4 panda es board.
Just wish to make sure - that's code for:
Tested-by: Archit Taneja
to be added?
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: of: display_timing: correct display-timings node finding
On 25/09/13 14:51, Andrzej Hajda wrote: > of_get_display_timing(s) use of_find_node_by_name > to get child node, this is incorrect, of_get_child_by_name > should be used instead. The patch fixes it. > Small typo is also corrected. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Kyungmin Park > --- > drivers/video/of_display_timing.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Thanks, queuing for 3.12 fixes. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King
---
drivers/ata/pata_ixp4xx_cf.c |5 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev);
+ int ret;
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
/* acquire resources and fill host */
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000);
data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ int ret;
+
+ ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
return drm_platform_init(&exynos_drm_driver, pdev);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* set dma mask for device */
- /* NOTE: this is a workaround for the hwmod not initializing properly */
- dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto fail;
Tested with omapdrm on omap4 panda es board.
Thanks,
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Don't limit fb console on 32M cards to 8 bpp
The comment suggests that intention was to limit 16M cards to save memory while code did something a bit different. 32bpp is a lot more useful with today's apps, such as Weston's fbdev backend and 32M cards are probably hardly used in apps where dedicating a bit more to pinned console would matter. Signed-off-by: Lubomir Rintel --- drivers/gpu/drm/radeon/radeon_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 665ced3..cef3bc7 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -344,7 +344,7 @@ int radeon_fbdev_init(struct radeon_device *rdev) int ret; /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) + if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (16*1024*1024)) bpp_sel = 8; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for the rt people and without the need for a new
separate lock for display regs in intel-kms.
E.g., for intel-kms:
i915_get_crtc_scanoutpos(..., ktime_t *stime, ktime_t *etime)
{
...
spin_lock_irqsave(...uncore.lock);
preempt_disable();
*stime = ktime_get();
position = __raw_i915_read32(dev_priv, PIPEDSL(pipe));
*etime = ktime_get();
preempt_enable();
spin_unlock_irqrestore(...uncore.lock)
...
}
With your patchset to reduce the amount of register reads needed in that
function, and given that forcewake handling isn't needed for these
registers, this should make it robust again and wouldn't need new locks.
Unless ktime_get is also a bad thing to do in a preempt disabled section?
ktime_get() works fine in preempt_disable sections, although it may add
some latencies, but you shouldn't need to worry about it.
I like this solution the best too, but if it does go in, I would ask to
send us the patch for adding the preempt_disable() and we can add the
preempt_disable_rt() to it. Why make mainline have a little more
overhead?
-- Steve
Good! I will do that. Thanks for clarifying the irq and constraints on
raw locks in the other thread.
-mario
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69245] Opencl random lockups whilst running tstellar's opencl-examples
https://bugs.freedesktop.org/show_bug.cgi?id=69245 --- Comment #2 from klondike --- Hi Tom, managed to get some time to test and it seems to be as you say. With development version of mesa + libdrm the issue seems to be gone. I'll try test development version of mesa 9.2 branch and if it also fails I'll try to bisect the issue so we can backport the fix to mesa 9.2.1 Thanks for the hint :) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On 25.09.13 09:49, Ville Syrjälä wrote: On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote: On 23.09.13 10:38, Ville Syrjälä wrote: On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote: On 09/17/2013 10:55 PM, Daniel Vetter wrote: On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote: On 09/11/2013 03:31 PM, Peter Hurley wrote: [+cc dri-devel] On 09/11/2013 11:38 AM, Steven Rostedt wrote: On Wed, 11 Sep 2013 11:16:43 -0400 Peter Hurley wrote: The funny part is, there's a comment there that shows that this was done even for "PREEMPT_RT". Unfortunately, the call to "get_scanout_position()" can call functions that use the rt-mutex "sleeping spin locks" and it breaks there. I guess we need to ask the authors of the mainline patch exactly why that preempt_disable() is needed? The drm core associates a timestamp with each vertical blank frame #. Drm drivers can optionally support a 'high resolution' hw timestamp. The vblank frame #/timestamp tuple is user-space visible. The i915 drm driver supports a hw timestamp via this drm helper function which computes the timestamp from the crtc scan position (based on the pixel clock). For mainline, the preempt_disable/_enable() isn't actually necessary because every call tree that leads here already has preemption disabled. For -RT, the maybe i915 register spinlock (uncore.lock) should be raw? No, it should not. Note, any other lock that can be held when it is held would also need to be raw. By that, you mean "any other lock" that might be claimed "would also need to be raw"? Hopefully not "any other lock" already held? And by taking a quick audit of the code, I see this: spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); /* Reset the chip */ /* GEN6_GDRST is not in the gt power well, no need to check * for fifo space for the write or forcewake the chip for * the read */ __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL); /* Spin waiting for the device to ack the reset request */ ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & GEN6_GRDOM_FULL) == 0, 500); That spin is unacceptable in RT with preemption and interrupts disabled. Yep. That would be bad. AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included in the force-wake set, so raw reads of the registers would probably be acceptable (thus obviating the need for claiming the uncore.lock). Except that _ALL_ register access is disabled with the uncore.lock during a gpu reset. Not sure if that's meant to include crtc registers or not, or what other synchronization/serialization issues are being handled/hidden by forcing all register accesses to wait during a gpu reset. Hopefully an i915 expert can weigh in here? Daniel, Can you shed some light on whether the i915+ crtc registers (specifically those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter()) read as part of the vblank counter/timestamp handling need to be prevented during gpu reset? The depency here in the locking is a recent addition: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access It's a (slightly) oversized hammer to work around a hardware issue - we could break it down to register blocks, which can be accessed concurrently, but that tends to be more fragile. But the chip really dies if you access (even just reads) the same block concurrently :( We could try break the spinlock protected section a bit in the reset handler - register access on a hung gpu tends to be ill-defined anyway. The implied wait with preemption and interrupts disabled is causing grief in -RT, but also a 4ms wait inside an irq handler seems like a bad idea. Oops, the magic code in wait_for which is just there to make the imo totally misguided kgdb support work papered over the aweful long wait in atomic context ever since we've added this in commit b6e45f866465f42b53d803b0c574da0fc508a0e9 Author: Keith Packard Date: Fri Jan 6 11:34:04 2012 -0800 drm/i915: Move reset forcewake processing to gen6_do_reset Reverting this change should be enough (code moved obviously a bit). Cheers, Daniel Regards, Peter Hurley What's the real issue here? That the vblank timestamp needs to be an accurate measurement of a realtime event. Sleeping/servicing interrupts while reading the registers necessary to compute the timestamp would be bad too. (edit: which hopefully Mario Kleiner clarified in his reply) My point earlier was three-fold: 1. Don't need the preempt_disable() for mainline: all callers are already holding interrupt-disabling spinlocks. 2. -RT still needs to prevent scheduling there. 3. the problem is i915-specific. [update: the radeon driver should also BUG like the i915 driver but probably should have mmio_idx_lock spinlock as raw] Ok, so register access must
[Bug 68244] screen flickering and no sound with radeon.audio=1 when using hdmi on HD5450
https://bugs.freedesktop.org/show_bug.cgi?id=68244 dagg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from dagg --- ok, the sound issue is resolved, here is the explenation. with Mr. Konig's help, I was able to make the sound work when rerouting the feed to the following card: card 1: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] strangly when I was using the intel card, I streamed it directly to the intel card. it seems to tno be an issue with the alsa drivers so I've posted a question on the alsa mailing list on the matter. so the sound it not dri issue. the flickering is still an issue, I'll try to gather more info and open a new bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: no hdmi sound on hd5450
>>>2013/8/18 stompdagg...@yahoo.com : >>> 2013/8/18 stompdagg...@yahoo.com : >> does the following patch: "[FIX][PATCH] drm/radeon: fix WREG32_OR macro >> setting bits in a register" which you've commited fixes my issue? >Yes, I believe so! Sorry, I forgot to ping you about that. thats ok, I've applied the patch it doesn't seems to work, I'll verify later today when I'll get home. also, does screen flickering is part of this bug? >>> >>>Please create a bug report, and stop using HTML in your e-mail all the time. >>> >>>Provide output of "avivotool regs hdmi" in your bug report. >> >>bug 68244 opened. >> >>I'm trying to figure out how to disable HTML in mails in yahoo, still no >>luck, sorry. > >Rafał, any updates on the mentioned above bug? is there anything I can do to >help? Hello Rafał, with Mr. Konig's help I was able to fix it, it isn't an dri issue but rather an alsa issue. for more info you can enter the but mentioned above and see the explanation I've posted there. thanks for your help. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #4 from Alexandre Demers --- Definitively something about sclk or mclk and the voltages, but I haven't had the time to dig deeper for now. I've added some printk to be sure everything was being maxed as supposed. Could it be a combo between freq and voltage? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #5 from Alex Deucher --- Take a look at ni_apply_state_adjust_rules() to see how the power state is adjusted based on various factors. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69670] KWin crashes when switching to OpenGL 3.1 + Raster
https://bugs.freedesktop.org/show_bug.cgi?id=69670 --- Comment #4 from Michel Dänzer --- As you can see in the kwin stdout output, radeonsi only supports OpenGL 2.1 in Mesa 9.2. I suspect the problem happens when kwin tries to create an OpenGL 3.x context, but I wonder if this is radeonsi specific — does it not happen e.g. if you run kwin with LIBGL_ALWAYS_SOFTWARE=1 ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #6 from Alexandre Demers --- (In reply to comment #5) > Take a look at ni_apply_state_adjust_rules() to see how the power state is > adjusted based on various factors. Ok, but I may have to wait until this weekend or at the beginning of next week to do so, I may not have some spare time until then. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.11-rc4] [HD2400] - radeon.dpm
Hi > As I suspected, on your system all the performance levels are the same: (...) > [8.961704]power level 0sclk: 45000 mclk: 5 vddc: > 950 > [8.961706]power level 1sclk: 45000 mclk: 5 vddc: > 950 > [8.961708]power level 2sclk: 45000 mclk: 5 vddc: > 950 (...) > So there is no dynamic switching supported on your system. I also had this problem and manage to "fix" it (on a HD2600) :) Please be warnned that this is dangerous, requires editing the bios and may brick your card. Also, will not work on recent cards (but a HD2400 should be ok). Also, this is a hack and no one will support you if things go wrong! You need a windows machine, for some steps, but other can use a linux equivalent... but editing the GPU bios i know no alternative to using the windows program. I also don't know is there is any way in linux to load a GPU bios (and avoid the flashing)... we have the firmware, but i think that the firmware is just a subset of the bios. So here is the "HOWTO": Make a usb pendrive bootable to DOS: Get this files: http://files.extremeoverclocking.com/file.php?f=196 http://pt.kioskea.net/download/baixaki-433-hp-usb-disk-storage-format-tool Unzip the windows98 DOS support to a directory and run the HP usb storage app and format the pendrive. Chek the flag "Create a DOS startup disk" and choose the extracted windows98 files. After formating, download and extract the ATI flash to the pen: http://www.techpowerup.com/downloads/1731/ATIFlash_3.79.html Now lets edit the bios. Ddownload this two apps: http://www.techpowerup.com/gpuz/ -> Dump the GPU Bios http://www.techpowerup.com/rbe/ -> ATI/AMD Bios editor use the gpu-z to dump the current bios, backup it up on a pendrive, to revert to the original bios if needed. use the rbe to edit the power levels. be conservative, DO NOT TOUCH the boot power profiles (this way you can always boot the machine), avoid changing the voltage, as it's more dangerous (but it can also save more power). Edit the lower leves to reduce the GPU frequencies and keep the level 2 high. please note that too low or too high frequencies may cause the card to be unstable. DRAM frequencies usually save little power, but may help reducing the heat. For evey change, test it and check if the card is stable, the picture is not corrupted in different resolutions and loads. Again, if something goes wrong, power off the machine and startup again, the boot profile should be the one that always work (don't forget to have a boot entry in grub that disables the dynamic powermanagement, to avoid jumping to a unstable profile). After doing the changes, save the bios and save it to the pendrive. Now shutdown the machine, make sure you have the full charge and have the power connected. If power faills during the flashing of the bios, you may brick the card/laptop. Startup the computer with the pendriver, enter the DOS and run the flash command: atiflash -p 0 .rom where the .rom is the new "tuned" bios. After some seconds and the command line returned, you can reboot and test it. If something fails, flash back the original bios. Test the card, increase the load, let screen/card enter the sleep mode (screensaver/suspend), change resolutions and look at the temperature. If all OK, you can try to tune even more. So this is a possible (and dangerous) solution for this problem, but may help some people. Good luck higuita ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.11-rc4] [HD2400] - radeon.dpm
On Thu, Sep 26, 2013 at 1:49 PM, wrote: > Hi > >> As I suspected, on your system all the performance levels are the same: > (...) >> [8.961704]power level 0sclk: 45000 mclk: 5 vddc: >> 950 >> [8.961706]power level 1sclk: 45000 mclk: 5 vddc: >> 950 >> [8.961708]power level 2sclk: 45000 mclk: 5 vddc: >> 950 > (...) >> So there is no dynamic switching supported on your system. > > I also had this problem and manage to "fix" it (on a HD2600) :) > > > > Please be warnned that this is dangerous, requires editing the bios > and > may brick your card. Also, will not work on recent cards (but a HD2400 should > be ok). > Also, this is a hack and no one will support you if things go wrong! > > > You need a windows machine, for some steps, but other can use a linux > equivalent... but editing the GPU bios i know no alternative to using the > windows program. I also don't know is there is any way in linux to load a GPU > bios (and avoid the flashing)... we have the firmware, but i think that the > firmware is just a subset of the bios. > > > So here is the "HOWTO": > > Make a usb pendrive bootable to DOS: > > Get this files: > http://files.extremeoverclocking.com/file.php?f=196 > http://pt.kioskea.net/download/baixaki-433-hp-usb-disk-storage-format-tool > > > Unzip the windows98 DOS support to a directory and run the HP usb > storage > app and format the pendrive. Chek the flag "Create a DOS startup disk" and > choose > the extracted windows98 files. > > After formating, download and extract the ATI flash to the pen: > > http://www.techpowerup.com/downloads/1731/ATIFlash_3.79.html > > Now lets edit the bios. Ddownload this two apps: > > http://www.techpowerup.com/gpuz/ -> Dump the GPU Bios > http://www.techpowerup.com/rbe/ -> ATI/AMD Bios editor > > use the gpu-z to dump the current bios, backup it up on a pendrive, to > revert to the original bios if needed. > > use the rbe to edit the power levels. be conservative, DO NOT TOUCH > the > boot power profiles (this way you can always boot the machine), avoid changing > the voltage, as it's more dangerous (but it can also save more power). > > Edit the lower leves to reduce the GPU frequencies and keep the level > 2 high. please note that too low or too high frequencies may cause the card > to be unstable. DRAM frequencies usually save little power, but may help > reducing > the heat. For evey change, test it and check if the card is stable, the > picture > is not corrupted in different resolutions and loads. Again, if something goes > wrong, power off the machine and startup again, the boot profile should be the > one that always work (don't forget to have a boot entry in grub that disables > the dynamic powermanagement, to avoid jumping to a unstable profile). > > After doing the changes, save the bios and save it to the pendrive. > > Now shutdown the machine, make sure you have the full charge and have > the power connected. If power faills during the flashing of the bios, you may > brick the card/laptop. > > Startup the computer with the pendriver, enter the DOS and run the > flash command: > > atiflash -p 0 .rom > > where the .rom is the new "tuned" bios. After some seconds and > the command line returned, you can reboot and test it. If something fails, > flash back the original bios. > > Test the card, increase the load, let screen/card enter the sleep > mode (screensaver/suspend), change resolutions and look at the temperature. > If all OK, you can try to tune even more. > > So this is a possible (and dangerous) solution for this problem, but > may help some people. You can edit the power states in the driver as well if you don't want to flash your vbios. However the same caveats apply. It's not recommended that you flash your vbios, or edit your power states. It may break your card, void your warranty, etc. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/51] DMA mask changes
2013/9/19 Russell King - ARM Linux : > This email is only being sent to the mailing lists in question, not to > anyone personally. The list of individuals is far to great to do that. > I'm hoping no mailing lists reject the patches based on the number of > recipients. Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks [PATCH 14/51] DMA-API: net: b43: (...) [PATCH 15/51] DMA-API: net: b43legacy: (...) ;) I believe Joe has some nice script for doing it that way. When fixing some coding style / formatting, he sends only related patches to the given ML. -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] module_reload fixes
From: Paulo Zanoni Hi These patches allow us to run the "module_reload" script from intel-gpu-tools on Haswell. The script basically just removes i915.ko and loads it again. There's a memory corruption fix and also the fix for fd.o #67813. Notice that the first patch fixes the case where we boot eDP+something, while patches 3-5 fix the case where we boot eDP-only. I couldn't find MAINTAINERS entries for vt.c or fbcon.c, but I heard the dri-devel list is a good place for such patches. Please tell me if I missed some mailing list. Cheers, Paulo Paulo Zanoni (5): drm/i915: redisable VGA when we disable the power well drm/i915: destroy connector sysfs files earlier tty/vt: add con_bind and con_unbind functions console/fbcon: implement con_bind and con_unbind drm/i915: put/get the power well at the FB bind/unbind functions drivers/gpu/drm/i915/intel_crt.c | 1 - drivers/gpu/drm/i915/intel_display.c | 7 ++- drivers/gpu/drm/i915/intel_dp.c | 1 - drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_dsi.c | 1 - drivers/gpu/drm/i915/intel_dvo.c | 1 - drivers/gpu/drm/i915/intel_fb.c | 23 +++ drivers/gpu/drm/i915/intel_hdmi.c| 1 - drivers/gpu/drm/i915/intel_lvds.c| 1 - drivers/gpu/drm/i915/intel_pm.c | 6 ++ drivers/gpu/drm/i915/intel_sdvo.c| 7 +-- drivers/gpu/drm/i915/intel_tv.c | 1 - drivers/tty/vt/vt.c | 6 ++ drivers/video/console/fbcon.c| 26 ++ include/linux/console.h | 2 ++ include/linux/fb.h | 4 16 files changed, 80 insertions(+), 10 deletions(-) -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/i915: redisable VGA when we disable the power well
From: Paulo Zanoni
VGA whack-a-mole!
We need VGA to be disabled whenever our driver is working. So even
without reproducible bugs this patch makes sense, but we do have a bug
solved by this patch.
If you boot a Haswell machine with eDP+HDMI, then kill your display
manager and run:
echo 0 > /sys/class/vtconsole/vtcon1/bind
you'll get thousands of "unclaimed register" messages. Notice that
since we have eDP+HDMI, the power well is *enabled* when we run the
command, but if you look at dmesg you'll see that at some point during
the boot we disabled it and then reenabled it. This patch solves this
problem.
I didn't do a deep analysis of the problem, but I guess vgacon gets
seriously confused when it sees that the VGA plane is enabled.
Besides the command above, this problem can also be reproduced by the
"module_reload" test from intel-gpu-tools.
Fixes regression introduced by:
commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni
drm/i915: switch disable_power_well default value to 1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 6 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 665fa8f..065ffed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10232,7 +10232,7 @@ static void intel_init_quirks(struct drm_device *dev)
}
/* Disable the VGA plane that we never use */
-static void i915_disable_vga(struct drm_device *dev)
+void i915_disable_vga(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
u8 sr1;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a17a86a..e63646a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -678,6 +678,7 @@ void
ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config,
int dotclock);
bool intel_crtc_active(struct drm_crtc *crtc);
+void i915_disable_vga(struct drm_device *dev);
void i915_disable_vga_mem(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2ac1c2f..7a8af95 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5329,6 +5329,12 @@ static void __intel_set_power_well(struct drm_device
*dev, bool enable)
if (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) &
HSW_PWR_WELL_STATE_ENABLED), 20))
DRM_ERROR("Timeout enabling power well\n");
+
+ if (I915_READ(i915_vgacntrl_reg(dev)) !=
+ VGA_DISP_DISABLE) {
+ i915_disable_vga(dev);
+ i915_disable_vga_mem(dev);
+ }
}
} else {
if (enable_requested) {
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/i915: destroy connector sysfs files earlier
From: Paulo Zanoni
For some reason, every single time I try to run module_reload
something tries to read the connector sysfs files. This happens
after we destroy the encoders and before we destroy the connectors, so
when the sysfs read triggers the connector detect() function,
intel_conector->encoder points to memory that was already freed.
The bad backtrace is just:
[] dump_stack+0x54/0x74
[] intel_dp_detect+0x1e/0x4b0 [i915]
[] status_show+0x3d/0x80 [drm]
[] dev_attr_show+0x20/0x60
[] ? sysfs_read_file+0x80/0x1b0
[] sysfs_read_file+0xa9/0x1b0
[] vfs_read+0x9e/0x170
[] SyS_read+0x4c/0xa0
[] system_call_fastpath+0x16/0x1b
But if you add tons of memory checking debug options to your Kernel
you'll also see:
- general protection fault:
- BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten
- INFO: Allocated in intel_ddi_init+0x65/0x270 [i915]
- INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915]
Among a bunch of other error messages.
So this commit just destroys the sysfs files before both the encoder
and connectors are freed.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_crt.c | 1 -
drivers/gpu/drm/i915/intel_display.c | 5 +
drivers/gpu/drm/i915/intel_dp.c | 1 -
drivers/gpu/drm/i915/intel_dsi.c | 1 -
drivers/gpu/drm/i915/intel_dvo.c | 1 -
drivers/gpu/drm/i915/intel_hdmi.c| 1 -
drivers/gpu/drm/i915/intel_lvds.c| 1 -
drivers/gpu/drm/i915/intel_sdvo.c| 7 +--
drivers/gpu/drm/i915/intel_tv.c | 1 -
9 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0263629..942b9ac 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -677,7 +677,6 @@ intel_crt_detect(struct drm_connector *connector, bool
force)
static void intel_crt_destroy(struct drm_connector *connector)
{
- drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 065ffed..793061f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10726,6 +10726,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
+ struct drm_connector *connector;
/*
* Interrupts and polling as the first thing to avoid creating havoc.
@@ -10768,6 +10769,10 @@ void intel_modeset_cleanup(struct drm_device *dev)
/* destroy backlight, if any, before the connectors */
intel_panel_destroy_backlight(dev);
+ /* destroy the sysfs files before encoders/connectors */
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head)
+ drm_sysfs_connector_remove(connector);
+
drm_mode_config_cleanup(dev);
intel_cleanup_overlay(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95a3159..7bdbb36 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3139,7 +3139,6 @@ intel_dp_connector_destroy(struct drm_connector
*connector)
if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
intel_panel_fini(&intel_connector->panel);
- drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 674fd49..9a2fdd2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -504,7 +504,6 @@ static void intel_dsi_destroy(struct drm_connector
*connector)
DRM_DEBUG_KMS("\n");
intel_panel_fini(&intel_connector->panel);
- drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 91287d1..1b64145 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -367,7 +367,6 @@ static int intel_dvo_get_modes(struct drm_connector
*connector)
static void intel_dvo_destroy(struct drm_connector *connector)
{
- drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6004f9c..4f4d346 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1181,7 +1181,6 @@ static void intel_hdmi_post_disable(struct intel_encoder
*encoder)
static void intel_hdmi_destroy(struct drm_connector *connector)
{
- drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drive
[PATCH 3/5] tty/vt: add con_bind and con_unbind functions
From: Paulo Zanoni
The consoles who need to do something when unbinding or binding can
optionally implement these functions.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA interface gets completely disabled, so when we unbind fbcon we
need to restore the VGA interface to allow vgacon to work.
Signed-off-by: Paulo Zanoni
---
drivers/tty/vt/vt.c | 6 ++
include/linux/console.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 9a8e8c5..beb5986 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3014,6 +3014,9 @@ static int do_bind_con_driver(const struct consw *csw,
int first, int last,
if (retval)
goto err;
+ if (csw->con_bind)
+ csw->con_bind();
+
if (!(con_driver->flag & CON_DRIVER_FLAG_INIT)) {
csw->con_startup();
con_driver->flag |= CON_DRIVER_FLAG_INIT;
@@ -3152,6 +3155,9 @@ int do_unbind_con_driver(const struct consw *csw, int
first, int last, int deflt
if (!con_is_bound(csw))
goto err;
+ if (csw->con_unbind)
+ csw->con_unbind();
+
first = max(first, con_driver->first);
last = min(last, con_driver->last);
diff --git a/include/linux/console.h b/include/linux/console.h
index 7571a16..5cd2c35 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -65,6 +65,8 @@ struct consw {
* Restore the console to its pre-debug state as closely as possible.
*/
int (*con_debug_leave)(struct vc_data *);
+ void(*con_bind)(void);
+ void(*con_unbind)(void);
};
extern const struct consw *conswitchp;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] console/fbcon: implement con_bind and con_unbind
From: Paulo Zanoni
And create fb_bind and fb_unbind fb_ops that the drivers can
implement.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA interface gets completely disabled, so when we unbind fbcon we
need to restore the VGA interface to allow vgacon to work.
Signed-off-by: Paulo Zanoni
---
drivers/video/console/fbcon.c | 26 ++
include/linux/fb.h| 4
2 files changed, 30 insertions(+)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index cd8a802..68d316a 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3298,6 +3298,30 @@ done:
return ret;
}
+static void fbcon_con_bind(void)
+{
+ struct fb_info *info = NULL;
+
+ info = registered_fb[info_idx];
+ if (!info)
+ return;
+
+ if (info->fbops->fb_bind)
+ info->fbops->fb_bind(info);
+}
+
+static void fbcon_con_unbind(void)
+{
+ struct fb_info *info = NULL;
+
+ info = registered_fb[info_idx];
+ if (!info)
+ return;
+
+ if (info->fbops->fb_unbind)
+ info->fbops->fb_unbind(info);
+}
+
/*
* The console `switch' structure for the frame buffer based console
*/
@@ -3328,6 +3352,8 @@ static const struct consw fb_con = {
.con_resize = fbcon_resize,
.con_debug_enter= fbcon_debug_enter,
.con_debug_leave= fbcon_debug_leave,
+ .con_bind = fbcon_con_bind,
+ .con_unbind = fbcon_con_unbind,
};
static struct notifier_block fbcon_event_notifier = {
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ffac70a..8074bd5 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -304,6 +304,10 @@ struct fb_ops {
/* called at KDB enter and leave time to prepare the console */
int (*fb_debug_enter)(struct fb_info *info);
int (*fb_debug_leave)(struct fb_info *info);
+
+ /* called when binding/unbinding */
+ void (*fb_bind)(struct fb_info *info);
+ void (*fb_unbind)(struct fb_info *info);
};
#ifdef CONFIG_FB_TILEBLITTING
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915: put/get the power well at the FB bind/unbind functions
From: Paulo Zanoni
If we run the following command on Haswell when the power well is
disabled:
echo 0 > /sys/class/vtconsole/vtcon1/bind
then we'll get thousands of consecutive interrupts because something
is trying to touch registers that are on the disabled power well. So
before we unbind the console, we need to enable the power well to make
the VGA interface work correctly. With this, whoever is using it
doesn't trigger interrupts on i915.ko.
Fixes regression introduced by:
commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni
drm/i915: switch disable_power_well default value to 1
Besides the command above, the "module_reload" test from
intel-gpu-tools can also be used to reproduce the bug fixed by this
patch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fb.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e63646a..a643c48 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -113,6 +113,7 @@ struct intel_fbdev {
struct intel_framebuffer ifb;
struct list_head fbdev_list;
struct drm_display_mode *our_mode;
+ bool first_bind_done;
};
struct intel_encoder {
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index d883b77..8c6ed1c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -43,6 +43,27 @@
#include
#include "i915_drv.h"
+static void intel_fb_bind(struct fb_info *info)
+{
+ struct drm_fb_helper *drm_helper = info->par;
+ struct drm_device *dev = drm_helper->dev;
+ struct intel_fbdev *ifbdev =
+ container_of(drm_helper, struct intel_fbdev, helper);
+
+ if (ifbdev->first_bind_done)
+ intel_display_power_put(dev, POWER_DOMAIN_VGA);
+ else
+ ifbdev->first_bind_done = true;
+}
+
+static void intel_fb_unbind(struct fb_info *info)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+
+ intel_display_power_get(dev, POWER_DOMAIN_VGA);
+}
+
static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
@@ -55,6 +76,8 @@ static struct fb_ops intelfb_ops = {
.fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
+ .fb_bind = intel_fb_bind,
+ .fb_unbind = intel_fb_unbind,
};
static int intelfb_create(struct drm_fb_helper *helper,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
On Thursday, September 26, 2013 09:49:03 AM Jörg Otte wrote: > 2013/9/25 Jani Nikula : > > On Wed, 25 Sep 2013, Jörg Otte wrote: > >> 2013/9/25 Jani Nikula : > >>> On Wed, 25 Sep 2013, Aaron Lu wrote: > On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: > > Backlight can't be modified with this patch set - neither with > > function keys nor with the gui. It is a step backward to v3.11-rc1 > >>> > >>> So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? > >> > >> In v3.11-rc1 it didn't work. > >> Since a later rc (I don't remember exactly which) it did work. > >> In v3.12-rc1/2 it does work. > >> In v3.12-rc2 + Aaron's patch set it again doesn't work. > >> > >>> > Thanks for the test. > > Please check /sys/class/backlight, is there only one link file > intel_backlight? > >>> > >>> Indeed, are there others? fujitsu-laptop perhaps? If yes, try > >>> CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. > >>> > >>> Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? > >> > >> There is only one intel_backlight link. > >> Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y > >> > >>> Embarrassingly there was a bug in i915 fixed just recently where the > >>> backlight device wasn't registered for > >>> CONFIG_BACKLIGHT_CLASS_DEVICE=m... > >>> > If so, please cd inside and try modify the brightness file using echo > with some values in the range of 0 - max_brightness, does the > backlight level change when you echo a new value? I guess it doesn't, > or you wouldn't notice problem. If indeed so, perhaps file a bug at > http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani > and Daniel can help fix your problem. > >>> > >>> Yup, please check the above, and report back. > >> > >> - echo 0..max_brightness > brightness does not work. > > > > Thanks for the info. > > > > How about v3.12-rc2 without Aaron's patches? Does intel_backlight also > > not work there? How about the acpi_video0 (which I presume is present) > > sysfs interface? > > > > Without Aaron's patches intel_backlight also does not work. > But acpi_video0 does (and takes precedence I think). So can you please open a bug entry at bugzilla.kernel.org against i915? The fact that ACPI video works for you doesn't mean that intel_backlight shouldn't, I suppose? Rafael ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69076] weston+rs690: triangle flickering
https://bugs.freedesktop.org/show_bug.cgi?id=69076 --- Comment #1 from David "okias" Heidelberger --- now it flickers for even GLX (git does that since 2 days circa) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
> isp->raw_dmamask = DMA_BIT_MASK(32);
> isp->dev->dma_mask = &isp->raw_dmamask;
> isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures check on the DMA mask. It can be replaced
> with dma_coerce_mask_and_coherent(), avoiding the direct initialization
> of this mask.
>
> Signed-off-by: Russell King
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.c |6 +++---
> drivers/media/platform/omap3isp/isp.h |3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
> isp->pdata = pdata;
> isp->ref_count = 0;
>
> - isp->raw_dmamask = DMA_BIT_MASK(32);
> - isp->dev->dma_mask = &isp->raw_dmamask;
> - isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> platform_set_drvdata(pdev, isp);
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -152,7 +152,6 @@ struct isp_xclk {
> * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
> * regions.
> * @mmio_size: Array with ISP register regions size in bytes.
> - * @raw_dmamask: Raw DMA mask
> * @stat_lock: Spinlock for handling statistics
> * @isp_mutex: Mutex for serializing requests to ISP.
> * @crashed: Bitmask of crashed entities (indexed by entity ID)
> @@ -190,8 +189,6 @@ struct isp_device {
> unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
> resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
>
> - u64 raw_dmamask;
> -
> /* ISP Obj */
> spinlock_t stat_lock; /* common lock for statistic drivers */
> struct mutex isp_mutex; /* For handling ref_count field */
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gma500: define do_gma_backlight_set only when used
On Thu, Sep 26, 2013 at 11:46 PM, Vincent Stehlé
wrote:
> Make sure static function do_gma_backlight_set() is only defined when
> CONFIG_BACKLIGHT_CLASS_DEVICE is defined, as it is never called otherwise.
>
> This fixes the following warning:
>
> drivers/gpu/drm/gma500/backlight.c:29:13: warning: ‘do_gma_backlight_set’
> defined but not used [-Wunused-function]
>
> While at it, remove some end of line spaces.
>
> Signed-off-by: Vincent Stehlé
> Cc: David Airlie
> ---
>
> Hi,
>
> This can be seen with mainline or linux-next with e.g. allmodconfig on x86.
>
> Best regards,
>
> V.
>
> drivers/gpu/drm/gma500/backlight.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/backlight.c
> b/drivers/gpu/drm/gma500/backlight.c
> index 143eba3..399731e 100644
> --- a/drivers/gpu/drm/gma500/backlight.c
> +++ b/drivers/gpu/drm/gma500/backlight.c
> @@ -26,13 +26,13 @@
> #include "intel_bios.h"
> #include "power.h"
>
> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> static void do_gma_backlight_set(struct drm_device *dev)
> {
> -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> struct drm_psb_private *dev_priv = dev->dev_private;
> backlight_update_status(dev_priv->backlight_device);
> -#endif
> }
> +#endif
>
> void gma_backlight_enable(struct drm_device *dev)
> {
> @@ -43,7 +43,7 @@ void gma_backlight_enable(struct drm_device *dev)
> dev_priv->backlight_device->props.brightness =
> dev_priv->backlight_level;
> do_gma_backlight_set(dev);
> }
> -#endif
> +#endif
> }
>
> void gma_backlight_disable(struct drm_device *dev)
> @@ -55,7 +55,7 @@ void gma_backlight_disable(struct drm_device *dev)
> dev_priv->backlight_device->props.brightness = 0;
> do_gma_backlight_set(dev);
> }
> -#endif
> +#endif
> }
>
> void gma_backlight_set(struct drm_device *dev, int v)
> @@ -67,7 +67,7 @@ void gma_backlight_set(struct drm_device *dev, int v)
> dev_priv->backlight_device->props.brightness = v;
> do_gma_backlight_set(dev);
> }
> -#endif
> +#endif
> }
>
> int gma_backlight_init(struct drm_device *dev)
> --
> 1.8.4.rc3
Thanks, looks good, I'll apply it to the gma500-fixes branch.
Acked-by: Patrik Jakobsson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.12 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #19 from Shawn Starr --- Currently testing with: radeon.dpm=0 radeon.dynclks=1 No crashes so far after two days of dynclks, but I am not ready to say the gpu resets are DPM related only still -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 16 September 2013 18:10, Inki Dae wrote:
> CCing devicetree,
>
>> -Original Message-
>> From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
>> Sent: Tuesday, September 10, 2013 5:28 PM
>> To: Sean Paul
>> Cc: Inki Dae; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
>> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
>> Shirish S
>> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
>> driver
>>
>> On 6 September 2013 19:21, Sean Paul wrote:
>> > On Thu, Sep 5, 2013 at 11:37 PM, Rahul Sharma
>> wrote:
>> >> On 5 September 2013 19:20, Inki Dae wrote:
>> >>>
>> >>>
>> -Original Message-
>> From: Sean Paul [mailto:seanp...@chromium.org]
>> Sent: Thursday, September 05, 2013 10:20 PM
>> To: Inki Dae
>> Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel;
>> kgene.kim;
>> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil
> joshi;
>> Shirish S
>> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
>> hdmiphy
>> driver
>>
>> On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae
> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-
>> samsung-
>> soc-
>> >> ow...@vger.kernel.org] On Behalf Of Rahul Sharma
>> >> Sent: Thursday, September 05, 2013 3:04 PM
>> >> To: Inki Dae
>> >> Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel;
>> kgene.kim;
>> >> sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil
>> joshi;
>> >> Shirish S
>> >> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
>> hdmiphy
>> >> driver
>> >>
>> >> On 5 September 2013 10:52, Inki Dae wrote:
>> >> >> >> >> >> +static struct hdmiphy_config hdmiphy_4210_configs[] =
>> {
>> >> >> >> >> >> + {
>> >> >> >> >> >> + .pixel_clock = 2700,
>> >> >> >> >> >> + .conf = {
>> >> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10,
> 0x1C,
>> > 0x30,
>> >> >> > 0x40,
>> >> >> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF,
> 0xF2,
>> > 0x54,
>> >> >> > 0x87,
>> >> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00,
> 0x08,
>> > 0x10,
>> >> >> > 0xE0,
>> >> >> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00,
> 0x00,
>> > 0x00,
>> >> >> > 0x00,
>> >> >> >> >> >> + },
>> >> >> >> >> >> + },
>> >> >> >> >> >> + {
>> >> >> >> >> >> + .pixel_clock = 27027000,
>> >> >> >> >> >> + .conf = {
>> >> >> >> >> >> + 0x01, 0x05, 0x00, 0xD4, 0x10,
> 0x9C,
>> > 0x09,
>> >> >> > 0x64,
>> >> >> >> >> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF,
> 0xF2,
>> > 0x54,
>> >> >> > 0x87,
>> >> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00,
> 0x08,
>> > 0x10,
>> >> >> > 0xE0,
>> >> >> >> >> >> + 0x22, 0x40, 0xE3, 0x26, 0x00,
> 0x00,
>> > 0x00,
>> >> >> > 0x00,
>> >> >> >> >> >> + },
>> >> >> >> >> >> + },
>> >> >> >> >> >> + {
>> >> >> >> >> >> + .pixel_clock = 74176000,
>> >> >> >> >> >> + .conf = {
>> >> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10,
> 0x9C,
>> > 0xef,
>> >> >> > 0x5B,
>> >> >> >> >> >> + 0x6D, 0x10, 0x01, 0x51, 0xef,
> 0xF3,
>> > 0x54,
>> >> >> > 0xb9,
>> >> >> >> >> >> + 0x84, 0x00, 0x30, 0x38, 0x00,
> 0x08,
>> > 0x10,
>> >> >> > 0xE0,
>> >> >> >> >> >> + 0x22, 0x40, 0xa5, 0x26, 0x01,
> 0x00,
>> > 0x00,
>> >> >> > 0x00,
>> >> >> >> >> >> + },
>> >> >> >> >> >> + },
>> >> >> >> >> >> + {
>> >> >> >> >> >> + .pixel_clock = 7425,
>> >> >> >> >> >> + .conf = {
>> >> >> >> >> >> + 0x01, 0x05, 0x00, 0xd8, 0x10,
> 0x9c,
>> > 0xf8,
>> >> >> > 0x40,
>> >> >> >> >> >> + 0x6a, 0x10, 0x01, 0x51, 0xff,
> 0xf1,
>> > 0x54,
>> >> >> > 0xba,
>> >> >> >> >> >> + 0x84, 0x00, 0x10, 0x38, 0x00,
> 0x08,
>> > 0x10,
>> >> >> > 0xe0,
>> >> >> >> >> >> + 0x22, 0x40, 0xa4, 0x26, 0x01,
> 0x00,
>> > 0x00,
>> >> >> > 0x00,
>> >> >> >> >> >> + },
>> >> >> >> >> >> + },
>> >> >> >> >> >> + {
>> >> >> >> >> >> + .pixel_clock = 14850,
>> >> >> >> >> >> + .conf = {
>> >> >> >> >> >> + 0x01, 0x05, 0x00, 0xD8, 0x10,
> 0x9C,
>> > 0xf8,
>> >>>
