[Linaro-mm-sig] [PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

Hi Subash, Could you re-post this patch seperately? your patch includes another one. Thanks, Inki Dae 2012/6/23 Subash Patel : > From: Subash Patel > > exynos_pages_to_sg() internally calls sg_kmalloc() which can return > no pages when the system is under high memory crunch. One such instance

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #12 from Sergio 2012-06-25 22:43:30 --- ArTourter, for me, in Fedora 18 (Kernel 3.4.2) solves the problem. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because:

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #11 from ArTourter 2012-06-25 22:31:03 --- I am not sure if this bug report is still live but having just updated my machine to the latest slackware64-current kernel (3.2.21), I am still getting my system to hang half way through

Bogus video resolution in Linux 3.5-rc4

Andy Furniss wrote: > HDMI TV - lots of new modes but it already advertised all the CVT that > it supports and all the new are bogus. Oops CEA not CVT.

Bogus video resolution in Linux 3.5-rc4

Am 25.06.2012 um 21:24 schrieb Takashi Iwai: >> > And, does the patch below help? >> >> Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz. > > I guess it worked casually because 1280x1024 at 75 was the highest > resolution / rate, so it was picked up as the preferred mode...

Bogus video resolution in Linux 3.5-rc4

Takashi Iwai wrote: >> The xrandr command shows various bogus modes. > > Can't these values be displayed on your monitor at all? > If they can be displayed, they are valid modes, not really bogus. > After all, they are values that EDID of your montor advertises as > available ranges. I have

Bogus video resolution in Linux 3.5-rc4

At Mon, 25 Jun 2012 19:40:48 +0200, Sven Joachim wrote: > > Am 25.06.2012 um 17:53 schrieb Takashi Iwai: > > > Looking at the EDID data, the problem is likely that your monitor > > doesn't give the proper preferred mode. > > What does xrandr output show? > > , > | Screen 0: minimum 320 x

Linux 3.2: After resume screen only turned on after switching terminals

Dear Linux folks, resuming from suspend to RAM the monitor was indicating by a blinking LED that it did not receive any signal. This is the first time this happened. Resuming from suspend to RAM had worked without problems before (and probably will work again the next tries). Logging in from

3.5.0-rc3 - i915 gmbus dpb timed out

On Mon, Jun 25, 2012 at 07:21:03PM +0200, Paul Rolland wrote: > Hello, > > I've booted a few seconds ago to a freshly compiled 3.5.0-rc3 kernel, and > short after starting X + KDE, I've got : > > Jun 25 19:16:58 tux kernel: [drm] GMBUS [i915 gmbus dpb] timed out, falling > back to bit banging

[Bug 51421] New: sin and cos is broken

https://bugs.freedesktop.org/show_bug.cgi?id=51421 Bug #: 51421 Summary: sin and cos is broken Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity:

Bogus video resolution in Linux 3.5-rc4

Am 25.06.2012 um 17:53 schrieb Takashi Iwai: > Looking at the EDID data, the problem is likely that your monitor > doesn't give the proper preferred mode. > What does xrandr output show? , | Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 | DVI-I-1 connected

3.5.0-rc3 - i915 gmbus dpb timed out

Hello, I've booted a few seconds ago to a freshly compiled 3.5.0-rc3 kernel, and short after starting X + KDE, I've got : Jun 25 19:16:58 tux kernel: [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 in my messages. Nothing like that before (3.4.0-vanilla), and

[PATCH 0/2] drm/edid: Undo the damage from adding extra_modes

On 2012-06-25 17:25 +0200, Adam Jackson wrote: > This fixes the extra_mode walk to be much more conservative. I still think > the whole idea is bogus and that guessing about clone mode sizes is a > userspace policy decision, but apparently xrandr --newmode / --addmode is > unreasonably

Bogus video resolution in Linux 3.5-rc4

At Mon, 25 Jun 2012 17:53:12 +0200, Takashi Iwai wrote: > > And, does the patch below help? BTW, the patch below contains the possible generic fix. It seems that EDID_QUIRK_FIRST_DETAILED_PREFERRED handling is missing from the beginning. So I wrote it just from what I can imagine from the

Bogus video resolution in Linux 3.5-rc4

At Mon, 25 Jun 2012 16:03:36 +0200, Sven Joachim wrote: > > After upgrading to Linux 3.5-rc4 from 3.4.4, I noticed that my monitor > switched to a resolution of 1280x960 rather than the native 1280x1024, > and nouveau has set up a framebuffer of 1680x945. It goes without > saying that the result

Bogus video resolution in Linux 3.5-rc4

file from a working kernel; in 3.5-rc4 it is identical. Cheers, Sven -- next part -- A non-text attachment was scrubbed... Name: edid Type: application/octet-stream Size: 128 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120625/b78706c8/attachment.obj>

Bogus video resolution in Linux 3.5-rc4

which my patch series would eliminate. - ajax -- 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/at

[Bug 43751] New: [TTM] Out of kernel memory

https://bugzilla.kernel.org/show_bug.cgi?id=43751 Summary: [TTM] Out of kernel memory Product: Drivers Version: 2.5 Kernel Version: 3.4.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity:

[PATCH 0/2] drm/edid: Undo the damage from adding extra_modes

e list. - ajax -- 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/20120625/586ff693/attachment-0001.pgp>

[PATCH 2/2] drm/edid: Be much more cautious about walking extra_modes

Essentially, only do this on digital displays. It's almost certainly not wise to add them on CRTs, but we can't tell CRT from LCD before EDID 1.4, so just use digital as a proxy for that. Bugzilla: https://bugs.freedesktop.org/51146 Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c |

[PATCH 1/2] drm/edid: Be more conservative about maximum pixel clock

Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5873e48..4a3e61a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@

[PATCH 0/2] drm/edid: Undo the damage from adding extra_modes

This fixes the extra_mode walk to be much more conservative. I still think the whole idea is bogus and that guessing about clone mode sizes is a userspace policy decision, but apparently xrandr --newmode / --addmode is unreasonably burdensome. This should fix a number of reported regressions,

[PATCH 2/2] DRM: Exynos: check for null in return value of dma_buf_map_attachment()

From: Subash Patel dma_buf_map_attachment() can return NULL and valid sg as return value. Hence the check for the returned scatter-gather must be using the inline function IS_ERR_OR_NULL() in place of IS_ERR() Change-Id: I33218480e220f6a26a1e726b336bf533a95363de

[PATCH 1/2] DRM: Exynos: return NULL if exynos_pages_to_sg fails

From: Subash Patel exynos_pages_to_sg() internally calls sg_kmalloc() which can return no pages when the system is under high memory crunch. One such instance is chromeos-install in the chromeos. This patch adds check for the return value of the function in subject to

[PATCH 0/2] Add return value checks in the drm-dmabuf

From: Subash Patel This patch series is split and re-send of my original patch, after request from Inki Dae. Below two patches add the required error checks in drm dmabuf when the system fails to allocate pages for the scatter-gather. This is very rare situation, and

[PATCH 2/2] DRM: Exynos: check for null in return value of dma_buf_map_attachment()

From: Subash Patel dma_buf_map_attachment() can return NULL and valid sg as return value. Hence the check for the returned scatter-gather must be using the inline function IS_ERR_OR_NULL() in place of IS_ERR() Change-Id: I33218480e220f6a26a1e726b336bf533a95363de

[PATCH 1/2] DRM: Exynos: return NULL if exynos_pages_to_sg fails

From: Subash Patel exynos_pages_to_sg() internally calls sg_kmalloc() which can return no pages when the system is under high memory crunch. One such instance is chromeos-install in the chromeos. This patch adds check for the return value of the function in subject to

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #22 from Jack Dodds 2012-06-25 03:51:46 PDT --- Thank you for the information. I found the PCI code 675D in various header files in xserver-xorg-video-ati-6.14.4 and mesa-8.0.2, leading me to believe that it was supported in

[PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)

continue; > + if (p->dbuf_mapped) { > + call_memop(q, unmap_dmabuf, p->mem_priv); > + p->dbuf_mapped = 0; > + } > + } > + } > } > > /** > -- > 1.7.7.3 > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120625/5b541e76/attachment.html>

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #21 from Michel D?nzer 2012-06-25 02:30:51 PDT --- (In reply to comment #20) > Radeon 7570 card - PCI identifier 675D That's a different card from the one this bug report is about. > libdrm-radeon1 & libdrm2: 2.4.33-1 Support for

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe

https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #20 from Jack Dodds 2012-06-24 18:42:24 PDT --- Further to the above - I have tried all the patches listed above, in various combinations, and the problem still exists. The startup of X fails with the messages

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #21 from Michel Dänzer mic...@daenzer.net 2012-06-25 02:30:51 PDT --- (In reply to comment #20) Radeon 7570 card - PCI identifier 675D That's a different card from the one this bug report is about. libdrm-radeon1 libdrm2:

[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe

https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #22 from Jack Dodds brmda...@hushmail.com 2012-06-25 03:51:46 PDT --- Thank you for the information. I found the PCI code 675D in various header files in xserver-xorg-video-ati-6.14.4 and mesa-8.0.2, leading me to believe that it

Re: [Linaro-mm-sig] [PATCH] DRM: exynos: return NULL if exynos_pages_to_sg fails

Hi Subash, Could you re-post this patch seperately? your patch includes another one. Thanks, Inki Dae 2012/6/23 Subash Patel subas...@gmail.com: From: Subash Patel subash...@samsung.com exynos_pages_to_sg() internally calls sg_kmalloc() which can return no pages when the system is under

Bogus video resolution in Linux 3.5-rc4

After upgrading to Linux 3.5-rc4 from 3.4.4, I noticed that my monitor switched to a resolution of 1280x960 rather than the native 1280x1024, and nouveau has set up a framebuffer of 1680x945. It goes without saying that the result looks terrible. Bisecting shows that the problem started with

[Bug 43751] New: [TTM] Out of kernel memory

https://bugzilla.kernel.org/show_bug.cgi?id=43751 Summary: [TTM] Out of kernel memory Product: Drivers Version: 2.5 Kernel Version: 3.4.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity:

[PATCH 1/2] drm/edid: Be more conservative about maximum pixel clock

Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5873e48..4a3e61a 100644 --- a/drivers/gpu/drm/drm_edid.c +++

[PATCH 0/2] drm/edid: Undo the damage from adding extra_modes

This fixes the extra_mode walk to be much more conservative. I still think the whole idea is bogus and that guessing about clone mode sizes is a userspace policy decision, but apparently xrandr --newmode / --addmode is unreasonably burdensome. This should fix a number of reported regressions,

[PATCH 2/2] drm/edid: Be much more cautious about walking extra_modes

Essentially, only do this on digital displays. It's almost certainly not wise to add them on CRTs, but we can't tell CRT from LCD before EDID 1.4, so just use digital as a proxy for that. Bugzilla: https://bugs.freedesktop.org/51146 Signed-off-by: Adam Jackson a...@redhat.com ---

Re: Bogus video resolution in Linux 3.5-rc4

At Mon, 25 Jun 2012 16:03:36 +0200, Sven Joachim wrote: After upgrading to Linux 3.5-rc4 from 3.4.4, I noticed that my monitor switched to a resolution of 1280x960 rather than the native 1280x1024, and nouveau has set up a framebuffer of 1680x945. It goes without saying that the result

Re: Bogus video resolution in Linux 3.5-rc4

At Mon, 25 Jun 2012 17:53:12 +0200, Takashi Iwai wrote: And, does the patch below help? BTW, the patch below contains the possible generic fix. It seems that EDID_QUIRK_FIRST_DETAILED_PREFERRED handling is missing from the beginning. So I wrote it just from what I can imagine from the

Re: [PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)

ping? On Tue, Jun 19, 2012 at 11:12 PM, Dima Zavin dmitr...@google.com wrote: Tomasz, I've encountered an issue with this patch when userspace does several stream_on/stream_off cycles. When the user tries to qbuf a buffer after doing stream_off, we trigger the dmabuf already pinned warning

Re: [PATCH 0/2] drm/edid: Undo the damage from adding extra_modes

On 2012-06-25 17:25 +0200, Adam Jackson wrote: This fixes the extra_mode walk to be much more conservative. I still think the whole idea is bogus and that guessing about clone mode sizes is a userspace policy decision, but apparently xrandr --newmode / --addmode is unreasonably burdensome.

3.5.0-rc3 - i915 gmbus dpb timed out

Hello, I've booted a few seconds ago to a freshly compiled 3.5.0-rc3 kernel, and short after starting X + KDE, I've got : Jun 25 19:16:58 tux kernel: [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 in my messages. Nothing like that before (3.4.0-vanilla), and

Re: Bogus video resolution in Linux 3.5-rc4

Am 25.06.2012 um 17:53 schrieb Takashi Iwai: Looking at the EDID data, the problem is likely that your monitor doesn't give the proper preferred mode. What does xrandr output show? , | Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 | DVI-I-1 connected 1280x1024+0+0

Re: [PATCH 0/2] drm/edid: Undo the damage from adding extra_modes

On Mon, 2012-06-25 at 19:14 +0200, Sven Joachim wrote: On 2012-06-25 17:25 +0200, Adam Jackson wrote: This fixes the extra_mode walk to be much more conservative. I still think the whole idea is bogus and that guessing about clone mode sizes is a userspace policy decision, but apparently

Re: 3.5.0-rc3 - i915 gmbus dpb timed out

On Mon, Jun 25, 2012 at 07:21:03PM +0200, Paul Rolland wrote: Hello, I've booted a few seconds ago to a freshly compiled 3.5.0-rc3 kernel, and short after starting X + KDE, I've got : Jun 25 19:16:58 tux kernel: [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin

Re: Bogus video resolution in Linux 3.5-rc4

On Mon, 2012-06-25 at 19:40 +0200, Sven Joachim wrote: And, does the patch below help? Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz. That is, in fact, what your monitor claims to prefer. The xrandr command shows various bogus modes. Most of which my patch series

Re: Bogus video resolution in Linux 3.5-rc4

At Mon, 25 Jun 2012 19:40:48 +0200, Sven Joachim wrote: Am 25.06.2012 um 17:53 schrieb Takashi Iwai: Looking at the EDID data, the problem is likely that your monitor doesn't give the proper preferred mode. What does xrandr output show? , | Screen 0: minimum 320 x 200, current

Re: Bogus video resolution in Linux 3.5-rc4

Am 25.06.2012 um 21:24 schrieb Takashi Iwai: And, does the patch below help? Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz. I guess it worked casually because 1280x1024@75 was the highest resolution / rate, so it was picked up as the preferred mode... Quite

[Bug 51421] New: sin and cos is broken

https://bugs.freedesktop.org/show_bug.cgi?id=51421 Bug #: 51421 Summary: sin and cos is broken Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity:

Re: Bogus video resolution in Linux 3.5-rc4

Takashi Iwai wrote: The xrandr command shows various bogus modes. Can't these values be displayed on your monitor at all? If they can be displayed, they are valid modes, not really bogus. After all, they are values that EDID of your montor advertises as available ranges. I have already

Re: Bogus video resolution in Linux 3.5-rc4

Andy Furniss wrote: HDMI TV - lots of new modes but it already advertised all the CVT that it supports and all the new are bogus. Oops CEA not CVT. ___ dri-devel mailing list dri-devel@lists.freedesktop.org

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #11 from ArTourter artour...@gmail.com 2012-06-25 22:31:03 --- I am not sure if this bug report is still live but having just updated my machine to the latest slackware64-current kernel (3.2.21), I am still getting my system to

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #12 from Sergio sergiomart...@gmail.com 2012-06-25 22:43:30 --- ArTourter, for me, in Fedora 18 (Kernel 3.4.2) solves the problem. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #13 from ArTourter artour...@gmail.com 2012-06-25 23:34:12 --- Hi, I have just compiled 3.4.4 and I still get exactly the same hang/freeze with ACPI active. Any clues about how to get sensible error report out of this would be

[Bug 50149] Faulty shaders on RS600

https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #13 from Tom Stellard tstel...@gmail.com 2012-06-25 19:10:56 PDT --- Created attachment 63471 -- https://bugs.freedesktop.org/attachment.cgi?id=63471 Possible fix patch 1 -- Configure bugmail:

[PATCH] drm/nouveau/fbcon: using nv_two_heads is not a good idea

From: Ben Skeggs bske...@redhat.com nv_two_heads() was never meant to be used outside of pre-nv50 code. The code checks for = NV_10 for 2 CRTCs, then downgrades a few specific chipsets to 1 CRTC based on (pci_device 0x0ff0). The breakage example seen is on GTX 560Ti, with a pciid of 0x1200,

[Bug 50149] Faulty shaders on RS600

https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #14 from Tom Stellard tstel...@gmail.com 2012-06-25 19:13:09 PDT --- Created attachment 63472 -- https://bugs.freedesktop.org/attachment.cgi?id=63472 Possible fix patch 2 Can you apply these two patches and try again. Lightsmark

[Bug 50149] Faulty shaders on RS600

https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #15 from Roman Šmakal schmakeri...@gmail.com 2012-06-25 19:30:13 PDT --- Actually i cant. My laptop cooling broken 2 weeks ago so i have to buy new fan for it. Will try these patches as soon as i fix it -- Configure bugmail:

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #14 from Vlad vo...@vovan.nl 2012-06-26 04:41:55 --- I had the same issue again after 3.2 kernel with 3.4.0. However at least vanilla 3.4.3 boots fine again. -- Configure bugmail:

[PATCH 1/2] DRM: Exynos: return NULL if exynos_pages_to_sg fails

From: Subash Patel subash...@samsung.com exynos_pages_to_sg() internally calls sg_kmalloc() which can return no pages when the system is under high memory crunch. One such instance is chromeos-install in the chromeos. This patch adds check for the return value of the function in subject to return

[PATCH 2/2] DRM: Exynos: check for null in return value of dma_buf_map_attachment()

From: Subash Patel subash...@samsung.com dma_buf_map_attachment() can return NULL and valid sg as return value. Hence the check for the returned scatter-gather must be using the inline function IS_ERR_OR_NULL() in place of IS_ERR() Change-Id: I33218480e220f6a26a1e726b336bf533a95363de

[PATCH 0/2] Add return value checks in the drm-dmabuf

From: Subash Patel subash...@samsung.com This patch series is split and re-send of my original patch, after request from Inki Dae. Below two patches add the required error checks in drm dmabuf when the system fails to allocate pages for the scatter-gather. This is very rare situation, and occurs

[PATCH 1/2] DRM: Exynos: return NULL if exynos_pages_to_sg fails

From: Subash Patel subash...@samsung.com exynos_pages_to_sg() internally calls sg_kmalloc() which can return no pages when the system is under high memory crunch. One such instance is chromeos-install in the chromeos. This patch adds check for the return value of the function in subject to return

[PATCH 2/2] DRM: Exynos: check for null in return value of dma_buf_map_attachment()

From: Subash Patel subash...@samsung.com dma_buf_map_attachment() can return NULL and valid sg as return value. Hence the check for the returned scatter-gather must be using the inline function IS_ERR_OR_NULL() in place of IS_ERR() Change-Id: I33218480e220f6a26a1e726b336bf533a95363de

[PATCH] i915: initialize CADL in opregion

This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is

Re: Linux 3.2: After resume screen only turned on after switching terminals

On Mon, 2012-06-25 at 21:14 +0200, Paul Menzel wrote: resuming from suspend to RAM the monitor was indicating by a blinking LED that it did not receive any signal. This is the first time this happened. Resuming from suspend to RAM had worked without problems before (and probably will work