[Bug 42876] System doesn't boot with GTX 550 Ti
https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #13 from ArTourter 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 useful. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
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 again the next tries). > > Logging in from SSH worked fine though. Switching terminal to tty1 > nothing changed but going back to tty7, where X was supposed to run), > and the monitor detected a signal and showed the screensaver. > > Switching to tty1 still does not work though, that means the monitor > indicates that it gets no signal. What about tty2-6 or any others? What does fbset -i say when the problem occurs? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer 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
[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
> is chromeos-install in the chromeos. This patch adds check for the return
> value of the function in subject to return NULL on failure.
>
> Signed-off-by: Subash Patel
> CC: dri-devel at lists.freedesktop.org
> CC: linux-samsung-soc at vger.kernel.org
> CC: linaro-mm-sig at lists.linaro.org
> CC: inki.dae at samsung.com
> CC: airlied at redhat.com
> CC: olofj at chromium.org
> ---
> ?drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | ? ?6 +-
> ?1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index 97325c1..c908a29 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -87,6 +87,10 @@ static struct sg_table *
> ? ? ? ?npages = buf->size / buf->page_size;
>
> ? ? ? ?sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
> + ? ? ? if (!sgt) {
> + ? ? ? ? ? ? ? DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
> + ? ? ? ? ? ? ? goto err_unlock;
> + ? ? ? }
> ? ? ? ?nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
>
> ? ? ? ?DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
> @@ -241,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
> drm_device *drm_dev,
>
>
> ? ? ? ?sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> - ? ? ? if (IS_ERR(sgt)) {
> + ? ? ? if (IS_ERR_OR_NULL(sgt)) {
> ? ? ? ? ? ? ? ?ret = PTR_ERR(sgt);
> ? ? ? ? ? ? ? ?goto err_buf_detach;
> ? ? ? ?}
> --
> 1.7.9.5
>
>
> ___
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
[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: --- You are watching the assignee of the bug.
[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 empty, the ACPI methods that are called
on pressing brightness / display switching hotkeys will not trigger a
notification. As a result, it appears as no hotkey has been pressed.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452
Tested-by: Peter Wu
Signed-off-by: Peter Wu
---
drivers/gpu/drm/i915/intel_opregion.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 18bd0af..adf6c79 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -427,6 +427,25 @@ blind_set:
goto end;
}
+static void intel_setup_cadls(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_opregion *opregion = &dev_priv->opregion;
+ int i = 0;
+ u32 disp_id;
+
+ /* Initialize the CADL field by duplicating the DIDL values.
+* Technically, this is not always correct as display outputs may exist,
+* but not active. This initialization is necessary for some Clevo
+* laptops that check this field before processing the brightness and
+* display switching hotkeys. Just like DIDL, CADL is NULL-terminated if
+* there are less than eight devices. */
+ do {
+ disp_id = ioread32(&opregion->acpi->didl[i]);
+ iowrite32(disp_id, &opregion->acpi->cadl[i]);
+ } while (++i < 8 && disp_id != 0);
+}
+
void intel_opregion_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -436,8 +455,10 @@ void intel_opregion_init(struct drm_device *dev)
return;
if (opregion->acpi) {
- if (drm_core_check_feature(dev, DRIVER_MODESET))
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_didl_outputs(dev);
+ intel_setup_cadls(dev);
+ }
/* Notify BIOS we are ready to handle ACPI video ext notifs.
* Right now, all the events are handled by the ACPI video
module.
--
1.7.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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
Signed-off-by: Subash Patel
CC: dri-devel@lists.freedesktop.org
CC: linux-samsung-...@vger.kernel.org
CC: linaro-mm-...@lists.linaro.org
CC: inki@samsung.com
CC: airl...@redhat.com
CC: ol...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 52cf761..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -245,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR(sgt)) {
+ if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 the booting sequence. As previously, the only thing that can be done at that point is to hard reset. My laptop has a dual graphics card and switching to the intel embedded one in the BIOS makes the system boot fine, but switching to the nvidia one makes the system unable to boot unless ACPI is switched off. I am still able to boot fine with kernels 3.1.x and below. -- 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 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 return NULL on failure.
Change-Id: I541ed30491a926ebe72738225041c9f2d88007bc
Signed-off-by: Subash Patel
CC: dri-devel@lists.freedesktop.org
CC: linux-samsung-...@vger.kernel.org
CC: linaro-mm-...@lists.linaro.org
CC: inki@samsung.com
CC: airl...@redhat.com
CC: ol...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..52cf761 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf->size / buf->page_size;
sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
+ if (!sgt) {
+ DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
+ goto err_unlock;
+ }
nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 occurs when the system is under memory pressure. Scatter-gather asks for memory using sg_kmalloc() and this can return no memory. Without below return value checks, the code will crash the system due to invalid pointer access. Subash Patel (2): DRM: Exynos: return NULL if exynos_pages_to_sg fails DRM: Exynos: check for null in return value of dma_buf_map_attachment() drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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
Signed-off-by: Subash Patel
CC: dri-devel@lists.freedesktop.org
CC: linux-samsung-...@vger.kernel.org
CC: linaro-mm-...@lists.linaro.org
CC: inki@samsung.com
CC: airl...@redhat.com
CC: ol...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 52cf761..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -245,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR(sgt)) {
+ if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 return NULL on failure.
Change-Id: I541ed30491a926ebe72738225041c9f2d88007bc
Signed-off-by: Subash Patel
CC: dri-devel@lists.freedesktop.org
CC: linux-samsung-...@vger.kernel.org
CC: linaro-mm-...@lists.linaro.org
CC: inki@samsung.com
CC: airl...@redhat.com
CC: ol...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..52cf761 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf->size / buf->page_size;
sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
+ if (!sgt) {
+ DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
+ goto err_unlock;
+ }
nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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.
[Bug 42876] System doesn't boot with GTX 550 Ti
https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #14 from Vlad 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: 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
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... Quite possible. Problem is that 1280x1024 at 60 looks worse, so I'd like to get the 75 Hz back. >> The xrandr command shows various bogus modes. > > Can't these values be displayed on your monitor at all? It's a TFT LCD with 1280x1024 pixels. Cheers, Sven
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 commented on bogus modes when the patch first went into dcn, but to repeat - HDMI TV - lots of new modes but it already advertised all the CVT that it supports and all the new are bogus. DVI 120Hz 1920x1080 monitor many bogus modes as it won't display > it's res and won't scale up some of the new modes. Even some of the new ones that are not "out of range" will actually end up setting something different and show some distortion. Maybe gained a couple.
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 1280 x 1024, maximum 8192 x 8192
> | DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
> 376mm x 301mm
> |1280x1024 75.0*60.0
> |1024x768 75.1 75.0 70.1 60.0
> |832x62474.6
> |800x60072.2 75.0 60.3 56.2
> |640x48072.8 75.0 66.7 60.0 59.9
> | VGA-1 disconnected (normal left inverted right x axis y axis)
> `
>
> I should note that the monitor is actually connected via VGA, not DVI.
> This seems to be similar to https://bugs.freedesktop.org/50830, but
> since it never caused any real problems for me, I didn't bother.
>
> > 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...
> 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.
Takashi
> ,
> | Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
> | DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
> 376mm x 301mm
> |1280x1024 60.0*+ 75.0
> |1680x945 60.0
> |1400x1050 60.0
> |1600x900 60.0
> |1440x900 75.0 59.9
> |1280x960 60.0
> |1366x768 60.0
> |1360x768 60.0
> |1280x800 74.9 59.8
> |1152x864 75.0
> |1280x768 74.9 59.9
> |1024x768 75.1 75.0 70.1 60.0
> |1024x576 60.0
> |832x62474.6
> |800x60072.2 75.0 60.3 56.2
> |848x48060.0
> |640x48075.0 72.8 72.8 66.7 60.0 59.9
> | VGA-1 disconnected (normal left inverted right x axis y axis)
> `
>
> Cheers,
>Sven
>
>
> > ---
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 5873e48..dab8580 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -116,6 +116,7 @@ static struct edid_quirk {
> >
> > /* Proview AY765C */
> > { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> > + { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> >
> > /* Samsung SyncMaster 205BW. Note: irony */
> > { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
> > @@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void
> > *c)
> > if (!newmode)
> > return;
> >
> > - if (closure->preferred)
> > + if (closure->preferred ||
> > + ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
> > +!closure->modes))
> > newmode->type |= DRM_MODE_TYPE_PREFERRED;
> >
> > drm_mode_probed_add(closure->connector, newmode);
>
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 SSH worked fine though. Switching terminal to tty1 nothing changed but going back to tty7, where X was supposed to run), and the monitor detected a signal and showed the screensaver. Switching to tty1 still does not work though, that means the monitor indicates that it gets no signal. The motherboard is an ASRock A780FullHD [1] and the OS is Debian Sid/unstable. I attach the output of `dmesg` and `/var/log/Xorg.0.log`. Thanks, Paul [1] http://www.asrock.com/mb/overview.asp?model=a780fullhd -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-2-686-pae (Debian 3.2.20-1) (debian-kernel at lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-7) ) #1 SMP Mon Jun 11 18:27:04 UTC 2012 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e6000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - cfeb (usable) [0.00] BIOS-e820: cfeb - cfec (ACPI data) [0.00] BIOS-e820: cfec - cfef (ACPI NVS) [0.00] BIOS-e820: cfef - cff0 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 00012000 (usable) [0.00] NX (Execute Disable) protection: active [0.00] DMI present. [0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./A780FullHD, BIOS P1.00 08/01/2008 [0.00] e820 update range: - 0001 (usable) ==> (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x12 max_arch_pfn = 0x100 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FF8000 write-back [0.00] 1 base 008000 mask FFC000 write-back [0.00] 2 base 00C000 mask FFF000 write-back [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00013000 aka 4864M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820 update range: d000 - 0001 (usable) ==> (reserved) [0.00] found SMP MP-table at [c00ff780] ff780 [0.00] initial memory mapped : 0 - 01a0 [0.00] Base memory trampoline at [c009b000] 9b000 size 16384 [0.00] init_memory_mapping: -379fe000 [0.00] 00 - 20 page 4k [0.00] 20 - 003780 page 2M [0.00] 003780 - 00379fe000 page 4k [0.00] kernel direct mapping tables up to 379fe000 @ 19fa000-1a0 [0.00] RAMDISK: 368ee000 - 3746f000 [0.00] ACPI: RSDP 000fa160 00014 (v00 ACPIAM) [0.00] ACPI: RSDT cfeb 00038 (v01 080108 RSDT2148 20080801 MSFT 0097) [0.00] ACPI: FACP cfeb0200 00084 (v02 A M I OEMFACP 12000601 MSFT 0097) [0.00] ACPI: DSDT cfeb0440 07737 (v01 AS146 AS146012 0012 INTL 20051117) [0.00] ACPI: FACS cfec 00040 [0.00] ACPI: APIC cfeb0390 0006C (v01 080108 APIC2148 20080801 MSFT 0097) [0.00] ACPI: MCFG cfeb0400 0003C (v01 080108 OEMMCFG 20080801 MSFT 0097) [0.00] ACPI: OEMB cfec0040 00071 (v01 080108 OEMB2148 20080801 MSFT 0097) [0.00] ACPI: SSDT cfeb7b80 0028A (v01 A M I POWERNOW 0001 AMD 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 3718MB HIGHMEM available. [0.00] 889MB LOWMEM available. [0.00] mapped low ram: 0 - 379fe000 [0.00] low ram: 0 - 379fe000 [0.00] Zone PFN ranges: [0.00] DMA 0x0010 -> 0x1000 [0.00] Normal 0x1000 -> 0x000379fe [0.00] HighMem 0x000379fe -> 0x0012 [0.00] Movable zone start PFN for each node [0.00] early_node_map[3] active PFN ranges [0.00] 0: 0x0010 -> 0x009f [0.00] 0: 0x0100 -> 0x000cfeb0 [0.00] 0: 0x0010 -> 0x0012 [0.00] On node 0 totalpages: 982591 [0.00] free_area_init_node: node 0, pgdat c1411d8
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 5 > > in my messages. > Nothing like that before (3.4.0-vanilla), and 3.5.0-rc4 not yet compiled. > > Anything I should check and/or report to help ? Nope, everything works as expected. This is purely an informational message (and we might need to create a patch to make it go away on non-debug settings). -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[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: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: cme3000 at gmail.com sin is broken with negative values it just renders on the right side of the screen in shaders like http://glsl.heroku.com/e#2465.1 cos seems to be broken, too, just replace sin with cos on that web page. mesa: git-d105654 OS: Debian unstable, kernel 3.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
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 (normal left inverted right x axis y axis)
376mm x 301mm
|1280x1024 75.0*60.0
|1024x768 75.1 75.0 70.1 60.0
|832x62474.6
|800x60072.2 75.0 60.3 56.2
|640x48072.8 75.0 66.7 60.0 59.9
| VGA-1 disconnected (normal left inverted right x axis y axis)
`
I should note that the monitor is actually connected via VGA, not DVI.
This seems to be similar to https://bugs.freedesktop.org/50830, but
since it never caused any real problems for me, I didn't bother.
> And, does the patch below help?
Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz.
The xrandr command shows various bogus modes.
,
| Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
| DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
376mm x 301mm
|1280x1024 60.0*+ 75.0
|1680x945 60.0
|1400x1050 60.0
|1600x900 60.0
|1440x900 75.0 59.9
|1280x960 60.0
|1366x768 60.0
|1360x768 60.0
|1280x800 74.9 59.8
|1152x864 75.0
|1280x768 74.9 59.9
|1024x768 75.1 75.0 70.1 60.0
|1024x576 60.0
|832x62474.6
|800x60072.2 75.0 60.3 56.2
|848x48060.0
|640x48075.0 72.8 72.8 66.7 60.0 59.9
| VGA-1 disconnected (normal left inverted right x axis y axis)
`
Cheers,
Sven
> ---
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5873e48..dab8580 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -116,6 +116,7 @@ static struct edid_quirk {
>
> /* Proview AY765C */
> { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> + { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> /* Samsung SyncMaster 205BW. Note: irony */
> { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
> @@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void
> *c)
> if (!newmode)
> return;
>
> - if (closure->preferred)
> + if (closure->preferred ||
> + ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
> + !closure->modes))
> newmode->type |= DRM_MODE_TYPE_PREFERRED;
>
> drm_mode_probed_add(closure->connector, newmode);
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #15 from Roman Šmakal 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: 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
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 3.5.0-rc4 not yet compiled. Anything I should check and/or report to help ? Best Paul
[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. > > This should fix a number of reported regressions, please test. Does not help in my case, unfortunately: instead of a bogus 1680x945 resolution I get a bogus 1400x1050 rather than the correct 1280x1024. Going to try Takashi's patch instead. Cheers, Sven
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #14 from Tom Stellard 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 looks a lot better to me with these patches. Do they help with any of your other games? -- 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
[PATCH] drm/nouveau/fbcon: using nv_two_heads is not a good idea
From: Ben Skeggs
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, which
gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing
memory corruption because there's actually 2 CRTCs..
This switches fbcon to use the CRTC count directly from the mode_config
structure, which will also fix the same issue on Kepler boards which have
4 CRTCs.
Signed-off-by: Ben Skeggs
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 8113e92..6fd2211 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -497,7 +497,7 @@ int nouveau_fbcon_init(struct drm_device *dev)
nfbdev->helper.funcs = &nouveau_fbcon_helper_funcs;
ret = drm_fb_helper_init(dev, &nfbdev->helper,
-nv_two_heads(dev) ? 2 : 1, 4);
+dev->mode_config.num_crtc, 4);
if (ret) {
kfree(nfbdev);
return ret;
--
1.7.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50149] Faulty shaders on RS600
https://bugs.freedesktop.org/show_bug.cgi?id=50149 --- Comment #13 from Tom Stellard 2012-06-25 19:10:56 PDT --- Created attachment 63471 --> https://bugs.freedesktop.org/attachment.cgi?id=63471 Possible fix patch 1 -- 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
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 comment:
/* Monitor forgot to set the first detailed is preferred bit. */
#define EDID_QUIRK_FIRST_DETAILED_PREFERRED (1 << 5)
Adam, is my interpretation correct?
Takashi
>
>
> Takashi
>
> ---
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5873e48..dab8580 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -116,6 +116,7 @@ static struct edid_quirk {
>
> /* Proview AY765C */
> { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> + { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> /* Samsung SyncMaster 205BW. Note: irony */
> { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
> @@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void
> *c)
> if (!newmode)
> return;
>
> - if (closure->preferred)
> + if (closure->preferred ||
> + ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
> + !closure->modes))
> newmode->type |= DRM_MODE_TYPE_PREFERRED;
>
> drm_mode_probed_add(closure->connector, newmode);
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 looks terrible.
>
> Bisecting shows that the problem started with commit cb21aafe1:
>
> --8<---cut here---start->8---
> commit cb21aafe121b1c3ad4c77cc5c22320163f16ba42
> Author: Adam Jackson
> Date: Fri Apr 13 16:33:36 2012 -0400
>
> drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types
>
> EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
> continuous frequency", and moves the set of supported timing formulas
> into the range descriptor itself. In any event, the range descriptor
> can act as a filter on the DMT list without regard to a specific timing
> formula.
>
> Signed-off-by: Adam Jackson
> Tested-by: Takashi Iwai
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Dave Airlie
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index cb40611..9363349 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1042,12 +1042,13 @@ do_inferred_modes(struct detailed_timing *timing,
> void *c)
> {
> struct detailed_mode_closure *closure = c;
> struct detailed_non_pixel *data = &timing->data.other_data;
> - int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
>
> - if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
> - closure->modes += drm_dmt_modes_for_range(closure->connector,
> - closure->edid,
> - timing);
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + return;
> +
> + closure->modes += drm_dmt_modes_for_range(closure->connector,
> + closure->edid,
> + timing);
> }
>
> static int
> --8<---cut here---end--->8---
>
> With a kernel from this commit nouveau sets up a resolution of
> 1400x1050; kernels built from commits cffd754 and fc48f16 complain about
> an invalid EDID and use the 1024x768 fallback.
>
> Attached is the /sys/class/drm/card0-DVI-I-1/edid file from a working
> kernel; in 3.5-rc4 it is identical.
Looking at the EDID data, the problem is likely that your monitor
doesn't give the proper preferred mode.
What does xrandr output show?
And, does the patch below help?
Takashi
---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5873e48..dab8580 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -116,6 +116,7 @@ static struct edid_quirk {
/* Proview AY765C */
{ "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
+ { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
/* Samsung SyncMaster 205BW. Note: irony */
{ "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
@@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void *c)
if (!newmode)
return;
- if (closure->preferred)
+ if (closure->preferred ||
+ ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
+!closure->modes))
newmode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(closure->connector, newmode);
[Bug 42876] System doesn't boot with GTX 550 Ti
https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #13 from ArTourter 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 useful. -- 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
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 commit cb21aafe1:
--8<---cut here---start->8---
commit cb21aafe121b1c3ad4c77cc5c22320163f16ba42
Author: Adam Jackson
Date: Fri Apr 13 16:33:36 2012 -0400
drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-by: Adam Jackson
Tested-by: Takashi Iwai
Reviewed-by: Rodrigo Vivi
Signed-off-by: Dave Airlie
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cb40611..9363349 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1042,12 +1042,13 @@ do_inferred_modes(struct detailed_timing *timing, void
*c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
- int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
- if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
- closure->modes += drm_dmt_modes_for_range(closure->connector,
- closure->edid,
- timing);
+ if (data->type != EDID_DETAIL_MONITOR_RANGE)
+ return;
+
+ closure->modes += drm_dmt_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
}
static int
--8<---cut here---end--->8---
With a kernel from this commit nouveau sets up a resolution of
1400x1050; kernels built from commits cffd754 and fc48f16 complain about
an invalid EDID and use the 1024x768 fallback.
Attached is the /sys/class/drm/card0-DVI-I-1/edid 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>
[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: --- 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 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 the booting sequence. As previously, the only thing that can be done at that point is to hard reset. My laptop has a dual graphics card and switching to the intel embedded one in the BIOS makes the system boot fine, but switching to the nvidia one makes the system unable to boot unless ACPI is switched off. I am still able to boot fine with kernels 3.1.x and below. -- 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
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 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/attachments/20120625/fcefe1ec/attachment.pgp>
[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: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: unicorp99 at hotbox.ru Regression: Yes i5 8GB 8600gt_512MB nouveau ubuntu 12.04 i386 vmware 8.0.4, kde, virtualbox 4.1.18, firefox, chrome, chromium, opera, dolphin, smplayer after one-two hours in kernel 3.4.3, 3.4.4 "[TTM] Out of kernel memory", all windows switch slows down. In /var/log/system many messages in second "[TTM] Out of kernel memory" on generic-pae 3.2.0-26.41 (3.2.19) all norm in three days running may be vmware nouveau 3D bug: [TTM] Out of kernel memory? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
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 http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 commented on bogus modes when the patch first went into dcn, but to repeat - HDMI TV - lots of new modes but it already advertised all the CVT that it supports and all the new are bogus. DVI 120Hz 1920x1080 monitor many bogus modes as it won't display > it's res and won't scale up some of the new modes. Even some of the new ones that are not "out of range" will actually end up setting something different and show some distortion. Maybe gained a couple. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 xrandr --newmode / --addmode is > > unreasonably burdensome. > > > > This should fix a number of reported regressions, please test. > > Does not help in my case, unfortunately: instead of a bogus 1680x945 > resolution I get a bogus 1400x1050 rather than the correct 1280x1024. > > Going to try Takashi's patch instead. Takashi's patch will promite 1280x1024 to the default - which is correct - but you'll still see a 1400x1050 in the mode list, because your monitor claims a maximum pixel clock of 140MHz and maximum hsync of 81kHz, and 1400x1050 at 60 fits in that. Fixing that would probably require additional quirk work to add "preferred mode is physical pixel size". EDID 1.4 redefines the "first detailed mode is preferred" bit to mean that anyway, but we're not currently using that to filter the mode 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>
[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: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: cme3...@gmail.com sin is broken with negative values it just renders on the right side of the screen in shaders like http://glsl.heroku.com/e#2465.1 cos seems to be broken, too, just replace sin with cos on that web page. mesa: git-d105654 OS: Debian unstable, kernel 3.4 -- 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: 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 possible. Problem is that 1280x1024@60 looks worse, so I'd like to get the 75 Hz back. >> The xrandr command shows various bogus modes. > > Can't these values be displayed on your monitor at all? It's a TFT LCD with 1280x1024 pixels. Cheers, Sven ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 1280 x 1024, maximum 8192 x 8192
> | DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
> 376mm x 301mm
> |1280x1024 75.0*60.0
> |1024x768 75.1 75.0 70.1 60.0
> |832x62474.6
> |800x60072.2 75.0 60.3 56.2
> |640x48072.8 75.0 66.7 60.0 59.9
> | VGA-1 disconnected (normal left inverted right x axis y axis)
> `
>
> I should note that the monitor is actually connected via VGA, not DVI.
> This seems to be similar to https://bugs.freedesktop.org/50830, but
> since it never caused any real problems for me, I didn't bother.
>
> > 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...
> 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.
Takashi
> ,
> | Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
> | DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
> 376mm x 301mm
> |1280x1024 60.0*+ 75.0
> |1680x945 60.0
> |1400x1050 60.0
> |1600x900 60.0
> |1440x900 75.0 59.9
> |1280x960 60.0
> |1366x768 60.0
> |1360x768 60.0
> |1280x800 74.9 59.8
> |1152x864 75.0
> |1280x768 74.9 59.9
> |1024x768 75.1 75.0 70.1 60.0
> |1024x576 60.0
> |832x62474.6
> |800x60072.2 75.0 60.3 56.2
> |848x48060.0
> |640x48075.0 72.8 72.8 66.7 60.0 59.9
> | VGA-1 disconnected (normal left inverted right x axis y axis)
> `
>
> Cheers,
>Sven
>
>
> > ---
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 5873e48..dab8580 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -116,6 +116,7 @@ static struct edid_quirk {
> >
> > /* Proview AY765C */
> > { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> > + { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> >
> > /* Samsung SyncMaster 205BW. Note: irony */
> > { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
> > @@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void
> > *c)
> > if (!newmode)
> > return;
> >
> > - if (closure->preferred)
> > + if (closure->preferred ||
> > + ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
> > +!closure->modes))
> > newmode->type |= DRM_MODE_TYPE_PREFERRED;
> >
> > drm_mode_probed_add(closure->connector, newmode);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 would eliminate. - ajax 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
[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 | 66 ---
1 files changed, 13 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4a3e61a..e198325 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1081,44 +1081,16 @@ static void fixup_mode_1366x768(struct drm_display_mode
*mode)
}
static int
-drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
- struct detailed_timing *timing)
-{
- int i, modes = 0;
- struct drm_display_mode *newmode;
- struct drm_device *dev = connector->dev;
-
- for (i = 0; i < num_extra_modes; i++) {
- const struct minimode *m = &extra_modes[i];
- newmode = drm_gtf_mode(dev, m->w, m->h, m->r, 0, 0);
- if (!newmode)
- return modes;
-
- fixup_mode_1366x768(newmode);
- if (!mode_in_range(newmode, edid, timing)) {
- drm_mode_destroy(dev, newmode);
- continue;
- }
-
- drm_mode_probed_add(connector, newmode);
- modes++;
- }
-
- return modes;
-}
-
-static int
-drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
- struct detailed_timing *timing)
+drm_extra_modes_for_range(struct drm_connector *connector, struct edid *edid,
+ struct detailed_timing *timing)
{
int i, modes = 0;
struct drm_display_mode *newmode;
struct drm_device *dev = connector->dev;
- bool rb = drm_monitor_supports_rb(edid);
for (i = 0; i < num_extra_modes; i++) {
const struct minimode *m = &extra_modes[i];
- newmode = drm_cvt_mode(dev, m->w, m->h, m->r, rb, 0, 0);
+ newmode = drm_cvt_mode(dev, m->w, m->h, m->r, true, 0, 0);
if (!newmode)
return modes;
@@ -1140,7 +1112,6 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
- struct detailed_data_monitor_range *range = &data->data.range;
if (data->type != EDID_DETAIL_MONITOR_RANGE)
return;
@@ -1149,28 +1120,17 @@ do_inferred_modes(struct detailed_timing *timing, void
*c)
closure->edid,
timing);
- if (!version_greater(closure->edid, 1, 1))
- return; /* GTF not defined yet */
-
- switch (range->flags) {
- case 0x02: /* secondary gtf, XXX could do more */
- case 0x00: /* default gtf */
- closure->modes += drm_gtf_modes_for_range(closure->connector,
- closure->edid,
- timing);
- break;
- case 0x04: /* cvt, only in 1.4+ */
- if (!version_greater(closure->edid, 1, 3))
- break;
+ /* Don't look at extra_modes for pre-CVT-era displays */
+ if (!version_greater(closure->edid, 1, 2))
+ return; /* CVT not defined yet */
- closure->modes += drm_cvt_modes_for_range(closure->connector,
- closure->edid,
- timing);
- break;
- case 0x01: /* just the ranges, no formula */
- default:
- break;
- }
+ /* Don't look at extra_modes for non-rb displays */
+ if (!drm_monitor_supports_rb(closure->edid))
+ return;
+
+ closure->modes += drm_extra_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
}
static int
--
1.7.7.6
[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 @@ -1007,8 +1007,15 @@ range_pixel_clock(struct edid *edid, u8 *t) if (edid->revision >= 4 && t[10] == 0x04) return (t[9] * 1) - ((t[12] >> 2) * 250); - /* 1.3 is pathetic, so fuzz up a bit */ - return t[9] * 1 + 5001; + /* +* Otherwise we have only 10MHz granularity. If we were using this +* code to filter an EDID mode list we'd want to round up like +* xserver does, as it's common to see a max of 160MHz but a 162MHz +* 1600x1200 mode as the preferred timing. But since we're using +* this as a filter while _building_ the list from implied support, +* not rounding up is the safe thing. +*/ + return t[9] * 1; } static bool -- 1.7.7.6
[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, please test. - ajax
[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
Signed-off-by: Subash Patel
CC: dri-devel at lists.freedesktop.org
CC: linux-samsung-soc at vger.kernel.org
CC: linaro-mm-sig at lists.linaro.org
CC: inki.dae at samsung.com
CC: airlied at redhat.com
CC: olofj at chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 52cf761..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -245,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR(sgt)) {
+ if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
--
1.7.9.5
[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 return NULL on failure.
Change-Id: I541ed30491a926ebe72738225041c9f2d88007bc
Signed-off-by: Subash Patel
CC: dri-devel at lists.freedesktop.org
CC: linux-samsung-soc at vger.kernel.org
CC: linaro-mm-sig at lists.linaro.org
CC: inki.dae at samsung.com
CC: airlied at redhat.com
CC: olofj at chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..52cf761 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf->size / buf->page_size;
sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
+ if (!sgt) {
+ DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
+ goto err_unlock;
+ }
nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
--
1.7.9.5
[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 occurs when the system is under memory pressure. Scatter-gather asks for memory using sg_kmalloc() and this can return no memory. Without below return value checks, the code will crash the system due to invalid pointer access. Subash Patel (2): DRM: Exynos: return NULL if exynos_pages_to_sg fails DRM: Exynos: check for null in return value of dma_buf_map_attachment() drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 1.7.9.5
[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
Signed-off-by: Subash Patel
CC: dri-devel at lists.freedesktop.org
CC: linux-samsung-soc at vger.kernel.org
CC: linaro-mm-sig at lists.linaro.org
CC: inki.dae at samsung.com
CC: airlied at redhat.com
CC: olofj at chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 52cf761..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -245,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR(sgt)) {
+ if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
--
1.7.9.5
[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 return NULL on failure.
Change-Id: I541ed30491a926ebe72738225041c9f2d88007bc
Signed-off-by: Subash Patel
CC: dri-devel at lists.freedesktop.org
CC: linux-samsung-soc at vger.kernel.org
CC: linaro-mm-sig at lists.linaro.org
CC: inki.dae at samsung.com
CC: airlied at redhat.com
CC: olofj at chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..52cf761 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf->size / buf->page_size;
sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
+ if (!sgt) {
+ DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
+ goto err_unlock;
+ }
nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
--
1.7.9.5
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 5 > > in my messages. > Nothing like that before (3.4.0-vanilla), and 3.5.0-rc4 not yet compiled. > > Anything I should check and/or report to help ? Nope, everything works as expected. This is purely an informational message (and we might need to create a patch to make it go away on non-debug settings). -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
[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 Wheezy. But now I see it is not mentioned in the .h files in libdrm-2.4.33. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
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 xrandr --newmode / --addmode is > > unreasonably burdensome. > > > > This should fix a number of reported regressions, please test. > > Does not help in my case, unfortunately: instead of a bogus 1680x945 > resolution I get a bogus 1400x1050 rather than the correct 1280x1024. > > Going to try Takashi's patch instead. Takashi's patch will promite 1280x1024 to the default - which is correct - but you'll still see a 1400x1050 in the mode list, because your monitor claims a maximum pixel clock of 140MHz and maximum hsync of 81kHz, and 1400x1050@60 fits in that. Fixing that would probably require additional quirk work to add "preferred mode is physical pixel size". EDID 1.4 redefines the "first detailed mode is preferred" bit to mean that anyway, but we're not currently using that to filter the mode list. - ajax 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
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 (normal left inverted right x axis y axis)
376mm x 301mm
|1280x1024 75.0*60.0
|1024x768 75.1 75.0 70.1 60.0
|832x62474.6
|800x60072.2 75.0 60.3 56.2
|640x48072.8 75.0 66.7 60.0 59.9
| VGA-1 disconnected (normal left inverted right x axis y axis)
`
I should note that the monitor is actually connected via VGA, not DVI.
This seems to be similar to https://bugs.freedesktop.org/50830, but
since it never caused any real problems for me, I didn't bother.
> And, does the patch below help?
Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz.
The xrandr command shows various bogus modes.
,
| Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
| DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis)
376mm x 301mm
|1280x1024 60.0*+ 75.0
|1680x945 60.0
|1400x1050 60.0
|1600x900 60.0
|1440x900 75.0 59.9
|1280x960 60.0
|1366x768 60.0
|1360x768 60.0
|1280x800 74.9 59.8
|1152x864 75.0
|1280x768 74.9 59.9
|1024x768 75.1 75.0 70.1 60.0
|1024x576 60.0
|832x62474.6
|800x60072.2 75.0 60.3 56.2
|848x48060.0
|640x48075.0 72.8 72.8 66.7 60.0 59.9
| VGA-1 disconnected (normal left inverted right x axis y axis)
`
Cheers,
Sven
> ---
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5873e48..dab8580 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -116,6 +116,7 @@ static struct edid_quirk {
>
> /* Proview AY765C */
> { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> + { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> /* Samsung SyncMaster 205BW. Note: irony */
> { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
> @@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void
> *c)
> if (!newmode)
> return;
>
> - if (closure->preferred)
> + if (closure->preferred ||
> + ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
> + !closure->modes))
> newmode->type |= DRM_MODE_TYPE_PREFERRED;
>
> drm_mode_probed_add(closure->connector, newmode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 3.5.0-rc4 not yet compiled. Anything I should check and/or report to help ? Best Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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. > > This should fix a number of reported regressions, please test. Does not help in my case, unfortunately: instead of a bogus 1680x945 resolution I get a bogus 1400x1050 rather than the correct 1280x1024. Going to try Takashi's patch instead. Cheers, Sven ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 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
> since we didn't unmap the buffer as dqbuf was never called.
>
> The below patch adds calls to unmap in queue_cancel, but my feeling is
> that we
> probably should be calling detach too (i.e. put_dmabuf).
>
> Thoughts?
>
> --Dima
>
> Subject: [PATCH] v4l: vb2: unmap dmabufs on STREAM_OFF event
>
> Currently, if the user issues a STREAM_OFF request and then
> tries to re-enqueue buffers, it will trigger a warning in
> the vb2 allocators as the buffer would still be mapped
> from before STREAM_OFF was called. The current expectation
> is that buffers will be unmapped in dqbuf, but that will never
> be called on the mapped buffers after a STREAM_OFF event.
>
> Cc: Sumit Semwal
> Cc: Tomasz Stanislawski
> Signed-off-by: Dima Zavin
> ---
> drivers/media/video/videobuf2-core.c | 22 --
> 1 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c
> index b431dc6..e2a8f12 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -1592,8 +1592,26 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
>/*
> * Reinitialize all buffers for next use.
> */
> - for (i = 0; i < q->num_buffers; ++i)
> - q->bufs[i]->state = VB2_BUF_STATE_DEQUEUED;
> + for (i = 0; i < q->num_buffers; ++i) {
> + struct vb2_buffer *vb = q->bufs[i];
> + int plane;
> +
> + vb->state = VB2_BUF_STATE_DEQUEUED;
> +
> + if (q->memory != V4L2_MEMORY_DMABUF)
> + continue;
> +
> + for (plane = 0; plane < vb->num_planes; ++plane) {
> + struct vb2_plane *p = &vb->planes[plane];
> +
> + if (!p->mem_priv)
> + continue;
> + if (p->dbuf_mapped) {
> + call_memop(q, unmap_dmabuf, p->mem_priv);
> + p->dbuf_mapped = 0;
> + }
> + }
> + }
> }
>
> /**
> --
> 1.7.7.3
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)
ping?
On Tue, Jun 19, 2012 at 11:12 PM, Dima Zavin 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
> since we didn't unmap the buffer as dqbuf was never called.
>
> The below patch adds calls to unmap in queue_cancel, but my feeling is
> that we
> probably should be calling detach too (i.e. put_dmabuf).
>
> Thoughts?
>
> --Dima
>
> Subject: [PATCH] v4l: vb2: unmap dmabufs on STREAM_OFF event
>
> Currently, if the user issues a STREAM_OFF request and then
> tries to re-enqueue buffers, it will trigger a warning in
> the vb2 allocators as the buffer would still be mapped
> from before STREAM_OFF was called. The current expectation
> is that buffers will be unmapped in dqbuf, but that will never
> be called on the mapped buffers after a STREAM_OFF event.
>
> Cc: Sumit Semwal
> Cc: Tomasz Stanislawski
> Signed-off-by: Dima Zavin
> ---
> drivers/media/video/videobuf2-core.c | 22 --
> 1 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c
> index b431dc6..e2a8f12 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -1592,8 +1592,26 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
>/*
> * Reinitialize all buffers for next use.
> */
> - for (i = 0; i < q->num_buffers; ++i)
> - q->bufs[i]->state = VB2_BUF_STATE_DEQUEUED;
> + for (i = 0; i < q->num_buffers; ++i) {
> + struct vb2_buffer *vb = q->bufs[i];
> + int plane;
> +
> + vb->state = VB2_BUF_STATE_DEQUEUED;
> +
> + if (q->memory != V4L2_MEMORY_DMABUF)
> + continue;
> +
> + for (plane = 0; plane < vb->num_planes; ++plane) {
> + struct vb2_plane *p = &vb->planes[plane];
> +
> + if (!p->mem_priv)
> + 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 your card was only added in libdrm_radeon 2.4.34. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
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 comment:
/* Monitor forgot to set the first detailed is preferred bit. */
#define EDID_QUIRK_FIRST_DETAILED_PREFERRED (1 << 5)
Adam, is my interpretation correct?
Takashi
>
>
> Takashi
>
> ---
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5873e48..dab8580 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -116,6 +116,7 @@ static struct edid_quirk {
>
> /* Proview AY765C */
> { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> + { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> /* Samsung SyncMaster 205BW. Note: irony */
> { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
> @@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void
> *c)
> if (!newmode)
> return;
>
> - if (closure->preferred)
> + if (closure->preferred ||
> + ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
> + !closure->modes))
> newmode->type |= DRM_MODE_TYPE_PREFERRED;
>
> drm_mode_probed_add(closure->connector, newmode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 looks terrible.
>
> Bisecting shows that the problem started with commit cb21aafe1:
>
> --8<---cut here---start->8---
> commit cb21aafe121b1c3ad4c77cc5c22320163f16ba42
> Author: Adam Jackson
> Date: Fri Apr 13 16:33:36 2012 -0400
>
> drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types
>
> EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
> continuous frequency", and moves the set of supported timing formulas
> into the range descriptor itself. In any event, the range descriptor
> can act as a filter on the DMT list without regard to a specific timing
> formula.
>
> Signed-off-by: Adam Jackson
> Tested-by: Takashi Iwai
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Dave Airlie
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index cb40611..9363349 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1042,12 +1042,13 @@ do_inferred_modes(struct detailed_timing *timing,
> void *c)
> {
> struct detailed_mode_closure *closure = c;
> struct detailed_non_pixel *data = &timing->data.other_data;
> - int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
>
> - if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
> - closure->modes += drm_dmt_modes_for_range(closure->connector,
> - closure->edid,
> - timing);
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + return;
> +
> + closure->modes += drm_dmt_modes_for_range(closure->connector,
> + closure->edid,
> + timing);
> }
>
> static int
> --8<---cut here---end--->8---
>
> With a kernel from this commit nouveau sets up a resolution of
> 1400x1050; kernels built from commits cffd754 and fc48f16 complain about
> an invalid EDID and use the 1024x768 fallback.
>
> Attached is the /sys/class/drm/card0-DVI-I-1/edid file from a working
> kernel; in 3.5-rc4 it is identical.
Looking at the EDID data, the problem is likely that your monitor
doesn't give the proper preferred mode.
What does xrandr output show?
And, does the patch below help?
Takashi
---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5873e48..dab8580 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -116,6 +116,7 @@ static struct edid_quirk {
/* Proview AY765C */
{ "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
+ { "PTS", 793, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
/* Samsung SyncMaster 205BW. Note: irony */
{ "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
@@ -1404,7 +1405,9 @@ do_detailed_mode(struct detailed_timing *timing, void *c)
if (!newmode)
return;
- if (closure->preferred)
+ if (closure->preferred ||
+ ((closure->quirks & EDID_QUIRK_FIRST_DETAILED_PREFERRED) &&
+!closure->modes))
newmode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(closure->connector, newmode);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 | 66 ---
1 files changed, 13 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4a3e61a..e198325 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1081,44 +1081,16 @@ static void fixup_mode_1366x768(struct drm_display_mode
*mode)
}
static int
-drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
- struct detailed_timing *timing)
-{
- int i, modes = 0;
- struct drm_display_mode *newmode;
- struct drm_device *dev = connector->dev;
-
- for (i = 0; i < num_extra_modes; i++) {
- const struct minimode *m = &extra_modes[i];
- newmode = drm_gtf_mode(dev, m->w, m->h, m->r, 0, 0);
- if (!newmode)
- return modes;
-
- fixup_mode_1366x768(newmode);
- if (!mode_in_range(newmode, edid, timing)) {
- drm_mode_destroy(dev, newmode);
- continue;
- }
-
- drm_mode_probed_add(connector, newmode);
- modes++;
- }
-
- return modes;
-}
-
-static int
-drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
- struct detailed_timing *timing)
+drm_extra_modes_for_range(struct drm_connector *connector, struct edid *edid,
+ struct detailed_timing *timing)
{
int i, modes = 0;
struct drm_display_mode *newmode;
struct drm_device *dev = connector->dev;
- bool rb = drm_monitor_supports_rb(edid);
for (i = 0; i < num_extra_modes; i++) {
const struct minimode *m = &extra_modes[i];
- newmode = drm_cvt_mode(dev, m->w, m->h, m->r, rb, 0, 0);
+ newmode = drm_cvt_mode(dev, m->w, m->h, m->r, true, 0, 0);
if (!newmode)
return modes;
@@ -1140,7 +1112,6 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
- struct detailed_data_monitor_range *range = &data->data.range;
if (data->type != EDID_DETAIL_MONITOR_RANGE)
return;
@@ -1149,28 +1120,17 @@ do_inferred_modes(struct detailed_timing *timing, void
*c)
closure->edid,
timing);
- if (!version_greater(closure->edid, 1, 1))
- return; /* GTF not defined yet */
-
- switch (range->flags) {
- case 0x02: /* secondary gtf, XXX could do more */
- case 0x00: /* default gtf */
- closure->modes += drm_gtf_modes_for_range(closure->connector,
- closure->edid,
- timing);
- break;
- case 0x04: /* cvt, only in 1.4+ */
- if (!version_greater(closure->edid, 1, 3))
- break;
+ /* Don't look at extra_modes for pre-CVT-era displays */
+ if (!version_greater(closure->edid, 1, 2))
+ return; /* CVT not defined yet */
- closure->modes += drm_cvt_modes_for_range(closure->connector,
- closure->edid,
- timing);
- break;
- case 0x01: /* just the ranges, no formula */
- default:
- break;
- }
+ /* Don't look at extra_modes for non-rb displays */
+ if (!drm_monitor_supports_rb(closure->edid))
+ return;
+
+ closure->modes += drm_extra_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
}
static int
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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, please test. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 @@ -1007,8 +1007,15 @@ range_pixel_clock(struct edid *edid, u8 *t) if (edid->revision >= 4 && t[10] == 0x04) return (t[9] * 1) - ((t[12] >> 2) * 250); - /* 1.3 is pathetic, so fuzz up a bit */ - return t[9] * 1 + 5001; + /* +* Otherwise we have only 10MHz granularity. If we were using this +* code to filter an EDID mode list we'd want to round up like +* xserver does, as it's common to see a max of 160MHz but a 162MHz +* 1600x1200 mode as the preferred timing. But since we're using +* this as a filter while _building_ the list from implied support, +* not rounding up is the safe thing. +*/ + return t[9] * 1; } static bool -- 1.7.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: unicor...@hotbox.ru Regression: Yes i5 8GB 8600gt_512MB nouveau ubuntu 12.04 i386 vmware 8.0.4, kde, virtualbox 4.1.18, firefox, chrome, chromium, opera, dolphin, smplayer after one-two hours in kernel 3.4.3, 3.4.4 "[TTM] Out of kernel memory", all windows switch slows down. In /var/log/system many messages in second "[TTM] Out of kernel memory" on generic-pae 3.2.0-26.41 (3.2.19) all norm in three days running may be vmware nouveau 3D bug: [TTM] Out of kernel memory? -- 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
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 commit cb21aafe1:
--8<---cut here---start->8---
commit cb21aafe121b1c3ad4c77cc5c22320163f16ba42
Author: Adam Jackson
Date: Fri Apr 13 16:33:36 2012 -0400
drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-by: Adam Jackson
Tested-by: Takashi Iwai
Reviewed-by: Rodrigo Vivi
Signed-off-by: Dave Airlie
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cb40611..9363349 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1042,12 +1042,13 @@ do_inferred_modes(struct detailed_timing *timing, void
*c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
- int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
- if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
- closure->modes += drm_dmt_modes_for_range(closure->connector,
- closure->edid,
- timing);
+ if (data->type != EDID_DETAIL_MONITOR_RANGE)
+ return;
+
+ closure->modes += drm_dmt_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
}
static int
--8<---cut here---end--->8---
With a kernel from this commit nouveau sets up a resolution of
1400x1050; kernels built from commits cffd754 and fc48f16 complain about
an invalid EDID and use the 1024x768 fallback.
Attached is the /sys/class/drm/card0-DVI-I-1/edid file from a working
kernel; in 3.5-rc4 it is identical.
Cheers,
Sven
edid
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 :
> 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 return NULL on failure.
>
> Signed-off-by: Subash Patel
> CC: dri-devel@lists.freedesktop.org
> CC: linux-samsung-...@vger.kernel.org
> CC: linaro-mm-...@lists.linaro.org
> CC: inki@samsung.com
> CC: airl...@redhat.com
> CC: ol...@chromium.org
> ---
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index 97325c1..c908a29 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -87,6 +87,10 @@ static struct sg_table *
> npages = buf->size / buf->page_size;
>
> sgt = exynos_pages_to_sg(buf->pages, npages, buf->page_size);
> + if (!sgt) {
> + DRM_DEBUG_PRIME("exynos_pages_to_sg returned NULL!\n");
> + goto err_unlock;
> + }
> nents = dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
>
> DRM_DEBUG_PRIME("npages = %d buffer size = 0x%lx page_size = 0x%lx\n",
> @@ -241,7 +245,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
> drm_device *drm_dev,
>
>
> sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> - if (IS_ERR(sgt)) {
> + if (IS_ERR_OR_NULL(sgt)) {
> ret = PTR_ERR(sgt);
> goto err_buf_detach;
> }
> --
> 1.7.9.5
>
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 Wheezy. But now I see it is not mentioned in the .h files in libdrm-2.4.33. -- 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 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 your card was only added in libdrm_radeon 2.4.34. -- 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 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 radeon_surface_best failed radeon_setup_kernel_mem failed Configuration (current Debian Wheezy): Radeon 7570 card - PCI identifier 675D Kernel: 3.2.0-2-amd64 xserver-xorg-video-radeon: 6.14.4-5 libdrm-radeon1 & libdrm2: 2.4.33-1 /etc/X11/xorg.conf.d: Does not contain a Device section. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
