Re: -next queue and EDID stuff
On Thu, Aug 30, 2012 at 12:23:43AM -0500, Ian Pilcher wrote: > On 08/29/2012 04:38 PM, Adam Jackson wrote: > > So to me, that says that drivers need to ask _both_ whether the monitor > > supports audio and whether it's HDMI before sending HDMI-specific audio > > signalling. > > OK, so the burden is on the individual drivers. > > In terms of moving forward with the rest of the EDID quirk stuff, are > you OK with either of these options: > > * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP. It won't > work "out of the box" with the Intel driver until that driver is > fixed to not send audio InfoFrames to non-HDMI displays (but anyone > who has the combination will be able to add their own quirk to make > it work). > > * Leave both flags, because both are accurate. The display is confused > by any InfoFrames (audio or AVI), and it is reporting non-existent > audio capabilities. The fact that the combination of the two flags > makes the display work with Intel GPUs is a happy/sad/neutral > accident, and the driver's behavior is still considered broken. > > (Essentially, this would mean just editing the comments to reflect the > above reasoning.) > > If needed, I can easily create a new patch for either option. Just let > me know. I've decided that simply fixing the intel driver is easier. Patch on it's way, please test. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/hdmi: only enable audio if there's a hdmi sink
Some monitors totally don't like to receive infoframes, and naturally don't claim to support hdmi. But for some odd reason they've added a CEA block to their edid, which automatically gives you basic audio. Still, we may not send out hdmi infoframes to them, hence check whether the sink is indeed hdmi capable. Also kill a stale comment while at it. References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg26765.html Cc: Adam Jackson Cc: Ian Pilcher Cc: sta...@vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_hdmi.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e4c37bb..7d35367 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -735,7 +735,11 @@ intel_hdmi_detect(struct drm_connector *connector, bool force) if (intel_hdmi->force_audio != HDMI_AUDIO_OFF_DVI) intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid); - intel_hdmi->has_audio = drm_detect_monitor_audio(edid); + + /* We are only allowed to send audio and audio related +* infoframes if it's an hdmi monitor. */ + intel_hdmi->has_audio = intel_hdmi->has_hdmi_sink && + drm_detect_monitor_audio(edid); } connector->display_info.raw_edid = NULL; kfree(edid); @@ -755,10 +759,6 @@ static int intel_hdmi_get_modes(struct drm_connector *connector) struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector); struct drm_i915_private *dev_priv = connector->dev->dev_private; - /* We should parse the EDID data and find out if it's an HDMI sink so -* we can send audio to it. -*/ - return intel_ddc_get_modes(connector, intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus)); @@ -783,7 +783,9 @@ intel_hdmi_detect_audio(struct drm_connector *connector) kfree(edid); } - return has_audio; + /* We are only allowed to send audio and audio related +* infoframes if it's an hdmi monitor. */ + return intel_hdmi->has_hdmi_sink && has_audio; } static int -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54230] r600-llvm-compiler completely broken at CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=54230 --- Comment #4 from Thomas Rohloff 2012-08-30 08:54:22 UTC --- As the video is to big for an attachment here's a link: https://vimeo.com/48479243 It shows Minecraft in-game. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch
https://bugzilla.kernel.org/show_bug.cgi?id=40622 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #14 from Alex Deucher 2011-08-08 16:28:15 --- No worries, it can get confusing. Unfortunately, I'm not that familiar with how each desktop environment handles hotkeys. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 42412] nouveau regression in 3.1-rc4
https://bugzilla.kernel.org/show_bug.cgi?id=42412 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk --- Comment #1 from Alan 2012-08-30 09:51:05 --- Is this still present in 3.4/3.5 ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 Alan changed: What|Removed |Added Status|NEW |NEEDINFO CC||a...@lxorguk.ukuu.org.uk --- Comment #10 from Alan 2012-08-30 10:48:35 --- Is this problem still seen ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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
Re: drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()
On Thu, 30 Aug 2012, Sascha Hauer wrote: > On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote: > > > > a pedantic observation, you can do with it what you wish (i'm not a > > list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629): > > > > #if !defined(__arm__) > > if (io_remap_pfn_range(vma, vma->vm_start, > >(map->offset + offset) >> PAGE_SHIFT, > >vma->vm_end - vma->vm_start, > >vma->vm_page_prot)) > > return -EAGAIN; > > #else > > if (remap_pfn_range(vma, vma->vm_start, > > (map->offset + offset) >> > > PAGE_SHIFT, > > vma->vm_end - vma->vm_start, > > vma->vm_page_prot)) > > return -EAGAIN; > > #endif > > This code goes down to: > > commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6 > Author: Jordan Crouse > Date: Thu May 27 13:40:26 2010 -0600 > > drm: Add __arm defines to DRM > > Add __arm defines to specify behavior specific for > an ARM processor. > > Signed-off-by: Jordan Crouse > Signed-off-by: Dave Airlie > > Even at that time io_remap_pfn_range on arm was defined as: > > > > > #define io_remap_pfn_range(vma,from,pfn,size,prot) \ > > remap_pfn_range(vma, from, pfn, size, prot) > > > > so it's not clear what the preprocessor test is for. admittedly, it > > should work, it just seems unnecessary. and it makes the code more > > confusing than it needs to be, but perhaps i've just misread > > something. > > I agree that this shouldn't be necessary. for simplicity, i can submit a patch that just does a straight call to remap_pfn_range(), unless someone can recognize something really subtle happening here. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6] drm: edid: add support for E-DDC
On Thu, Aug 30, 2012 at 12:34:06PM +0530, Shirish S wrote:
> @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> +
> + /*
> + * Avoid sending the segment addr to not upset non-compliant ddc
> + * monitors.
> + */
Indentation is still wrong. Or is it gettimg mangled by some email server?
> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> +
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> adapter->name);
> break;
> }
> - } while (ret != 2 && --retries);
> + } while (ret != xfers && --retries);
>
> - return ret == 2 ? 0 : -1;
> + return ret == xfers ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()
On Thu, 30 Aug 2012, Robert P. J. Day wrote: > On Thu, 30 Aug 2012, Sascha Hauer wrote: > > > On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote: > > > > > > a pedantic observation, you can do with it what you wish (i'm not a > > > list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629): > > > > > > #if !defined(__arm__) > > > if (io_remap_pfn_range(vma, vma->vm_start, > > >(map->offset + offset) >> > > > PAGE_SHIFT, > > >vma->vm_end - vma->vm_start, > > >vma->vm_page_prot)) > > > return -EAGAIN; > > > #else > > > if (remap_pfn_range(vma, vma->vm_start, > > > (map->offset + offset) >> > > > PAGE_SHIFT, > > > vma->vm_end - vma->vm_start, > > > vma->vm_page_prot)) > > > return -EAGAIN; > > > #endif > > > > This code goes down to: > > > > commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6 > > Author: Jordan Crouse > > Date: Thu May 27 13:40:26 2010 -0600 > > > > drm: Add __arm defines to DRM > > > > Add __arm defines to specify behavior specific for > > an ARM processor. > > > > Signed-off-by: Jordan Crouse > > Signed-off-by: Dave Airlie > > > > Even at that time io_remap_pfn_range on arm was defined as: > > > > > > > > #define io_remap_pfn_range(vma,from,pfn,size,prot) \ > > > remap_pfn_range(vma, from, pfn, size, prot) > > > > > > so it's not clear what the preprocessor test is for. admittedly, it > > > should work, it just seems unnecessary. and it makes the code more > > > confusing than it needs to be, but perhaps i've just misread > > > something. > > > > I agree that this shouldn't be necessary. > > for simplicity, i can submit a patch that just does a straight call > to remap_pfn_range(), unless someone can recognize something really > subtle happening here. sorry, that should have been a straight call to io_remap_pfn_range() since that is the call invoked for all but ARM. i'll post a patch shortly and someone else can decide whether or not to apply it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM DRIVERS: Remove unnecessary test for ARM.
Since arch/arm/include/asm/pgtable.h contains:
#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)
there is no point treating ARM as a special case in distinguishing
between remap_pfn_range() and io_remap_pfn_range().
Signed-off-by: Robert P. J. Day
---
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..34e6503 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -619,20 +619,11 @@ int drm_mmap_locked(struct file *filp, struct
vm_area_struct *vma)
offset = drm_core_get_reg_ofs(dev);
vma->vm_flags |= VM_IO; /* not in core dump */
vma->vm_page_prot = drm_io_prot(map->type, vma);
-#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
-#else
- if (remap_pfn_range(vma, vma->vm_start,
- (map->offset + offset) >> PAGE_SHIFT,
- vma->vm_end - vma->vm_start,
- vma->vm_page_prot))
- return -EAGAIN;
-#endif
-
DRM_DEBUG(" Type = %d; start = 0x%lx, end = 0x%lx,"
" offset = 0x%llx\n",
map->type,
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: add a tracepoint for gpu frequency changes
We've had and still have too many issues where the gpu turbot doesn't
quite to what it's supposed to do (or what we want it to do).
Adding a tracepoint to track when the desired gpu frequence changes
should help a lot in characterizing and understanding problematic
workloads.
Also, this should be fairly interesting for power tuning (and
especially noticing when the gpu is stuck in high frequencies, as has
happened in the past) and hence for integration into powertop and
similar tools.
Cc: Arjan van de Ven
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_trace.h | 15 +++
drivers/gpu/drm/i915/intel_pm.c |2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 3c4093d..8134421 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -430,6 +430,21 @@ TRACE_EVENT(i915_reg_rw,
(u32)(__entry->val >> 32))
);
+TRACE_EVENT(intel_gpu_freq_change,
+ TP_PROTO(u32 freq),
+ TP_ARGS(freq),
+
+ TP_STRUCT__entry(
+__field(u32, freq)
+),
+
+ TP_fast_assign(
+ __entry->freq = freq;
+ ),
+
+ TP_printk("new_freq=%u", __entry->freq)
+);
+
#endif /* _I915_TRACE_H_ */
/* This part must be outside protection */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ebe3498..194a72f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2343,6 +2343,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
dev_priv->rps.cur_delay = val;
+
+ trace_intel_gpu_freq_change(val * 50);
}
static void gen6_disable_rps(struct drm_device *dev)
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
udl vs udlfb and EDID trouble
Hi all, I've been playing with some DisplayLink adapters, six of them to be precise connected to six identical HDMI monitors. Under kernel 3.5 things did not really work for me apparently because of the udl driver's inability to fetch EDID. Interestingly, logged EDID blocks were different for each of the six monitors which suggests a serious bug somewhere. I've then went to see if I can load my own EDID, because I remember doing it via /sys/class/graphics/fb?/edid before, but that file was not there. (Is it possible to override EDID with the udl driver?) To cut the long story short, I figured out there are two drivers for this hardware. Fedora based 3.5 kernel builds and uses udl, while the older 3.3.2 I played with before builds and uses udlfb. (Why two drivers?) Now going back to 3.3.2 and udlfb, EDID got correctly fetched from all six monitors. Udlfb seems the EDID like this: # hexdump /sys/class/graphics/fb1/edid -C 00 ff ff ff ff ff ff 00 4c 2d 02 09 00 00 00 00 |L-..| 0010 29 15 01 03 80 29 17 78 0a ee 91 a3 54 4c 99 26 |)).xTL.&| 0020 0f 50 54 bd ef 80 71 4f 81 c0 81 00 81 80 95 00 |.PT...qO| 0030 a9 c0 b3 00 01 01 02 3a 80 18 71 38 2d 40 58 2c |...:..q8-@X,| 0040 45 00 a0 5a 00 00 00 1e 66 21 56 aa 51 00 1e 30 |E..Zf!V.Q..0| 0050 46 8f 33 00 a0 5a 00 00 00 1e 00 00 00 fd 00 18 |F.3..Z..| 0060 4b 0f 51 17 00 0a 20 20 20 20 20 20 00 00 00 fc |K.Q... | 0070 00 53 41 4d 53 55 4e 47 0a 20 20 20 20 20 01 f1 |.SAMSUNG. ..| 0080 Below are the corrupt EDID blocks udl under 3.5 was getting. It's a lot of text but someone perhaps will be able to infer something from them. 2012-08-29T16:53:00.048995+01:00 kernel[] info:[ 18.343314] [drm] vendor descriptor length:2e data:2e 5f 01 002c 00 04 04 01 00 03 2012-08-29T16:53:00.048999+01:00 kernel[] err:[ 18.362643] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 199 2012-08-29T16:53:00.049008+01:00 kernel[] err:[ 18.362655] Raw EDID: 2012-08-29T16:53:00.049014+01:00 kernel[] err:[ 18.362662]00 40 39 a0 ff ff ff ff 00 70 41 a0 ff ff ff ff 2012-08-29T16:53:00.049017+01:00 kernel[] err:[ 18.362667]04 00 00 00 00 00 00 00 99 a9 77 61 00 88 ff ff 2012-08-29T16:53:00.049020+01:00 kernel[] err:[ 18.362672]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049024+01:00 kernel[] err:[ 18.362677]b0 a9 77 61 00 88 ff ff 30 95 6c 60 00 88 ff ff 2012-08-29T16:53:00.049101+01:00 kernel[] err:[ 18.362681]7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049105+01:00 kernel[] err:[ 18.362686]40 a6 c3 62 00 88 ff ff e0 16 00 00 00 00 00 00 2012-08-29T16:53:00.049108+01:00 kernel[] err:[ 18.362690]40 00 00 00 00 00 00 00 58 82 02 00 00 00 00 00 2012-08-29T16:53:00.049119+01:00 kernel[] err:[ 18.362695]00 00 00 00 40 00 38 00 07 00 40 00 1c 00 1b 00 2012-08-29T16:53:00.049124+01:00 kernel[] warning:[ 18.362707] usb 2-1.2: DVI-I-1: EDID invalid. 2012-08-29T16:53:00.049126+01:00 kernel[] info:[ 18.364581] fb1: udldrmfb frame buffer device 2012-08-29T16:53:00.049130+01:00 kernel[] info:[ 18.364594] [drm] Initialized udl 0.0.1 20120220 on minor 1 2012-08-29T16:53:00.049133+01:00 kernel[] info:[ 18.365388] [drm] vendor descriptor length:2e data:2e 5f 01 002c 00 04 04 01 00 03 2012-08-29T16:53:00.049136+01:00 kernel[] err:[ 18.421823] Raw EDID: 2012-08-29T16:53:00.049139+01:00 kernel[] err:[ 18.421842]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049142+01:00 kernel[] err:[ 18.421848]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049152+01:00 kernel[] err:[ 18.421853]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049157+01:00 kernel[] err:[ 18.421857]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049160+01:00 kernel[] err:[ 18.421862]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049163+01:00 kernel[] err:[ 18.421866]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049167+01:00 kernel[] err:[ 18.421871]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049170+01:00 kernel[] err:[ 18.421875]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049173+01:00 kernel[] warning:[ 18.421889] usb 2-1.3: DVI-I-2: EDID invalid. 2012-08-29T16:53:00.049182+01:00 kernel[] info:[ 18.424921] fb2: udldrmfb frame buffer device 2012-08-29T16:53:00.049187+01:00 kernel[] info:[ 18.424987] [drm] Initialized udl 0.0.1 20120220 on minor 2 2012-08-29T16:53:00.049190+01:00 kernel[] info:[ 18.428455] [drm] vendor descriptor length:2e data:2e 5f 01 002c 00 04 04 01 00 03 2012-08-29T16:53:00.049193+01:00 kernel[] err:[ 18.491450] Raw EDID: 2012-08-29T16:53:00.049196+01:00 kernel[] err:[ 18.491469]00 00 00 00 00 00 00 00 0
[Bug 54230] r600-llvm-compiler completely broken at CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=54230 Tom Stellard changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|git Component|DRM/Radeon |Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 54230] r600-llvm-compiler completely broken at CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=54230 --- Comment #5 from Tom Stellard 2012-08-30 13:13:28 UTC --- The llvm backend hasn't been tested much on Cayman, so probably some of the Cayman specific features aren't working correctly. Could you set the environment variable R600_DUMP_SHADERS=1 and then post the debug output from compiz and minecraft? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42182] Screen brightness is still set to MINIMUM and am unable to change it
https://bugzilla.kernel.org/show_bug.cgi?id=42182 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|x86-64 |Video(DRI - non Intel) AssignedTo|platform_x86_64@kernel-bugs |drivers_video-dri@kernel-bu |.osdl.org |gs.osdl.org Product|Platform Specific/Hardware |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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
Re: [PATCH] drm/radeon: fix dig encoder selection on DCE61
On Thu, Aug 30, 2012 at 2:27 AM, Michel Dänzer wrote:
> On Mit, 2012-08-29 at 20:02 -0400, alexdeuc...@gmail.com wrote:
>> From: Alex Deucher
>>
>> Was using the DCE41 code which was wrong. Fixes
>> blank displays on a number of Trinity systems.
>>
>> Signed-off-by: Alex Deucher
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/gpu/drm/radeon/atombios_encoders.c | 31
>> +++
>> 1 files changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index 4a7f95e..6e8803a 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1769,13 +1769,34 @@ static int radeon_atom_pick_dig_encoder(struct
>> drm_encoder *encoder)
>> struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
>> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> struct drm_encoder *test_encoder;
>> - struct radeon_encoder_atom_dig *dig;
>> + struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>> uint32_t dig_enc_in_use = 0;
>>
>> - /* DCE4/5 */
>> - if (ASIC_IS_DCE4(rdev)) {
>> - dig = radeon_encoder->enc_priv;
>> - if (ASIC_IS_DCE41(rdev)) {
>> + if (ASIC_IS_DCE6(rdev)) {
>> + /* DCE6 */
>> + switch (radeon_encoder->encoder_id) {
>> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
>> + if (dig->linkb)
>> + return 1;
>> + else
>> + return 0;
>> + break;
>> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>> + if (dig->linkb)
>> + return 3;
>> + else
>> + return 2;
>> + break;
>> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
>> + if (dig->linkb)
>> + return 5;
>> + else
>> + return 4;
>> + break;
>> + }
>> + } else if (ASIC_IS_DCE4(rdev)) {
>> + /* DCE4/5 */
>> + if (ASIC_IS_DCE41(rdev) && !ASIC_IS_DCE61(rdev)) {
>
> The !ASIC_IS_DCE61(rdev) seems redundant here. Either way though,
>
whoops, yes, it is. I was considering whether to add a !DCE61 check
or a new DCE6 section and decided the latter was cleaner, but never
removed the other check. Oh well. I'll clean it up later. Thanks!
> Reviewed-by: Michel Dänzer
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes
On Thu, 30 Aug 2012 13:26:48 +0200, Daniel Vetter wrote: > We've had and still have too many issues where the gpu turbot doesn't > quite to what it's supposed to do (or what we want it to do). > > Adding a tracepoint to track when the desired gpu frequence changes > should help a lot in characterizing and understanding problematic > workloads. > > Also, this should be fairly interesting for power tuning (and > especially noticing when the gpu is stuck in high frequencies, as has > happened in the past) and hence for integration into powertop and > similar tools. > > Cc: Arjan van de Ven > Signed-off-by: Daniel Vetter Like it, even the naming scheme. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42182] Screen brightness is still set to MINIMUM and am unable to change it
https://bugzilla.kernel.org/show_bug.cgi?id=42182 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2012-08-30 13:46:33 --- Is this still an issue with a newer kernel? Make sure your kernel has the acpi backlight controls included. My drm-next queue for 3.7 has support for native backlight control (assuming the OEM uses the on chip backlight controller) if you can't get the acpi backlight controls working. http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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
Re: [PATCH] drm/i915: add a tracepoint for gpu frequency changes
Am Donnerstag, den 30.08.2012, 13:26 +0200 schrieb Daniel Vetter:
> We've had and still have too many issues where the gpu turbot doesn't
s,turbot,turbo,
> quite to what it's supposed to do (or what we want it to do).
s,to,do,
> Adding a tracepoint to track when the desired gpu frequence changes
frequenc*y*
> should help a lot in characterizing and understanding problematic
> workloads.
>
> Also, this should be fairly interesting for power tuning (and
> especially noticing when the gpu is stuck in high frequencies, as has
> happened in the past) and hence for integration into powertop and
> similar tools.
If this can be used from user space already, it would be nice to add
some notes to the commit how this can be done.
> Cc: Arjan van de Ven
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_trace.h | 15 +++
> drivers/gpu/drm/i915/intel_pm.c |2 ++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index 3c4093d..8134421 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -430,6 +430,21 @@ TRACE_EVENT(i915_reg_rw,
> (u32)(__entry->val >> 32))
> );
>
> +TRACE_EVENT(intel_gpu_freq_change,
> + TP_PROTO(u32 freq),
> + TP_ARGS(freq),
> +
> + TP_STRUCT__entry(
> + __field(u32, freq)
> + ),
> +
> + TP_fast_assign(
> +__entry->freq = freq;
> +),
> +
> + TP_printk("new_freq=%u", __entry->freq)
> +);
> +
> #endif /* _I915_TRACE_H_ */
>
> /* This part must be outside protection */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ebe3498..194a72f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2343,6 +2343,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
> I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
>
> dev_priv->rps.cur_delay = val;
> +
> + trace_intel_gpu_freq_change(val * 50);
> }
>
> static void gen6_disable_rps(struct drm_device *dev)
Acked-by: Paul Menzel
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] New dma_buf -> EGLImage EGL extension
Hi All, Over the last few months I've been working on & off with a few people from Linaro on a new EGL extension. The extension allows constructing an EGLImage from a (set of) dma_buf file descriptors, including support for multi-plane YUV. I envisage the primary use-case of this extension to be importing video frames from v4l2 into the EGL/GLES graphics driver to texture from. Originally the intent was to develop this as a Khronos-ratified extension. However, this is a little too platform-specific to be an officially sanctioned Khronos extension. It also goes against the general "EGLStream" direction the EGL working group is going in. As such, the general feeling was to make this an EXT "multi-vendor" extension with no official stamp of approval from Khronos. As this is no-longer intended to be a Khronos extension, I've re-written it to be a lot more Linux & dma_buf specific. It also allows me to circulate the extension more widely (I.e. To those outside Khronos membership). ARM are implementing this extension for at least our Mali-T6xx driver and likely earlier drivers too. I am sending this e-mail to solicit feedback, both from other vendors who might implement this extension (Mesa3D?) and from potential users of the extension. However, any feedback is welcome. Please find the extension text as it currently stands below. There several open issues which I've proposed solutions for, but I'm not really happy with those proposals and hoped others could chip-in with better ideas. There are likely other issues I've not thought about which also need to be added and addressed. Once there's a general consensus or if no-one's interested, I'll update the spec, move it out of Draft status and get it added to the Khronos registry, which includes assigning values for the new symbols. Cheers, Tom -8<- Name EXT_image_dma_buf_import Name Strings EGL_EXT_image_dma_buf_import Contributors Jesse Barker Rob Clark Tom Cooksey Contacts Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) Status DRAFT Version Version 3, August 16, 2012 Number EGL Extension ??? Dependencies EGL 1.2 is required. EGL_KHR_image_base is required. The EGL implementation must be running on a Linux kernel supporting the dma_buf buffer sharing mechanism. This extension is written against the wording of the EGL 1.2 Specification. Overview This extension allows creating an EGLImage from a Linux dma_buf file descriptor or multiple file descriptors in the case of multi-plane YUV images. New Types None New Procedures and Functions None New Tokens Accepted by the parameter of eglCreateImageKHR: EGL_LINUX_DMA_BUF_EXT Accepted as an attribute in the parameter of eglCreateImageKHR: EGL_LINUX_DRM_FOURCC_EXT EGL_DMA_BUF_PLANE0_FD_EXT EGL_DMA_BUF_PLANE0_OFFSET_EXT EGL_DMA_BUF_PLANE0_PITCH_EXT EGL_DMA_BUF_PLANE1_FD_EXT EGL_DMA_BUF_PLANE1_OFFSET_EXT EGL_DMA_BUF_PLANE1_PITCH_EXT EGL_DMA_BUF_PLANE2_FD_EXT EGL_DMA_BUF_PLANE2_OFFSET_EXT EGL_DMA_BUF_PLANE2_PITCH_EXT Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation) Add to section 2.5.1 "EGLImage Specification" (as defined by the EGL_KHR_image_base specification), in the description of eglCreateImageKHR: "Values accepted for are listed in Table aaa, below. +-++ | | Notes | +-++ | EGL_LINUX_DMA_BUF_EXT | Used for EGLImages imported from Linux | | | dma_buf file descriptors | +-++ Table aaa. Legal values for eglCreateImageKHR parameter ... If is EGL_LINUX_DMA_BUF_EXT, must be a valid display, must be EGL_NO_CONTEXT, and must be NULL, cast into the type EGLClientBuffer. The details of the image is specified by the attributes passed into eglCreateImageKHR. Required attributes and their values are as follows: * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl. * EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image. * EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes. * EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats.
Re: udl vs udlfb and EDID trouble
On Thu, Aug 30, 2012 at 8:24 AM, Tvrtko Ursulin wrote: > > Hi all, > > I've been playing with some DisplayLink adapters, six of them to be precise > connected to six identical HDMI monitors. > > Under kernel 3.5 things did not really work for me apparently because of the > udl driver's inability to fetch EDID. Interestingly, logged EDID blocks were > different for each of the six monitors which suggests a serious bug somewhere. > > I've then went to see if I can load my own EDID, because I remember doing it > via /sys/class/graphics/fb?/edid before, but that file was not there. > (Is it possible to override EDID with the udl driver?) > > To cut the long story short, I figured out there are two drivers for this > hardware. Fedora based 3.5 kernel builds and uses udl, while the older 3.3.2 > I played with before builds and uses udlfb. (Why two drivers?) udlfb was the original driver. It's a basic kernel fb driver. udl is a drm driver that Dave wrote based on udlfb. The drm variant will eventually allow you to hotplug displaylink adapters in X and use acceleration provided by another GPU. > > Now going back to 3.3.2 and udlfb, EDID got correctly fetched from all six > monitors. Sounds like a bug in the udl i2c code. Probably worth comparing the relevant udl and uldfb code; it may be a simple fix. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix dig encoder selection on DCE61
2012/8/30 Alex Deucher :
> On Thu, Aug 30, 2012 at 2:27 AM, Michel Dänzer wrote:
>> On Mit, 2012-08-29 at 20:02 -0400, alexdeuc...@gmail.com wrote:
>>> - /* DCE4/5 */
>>> - if (ASIC_IS_DCE4(rdev)) {
>>> - dig = radeon_encoder->enc_priv;
>>> - if (ASIC_IS_DCE41(rdev)) {
>>> + if (ASIC_IS_DCE6(rdev)) {
>>> + /* DCE6 */
Amazing comment ;)
--
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42672] Nouveau. Screen corruption and occasional gpu lockup
https://bugzilla.kernel.org/show_bug.cgi?id=42672 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Kernel Version|3.2.2 |3.3.1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 42708] drm:radeon_cs_ioctl "Failed to schedule IB" error after s2ram and wakeup
https://bugzilla.kernel.org/show_bug.cgi?id=42708 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #35 from Alex Deucher 2012-08-30 14:25:55 UTC --- (In reply to comment #34) > Alex, > Please see the DSDT table from a Macbook Pro booted in EFI mode. Maybe it will > give you some ideas for extracting the VBIOS. Sorry, I'm not really much of an ACPI or Mac expert. I don't see anything relevant. IIRC, the vbios on macs is only available in boot services so it's likely gone by the time the OS is loaded. You'd probably need the boot loader to grab it and store a copy somewhere so the OS can access it when it loads. I'm not sure how Apple does it. Someone more familiar with Macs may have some ideas. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 42787] Video flickers on X1200 / RS690 over DVI
https://bugzilla.kernel.org/show_bug.cgi?id=42787 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 42708] drm:radeon_cs_ioctl "Failed to schedule IB" error after s2ram and wakeup
https://bugzilla.kernel.org/show_bug.cgi?id=42708 Dizintegrator changed: What|Removed |Added Status|NEW |RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #1 from Dizintegrator 2012-08-30 14:43:05 --- Not reproduceable anymore on kernels 3.4 - 3.5. Closed. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 46711] New: vmwgfx does not work in qemu/kvm
https://bugzilla.kernel.org/show_bug.cgi?id=46711 URL: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1 037606 Summary: vmwgfx does not work in qemu/kvm Product: Drivers Version: 2.5 Kernel Version: 3.6-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: hramr...@gmail.com Regression: No vmwgfx fails in kvm (running something like kvm -m 2048 -vga vmware -hda ubuntu.img): [ 29.856068] [drm] Initialized drm 1.1.0 20060810 [ 29.905192] [drm] Capabilities: [ 29.905196] [drm] Rect copy. [ 29.905197] [drm] Cursor. [ 29.905198] [drm] Cursor bypass. [ 29.905198] [drm] Cursor bypass 2. [ 29.905200] [drm] VRAM at 0xfd00 size is 16384 kiB [ 29.905201] [drm] MMIO at 0xfe00 size is 64 kiB [ 29.905203] [drm] global init. [ 29.907091] [TTM] Zone kernel: Available graphics memory: 1025792 kiB [ 29.907093] [TTM] Initializing pool allocator [ 29.907097] [TTM] Initializing DMA pool allocator [ 29.907432] [drm:vmw_driver_load] *ERROR* Hardware has no pitchlock [ 29.907475] [TTM] Finalizing pool allocator [ 29.907478] [TTM] Finalizing DMA pool allocator [ 29.907494] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 29.907676] vmwgfx: probe of :00:02.0 failed with error -38 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 42795] Unable to boot with the radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=42795 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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
Re: [PATCH] drm/i915/hdmi: only enable audio if there's a hdmi sink
On 8/30/12 3:44 AM, Daniel Vetter wrote: Some monitors totally don't like to receive infoframes, and naturally don't claim to support hdmi. But for some odd reason they've added a CEA block to their edid, which automatically gives you basic audio. Still, we may not send out hdmi infoframes to them, hence check whether the sink is indeed hdmi capable. Also kill a stale comment while at it. Does an incomplete version of what it says on the box, you need to hit the HDMI code in intel_sdvo.c too. At which point, should do the obvious bool drm_monitor_has_hdmi_audio() in drm_edid.c. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)
https://bugzilla.kernel.org/show_bug.cgi?id=36072 aceman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|OBSOLETE| --- Comment #8 from aceman 2012-08-30 15:32:57 --- Yes, still happens randomly, on kernel 3.5.3, X.org 1.12, ati driver 6.99.99, Mesa git (9.0): Aug 29 23:46:50 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Aug 29 23:47:16 coolbox last message repeated 646 times Aug 29 23:48:07 coolbox last message repeated 554 times Aug 29 23:50:15 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Aug 29 23:50:41 coolbox last message repeated 6 times Aug 29 23:50:41 coolbox kernel: vmap allocation for size 178966528 failed: use vmalloc= to increase size. Aug 29 23:50:41 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Aug 29 23:50:49 coolbox last message repeated 131 times Aug 29 23:50:58 coolbox kernel: [ cut here ] Aug 29 23:50:58 coolbox kernel: kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:1167! Aug 29 23:50:58 coolbox kernel: invalid opcode: [#1] SMP Aug 29 23:50:58 coolbox kernel: Modules linked in: usb_storage autofs4 nf_conntrack_ftp xt_tcpudp xt_owner xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_LOG iptable_filter ip _tables x_tables asus_atk0110 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss cx88_blackbird cx2341x cx8802 tuner_simple tuner_types tda9887 tda8290 tea5767 tuner cx8800 cx88xx r c_core tveeprom v4l2_common videodev videobuf_dma_sg videobuf_core btcx_risc k10temp forcedeth snd_hda_codec_via snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc i2c_nforce2 ext4 mbcac he jbd2 crc16 usbhid powernow_k8 mperf ohci_hcd ehci_hcd usbcore usb_common fuse [last unloaded: microcode] Aug 29 23:50:58 coolbox kernel: Aug 29 23:50:58 coolbox kernel: Pid: 19931, comm: celestia Not tainted 2.6.45.3 #93 System manufacturer System Product Name/M2N68 Aug 29 23:50:58 coolbox kernel: EIP: 0060:[] EFLAGS: 00010206 CPU: 3 Aug 29 23:50:58 coolbox kernel: EIP is at ttm_bo_check_placement+0x19/0x20 Aug 29 23:50:58 coolbox kernel: EAX: e1f12c2c EBX: 2aac ECX: EDX: 0100 Aug 29 23:50:58 coolbox kernel: ESI: ec13c468 EDI: ebbf71c0 EBP: 00021240 ESP: eaa33d70 Aug 29 23:50:58 coolbox kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Aug 29 23:50:58 coolbox kernel: CR0: 8005003b CR2: aa634000 CR3: 2afab000 CR4: 07f0 Aug 29 23:50:58 coolbox kernel: DR0: DR1: DR2: DR3: Aug 29 23:50:58 coolbox kernel: DR6: 0ff0 DR7: 0400 Aug 29 23:50:58 coolbox kernel: Process celestia (pid: 19931, ti=eaa32000 task=ec27a030 task.ti=eaa32000) Aug 29 23:50:58 coolbox kernel: Stack: Aug 29 23:50:58 coolbox kernel: c030b4c9 01aac000 e1f12c2c e1f12c00 fff4 0001 Aug 29 23:50:58 coolbox kernel: 02aac000 c033bb07 e1f12c14 0001 0001 Aug 29 23:50:58 coolbox kernel: 00021240 c033b850 0001 0001 ec13c468 ec13cd38 Aug 29 23:50:58 coolbox kernel: Call Trace: Aug 29 23:50:58 coolbox kernel: [] ? ttm_bo_init+0x179/0x370 Aug 29 23:50:58 coolbox kernel: [] ? radeon_bo_create+0x197/0x290 Aug 29 23:50:58 coolbox kernel: [] ? radeon_bo_clear_va+0x80/0x80 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_object_create+0x5c/0xf0 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_create_ioctl+0x66/0xf0 Aug 29 23:50:58 coolbox kernel: [] ? _copy_from_user+0x33/0x70 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_pwrite_ioctl+0x30/0x30 Aug 29 23:50:58 coolbox kernel: [] ? drm_ioctl+0x36c/0x3d0 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_pwrite_ioctl+0x30/0x30 Aug 29 23:50:58 coolbox kernel: [] ? free_pgtables+0x8a/0xb0 Aug 29 23:50:58 coolbox kernel: [] ? tlb_finish_mmu+0x9/0x30 Aug 29 23:50:58 coolbox kernel: [] ? drm_copy_field+0x70/0x70 Aug 29 23:50:58 coolbox kernel: [] ? do_vfs_ioctl+0x7a/0x580 Aug 29 23:50:58 coolbox kernel: [] ? do_munmap+0x245/0x300 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? sys_ioctl+0x2e/0x50 Aug 29 23:50:58 coolbox kernel: [] ? syscall_call+0x7/0xb Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: Code: 8b 6c 24 14 83 c4 18 c3 8d 76 00 8d bc 27 00 00 00 00 8b 0a 85 c9 75 09 83 7a 04 00 75 03 31 c0 c3 8b 52 04 29 ca 39 50 44 76 f3 <0f> 0b 90 8d 74 26 00 8b 4a 14 53 6b d9 50 8b 44 18 1c a8 01 75 Aug 29 23:50:58 coolbox kernel: EIP: [] ttm_bo_check_placement+0x19/0x20 SS:ESP 0068:eaa33d70 Aug 29
Re: [PATCH V6] drm: edid: add support for E-DDC
On Thu, Aug 30, 2012 at 3:58 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Thu, Aug 30, 2012 at 12:34:06PM +0530, Shirish S wrote:
> > @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > .buf= buf,
> > }
> > };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > +
> > + /*
> > + * Avoid sending the segment addr to not upset non-compliant ddc
> > + * monitors.
> > + */
>
> Indentation is still wrong. Or is it gettimg mangled by some email server?
>
> I have double checked with checkpatch, i did not get any errors or
warnings,
looks like as you are saying may be true.
Requesting for merge!
> > + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> > +
> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> > adapter->name);
> > break;
> > }
> > - } while (ret != 2 && --retries);
> > + } while (ret != xfers && --retries);
> >
> > - return ret == 2 ? 0 : -1;
> > + return ret == xfers ? 0 : -1;
> > }
> >
> > static bool drm_edid_is_zero(u8 *in_edid, int length)
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 Alan changed: What|Removed |Added Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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
[PATCH] drm/radeon: implement bounds checking on thermal controller lookup
From: Alex Deucher
Don't read past the end of the array if we encounter an unknown
thermal controller.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index e368b30..01b90b4 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2009,7 +2009,8 @@ static int radeon_atombios_parse_power_table_1_3(struct
radeon_device *rdev)
power_info = (union power_info *)(mode_info->atom_context->bios +
data_offset);
/* add the i2c bus for thermal/fan chip */
- if (power_info->info.ucOverdriveThermalController > 0) {
+ if ((power_info->info.ucOverdriveThermalController > 0) &&
+ (power_info->info.ucOverdriveThermalController <
ARRAY_SIZE(thermal_controller_names))) {
DRM_INFO("Possible %s thermal controller at 0x%02x\n",
thermal_controller_names[power_info->info.ucOverdriveThermalController],
power_info->info.ucOverdriveControllerAddress >> 1);
@@ -2213,7 +2214,7 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
(controller->ucType ==
ATOM_PP_THERMALCONTROLLER_EMC2103_WITH_INTERNAL)) {
DRM_INFO("Special thermal controller config\n");
- } else {
+ } else if (controller->ucType <
ARRAY_SIZE(pp_lib_thermal_controller_names)) {
DRM_INFO("Possible %s thermal controller at 0x%02x %s
fan control\n",
pp_lib_thermal_controller_names[controller->ucType],
controller->ucI2cAddress >> 1,
@@ -2228,6 +2229,12 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
strlcpy(info.type, name, sizeof(info.type));
i2c_new_device(&rdev->pm.i2c_bus->adapter,
&info);
}
+ } else {
+ DRM_INFO("Unknown thermal controller type %d at 0x%02x
%s fan control\n",
+controller->ucType,
+controller->ucI2cAddress >> 1,
+(controller->ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
}
}
}
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #36 from Stefan Dösinger 2012-08-30 17:39:59 UTC --- My guess would be that they simply store it in the driver, i.e. similarly to what my hack does. Considering that they have hardware and software under full control I don't see why they want a video bios that's separate from the driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
drm: Adding the option IRQ_ONESHOT to support irq oneshot
From: liu chuansheng Subject: [PATCH] drm: Adding the option IRQ_ONESHOT to support irq oneshot For some platforms, we want the irq is handled as one shot, then even when we use the irq thread, with this option, the new irq will come until the irq thread finished. So we have the requirement for IRQ_ONESHOT. Signed-off-by: liu chuansheng --- drivers/gpu/drm/drm_irq.c |3 +++ include/drm/drmP.h|1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 03f16f3..7a8a581 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -345,6 +345,9 @@ int drm_irq_install(struct drm_device *dev) if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED)) sh_flags = IRQF_SHARED; +if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT)) +sh_flags |= IRQF_ONESHOT; + if (dev->devname) irqname = dev->devname; else diff --git a/include/drm/drmP.h b/include/drm/drmP.h index d6b67bb..dfede31 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...); #define DRIVER_GEM 0x1000 #define DRIVER_MODESET 0x2000 #define DRIVER_PRIME 0x4000 +#define DRIVER_IRQ_ONESHOT 0x8000 #define DRIVER_BUS_PCI 0x1 #define DRIVER_BUS_PLATFORM 0x2 -- 1.7.0.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing
So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider object interface, so that Optimus-based laptops can use our driver to drive the discrete GPU and display on the integrated GPU. The good news is that I've got a proof of concept working. During a review of the current code, we came up with a few concerns: 1. The output source is responsible for allocating the shared memory Right now, the X server calls CreatePixmap on the output source screen and then expects the output sink screen to be able to display from whatever memory the source allocates. Right now, the source has no mechanism for asking the sink what its requirements are for the surface. I'm using our own internal pitch alignment requirements and that seems to be good enough for the Intel device to scan out, but that could be pure luck. Does it make sense to add a mechanism for drivers to negotiate this with each other, or is it sufficient to just define a lowest common denominator format and if your hardware can't deal with that format, you just don't get to share buffers? One of my coworkers brought to my attention the fact that Tegra requires a specific pitch alignment, and cannot accommodate larger pitches. If other SoC designs have similar restrictions, we might need to add a handshake mechanism. 2. There's no fallback mechanism if sharing can't be negotiated If RandR fails to share a pixmap with the output sink screen, the whole modeset fails. This means you'll end up not seeing anything on the screen and you'll probably think your computer locked up. Should there be some sort of software copy fallback to ensure that something at least shows up on the display? 3. How should the memory be allocated? In the prototype I threw together, I'm allocating the shared memory using shm_open and then exporting that as a dma-buf file descriptor using an ioctl I added to the kernel, and then importing that memory back into our driver through dma_buf_attach & dma_buf_map_attachment. Does it make sense for user-space programs to be able to export shmfs files like that? Should that interface go in DRM / GEM / PRIME instead? Something else? I'm pretty unfamiliar with this kernel code so any suggestions would be appreciated. -- Aaron P.S. for those unfamiliar with PRIME: Dave Airlie added new support to the X Resize and Rotate extension version 1.4 to support offloading display and rendering to different drivers. PRIME is the DRM implementation in the kernel, layered on top of DMA-BUF, that implements the actual sharing of buffers between drivers. http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=randrproto-1.4.0#n122 http://airlied.livejournal.com/7.html - update on hotplug server http://airlied.livejournal.com/76078.html - randr 1.5 demo videos --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing
On 08/30/2012 10:31 AM, Aaron Plattner wrote: So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider object interface, so that Optimus-based laptops can use our driver to drive the discrete GPU and display on the integrated GPU. The good news is that I've got a proof of concept working. During a review of the current code, we came up with a few concerns: 1. The output source is responsible for allocating the shared memory Right now, the X server calls CreatePixmap on the output source screen and then expects the output sink screen to be able to display from whatever memory the source allocates. Right now, the source has no mechanism for asking the sink what its requirements are for the surface. I'm using our own internal pitch alignment requirements and that seems to be good enough for the Intel device to scan out, but that could be pure luck. Does it make sense to add a mechanism for drivers to negotiate this with each other, or is it sufficient to just define a lowest common denominator format and if your hardware can't deal with that format, you just don't get to share buffers? One of my coworkers brought to my attention the fact that Tegra requires a specific pitch alignment, and cannot accommodate larger pitches. If other SoC designs have similar restrictions, we might need to add a handshake mechanism. 2. There's no fallback mechanism if sharing can't be negotiated If RandR fails to share a pixmap with the output sink screen, the whole modeset fails. This means you'll end up not seeing anything on the screen and you'll probably think your computer locked up. Should there be some sort of software copy fallback to ensure that something at least shows up on the display? 3. How should the memory be allocated? In the prototype I threw together, I'm allocating the shared memory using shm_open and then exporting that as a dma-buf file descriptor using an ioctl I added to the kernel, and then importing that memory back into our driver through dma_buf_attach & dma_buf_map_attachment. Does it make sense for user-space programs to be able to export shmfs files like that? Should that interface go in DRM / GEM / PRIME instead? Something else? I'm pretty unfamiliar with this kernel code so any suggestions would be appreciated. There's also a #4 that didn't seem relevant to cross-post to linaro-mm-sig: 4. There's no mechanism for double buffering the output sink RandR allocates one pixmap on the output source screen and sets up tracking so the source driver can copy the screen into the shared pixmap. However, the sink driver scans out from the shared pixmap directly. There's no mechanism to prevent tearing on the sink side of the pipeline. It seems like it would be nice if the source could trigger the sink device to flip between front and back buffers when the copy is finished, and get back a fence to indicate when the flip has occurred and the source can start the next copy. -- Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #22 from Alexandre Demers 2012-08-30 21:34:48 UTC --- It seems Marek has more weight than me about lockups related to VM on Cayman(problem first reported as bug 45018). Patch by Marek to disable VM by default for Cayman: http://lists.freedesktop.org/archives/mesa-dev/2012-August/026590.html If you have any news on the subject, feel free to add info in the current bug. To Marek: are you experiencing the same first lockup in the piglit tests as reported in comment 10. I'm sure have seen a previous comment from another dev who was also experiencing lockups on Cayman, but I can't find who that was. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #23 from Alex Deucher 2012-08-30 21:42:20 UTC --- (In reply to comment #22) > It seems Marek has more weight than me about lockups related to VM on > Cayman(problem first reported as bug 45018). Well, we were hoping to get this resolved in time for 9.0, but as it's getting pretty close now, it's probably better to disable it at least for the 9.0 release. The problem is, when it's disabled, there's not much chance of anyone testing it, so it's not likely to ever get properly fixed. Also, SI only supports VM, so we can't disable VM for SI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 Niels Ole Salscheider changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #11 from Niels Ole Salscheider 2012-08-30 22:20:42 --- This issue is fixed in recent kernels. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- 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 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #24 from Alexandre Demers 2012-08-30 22:38:36 UTC --- (In reply to comment #23) > (In reply to comment #22) > > It seems Marek has more weight than me about lockups related to VM on > > Cayman(problem first reported as bug 45018). > > Well, we were hoping to get this resolved in time for 9.0, but as it's getting > pretty close now, it's probably better to disable it at least for the 9.0 > release. The problem is, when it's disabled, there's not much chance of > anyone > testing it, so it's not likely to ever get properly fixed. Also, SI only > supports VM, so we can't disable VM for SI. Meanwhile, since fixes committed for bug 45018 helped me a lot, I'll gladly keep VM activated to test it. After all, my desktop is now usable now, I've been running for 3 days without any lockup, while I was previously only able to run for a couple of hours before restarting. So, if you have any patches you want to test that could help, ask me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm/radeon: implement bounds checking on thermal controller lookup
On Don, 2012-08-30 at 13:32 -0400, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > Don't read past the end of the array if we encounter an unknown > thermal controller. > > Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52256] Trinity (ARUBA) DP link training problems
https://bugs.freedesktop.org/show_bug.cgi?id=52256 --- Comment #8 from Alex Deucher 2012-08-30 00:13:43 UTC --- Should be fixed in my drm-next-3.6 branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.6 there are several patches required. The patches should show up in stable kernels as well once Dave pulls them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52256] Trinity (ARUBA) DP link training problems
https://bugs.freedesktop.org/show_bug.cgi?id=52256 --- Comment #9 from LRN 2012-08-30 01:40:44 UTC --- Pulled your drm-next-3.6 branch, and merged with current linux master. Display now works! There are font rendering problems with X server, but that's another issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #34 from Anonymous Helper 2012-08-30 01:48:07 UTC --- Created attachment 66308 --> https://bugs.freedesktop.org/attachment.cgi?id=66308 DSDT table from Macbook Pro 8,2 (EFI boot) Alex, Please see the DSDT table from a Macbook Pro booted in EFI mode. Maybe it will give you some ideas for extracting the VBIOS. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
-next queue and EDID stuff
On 08/29/2012 04:38 PM, Adam Jackson wrote: > So to me, that says that drivers need to ask _both_ whether the monitor > supports audio and whether it's HDMI before sending HDMI-specific audio > signalling. OK, so the burden is on the individual drivers. In terms of moving forward with the rest of the EDID quirk stuff, are you OK with either of these options: * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP. It won't work "out of the box" with the Intel driver until that driver is fixed to not send audio InfoFrames to non-HDMI displays (but anyone who has the combination will be able to add their own quirk to make it work). * Leave both flags, because both are accurate. The display is confused by any InfoFrames (audio or AVI), and it is reporting non-existent audio capabilities. The fact that the combination of the two flags makes the display work with Intel GPUs is a happy/sad/neutral accident, and the driver's behavior is still considered broken. (Essentially, this would mean just editing the comments to reflect the above reasoning.) If needed, I can easily create a new patch for either option. Just let me know. Thanks! -- Ian Pilcher arequipeno at gmail.com "If you're going to shift my paradigm ... at least buy me dinner first."
[git pull] drm fixes
Hi Linus, a bunch of scattered fixes ati/intel/nouveau, couple of core ones, nothing too shocking or different. Dave. The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0: Linux 3.6-rc3 (2012-08-22 13:29:06 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b: drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S (2012-08-30 14:14:12 +1000) Alex Deucher (5): drm/radeon: don't disable plls that are in use by other crtcs drm/radeon/atom: rework DIG modesetting on DCE3+ drm/radeon/atom: powergating fixes for DCE6 drm/radeon: rework panel mode setup drm/radeon: fix dig encoder selection on DCE61 Ben Skeggs (1): drm/nvc0/copy: check PUNITS to determine which copy engines are disabled Calvin Walton (1): i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard Chris Wilson (1): drm/i915: Use the correct size of the GTT for placing the per-process entries Christian K?nig (1): drm/radeon: fix double free in radeon_gpu_reset Dave Airlie (3): Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Forest Bond (1): gma500: Consider CRTC initially active. Jakob Bornecrantz (1): drm: Check for invalid cursor flags Jerome Glisse (1): drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740 Marek Ol??k (3): drm/radeon: fix reading CB_COLORn_MASK from the CS drm/radeon: initialize tracked CS state drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700 Paul Menzel (1): drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S Vijay Purushothaman (1): drm/i915: fix color order for BGR formats on IVB Ville Syrj?l? (1): drm: Initialize object type when using DRM_MODE() macro Xu, Anhua (1): drm/i915: fix wrong order of parameters in port checking functions drivers/gpu/drm/drm_crtc.c |2 +- drivers/gpu/drm/drm_edid.c |3 + drivers/gpu/drm/gma500/psb_intel_display.c |3 + drivers/gpu/drm/i915/i915_gem_gtt.c|2 +- drivers/gpu/drm/i915/intel_display.c | 12 +-- drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_sprite.c|4 +- drivers/gpu/drm/nouveau/nouveau_state.c|6 +- drivers/gpu/drm/radeon/atombios_crtc.c | 36 --- drivers/gpu/drm/radeon/atombios_dp.c | 29 +++--- drivers/gpu/drm/radeon/atombios_encoders.c | 140 +++- drivers/gpu/drm/radeon/r600_cs.c | 30 +- drivers/gpu/drm/radeon/r600d.h |8 ++ drivers/gpu/drm/radeon/radeon_device.c |5 +- drivers/gpu/drm/radeon/radeon_drv.c|3 +- drivers/gpu/drm/radeon/reg_srcs/r600 |1 - include/drm/drm_crtc.h |3 +- include/drm/drm_mode.h |5 +- 18 files changed, 174 insertions(+), 126 deletions(-)
[PATCH V6] drm: edid: add support for E-DDC
From: Shirish S This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Changes from V1: 1. Data type of offset adress updated to unsigned short 2. Updated the buf feild of msg[0] Changes from V2: Add switch for DDC and E-DDC Changes from V3: Remove switch,and avoid sending of segment data for non E-DDC Changes from V4: Fix review comments about space and comment indentation. Changes from V5: Compacted the code. Based on drm-next branch Shirish S (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 19 --- 1 files changed, 16 insertions(+), 3 deletions(-)
[PATCH V6] drm: edid: add support for E-DDC
From: Shirish S This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Changes from V1: 1. Data type of offset adress updated to unsigned short 2. Updated the buf feild of msg[0] Changes from V2: Add switch for DDC and E-DDC Changes from V3: Remove switch,and avoid sending of segment data for non E-DDC Changes from V4: Fix review comments about space and comment indentation. Changes from V5: Compacted the code. Based on drm-next branch Shirish S (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 19 --- 1 files changed, 16 insertions(+), 3 deletions(-)
[PATCH v6] drm: edid: add support for E-DDC
From: Shirish S
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S
Reviewed-by: Jean Delvare
Reviewed-by: Daniel Vetter
Reviewed-by: Ville Syrjala
---
drivers/gpu/drm/drm_edid.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..7f62de5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned
char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &segment,
+ }, {
.addr = DDC_ADDR,
.flags = 0,
.len= 1,
@@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
.buf= buf,
}
};
- ret = i2c_transfer(adapter, msgs, 2);
+
+ /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+ ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
- } while (ret != 2 && --retries);
+ } while (ret != xfers && --retries);
- return ret == 2 ? 0 : -1;
+ return ret == xfers ? 0 : -1;
}
static bool drm_edid_is_zero(u8 *in_edid, int length)
--
1.7.0.4
[PATCH V6] drm: edid: add support for E-DDC
This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Changes from V1: 1. Data type of offset adress updated to unsigned short 2. Updated the buf feild of msg[0] Changes from V2: Add switch for DDC and E-DDC Changes from V3: Remove switch,and avoid sending of segment data for non E-DDC Changes from V4: Fix review comments about space and comment indentation. Changes from V5: Compacted the code. Based on drm-next branch Shirish S (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 19 --- 1 files changed, 16 insertions(+), 3 deletions(-)
[PATCH V6] drm: edid: add support for E-DDC
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S
Reviewed-by: Jean Delvare
Reviewed-by: Daniel Vetter
Reviewed-by: Ville Syrjala
---
drivers/gpu/drm/drm_edid.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..7f62de5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned
char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &segment,
+ }, {
.addr = DDC_ADDR,
.flags = 0,
.len= 1,
@@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
.buf= buf,
}
};
- ret = i2c_transfer(adapter, msgs, 2);
+
+ /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+ ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
- } while (ret != 2 && --retries);
+ } while (ret != xfers && --retries);
- return ret == 2 ? 0 : -1;
+ return ret == xfers ? 0 : -1;
}
static bool drm_edid_is_zero(u8 *in_edid, int length)
--
1.7.0.4
[PATCH] drm: edid: add support for E-DDC
From: Shirish S
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S
Reviewed-by: Jean Delvare
Reviewed-by: Daniel Vetter
Reviewed-by: Ville Syrjala
---
drivers/gpu/drm/drm_edid.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcc4725..7f62de5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned
char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned char xfers = segment ? 3 : 2;
int ret, retries = 5;
/* The core i2c driver will automatically retry the transfer if the
@@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
do {
struct i2c_msg msgs[] = {
{
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &segment,
+ }, {
.addr = DDC_ADDR,
.flags = 0,
.len= 1,
@@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
.buf= buf,
}
};
- ret = i2c_transfer(adapter, msgs, 2);
+
+ /*
+* Avoid sending the segment addr to not upset non-compliant ddc
+* monitors.
+*/
+ ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
- } while (ret != 2 && --retries);
+ } while (ret != xfers && --retries);
- return ret == 2 ? 0 : -1;
+ return ret == xfers ? 0 : -1;
}
static bool drm_edid_is_zero(u8 *in_edid, int length)
--
1.7.0.4
[PATCH] drm/radeon: fix dig encoder selection on DCE61
On Mit, 2012-08-29 at 20:02 -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Was using the DCE41 code which was wrong. Fixes
> blank displays on a number of Trinity systems.
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c | 31 +++
> 1 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 4a7f95e..6e8803a 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -1769,13 +1769,34 @@ static int radeon_atom_pick_dig_encoder(struct
> drm_encoder *encoder)
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct drm_encoder *test_encoder;
> - struct radeon_encoder_atom_dig *dig;
> + struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
> uint32_t dig_enc_in_use = 0;
>
> - /* DCE4/5 */
> - if (ASIC_IS_DCE4(rdev)) {
> - dig = radeon_encoder->enc_priv;
> - if (ASIC_IS_DCE41(rdev)) {
> + if (ASIC_IS_DCE6(rdev)) {
> + /* DCE6 */
> + switch (radeon_encoder->encoder_id) {
> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
> + if (dig->linkb)
> + return 1;
> + else
> + return 0;
> + break;
> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
> + if (dig->linkb)
> + return 3;
> + else
> + return 2;
> + break;
> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
> + if (dig->linkb)
> + return 5;
> + else
> + return 4;
> + break;
> + }
> + } else if (ASIC_IS_DCE4(rdev)) {
> + /* DCE4/5 */
> + if (ASIC_IS_DCE41(rdev) && !ASIC_IS_DCE61(rdev)) {
The !ASIC_IS_DCE61(rdev) seems redundant here. Either way though,
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()
On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote: > > a pedantic observation, you can do with it what you wish (i'm not a > list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629): > > #if !defined(__arm__) > if (io_remap_pfn_range(vma, vma->vm_start, >(map->offset + offset) >> PAGE_SHIFT, >vma->vm_end - vma->vm_start, >vma->vm_page_prot)) > return -EAGAIN; > #else > if (remap_pfn_range(vma, vma->vm_start, > (map->offset + offset) >> PAGE_SHIFT, > vma->vm_end - vma->vm_start, > vma->vm_page_prot)) > return -EAGAIN; > #endif This code goes down to: commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6 Author: Jordan Crouse Date: Thu May 27 13:40:26 2010 -0600 drm: Add __arm defines to DRM Add __arm defines to specify behavior specific for an ARM processor. Signed-off-by: Jordan Crouse Signed-off-by: Dave Airlie Even at that time io_remap_pfn_range on arm was defined as: > > #define io_remap_pfn_range(vma,from,pfn,size,prot) \ > remap_pfn_range(vma, from, pfn, size, prot) > > so it's not clear what the preprocessor test is for. admittedly, it > should work, it just seems unnecessary. and it makes the code more > confusing than it needs to be, but perhaps i've just misread > something. I agree that this shouldn't be necessary. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
-next queue and EDID stuff
On Thu, Aug 30, 2012 at 12:23:43AM -0500, Ian Pilcher wrote: > On 08/29/2012 04:38 PM, Adam Jackson wrote: > > So to me, that says that drivers need to ask _both_ whether the monitor > > supports audio and whether it's HDMI before sending HDMI-specific audio > > signalling. > > OK, so the burden is on the individual drivers. > > In terms of moving forward with the rest of the EDID quirk stuff, are > you OK with either of these options: > > * Remove EDID_QUIRK_NO_AUDIO from the flags for the LG L246WP. It won't > work "out of the box" with the Intel driver until that driver is > fixed to not send audio InfoFrames to non-HDMI displays (but anyone > who has the combination will be able to add their own quirk to make > it work). > > * Leave both flags, because both are accurate. The display is confused > by any InfoFrames (audio or AVI), and it is reporting non-existent > audio capabilities. The fact that the combination of the two flags > makes the display work with Intel GPUs is a happy/sad/neutral > accident, and the driver's behavior is still considered broken. > > (Essentially, this would mean just editing the comments to reflect the > above reasoning.) > > If needed, I can easily create a new patch for either option. Just let > me know. I've decided that simply fixing the intel driver is easier. Patch on it's way, please test. Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm/i915/hdmi: only enable audio if there's a hdmi sink
Some monitors totally don't like to receive infoframes, and naturally don't claim to support hdmi. But for some odd reason they've added a CEA block to their edid, which automatically gives you basic audio. Still, we may not send out hdmi infoframes to them, hence check whether the sink is indeed hdmi capable. Also kill a stale comment while at it. References: http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg26765.html Cc: Adam Jackson Cc: Ian Pilcher Cc: stable at vger.kernel.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_hdmi.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e4c37bb..7d35367 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -735,7 +735,11 @@ intel_hdmi_detect(struct drm_connector *connector, bool force) if (intel_hdmi->force_audio != HDMI_AUDIO_OFF_DVI) intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid); - intel_hdmi->has_audio = drm_detect_monitor_audio(edid); + + /* We are only allowed to send audio and audio related +* infoframes if it's an hdmi monitor. */ + intel_hdmi->has_audio = intel_hdmi->has_hdmi_sink && + drm_detect_monitor_audio(edid); } connector->display_info.raw_edid = NULL; kfree(edid); @@ -755,10 +759,6 @@ static int intel_hdmi_get_modes(struct drm_connector *connector) struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector); struct drm_i915_private *dev_priv = connector->dev->dev_private; - /* We should parse the EDID data and find out if it's an HDMI sink so -* we can send audio to it. -*/ - return intel_ddc_get_modes(connector, intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus)); @@ -783,7 +783,9 @@ intel_hdmi_detect_audio(struct drm_connector *connector) kfree(edid); } - return has_audio; + /* We are only allowed to send audio and audio related +* infoframes if it's an hdmi monitor. */ + return intel_hdmi->has_hdmi_sink && has_audio; } static int -- 1.7.10.4
[Bug 54230] r600-llvm-compiler completely broken at CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=54230 --- Comment #4 from Thomas Rohloff 2012-08-30 08:54:22 UTC --- As the video is to big for an attachment here's a link: https://vimeo.com/48479243 It shows Minecraft in-game. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 40622] [radeon] - kms wrong resolution mode used after backlight on/off switch
https://bugzilla.kernel.org/show_bug.cgi?id=40622 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #14 from Alex Deucher 2011-08-08 16:28:15 --- No worries, it can get confusing. Unfortunately, I'm not that familiar with how each desktop environment handles hotkeys. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 42412] nouveau regression in 3.1-rc4
https://bugzilla.kernel.org/show_bug.cgi?id=42412 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk --- Comment #1 from Alan 2012-08-30 09:51:05 --- Is this still present in 3.4/3.5 ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 Alan changed: What|Removed |Added Status|NEW |NEEDINFO CC||alan at lxorguk.ukuu.org.uk --- Comment #10 from Alan 2012-08-30 10:48:35 --- Is this problem still seen ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()
On Thu, 30 Aug 2012, Sascha Hauer wrote: > On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote: > > > > a pedantic observation, you can do with it what you wish (i'm not a > > list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629): > > > > #if !defined(__arm__) > > if (io_remap_pfn_range(vma, vma->vm_start, > >(map->offset + offset) >> PAGE_SHIFT, > >vma->vm_end - vma->vm_start, > >vma->vm_page_prot)) > > return -EAGAIN; > > #else > > if (remap_pfn_range(vma, vma->vm_start, > > (map->offset + offset) >> > > PAGE_SHIFT, > > vma->vm_end - vma->vm_start, > > vma->vm_page_prot)) > > return -EAGAIN; > > #endif > > This code goes down to: > > commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6 > Author: Jordan Crouse > Date: Thu May 27 13:40:26 2010 -0600 > > drm: Add __arm defines to DRM > > Add __arm defines to specify behavior specific for > an ARM processor. > > Signed-off-by: Jordan Crouse > Signed-off-by: Dave Airlie > > Even at that time io_remap_pfn_range on arm was defined as: > > > > > #define io_remap_pfn_range(vma,from,pfn,size,prot) \ > > remap_pfn_range(vma, from, pfn, size, prot) > > > > so it's not clear what the preprocessor test is for. admittedly, it > > should work, it just seems unnecessary. and it makes the code more > > confusing than it needs to be, but perhaps i've just misread > > something. > > I agree that this shouldn't be necessary. for simplicity, i can submit a patch that just does a straight call to remap_pfn_range(), unless someone can recognize something really subtle happening here. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH V6] drm: edid: add support for E-DDC
On Thu, Aug 30, 2012 at 12:34:06PM +0530, Shirish S wrote:
> @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> +
> + /*
> + * Avoid sending the segment addr to not upset non-compliant ddc
> + * monitors.
> + */
Indentation is still wrong. Or is it gettimg mangled by some email server?
> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> +
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> adapter->name);
> break;
> }
> - } while (ret != 2 && --retries);
> + } while (ret != xfers && --retries);
>
> - return ret == 2 ? 0 : -1;
> + return ret == xfers ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
--
Ville Syrj?l?
Intel OTC
drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()
On Thu, 30 Aug 2012, Robert P. J. Day wrote: > On Thu, 30 Aug 2012, Sascha Hauer wrote: > > > On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote: > > > > > > a pedantic observation, you can do with it what you wish (i'm not a > > > list subscriber). in drivers/gpu/drm/drm_vm.c, we read (line 629): > > > > > > #if !defined(__arm__) > > > if (io_remap_pfn_range(vma, vma->vm_start, > > >(map->offset + offset) >> > > > PAGE_SHIFT, > > >vma->vm_end - vma->vm_start, > > >vma->vm_page_prot)) > > > return -EAGAIN; > > > #else > > > if (remap_pfn_range(vma, vma->vm_start, > > > (map->offset + offset) >> > > > PAGE_SHIFT, > > > vma->vm_end - vma->vm_start, > > > vma->vm_page_prot)) > > > return -EAGAIN; > > > #endif > > > > This code goes down to: > > > > commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6 > > Author: Jordan Crouse > > Date: Thu May 27 13:40:26 2010 -0600 > > > > drm: Add __arm defines to DRM > > > > Add __arm defines to specify behavior specific for > > an ARM processor. > > > > Signed-off-by: Jordan Crouse > > Signed-off-by: Dave Airlie > > > > Even at that time io_remap_pfn_range on arm was defined as: > > > > > > > > #define io_remap_pfn_range(vma,from,pfn,size,prot) \ > > > remap_pfn_range(vma, from, pfn, size, prot) > > > > > > so it's not clear what the preprocessor test is for. admittedly, it > > > should work, it just seems unnecessary. and it makes the code more > > > confusing than it needs to be, but perhaps i've just misread > > > something. > > > > I agree that this shouldn't be necessary. > > for simplicity, i can submit a patch that just does a straight call > to remap_pfn_range(), unless someone can recognize something really > subtle happening here. sorry, that should have been a straight call to io_remap_pfn_range() since that is the call invoked for all but ARM. i'll post a patch shortly and someone else can decide whether or not to apply it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH] DRM DRIVERS: Remove unnecessary test for ARM.
Since arch/arm/include/asm/pgtable.h contains:
#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)
there is no point treating ARM as a special case in distinguishing
between remap_pfn_range() and io_remap_pfn_range().
Signed-off-by: Robert P. J. Day
---
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..34e6503 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -619,20 +619,11 @@ int drm_mmap_locked(struct file *filp, struct
vm_area_struct *vma)
offset = drm_core_get_reg_ofs(dev);
vma->vm_flags |= VM_IO; /* not in core dump */
vma->vm_page_prot = drm_io_prot(map->type, vma);
-#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
-#else
- if (remap_pfn_range(vma, vma->vm_start,
- (map->offset + offset) >> PAGE_SHIFT,
- vma->vm_end - vma->vm_start,
- vma->vm_page_prot))
- return -EAGAIN;
-#endif
-
DRM_DEBUG(" Type = %d; start = 0x%lx, end = 0x%lx,"
" offset = 0x%llx\n",
map->type,
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH] drm/i915: add a tracepoint for gpu frequency changes
We've had and still have too many issues where the gpu turbot doesn't
quite to what it's supposed to do (or what we want it to do).
Adding a tracepoint to track when the desired gpu frequence changes
should help a lot in characterizing and understanding problematic
workloads.
Also, this should be fairly interesting for power tuning (and
especially noticing when the gpu is stuck in high frequencies, as has
happened in the past) and hence for integration into powertop and
similar tools.
Cc: Arjan van de Ven
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_trace.h | 15 +++
drivers/gpu/drm/i915/intel_pm.c |2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 3c4093d..8134421 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -430,6 +430,21 @@ TRACE_EVENT(i915_reg_rw,
(u32)(__entry->val >> 32))
);
+TRACE_EVENT(intel_gpu_freq_change,
+ TP_PROTO(u32 freq),
+ TP_ARGS(freq),
+
+ TP_STRUCT__entry(
+__field(u32, freq)
+),
+
+ TP_fast_assign(
+ __entry->freq = freq;
+ ),
+
+ TP_printk("new_freq=%u", __entry->freq)
+);
+
#endif /* _I915_TRACE_H_ */
/* This part must be outside protection */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ebe3498..194a72f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2343,6 +2343,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
dev_priv->rps.cur_delay = val;
+
+ trace_intel_gpu_freq_change(val * 50);
}
static void gen6_disable_rps(struct drm_device *dev)
--
1.7.10.4
udl vs udlfb and EDID trouble
Hi all, I've been playing with some DisplayLink adapters, six of them to be precise connected to six identical HDMI monitors. Under kernel 3.5 things did not really work for me apparently because of the udl driver's inability to fetch EDID. Interestingly, logged EDID blocks were different for each of the six monitors which suggests a serious bug somewhere. I've then went to see if I can load my own EDID, because I remember doing it via /sys/class/graphics/fb?/edid before, but that file was not there. (Is it possible to override EDID with the udl driver?) To cut the long story short, I figured out there are two drivers for this hardware. Fedora based 3.5 kernel builds and uses udl, while the older 3.3.2 I played with before builds and uses udlfb. (Why two drivers?) Now going back to 3.3.2 and udlfb, EDID got correctly fetched from all six monitors. Udlfb seems the EDID like this: # hexdump /sys/class/graphics/fb1/edid -C 00 ff ff ff ff ff ff 00 4c 2d 02 09 00 00 00 00 |L-..| 0010 29 15 01 03 80 29 17 78 0a ee 91 a3 54 4c 99 26 |)).xTL.&| 0020 0f 50 54 bd ef 80 71 4f 81 c0 81 00 81 80 95 00 |.PT...qO| 0030 a9 c0 b3 00 01 01 02 3a 80 18 71 38 2d 40 58 2c |...:..q8- at X,| 0040 45 00 a0 5a 00 00 00 1e 66 21 56 aa 51 00 1e 30 |E..Zf!V.Q..0| 0050 46 8f 33 00 a0 5a 00 00 00 1e 00 00 00 fd 00 18 |F.3..Z..| 0060 4b 0f 51 17 00 0a 20 20 20 20 20 20 00 00 00 fc |K.Q... | 0070 00 53 41 4d 53 55 4e 47 0a 20 20 20 20 20 01 f1 |.SAMSUNG. ..| 0080 Below are the corrupt EDID blocks udl under 3.5 was getting. It's a lot of text but someone perhaps will be able to infer something from them. 2012-08-29T16:53:00.048995+01:00 kernel[] info:[ 18.343314] [drm] vendor descriptor length:2e data:2e 5f 01 002c 00 04 04 01 00 03 2012-08-29T16:53:00.048999+01:00 kernel[] err:[ 18.362643] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 199 2012-08-29T16:53:00.049008+01:00 kernel[] err:[ 18.362655] Raw EDID: 2012-08-29T16:53:00.049014+01:00 kernel[] err:[ 18.362662]00 40 39 a0 ff ff ff ff 00 70 41 a0 ff ff ff ff 2012-08-29T16:53:00.049017+01:00 kernel[] err:[ 18.362667]04 00 00 00 00 00 00 00 99 a9 77 61 00 88 ff ff 2012-08-29T16:53:00.049020+01:00 kernel[] err:[ 18.362672]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049024+01:00 kernel[] err:[ 18.362677]b0 a9 77 61 00 88 ff ff 30 95 6c 60 00 88 ff ff 2012-08-29T16:53:00.049101+01:00 kernel[] err:[ 18.362681]7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049105+01:00 kernel[] err:[ 18.362686]40 a6 c3 62 00 88 ff ff e0 16 00 00 00 00 00 00 2012-08-29T16:53:00.049108+01:00 kernel[] err:[ 18.362690]40 00 00 00 00 00 00 00 58 82 02 00 00 00 00 00 2012-08-29T16:53:00.049119+01:00 kernel[] err:[ 18.362695]00 00 00 00 40 00 38 00 07 00 40 00 1c 00 1b 00 2012-08-29T16:53:00.049124+01:00 kernel[] warning:[ 18.362707] usb 2-1.2: DVI-I-1: EDID invalid. 2012-08-29T16:53:00.049126+01:00 kernel[] info:[ 18.364581] fb1: udldrmfb frame buffer device 2012-08-29T16:53:00.049130+01:00 kernel[] info:[ 18.364594] [drm] Initialized udl 0.0.1 20120220 on minor 1 2012-08-29T16:53:00.049133+01:00 kernel[] info:[ 18.365388] [drm] vendor descriptor length:2e data:2e 5f 01 002c 00 04 04 01 00 03 2012-08-29T16:53:00.049136+01:00 kernel[] err:[ 18.421823] Raw EDID: 2012-08-29T16:53:00.049139+01:00 kernel[] err:[ 18.421842]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049142+01:00 kernel[] err:[ 18.421848]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049152+01:00 kernel[] err:[ 18.421853]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049157+01:00 kernel[] err:[ 18.421857]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049160+01:00 kernel[] err:[ 18.421862]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049163+01:00 kernel[] err:[ 18.421866]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049167+01:00 kernel[] err:[ 18.421871]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049170+01:00 kernel[] err:[ 18.421875]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2012-08-29T16:53:00.049173+01:00 kernel[] warning:[ 18.421889] usb 2-1.3: DVI-I-2: EDID invalid. 2012-08-29T16:53:00.049182+01:00 kernel[] info:[ 18.424921] fb2: udldrmfb frame buffer device 2012-08-29T16:53:00.049187+01:00 kernel[] info:[ 18.424987] [drm] Initialized udl 0.0.1 20120220 on minor 2 2012-08-29T16:53:00.049190+01:00 kernel[] info:[ 18.428455] [drm] vendor descriptor length:2e data:2e 5f 01 002c 00 04 04 01 00 03 2012-08-29T16:53:00.049193+01:00 kernel[] err:[ 18.491450] Raw EDID: 2012-08-29T16:53:00.049196+01:00 kernel[] err:[ 18.491469]00 00 00 00 00 00 00
[Bug 54230] r600-llvm-compiler completely broken at CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=54230 Tom Stellard changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|git Component|DRM/Radeon |Drivers/Gallium/r600 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 54230] r600-llvm-compiler completely broken at CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=54230 --- Comment #5 from Tom Stellard 2012-08-30 13:13:28 UTC --- The llvm backend hasn't been tested much on Cayman, so probably some of the Cayman specific features aren't working correctly. Could you set the environment variable R600_DUMP_SHADERS=1 and then post the debug output from compiz and minecraft? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42182] Screen brightness is still set to MINIMUM and am unable to change it
https://bugzilla.kernel.org/show_bug.cgi?id=42182 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|x86-64 |Video(DRI - non Intel) AssignedTo|platform_x86_64 at kernel-bugs |drivers_video-dri at kernel-bu |.osdl.org |gs.osdl.org Product|Platform Specific/Hardware |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/radeon: fix dig encoder selection on DCE61
On Thu, Aug 30, 2012 at 2:27 AM, Michel D?nzer wrote:
> On Mit, 2012-08-29 at 20:02 -0400, alexdeucher at gmail.com wrote:
>> From: Alex Deucher
>>
>> Was using the DCE41 code which was wrong. Fixes
>> blank displays on a number of Trinity systems.
>>
>> Signed-off-by: Alex Deucher
>> Cc: stable at vger.kernel.org
>> ---
>> drivers/gpu/drm/radeon/atombios_encoders.c | 31
>> +++
>> 1 files changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeon/atombios_encoders.c
>> index 4a7f95e..6e8803a 100644
>> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
>> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
>> @@ -1769,13 +1769,34 @@ static int radeon_atom_pick_dig_encoder(struct
>> drm_encoder *encoder)
>> struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
>> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
>> struct drm_encoder *test_encoder;
>> - struct radeon_encoder_atom_dig *dig;
>> + struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>> uint32_t dig_enc_in_use = 0;
>>
>> - /* DCE4/5 */
>> - if (ASIC_IS_DCE4(rdev)) {
>> - dig = radeon_encoder->enc_priv;
>> - if (ASIC_IS_DCE41(rdev)) {
>> + if (ASIC_IS_DCE6(rdev)) {
>> + /* DCE6 */
>> + switch (radeon_encoder->encoder_id) {
>> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
>> + if (dig->linkb)
>> + return 1;
>> + else
>> + return 0;
>> + break;
>> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>> + if (dig->linkb)
>> + return 3;
>> + else
>> + return 2;
>> + break;
>> + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
>> + if (dig->linkb)
>> + return 5;
>> + else
>> + return 4;
>> + break;
>> + }
>> + } else if (ASIC_IS_DCE4(rdev)) {
>> + /* DCE4/5 */
>> + if (ASIC_IS_DCE41(rdev) && !ASIC_IS_DCE61(rdev)) {
>
> The !ASIC_IS_DCE61(rdev) seems redundant here. Either way though,
>
whoops, yes, it is. I was considering whether to add a !DCE61 check
or a new DCE6 section and decided the latter was cleaner, but never
removed the other check. Oh well. I'll clean it up later. Thanks!
> Reviewed-by: Michel D?nzer
>
>
> --
> Earthling Michel D?nzer | http://www.amd.com
> Libre software enthusiast | Debian, X and DRI developer
[Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes
On Thu, 30 Aug 2012 13:26:48 +0200, Daniel Vetter wrote: > We've had and still have too many issues where the gpu turbot doesn't > quite to what it's supposed to do (or what we want it to do). > > Adding a tracepoint to track when the desired gpu frequence changes > should help a lot in characterizing and understanding problematic > workloads. > > Also, this should be fairly interesting for power tuning (and > especially noticing when the gpu is stuck in high frequencies, as has > happened in the past) and hence for integration into powertop and > similar tools. > > Cc: Arjan van de Ven > Signed-off-by: Daniel Vetter Like it, even the naming scheme. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 42182] Screen brightness is still set to MINIMUM and am unable to change it
https://bugzilla.kernel.org/show_bug.cgi?id=42182 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2012-08-30 13:46:33 --- Is this still an issue with a newer kernel? Make sure your kernel has the acpi backlight controls included. My drm-next queue for 3.7 has support for native backlight control (assuming the OEM uses the on chip backlight controller) if you can't get the acpi backlight controls working. http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/i915: add a tracepoint for gpu frequency changes
Am Donnerstag, den 30.08.2012, 13:26 +0200 schrieb Daniel Vetter:
> We've had and still have too many issues where the gpu turbot doesn't
s,turbot,turbo,
> quite to what it's supposed to do (or what we want it to do).
s,to,do,
> Adding a tracepoint to track when the desired gpu frequence changes
frequenc*y*
> should help a lot in characterizing and understanding problematic
> workloads.
>
> Also, this should be fairly interesting for power tuning (and
> especially noticing when the gpu is stuck in high frequencies, as has
> happened in the past) and hence for integration into powertop and
> similar tools.
If this can be used from user space already, it would be nice to add
some notes to the commit how this can be done.
> Cc: Arjan van de Ven
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_trace.h | 15 +++
> drivers/gpu/drm/i915/intel_pm.c |2 ++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index 3c4093d..8134421 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -430,6 +430,21 @@ TRACE_EVENT(i915_reg_rw,
> (u32)(__entry->val >> 32))
> );
>
> +TRACE_EVENT(intel_gpu_freq_change,
> + TP_PROTO(u32 freq),
> + TP_ARGS(freq),
> +
> + TP_STRUCT__entry(
> + __field(u32, freq)
> + ),
> +
> + TP_fast_assign(
> +__entry->freq = freq;
> +),
> +
> + TP_printk("new_freq=%u", __entry->freq)
> +);
> +
> #endif /* _I915_TRACE_H_ */
>
> /* This part must be outside protection */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ebe3498..194a72f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2343,6 +2343,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
> I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
>
> dev_priv->rps.cur_delay = val;
> +
> + trace_intel_gpu_freq_change(val * 50);
> }
>
> static void gen6_disable_rps(struct drm_device *dev)
Acked-by: Paul Menzel
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120830/c9b304cb/attachment.pgp>
[RFC] New dma_buf -> EGLImage EGL extension
Hi All, Over the last few months I've been working on & off with a few people from Linaro on a new EGL extension. The extension allows constructing an EGLImage from a (set of) dma_buf file descriptors, including support for multi-plane YUV. I envisage the primary use-case of this extension to be importing video frames from v4l2 into the EGL/GLES graphics driver to texture from. Originally the intent was to develop this as a Khronos-ratified extension. However, this is a little too platform-specific to be an officially sanctioned Khronos extension. It also goes against the general "EGLStream" direction the EGL working group is going in. As such, the general feeling was to make this an EXT "multi-vendor" extension with no official stamp of approval from Khronos. As this is no-longer intended to be a Khronos extension, I've re-written it to be a lot more Linux & dma_buf specific. It also allows me to circulate the extension more widely (I.e. To those outside Khronos membership). ARM are implementing this extension for at least our Mali-T6xx driver and likely earlier drivers too. I am sending this e-mail to solicit feedback, both from other vendors who might implement this extension (Mesa3D?) and from potential users of the extension. However, any feedback is welcome. Please find the extension text as it currently stands below. There several open issues which I've proposed solutions for, but I'm not really happy with those proposals and hoped others could chip-in with better ideas. There are likely other issues I've not thought about which also need to be added and addressed. Once there's a general consensus or if no-one's interested, I'll update the spec, move it out of Draft status and get it added to the Khronos registry, which includes assigning values for the new symbols. Cheers, Tom -8<- Name EXT_image_dma_buf_import Name Strings EGL_EXT_image_dma_buf_import Contributors Jesse Barker Rob Clark Tom Cooksey Contacts Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) Status DRAFT Version Version 3, August 16, 2012 Number EGL Extension ??? Dependencies EGL 1.2 is required. EGL_KHR_image_base is required. The EGL implementation must be running on a Linux kernel supporting the dma_buf buffer sharing mechanism. This extension is written against the wording of the EGL 1.2 Specification. Overview This extension allows creating an EGLImage from a Linux dma_buf file descriptor or multiple file descriptors in the case of multi-plane YUV images. New Types None New Procedures and Functions None New Tokens Accepted by the parameter of eglCreateImageKHR: EGL_LINUX_DMA_BUF_EXT Accepted as an attribute in the parameter of eglCreateImageKHR: EGL_LINUX_DRM_FOURCC_EXT EGL_DMA_BUF_PLANE0_FD_EXT EGL_DMA_BUF_PLANE0_OFFSET_EXT EGL_DMA_BUF_PLANE0_PITCH_EXT EGL_DMA_BUF_PLANE1_FD_EXT EGL_DMA_BUF_PLANE1_OFFSET_EXT EGL_DMA_BUF_PLANE1_PITCH_EXT EGL_DMA_BUF_PLANE2_FD_EXT EGL_DMA_BUF_PLANE2_OFFSET_EXT EGL_DMA_BUF_PLANE2_PITCH_EXT Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation) Add to section 2.5.1 "EGLImage Specification" (as defined by the EGL_KHR_image_base specification), in the description of eglCreateImageKHR: "Values accepted for are listed in Table aaa, below. +-++ | | Notes | +-++ | EGL_LINUX_DMA_BUF_EXT | Used for EGLImages imported from Linux | | | dma_buf file descriptors | +-++ Table aaa. Legal values for eglCreateImageKHR parameter ... If is EGL_LINUX_DMA_BUF_EXT, must be a valid display, must be EGL_NO_CONTEXT, and must be NULL, cast into the type EGLClientBuffer. The details of the image is specified by the attributes passed into eglCreateImageKHR. Required attributes and their values are as follows: * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl. * EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image. * EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes. * EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats. Fo
udl vs udlfb and EDID trouble
On Thu, Aug 30, 2012 at 8:24 AM, Tvrtko Ursulin wrote: > > Hi all, > > I've been playing with some DisplayLink adapters, six of them to be precise > connected to six identical HDMI monitors. > > Under kernel 3.5 things did not really work for me apparently because of the > udl driver's inability to fetch EDID. Interestingly, logged EDID blocks were > different for each of the six monitors which suggests a serious bug somewhere. > > I've then went to see if I can load my own EDID, because I remember doing it > via /sys/class/graphics/fb?/edid before, but that file was not there. > (Is it possible to override EDID with the udl driver?) > > To cut the long story short, I figured out there are two drivers for this > hardware. Fedora based 3.5 kernel builds and uses udl, while the older 3.3.2 > I played with before builds and uses udlfb. (Why two drivers?) udlfb was the original driver. It's a basic kernel fb driver. udl is a drm driver that Dave wrote based on udlfb. The drm variant will eventually allow you to hotplug displaylink adapters in X and use acceleration provided by another GPU. > > Now going back to 3.3.2 and udlfb, EDID got correctly fetched from all six > monitors. Sounds like a bug in the udl i2c code. Probably worth comparing the relevant udl and uldfb code; it may be a simple fix. Alex
[PATCH] drm/radeon: fix dig encoder selection on DCE61
2012/8/30 Alex Deucher :
> On Thu, Aug 30, 2012 at 2:27 AM, Michel D?nzer wrote:
>> On Mit, 2012-08-29 at 20:02 -0400, alexdeucher at gmail.com wrote:
>>> - /* DCE4/5 */
>>> - if (ASIC_IS_DCE4(rdev)) {
>>> - dig = radeon_encoder->enc_priv;
>>> - if (ASIC_IS_DCE41(rdev)) {
>>> + if (ASIC_IS_DCE6(rdev)) {
>>> + /* DCE6 */
Amazing comment ;)
--
Rafa?
[Bug 42672] Nouveau. Screen corruption and occasional gpu lockup
https://bugzilla.kernel.org/show_bug.cgi?id=42672 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Kernel Version|3.2.2 |3.3.1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 42708] drm:radeon_cs_ioctl "Failed to schedule IB" error after s2ram and wakeup
https://bugzilla.kernel.org/show_bug.cgi?id=42708 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #35 from Alex Deucher 2012-08-30 14:25:55 UTC --- (In reply to comment #34) > Alex, > Please see the DSDT table from a Macbook Pro booted in EFI mode. Maybe it will > give you some ideas for extracting the VBIOS. Sorry, I'm not really much of an ACPI or Mac expert. I don't see anything relevant. IIRC, the vbios on macs is only available in boot services so it's likely gone by the time the OS is loaded. You'd probably need the boot loader to grab it and store a copy somewhere so the OS can access it when it loads. I'm not sure how Apple does it. Someone more familiar with Macs may have some ideas. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42787] Video flickers on X1200 / RS690 over DVI
https://bugzilla.kernel.org/show_bug.cgi?id=42787 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 42708] drm:radeon_cs_ioctl "Failed to schedule IB" error after s2ram and wakeup
https://bugzilla.kernel.org/show_bug.cgi?id=42708 Dizintegrator changed: What|Removed |Added Status|NEW |RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #1 from Dizintegrator 2012-08-30 14:43:05 --- Not reproduceable anymore on kernels 3.4 - 3.5. Closed. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46711] New: vmwgfx does not work in qemu/kvm
https://bugzilla.kernel.org/show_bug.cgi?id=46711 URL: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1 037606 Summary: vmwgfx does not work in qemu/kvm Product: Drivers Version: 2.5 Kernel Version: 3.6-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: hramrach at gmail.com Regression: No vmwgfx fails in kvm (running something like kvm -m 2048 -vga vmware -hda ubuntu.img): [ 29.856068] [drm] Initialized drm 1.1.0 20060810 [ 29.905192] [drm] Capabilities: [ 29.905196] [drm] Rect copy. [ 29.905197] [drm] Cursor. [ 29.905198] [drm] Cursor bypass. [ 29.905198] [drm] Cursor bypass 2. [ 29.905200] [drm] VRAM at 0xfd00 size is 16384 kiB [ 29.905201] [drm] MMIO at 0xfe00 size is 64 kiB [ 29.905203] [drm] global init. [ 29.907091] [TTM] Zone kernel: Available graphics memory: 1025792 kiB [ 29.907093] [TTM] Initializing pool allocator [ 29.907097] [TTM] Initializing DMA pool allocator [ 29.907432] [drm:vmw_driver_load] *ERROR* Hardware has no pitchlock [ 29.907475] [TTM] Finalizing pool allocator [ 29.907478] [TTM] Finalizing DMA pool allocator [ 29.907494] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 29.907676] vmwgfx: probe of :00:02.0 failed with error -38 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 42795] Unable to boot with the radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=42795 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/i915/hdmi: only enable audio if there's a hdmi sink
On 8/30/12 3:44 AM, Daniel Vetter wrote: > Some monitors totally don't like to receive infoframes, and naturally > don't claim to support hdmi. > > But for some odd reason they've added a CEA block to their edid, > which automatically gives you basic audio. Still, we may not send > out hdmi infoframes to them, hence check whether the sink is indeed > hdmi capable. > > Also kill a stale comment while at it. Does an incomplete version of what it says on the box, you need to hit the HDMI code in intel_sdvo.c too. At which point, should do the obvious bool drm_monitor_has_hdmi_audio() in drm_edid.c. - ajax
[Bug 36072] celestia causes kernel oops when allocation a lot of memory (for textures)
https://bugzilla.kernel.org/show_bug.cgi?id=36072 aceman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|OBSOLETE| --- Comment #8 from aceman 2012-08-30 15:32:57 --- Yes, still happens randomly, on kernel 3.5.3, X.org 1.12, ati driver 6.99.99, Mesa git (9.0): Aug 29 23:46:50 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Aug 29 23:47:16 coolbox last message repeated 646 times Aug 29 23:48:07 coolbox last message repeated 554 times Aug 29 23:50:15 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Aug 29 23:50:41 coolbox last message repeated 6 times Aug 29 23:50:41 coolbox kernel: vmap allocation for size 178966528 failed: use vmalloc= to increase size. Aug 29 23:50:41 coolbox kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Aug 29 23:50:49 coolbox last message repeated 131 times Aug 29 23:50:58 coolbox kernel: [ cut here ] Aug 29 23:50:58 coolbox kernel: kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:1167! Aug 29 23:50:58 coolbox kernel: invalid opcode: [#1] SMP Aug 29 23:50:58 coolbox kernel: Modules linked in: usb_storage autofs4 nf_conntrack_ftp xt_tcpudp xt_owner xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_LOG iptable_filter ip _tables x_tables asus_atk0110 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss cx88_blackbird cx2341x cx8802 tuner_simple tuner_types tda9887 tda8290 tea5767 tuner cx8800 cx88xx r c_core tveeprom v4l2_common videodev videobuf_dma_sg videobuf_core btcx_risc k10temp forcedeth snd_hda_codec_via snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc i2c_nforce2 ext4 mbcac he jbd2 crc16 usbhid powernow_k8 mperf ohci_hcd ehci_hcd usbcore usb_common fuse [last unloaded: microcode] Aug 29 23:50:58 coolbox kernel: Aug 29 23:50:58 coolbox kernel: Pid: 19931, comm: celestia Not tainted 2.6.45.3 #93 System manufacturer System Product Name/M2N68 Aug 29 23:50:58 coolbox kernel: EIP: 0060:[] EFLAGS: 00010206 CPU: 3 Aug 29 23:50:58 coolbox kernel: EIP is at ttm_bo_check_placement+0x19/0x20 Aug 29 23:50:58 coolbox kernel: EAX: e1f12c2c EBX: 2aac ECX: EDX: 0100 Aug 29 23:50:58 coolbox kernel: ESI: ec13c468 EDI: ebbf71c0 EBP: 00021240 ESP: eaa33d70 Aug 29 23:50:58 coolbox kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Aug 29 23:50:58 coolbox kernel: CR0: 8005003b CR2: aa634000 CR3: 2afab000 CR4: 07f0 Aug 29 23:50:58 coolbox kernel: DR0: DR1: DR2: DR3: Aug 29 23:50:58 coolbox kernel: DR6: 0ff0 DR7: 0400 Aug 29 23:50:58 coolbox kernel: Process celestia (pid: 19931, ti=eaa32000 task=ec27a030 task.ti=eaa32000) Aug 29 23:50:58 coolbox kernel: Stack: Aug 29 23:50:58 coolbox kernel: c030b4c9 01aac000 e1f12c2c e1f12c00 fff4 0001 Aug 29 23:50:58 coolbox kernel: 02aac000 c033bb07 e1f12c14 0001 0001 Aug 29 23:50:58 coolbox kernel: 00021240 c033b850 0001 0001 ec13c468 ec13cd38 Aug 29 23:50:58 coolbox kernel: Call Trace: Aug 29 23:50:58 coolbox kernel: [] ? ttm_bo_init+0x179/0x370 Aug 29 23:50:58 coolbox kernel: [] ? radeon_bo_create+0x197/0x290 Aug 29 23:50:58 coolbox kernel: [] ? radeon_bo_clear_va+0x80/0x80 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_object_create+0x5c/0xf0 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_create_ioctl+0x66/0xf0 Aug 29 23:50:58 coolbox kernel: [] ? _copy_from_user+0x33/0x70 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_pwrite_ioctl+0x30/0x30 Aug 29 23:50:58 coolbox kernel: [] ? drm_ioctl+0x36c/0x3d0 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? radeon_gem_pwrite_ioctl+0x30/0x30 Aug 29 23:50:58 coolbox kernel: [] ? free_pgtables+0x8a/0xb0 Aug 29 23:50:58 coolbox kernel: [] ? tlb_finish_mmu+0x9/0x30 Aug 29 23:50:58 coolbox kernel: [] ? drm_copy_field+0x70/0x70 Aug 29 23:50:58 coolbox kernel: [] ? do_vfs_ioctl+0x7a/0x580 Aug 29 23:50:58 coolbox kernel: [] ? do_munmap+0x245/0x300 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? sys_ioctl+0x2e/0x50 Aug 29 23:50:58 coolbox kernel: [] ? syscall_call+0x7/0xb Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: [] ? sys_umount+0x37d/0x380 Aug 29 23:50:58 coolbox kernel: Code: 8b 6c 24 14 83 c4 18 c3 8d 76 00 8d bc 27 00 00 00 00 8b 0a 85 c9 75 09 83 7a 04 00 75 03 31 c0 c3 8b 52 04 29 ca 39 50 44 76 f3 <0f> 0b 90 8d 74 26 00 8b 4a 14 53 6b d9 50 8b 44 18 1c a8 01 75 Aug 29 23:50:58 coolbox kernel: EIP: [] ttm_bo_check_placement+0x19/0x20 SS:ESP 0068:eaa33d70 Aug 29
[PATCH V6] drm: edid: add support for E-DDC
On Thu, Aug 30, 2012 at 3:58 AM, Ville Syrj?l? <
ville.syrjala at linux.intel.com> wrote:
> On Thu, Aug 30, 2012 at 12:34:06PM +0530, Shirish S wrote:
> > @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > .buf= buf,
> > }
> > };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > +
> > + /*
> > + * Avoid sending the segment addr to not upset non-compliant ddc
> > + * monitors.
> > + */
>
> Indentation is still wrong. Or is it gettimg mangled by some email server?
>
> I have double checked with checkpatch, i did not get any errors or
warnings,
looks like as you are saying may be true.
Requesting for merge!
> > + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> > +
> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> > adapter->name);
> > break;
> > }
> > - } while (ret != 2 && --retries);
> > + } while (ret != xfers && --retries);
> >
> > - return ret == 2 ? 0 : -1;
> > + return ret == xfers ? 0 : -1;
> > }
> >
> > static bool drm_edid_is_zero(u8 *in_edid, int length)
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120830/79e97406/attachment.html>
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 Alan changed: What|Removed |Added Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/radeon: implement bounds checking on thermal controller lookup
From: Alex Deucher
Don't read past the end of the array if we encounter an unknown
thermal controller.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index e368b30..01b90b4 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2009,7 +2009,8 @@ static int radeon_atombios_parse_power_table_1_3(struct
radeon_device *rdev)
power_info = (union power_info *)(mode_info->atom_context->bios +
data_offset);
/* add the i2c bus for thermal/fan chip */
- if (power_info->info.ucOverdriveThermalController > 0) {
+ if ((power_info->info.ucOverdriveThermalController > 0) &&
+ (power_info->info.ucOverdriveThermalController <
ARRAY_SIZE(thermal_controller_names))) {
DRM_INFO("Possible %s thermal controller at 0x%02x\n",
thermal_controller_names[power_info->info.ucOverdriveThermalController],
power_info->info.ucOverdriveControllerAddress >> 1);
@@ -2213,7 +2214,7 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
(controller->ucType ==
ATOM_PP_THERMALCONTROLLER_EMC2103_WITH_INTERNAL)) {
DRM_INFO("Special thermal controller config\n");
- } else {
+ } else if (controller->ucType <
ARRAY_SIZE(pp_lib_thermal_controller_names)) {
DRM_INFO("Possible %s thermal controller at 0x%02x %s
fan control\n",
pp_lib_thermal_controller_names[controller->ucType],
controller->ucI2cAddress >> 1,
@@ -2228,6 +2229,12 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
strlcpy(info.type, name, sizeof(info.type));
i2c_new_device(&rdev->pm.i2c_bus->adapter,
&info);
}
+ } else {
+ DRM_INFO("Unknown thermal controller type %d at 0x%02x
%s fan control\n",
+controller->ucType,
+controller->ucI2cAddress >> 1,
+(controller->ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
}
}
}
--
1.7.7.5
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #36 from Stefan D?singer 2012-08-30 17:39:59 UTC --- My guess would be that they simply store it in the driver, i.e. similarly to what my hack does. Considering that they have hardware and software under full control I don't see why they want a video bios that's separate from the driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
drm: Adding the option IRQ_ONESHOT to support irq oneshot
From: liu chuansheng Subject: [PATCH] drm: Adding the option IRQ_ONESHOT to support irq oneshot For some platforms, we want the irq is handled as one shot, then even when we use the irq thread, with this option, the new irq will come until the irq thread finished. So we have the requirement for IRQ_ONESHOT. Signed-off-by: liu chuansheng --- drivers/gpu/drm/drm_irq.c |3 +++ include/drm/drmP.h|1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 03f16f3..7a8a581 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -345,6 +345,9 @@ int drm_irq_install(struct drm_device *dev) if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED)) sh_flags = IRQF_SHARED; +if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT)) +sh_flags |= IRQF_ONESHOT; + if (dev->devname) irqname = dev->devname; else diff --git a/include/drm/drmP.h b/include/drm/drmP.h index d6b67bb..dfede31 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...); #define DRIVER_GEM 0x1000 #define DRIVER_MODESET 0x2000 #define DRIVER_PRIME 0x4000 +#define DRIVER_IRQ_ONESHOT 0x8000 #define DRIVER_BUS_PCI 0x1 #define DRIVER_BUS_PLATFORM 0x2 -- 1.7.0.4
A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing
So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider object interface, so that Optimus-based laptops can use our driver to drive the discrete GPU and display on the integrated GPU. The good news is that I've got a proof of concept working. During a review of the current code, we came up with a few concerns: 1. The output source is responsible for allocating the shared memory Right now, the X server calls CreatePixmap on the output source screen and then expects the output sink screen to be able to display from whatever memory the source allocates. Right now, the source has no mechanism for asking the sink what its requirements are for the surface. I'm using our own internal pitch alignment requirements and that seems to be good enough for the Intel device to scan out, but that could be pure luck. Does it make sense to add a mechanism for drivers to negotiate this with each other, or is it sufficient to just define a lowest common denominator format and if your hardware can't deal with that format, you just don't get to share buffers? One of my coworkers brought to my attention the fact that Tegra requires a specific pitch alignment, and cannot accommodate larger pitches. If other SoC designs have similar restrictions, we might need to add a handshake mechanism. 2. There's no fallback mechanism if sharing can't be negotiated If RandR fails to share a pixmap with the output sink screen, the whole modeset fails. This means you'll end up not seeing anything on the screen and you'll probably think your computer locked up. Should there be some sort of software copy fallback to ensure that something at least shows up on the display? 3. How should the memory be allocated? In the prototype I threw together, I'm allocating the shared memory using shm_open and then exporting that as a dma-buf file descriptor using an ioctl I added to the kernel, and then importing that memory back into our driver through dma_buf_attach & dma_buf_map_attachment. Does it make sense for user-space programs to be able to export shmfs files like that? Should that interface go in DRM / GEM / PRIME instead? Something else? I'm pretty unfamiliar with this kernel code so any suggestions would be appreciated. -- Aaron P.S. for those unfamiliar with PRIME: Dave Airlie added new support to the X Resize and Rotate extension version 1.4 to support offloading display and rendering to different drivers. PRIME is the DRM implementation in the kernel, layered on top of DMA-BUF, that implements the actual sharing of buffers between drivers. http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=randrproto-1.4.0#n122 http://airlied.livejournal.com/7.html - update on hotplug server http://airlied.livejournal.com/76078.html - randr 1.5 demo videos --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ---
[Linaro-mm-sig] A few questions about the best way to implement RandR 1.4 / PRIME buffer sharing
On 08/30/2012 10:31 AM, Aaron Plattner wrote: > So I've been experimenting with support for Dave Airlie's new RandR 1.4 > provider > object interface, so that Optimus-based laptops can use our driver to drive > the > discrete GPU and display on the integrated GPU. The good news is that I've > got > a proof of concept working. > > During a review of the current code, we came up with a few concerns: > > 1. The output source is responsible for allocating the shared memory > > Right now, the X server calls CreatePixmap on the output source screen and > then > expects the output sink screen to be able to display from whatever memory the > source allocates. Right now, the source has no mechanism for asking the sink > what its requirements are for the surface. I'm using our own internal pitch > alignment requirements and that seems to be good enough for the Intel device > to > scan out, but that could be pure luck. > > Does it make sense to add a mechanism for drivers to negotiate this with each > other, or is it sufficient to just define a lowest common denominator format > and > if your hardware can't deal with that format, you just don't get to share > buffers? > > One of my coworkers brought to my attention the fact that Tegra requires a > specific pitch alignment, and cannot accommodate larger pitches. If other SoC > designs have similar restrictions, we might need to add a handshake mechanism. > > 2. There's no fallback mechanism if sharing can't be negotiated > > If RandR fails to share a pixmap with the output sink screen, the whole > modeset > fails. This means you'll end up not seeing anything on the screen and you'll > probably think your computer locked up. Should there be some sort of software > copy fallback to ensure that something at least shows up on the display? > > 3. How should the memory be allocated? > > In the prototype I threw together, I'm allocating the shared memory using > shm_open and then exporting that as a dma-buf file descriptor using an ioctl I > added to the kernel, and then importing that memory back into our driver > through > dma_buf_attach & dma_buf_map_attachment. Does it make sense for user-space > programs to be able to export shmfs files like that? Should that interface go > in DRM / GEM / PRIME instead? Something else? I'm pretty unfamiliar with > this > kernel code so any suggestions would be appreciated. There's also a #4 that didn't seem relevant to cross-post to linaro-mm-sig: 4. There's no mechanism for double buffering the output sink RandR allocates one pixmap on the output source screen and sets up tracking so the source driver can copy the screen into the shared pixmap. However, the sink driver scans out from the shared pixmap directly. There's no mechanism to prevent tearing on the sink side of the pipeline. It seems like it would be nice if the source could trigger the sink device to flip between front and back buffers when the copy is finished, and get back a fence to indicate when the flip has occurred and the source can start the next copy. -- Aaron
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #22 from Alexandre Demers 2012-08-30 21:34:48 UTC --- It seems Marek has more weight than me about lockups related to VM on Cayman(problem first reported as bug 45018). Patch by Marek to disable VM by default for Cayman: http://lists.freedesktop.org/archives/mesa-dev/2012-August/026590.html If you have any news on the subject, feel free to add info in the current bug. To Marek: are you experiencing the same first lockup in the piglit tests as reported in comment 10. I'm sure have seen a previous comment from another dev who was also experiencing lockups on Cayman, but I can't find who that was. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #23 from Alex Deucher 2012-08-30 21:42:20 UTC --- (In reply to comment #22) > It seems Marek has more weight than me about lockups related to VM on > Cayman(problem first reported as bug 45018). Well, we were hoping to get this resolved in time for 9.0, but as it's getting pretty close now, it's probably better to disable it at least for the 9.0 release. The problem is, when it's disabled, there's not much chance of anyone testing it, so it's not likely to ever get properly fixed. Also, SI only supports VM, so we can't disable VM for SI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41732] [radeon] KMS (and X.org) detect wrong outputs
https://bugzilla.kernel.org/show_bug.cgi?id=41732 Niels Ole Salscheider changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||PATCH_ALREADY_AVAILABLE --- Comment #11 from Niels Ole Salscheider 2012-08-30 22:20:42 --- This issue is fixed in recent kernels. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #24 from Alexandre Demers 2012-08-30 22:38:36 UTC --- (In reply to comment #23) > (In reply to comment #22) > > It seems Marek has more weight than me about lockups related to VM on > > Cayman(problem first reported as bug 45018). > > Well, we were hoping to get this resolved in time for 9.0, but as it's getting > pretty close now, it's probably better to disable it at least for the 9.0 > release. The problem is, when it's disabled, there's not much chance of > anyone > testing it, so it's not likely to ever get properly fixed. Also, SI only > supports VM, so we can't disable VM for SI. Meanwhile, since fixes committed for bug 45018 helped me a lot, I'll gladly keep VM activated to test it. After all, my desktop is now usable now, I've been running for 3 days without any lockup, while I was previously only able to run for a couple of hours before restarting. So, if you have any patches you want to test that could help, ask me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
