Re: [Nouveau] [PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()
On Mon, Nov 10, 2014 at 11:39 PM, Daniel Vetter wrote:
> Hi Ben,
>
> The below patch from Jani also touches nouveau, can you please take a
> look at it an ack? The core part + nouveau apply on top of drm-next,
> the i915 part needs stuff from my next queue. So I'd prefer if we can
> get this in through drm-intel-next.
>
> Hi Dave,
>
> Ack on that from your side?
>
> Cheers, Daniel
>
> On Tue, Oct 28, 2014 at 3:20 PM, Jani Nikula wrote:
>> The Baseline_ELD_Len field does not include ELD Header Block size.
>>
>> From High Definition Audio Specification, Revision 1.0a:
>>
>> The header block is a fixed size of 4 bytes. The baseline block
>> is variable size in multiple of 4 bytes, and its size is defined
>> in the header block Baseline_ELD_Len field (in number of
>> DWords).
>>
>> Do not include the header size in Baseline_ELD_Len field. Fix all known
>> users of eld[2].
>>
>> While at it, switch to DIV_ROUND_UP instead of open coding it.
>>
>> Signed-off-by: Jani Nikula
Acked-by: Ben Skeggs
>>
>> ---
>>
>> This is based on an audio rework series which is mid-way being merged to
>> i915. I don't think this should be cc: stable worthy, as, AFAICT, we
>> don't use the vendor block, and anyone reading SADs respecting SAD_Count
>> should stop at the same offset regardless of this patch. So I propose
>> this gets eventually merged via i915 without a rush.
>> ---
>> drivers/gpu/drm/drm_edid.c | 7 +--
>> drivers/gpu/drm/i915/intel_audio.c | 16
>> drivers/gpu/drm/nouveau/nv50_display.c | 3 ++-
>> 3 files changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 3bf999134bcc..45aaa6f5ef36 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3128,9 +3128,12 @@ void drm_edid_to_eld(struct drm_connector *connector,
>> struct edid *edid)
>> }
>> }
>> eld[5] |= sad_count << 4;
>> - eld[2] = (20 + mnl + sad_count * 3 + 3) / 4;
>>
>> - DRM_DEBUG_KMS("ELD size %d, SAD count %d\n", (int)eld[2], sad_count);
>> + eld[DRM_ELD_BASELINE_ELD_LEN] =
>> + DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
>> +
>> + DRM_DEBUG_KMS("ELD size %d, SAD count %d\n",
>> + drm_eld_size(eld), sad_count);
>> }
>> EXPORT_SYMBOL(drm_edid_to_eld);
>>
>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> index 20af973d7cba..439fa4afa18b 100644
>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>> @@ -107,7 +107,7 @@ static bool intel_eld_uptodate(struct drm_connector
>> *connector,
>> tmp &= ~bits_elda;
>> I915_WRITE(reg_elda, tmp);
>>
>> - for (i = 0; i < eld[2]; i++)
>> + for (i = 0; i < drm_eld_size(eld) / 4; i++)
>> if (I915_READ(reg_edid) != *((uint32_t *)eld + i))
>> return false;
>>
>> @@ -162,7 +162,7 @@ static void g4x_audio_codec_enable(struct drm_connector
>> *connector,
>> len = (tmp >> 9) & 0x1f;/* ELD buffer size */
>> I915_WRITE(G4X_AUD_CNTL_ST, tmp);
>>
>> - len = min_t(int, eld[2], len);
>> + len = min(drm_eld_size(eld) / 4, len);
>> DRM_DEBUG_DRIVER("ELD size %d\n", len);
>> for (i = 0; i < len; i++)
>> I915_WRITE(G4X_HDMIW_HDMIEDID, *((uint32_t *)eld + i));
>> @@ -209,7 +209,7 @@ static void hsw_audio_codec_enable(struct drm_connector
>> *connector,
>> int len, i;
>>
>> DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
>> - pipe_name(pipe), eld[2]);
>> + pipe_name(pipe), drm_eld_size(eld));
>>
>> /* Enable audio presence detect, invalidate ELD */
>> tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
>> @@ -225,8 +225,8 @@ static void hsw_audio_codec_enable(struct drm_connector
>> *connector,
>> I915_WRITE(HSW_AUD_DIP_ELD_CTRL(pipe), tmp);
>>
>> /* Up to 84 bytes of hw ELD buffer */
>> - len = min_t(int, eld[2], 21);
>> - for (i = 0; i < len; i++)
>> + len = min(drm_eld_size(eld), 84);
>> + for (i = 0; i < len / 4; i++)
>> I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((uint32_t *)eld + i));
>>
>> /* ELD valid */
>> @@ -315,7 +315,7 @@ static void ilk_audio_codec_enable(struct drm_connector
>> *connector,
>> int aud_cntrl_st2;
>>
>> DRM_DEBUG_KMS("Enable audio codec on port %c, pipe %c, %u bytes
>> ELD\n",
>> - port_name(port), pipe_name(pipe), eld[2]);
>> + port_name(port), pipe_name(pipe), drm_eld_size(eld));
>>
>> /* XXX: vblank wait here */
>>
>> @@ -354,8 +354,8 @@ static void ilk_audio_codec_enable(struct drm_connector
>> *connector,
>> I915_WRITE(aud_cntl_st, tmp);
>>
>> /* Up to 84 bytes of hw ELD buffer */
>> -
[Nouveau] [Bug 85160] [NV94] INVALID_STATE error, X fails to start on GeForce 9600 GT with dual monitors, kernels 3.18.0-0.rc0.git8.2.fc22.1 onwards
https://bugs.freedesktop.org/show_bug.cgi?id=85160 --- Comment #24 from Roy --- (In reply to poma from comment #23) > Created attachment 109248 [details] > dmesg-3.18.0-0.rc4.git0.1.fc22.x86_64-NV50 That's not surprising given this fix was not merged in that tree. Please be patient, we'll get the fix in (or a different one if new data pops up) before 3.18 gets released. -- You are receiving this mail because: You are the QA Contact for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 85160] [NV94] INVALID_STATE error, X fails to start on GeForce 9600 GT with dual monitors, kernels 3.18.0-0.rc0.git8.2.fc22.1 onwards
https://bugs.freedesktop.org/show_bug.cgi?id=85160 poma changed: What|Removed |Added QA Contact|xorg-t...@lists.x.org |nouveau@lists.freedesktop.o ||rg -- You are receiving this mail because: You are the QA Contact for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nv50/disp: Fix modeset on G94
On 31.10.2014 11:28, Roy Spliet wrote:
>
> --- Ursprüngliche Nachricht ---
> Von: Ben Skeggs
> Datum: 00:52:05 31-10-2014
> An: Ilia Mirkin
> Betreff: Re: [Nouveau] [PATCH] nv50/disp: Fix modeset on G94
>
>> On Fri, Oct 31, 2014 at 8:00 AM, Ilia Mirkin
>> wrote:
>>> On Thu, Oct 30, 2014 at 5:57 PM, Roy Spliet
>> wrote:
Commit 1dce6264045cd23e9c07574ed0bb31c7dce9354f introduced a regression
>> spotted
on several G94 (FDObz #85160). This device seems to expect the vblank
>> period to
>>>
>>> I believe that's often done as a
>>>
>>> Bugzilla: https://bugs.freedesktop.org/bla
>>>
>>> annotation
>>>
be set after setting scale instead of before.
V2: shove this in a separate function
This is a candidate bug-fix for 3.18
Signed-off-by: Roy Spliet
Tested-by: Zlatko Calusic
Tested-by: Michael Riesch
Tested-by: "poma"
Tested-by: Adam Williamson
---
drivers/gpu/drm/nouveau/nv50_display.c | 26 --
>>
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
>>
index ae873d1..2f24a08 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -791,6 +791,23 @@ nv50_crtc_set_scale(struct nouveau_crtc *nv_crtc,
>> bool update)
}
static int
+nv50_crtc_set_raster_vblank_dmi(struct nouveau_crtc *nv_crtc, u32
>> usec)
>>>
>>> What's "dmi"?
>> SetRasterVertBlankDmi is the name of method 0x828. I presume it's
>> Display Memory Interface or something to that effect.
>>
>>>
+{
+ struct nv50_mast *mast = nv50_mast(nv_crtc->base.dev);
>>
+ u32 *push;
+
+ push = evo_wait(mast, 8);
>>>
>>> Just needs to be 2, no?
>> Yes, doesn't matter too much though.
> If it is, we might need to fix nv50_crtc_mode_set() too; it seems to assume
> the second parameter in evo_wait() is bytes, not words.
>
>>
>>>
+ if (!push)
+ return -ENOMEM;
+
+ evo_mthd(push, 0x0828 + (nv_crtc->index * 0x400), 1);
>>
+ evo_data(push, usec);
+ evo_kick(push, mast);
+
+ return 0;
+}
+
+static int
nv50_crtc_set_color_vibrance(struct nouveau_crtc *nv_crtc, bool
>> update)
{
struct nv50_mast *mast = nv50_mast(nv_crtc->base.dev);
>>
@@ -1104,14 +1121,14 @@ nv50_crtc_mode_set(struct drm_crtc *crtc,
>> struct drm_display_mode *umode,
evo_mthd(push, 0x0804 + (nv_crtc->index
>> * 0x400), 2);
evo_data(push, 0x0080 | mode->clock);
>>
evo_data(push, (ilace == 2) ? 2 : 0);
- evo_mthd(push, 0x0810 + (nv_crtc->index
>> * 0x400), 8);
+ evo_mthd(push, 0x0810 + (nv_crtc->index
>> * 0x400), 6);
evo_data(push, 0x);
evo_data(push, (vactive << 16) | hactive);
>>
evo_data(push, ( vsynce << 16) | hsynce);
>>
evo_data(push, (vblanke << 16) | hblanke);
>>
evo_data(push, (vblanks << 16) | hblanks);
>>
evo_data(push, (vblan2e << 16) | vblan2s);
>>
- evo_data(push, vblankus);
+ evo_mthd(push, 0x082c + (nv_crtc->index
>> * 0x400), 1);
evo_data(push, 0x);
evo_mthd(push, 0x0900 + (nv_crtc->index
>> * 0x400), 2);
evo_data(push, 0x0311);
@@ -1141,6 +1158,11 @@ nv50_crtc_mode_set(struct drm_crtc *crtc,
>> struct drm_display_mode *umode,
nv_connector = nouveau_crtc_connector_get(nv_crtc);
nv50_crtc_set_dither(nv_crtc, false);
nv50_crtc_set_scale(nv_crtc, false);
+
+ /* G94 only accepts this after setting scale */
+ if (nv50_vers(mast) < GF110_DISP_CORE_CHANNEL_DMA)
+ nv50_crtc_set_raster_vblank_dmi(nv_crtc, vblankus);
>>
+
nv50_crtc_set_color_vibrance(nv_crtc, false);
nv50_crtc_set_image(nv_crtc, crtc->primary->fb, x,
>> y, false);
return 0;
--
2.1.0
None of all this&that patches does not work anymore.
poma
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] [NV84] gpu hang on resume from suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #11 from Takashi Iwai --- (In reply to Lars Müller from comment #9) > Created attachment 109236 [details] > Retest S3 after calling: echo 0 > /sys/power/pm_async > > With /sys/power/pm_async set to 0 the system no longer crashes while resume. > > I'm able to ssh into the system but x.org doesn't come back. The two > screens stay black. OK, then I guess you're seeing two distinct issues. One is the broken graphics by S3, and another is the kernel panic due to the stall of disk PM. Disabling async PM seems curing the latter while the graphics remains broken. Could you try to boot with nomodeset boot option in runlevel 3, and try S3, but without pm_async adjustment? The graphics can be broken in this case after S3, but if the system alives, you should be able to remote-login. If S3 crashes even without nouveau, we can check the two issues above completely separately. If S3 crash happens only with nouveau, it implies that the disk problem is somehow related with nouveau problem. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] [NV84] gpu hang on resume from suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #10 from Lars Müller --- Created attachment 109237 --> https://bugs.freedesktop.org/attachment.cgi?id=109237&action=edit dmesg output as requested with comment #6 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] [NV84] gpu hang on resume from suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=86115 Lars Müller changed: What|Removed |Added Attachment #109227|0 |1 is obsolete|| --- Comment #9 from Lars Müller --- Created attachment 109236 --> https://bugs.freedesktop.org/attachment.cgi?id=109236&action=edit Retest S3 after calling: echo 0 > /sys/power/pm_async With /sys/power/pm_async set to 0 the system no longer crashes while resume. I'm able to ssh into the system but x.org doesn't come back. The two screens stay black. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain
On Wed, Nov 5, 2014 at 5:23 AM, Alexandre Courbot wrote:
> On 10/30/2014 12:29 AM, Ilia Mirkin wrote:
>>
>> On Mon, Oct 27, 2014 at 6:34 AM, Alexandre Courbot
>> wrote:
>>>
>>> GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
>>> sub-optimal and sometimes even harmful. Set its VRAM domain to
>>> NOUVEAU_BO_GART so all objects are allocated in system memory.
>>>
>>> Signed-off-by: Alexandre Courbot
>>> ---
>>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>>> b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>>> index ac5823e4a8d5..ad143cd9a140 100644
>>> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>>> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>>> @@ -620,6 +620,16 @@ nvc0_screen_create(struct nouveau_device *dev)
>>> return NULL;
>>> pscreen = &screen->base.base;
>>>
>>> + /* Recognize chipsets with no VRAM */
>>> + switch (dev->chipset) {
>>> + /* GK20A */
>>> + case 0xea:
>>> + screen->base.vram_domain = NOUVEAU_BO_GART;
>>
>>
>> I think you also want to set vidmem_bindings = 0... although
>> potentially after the |= that's done below. Although I guess that
>> constbuf + command args buf need to be |='d into the sysmem_bindings
>> for this to work out well.
>
>
> Thanks for pointing this out ; I didn't know about vidmem_bindings to be
> honest. Will update and resend.
>
> Apart from this detail, are you ok with the changes brought by these
> patches?
I'm not against them... I do wonder a bit if there isn't some better
way of doing this, but in the absence of such a way, this seems fine.
-ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86109] kernel oops after lightdm startup
https://bugs.freedesktop.org/show_bug.cgi?id=86109 Tobias Klausmann changed: What|Removed |Added Attachment #109220|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] [NV84] gpu hang on resume from suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #8 from Takashi Iwai --- (In reply to Takashi Iwai from comment #4) > In order to make things a bit more straight, could you retest S3 after doing: > echo 1 > /sys/power/pm_async > ? Doh, sorry, I wanted to see the result with *disabled* async PM. Lars, please retest with echo 0 > /sys/power/pm_async Certainly there is a GPU hang at PM, but I'd like to know whether it's the real culprit of the whole hang. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] [NV84] gpu hang on resume from suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #7 from Takashi Iwai --- FYI, there are a few kernel packages available in OBS home:tiwai:kernel:3.13, home:tiwai:kernel:3.14, and home:tiwai:kernel:3.15 repos. For 3.12, you can use OBS Kernel:SLE12. Kernel:stable is for 3.17, and Kernel:HEAD is for 3.18-rc. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] [NV84] gpu hang on resume from suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=86115 Ilia Mirkin changed: What|Removed |Added Summary|Suspend to RAM fails when |[NV84] gpu hang on resume |using Nouveau |from suspend to ram -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #6 from Ilia Mirkin --- There was a change which fixed fbcon acceleration after resume -- before it effectively switched into software mode on resume, but that got fixed. Unfortunately if the GPU is unhappy on resume, that means that the console also hangs. Specifically it was commit ecf24de071f4f6cea79ecef5d990794df5875ee1. Could you test a few kernels to see whether it's the same issue you're seeing? e.g. does 3.14 work while 3.15 fails? If so, can you do a bisect to confirm (and if not, also do a bisect to figure out what broke it). git bisect start v3.16 v3.13 -- drivers/gpu/drm/nouveau should cover the whole range you mentioned (3.13 = good, 3.16 = bad). Separately, could you attach a full dmesg after boot? That should answer a number of basic questions about some of your setup's specifics. Additionally, how is your monitor(s) connected? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #5 from Lars Müller --- Created attachment 109227 --> https://bugs.freedesktop.org/attachment.cgi?id=109227&action=edit Retest S3 after calling: echo 1 > /sys/power/pm_async -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #4 from Takashi Iwai --- In order to make things a bit more straight, could you retest S3 after doing: echo 1 > /sys/power/pm_async ? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #3 from Lars Müller --- Created attachment 109224 --> https://bugs.freedesktop.org/attachment.cgi?id=109224&action=edit kernel ooops trace (3.16.6) Add lost kernel ooops trace and more detailes kernel RPM details. kernel-default-3.16.6-2.1.x86_64 Source Timestamp: 2014-10-20 15:47:22 +0200 GIT Revision: feb42eacae8d76252ab69a58d05a0be2cebd8a08 GIT Branch: openSUSE-13.2 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #2 from Lars Müller --- (In reply to Ilia Mirkin from comment #1) > (In reply to Lars Müller from comment #0) > > With the same hardware suspend to memory worked with openSUSE 13.1. > > What kernel is that? 3.11.10 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 --- Comment #1 from Ilia Mirkin --- (In reply to Lars Müller from comment #0) > With the same hardware suspend to memory worked with openSUSE 13.1. What kernel is that? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86115] New: Suspend to RAM fails when using Nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=86115 Bug ID: 86115 Summary: Suspend to RAM fails when using Nouveau Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: l...@samba.org QA Contact: xorg-t...@lists.x.org The system in question has a NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1) graphics card installed. Triggering suspend to memory works but the resume fails and leads to blinking shift and scroll lock keyboard leds. This is a fresh install, no upgrade. With the same hardware suspend to memory worked with openSUSE 13.1. I've also tested kernel-vanilla 3.18.rc3.next.20141106-1.1.g2af2e06 and it shows the same defect as with openSUSE 13.2. Via netconsole I had been able to capture an even more detailed trace with no_console_suspend set. Thanks to Takashi Iwai for his debugging hints. The same initially was reported at the SUSE bug tracked as it was first seen with the openSUSE 13.2 kernel-default. https://bugzilla.suse.com/show_bug.cgi?id=904483 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 86109] New: kernel oops after lightdm startup
https://bugs.freedesktop.org/show_bug.cgi?id=86109 Bug ID: 86109 Summary: kernel oops after lightdm startup Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: etie...@zol.fr QA Contact: xorg-t...@lists.x.org Created attachment 109220 --> https://bugs.freedesktop.org/attachment.cgi?id=109220&action=edit kernel oops photo Since debian testing kernel update from 3.16.2 to 3.16.5 (also reproduced with 3.16.7), I sometimes (~3/4) get a crash few seconds after lightdm launch. It seems to be a reproduction of that (bisected) fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1158061 Hardware name: Sony Corporation VPCZ12L9E/VAIO, BIOS R3031C3 10/04/2011 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) 01:00.0 VGA compatible controller: NVIDIA Corporation GT216M [GeForce GT 330M] (rev a2) thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()
Hi Ben,
The below patch from Jani also touches nouveau, can you please take a
look at it an ack? The core part + nouveau apply on top of drm-next,
the i915 part needs stuff from my next queue. So I'd prefer if we can
get this in through drm-intel-next.
Hi Dave,
Ack on that from your side?
Cheers, Daniel
On Tue, Oct 28, 2014 at 3:20 PM, Jani Nikula wrote:
> The Baseline_ELD_Len field does not include ELD Header Block size.
>
> From High Definition Audio Specification, Revision 1.0a:
>
> The header block is a fixed size of 4 bytes. The baseline block
> is variable size in multiple of 4 bytes, and its size is defined
> in the header block Baseline_ELD_Len field (in number of
> DWords).
>
> Do not include the header size in Baseline_ELD_Len field. Fix all known
> users of eld[2].
>
> While at it, switch to DIV_ROUND_UP instead of open coding it.
>
> Signed-off-by: Jani Nikula
>
> ---
>
> This is based on an audio rework series which is mid-way being merged to
> i915. I don't think this should be cc: stable worthy, as, AFAICT, we
> don't use the vendor block, and anyone reading SADs respecting SAD_Count
> should stop at the same offset regardless of this patch. So I propose
> this gets eventually merged via i915 without a rush.
> ---
> drivers/gpu/drm/drm_edid.c | 7 +--
> drivers/gpu/drm/i915/intel_audio.c | 16
> drivers/gpu/drm/nouveau/nv50_display.c | 3 ++-
> 3 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3bf999134bcc..45aaa6f5ef36 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3128,9 +3128,12 @@ void drm_edid_to_eld(struct drm_connector *connector,
> struct edid *edid)
> }
> }
> eld[5] |= sad_count << 4;
> - eld[2] = (20 + mnl + sad_count * 3 + 3) / 4;
>
> - DRM_DEBUG_KMS("ELD size %d, SAD count %d\n", (int)eld[2], sad_count);
> + eld[DRM_ELD_BASELINE_ELD_LEN] =
> + DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
> +
> + DRM_DEBUG_KMS("ELD size %d, SAD count %d\n",
> + drm_eld_size(eld), sad_count);
> }
> EXPORT_SYMBOL(drm_edid_to_eld);
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 20af973d7cba..439fa4afa18b 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -107,7 +107,7 @@ static bool intel_eld_uptodate(struct drm_connector
> *connector,
> tmp &= ~bits_elda;
> I915_WRITE(reg_elda, tmp);
>
> - for (i = 0; i < eld[2]; i++)
> + for (i = 0; i < drm_eld_size(eld) / 4; i++)
> if (I915_READ(reg_edid) != *((uint32_t *)eld + i))
> return false;
>
> @@ -162,7 +162,7 @@ static void g4x_audio_codec_enable(struct drm_connector
> *connector,
> len = (tmp >> 9) & 0x1f;/* ELD buffer size */
> I915_WRITE(G4X_AUD_CNTL_ST, tmp);
>
> - len = min_t(int, eld[2], len);
> + len = min(drm_eld_size(eld) / 4, len);
> DRM_DEBUG_DRIVER("ELD size %d\n", len);
> for (i = 0; i < len; i++)
> I915_WRITE(G4X_HDMIW_HDMIEDID, *((uint32_t *)eld + i));
> @@ -209,7 +209,7 @@ static void hsw_audio_codec_enable(struct drm_connector
> *connector,
> int len, i;
>
> DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
> - pipe_name(pipe), eld[2]);
> + pipe_name(pipe), drm_eld_size(eld));
>
> /* Enable audio presence detect, invalidate ELD */
> tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> @@ -225,8 +225,8 @@ static void hsw_audio_codec_enable(struct drm_connector
> *connector,
> I915_WRITE(HSW_AUD_DIP_ELD_CTRL(pipe), tmp);
>
> /* Up to 84 bytes of hw ELD buffer */
> - len = min_t(int, eld[2], 21);
> - for (i = 0; i < len; i++)
> + len = min(drm_eld_size(eld), 84);
> + for (i = 0; i < len / 4; i++)
> I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((uint32_t *)eld + i));
>
> /* ELD valid */
> @@ -315,7 +315,7 @@ static void ilk_audio_codec_enable(struct drm_connector
> *connector,
> int aud_cntrl_st2;
>
> DRM_DEBUG_KMS("Enable audio codec on port %c, pipe %c, %u bytes
> ELD\n",
> - port_name(port), pipe_name(pipe), eld[2]);
> + port_name(port), pipe_name(pipe), drm_eld_size(eld));
>
> /* XXX: vblank wait here */
>
> @@ -354,8 +354,8 @@ static void ilk_audio_codec_enable(struct drm_connector
> *connector,
> I915_WRITE(aud_cntl_st, tmp);
>
> /* Up to 84 bytes of hw ELD buffer */
> - len = min_t(int, eld[2], 21);
> - for (i = 0; i < len; i++)
> + len = min(drm_eld_size(eld), 84);
> + for (i = 0; i < len / 4; i++)
> I915_WRITE(hdmiw_hdmiedid, *((uint32_t *)eld +
