Created attachment 82619 [details]
Xorg Log

Hi Alex
I would assume that your kernel does not have the following patch it can be found at the nouveau repo [1]

commit bf03d1b293cc556df53545e318110505014d805e
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Jul 3 03:06:02 2013 -0400

    drm/nva3/disp: Fix HDMI audio regression
    
    This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
    HDMI audio regression). The regression happened as a result of
    refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
    core).
    
    Reported-and-tested-by: Max Baldwin <archerseven@gmail.com>
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: stable@vger.kernel.org


Note that HDMI audio is not fully reverse-engineered, thus you may be one of the "lucky" people where it does a bit of extra in order to work :)

[1] http://cgit.freedesktop.org/nouveau/linux-2.6/

Created attachment 82626 [details]
DMESG

Created attachment 82627 [details]
Xorg log

Hi Emil,

I applied the patch.  For reference:

[/linux-3.10.1/drivers/gpu/drm/nouveau/core/engine/disp]$ diff hdminva3.c-orig
hdminva3.c
56a57,60
>         nv_mask(priv, 0x61c5d0 + soff, 0x00070001, 0x00010001); /* SPARE,
>         HW_CTS */
>         nv_mask(priv, 0x61c568 + soff, 0x00010101, 0x00000000); /* ACR_CTRL,
>         ??
> */
>         nv_mask(priv, 0x61c578 + soff, 0x80000000, 0x80000000); /*
>         ACR_0441_ENABLE */
------------------------------------------------------------------------------
No cigar:

aplay -D plughw:1,x test.wav    # x = 3, 7, 8, _9_
NO SOUND

and

cat /proc/asound/card1/eld#3.0
monitor_present         1
eld_valid               0
-------------------------------
COMMENTS
I'm a little skeptical for two reasons:

1.  The patch (date, presentation) implies that everything was hunky-dory
until those guys on 3.10.1 did something.
Not true.  The nouveau HDMI sound has _never_ worked since 3.8.0 (when I
started paying attention.)

2.  I'm far from a kernel-, nouveau-, patch-, etc-. expert but common sense(?)
tells me that a mere three lines of code can't fix this problem which, again
common sense, looks a lot more intractable.  If I can offer an uneducated guess
nouveau should work first on this 'eld#3.0' to see it handling an EDID properly
(like NVIDIA did - see submission) in order to have a chance at competing with
the big boys (Nvidia, Windows) in the HDMI sound arena (although an elementary
and vital requirement/capability at this day and age).

I'm attaching the new dmesg and Xorg log for this patch attempt.

Thank you for your trying to help,
-- Alex

Well, for clarity, commit 8e9e3d2de which introduced the regression first appeared in v3.8-rc1. And my fix *did* enable at least one user (with a GeForce 550 Ti IIRC) to get HDMI audio to work fine. (In his situation, sending DTS/AC3 worked fine, but regular PCM audio sent crap, and futzing with those registers fixed it.)

It would be worthwhile for you to test out v3.7 and see if it worked. If it did, that means there are further differences. If not, it means that getting things fully supported will require more RE work.

BTW, does video work fine? Can you post the output of "xrandr -q"?

nouveau  [     DRM] allocated 640x400 fb: 0x60000, bo f4cf1800

But your monitor can probably do a bit more than 640x400, which indeed points to a potential EDID problem parsing problem. (I also don't see 640x400 as one of the modes reported by X.) Normally it picks the native resolution of your monitor... do you have something on cmdline that overrides that? Normally there's a Command line: printed in the dmesg, but yours doesn't have it. Perhaps that happens when the cmdline is empty...

Lastly, is this a x86_32 kernel? Can't imagine it'd matter, but good to know in any case. (I guess it is since you mention i686, but kernel can still be x86_64 in that case.)

Hi Ilia,

(In reply to comment #7)
> BTW, does video work fine?
Always perfect (on all kernels, on NVIDIA proprietary, Win 7, etc.).

> Can you post the output of "xrandr -q"?
xrandr --version
xrandr program version       1.4.0
Server reports RandR version 1.4

xrandr [-q]                                   # works without "-q" on mine.
Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192
DVI-I-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 553mm x 311mm
   1280x720       60.0*+   50.0  
   1920x1080      60.0 +   50.0  
   1920x1080i     60.1     50.0  
   1680x1050      59.9  
   1280x1024      75.0     60.0  
   1440x900       59.9  
   1280x960       60.0  
   1152x864       75.0  
   1440x576       50.0  
   1024x768       75.1     70.1     60.0  
   1440x480       59.9  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   720x576        50.0  
   720x480        59.9  
   640x480        75.0     66.7     60.0     59.9  
   720x400        70.1  
VGA-1 disconnected (normal left inverted right x axis y axis)

NOTE:  Monitor is 1920x1080 native (especially on 25in.! ).
However, I like it on 1280x720.  In /etc/X11/xorg.conf:
 Modes   "1280x720" "1024x768" "1440x900" "1920x1080"
This shouldn't affect sound though :)

> But your monitor can probably do a bit more than 640x400, which indeed
> points to a potential EDID problem parsing problem. (I also don't see
> 640x400 as one of the modes reported by X.) Normally it picks the native
> resolution of your monitor... do you have something on cmdline that
> overrides that?

I don't need to.  My life style has always been absolutely inflexible:

1.  Boot to Level 3 ("console/VGA/Text mode").  Work there.  Compile kernels and
the like.  Impress the neighbors (who don't have Linux).
2.  When I please (like when I want to listen to HDMI sound :), I go to
 Level 5 at a resolution based on the modeline above.  Do graphics things.
3.  When done, I come down to Level 3.  Work some more.  When tired or disgusted I hit 'poweroff'.

> Lastly, is this a x86_32 kernel? 
You'll be the judge:
uname -a
Linux AlexP5 3.10.1 #1 SMP Thu Jul 18 14:17:31 EDT 2013 i686 i686 i386 GNU/Linux

Note:  The time above reflects the last one compiled with the patch.

Just curious:  the sound logic is in the nouveau-kernel module or a combination of nouveau-kernel and Xorg-nouveau (nouveau_drv.so)?
I know not to expect sound other than at level 5 (Xorg).

Thank you for your work and interest.
-- Alex

There shouldn't be anything in the DDX that affects HDMI audio (or, indeed, HDMI). All modesetting is done by the kernel ("KMS"), and that includes setting up all the proper audio stuff.

So... two questions that I don't feel were fully answered:

(a) Does HDMI video work fine with nouveau in the kernels that you've tried?

(b) Can you test out a 3.7-based kernel (3.7.x should all be fine for this exercise, the "refactor" patches are generally not backported into the stable series) and see if HDMI audio works there?

And a fresh question:

(c) Can you try unplugging and then re-plugging the HDMI cable after the computer is all booted up and check the ELD status then? There's an old bug that alludes to a timing issue between nvidia and alsa loading, and I have no idea if it's fixed (bug #32406).

(In reply to comment #9)

> (a) Does HDMI video work fine with nouveau in the kernels that you've tried?
As I said, "Always perfect".  With _nouveau_.

> (b) Can you test out a 3.7-based kernel?
I suppose I can.  Let me know if it's critical for you to proceed with your work.  I'd rather wait for some more of your thoughts/tests/results _if possible_.  However, I'll jump to it immediately if you say the word.

> (c) Can you try unplugging and then re-plugging the HDMI cable after the
> computer is all booted up and check the ELD status then? There's an old bug
> that alludes to a timing issue between nvidia and alsa loading, and I have
> no idea if it's fixed (bug #32406).

I'll do that as soon as I release this reply and report the results.

(In reply to comment #9)

> (c) Can you try unplugging and then re-plugging the HDMI cable after the
> computer is all booted up and check the ELD status then? There's an old bug
> that alludes to a timing issue between nvidia and alsa loading, and I have
> no idea if it's fixed (bug #32406).

Same:
alex[~]% cat /proc/asound/card1/eld#3.0
monitor_present         1
eld_valid               0

(In reply to comment #10)
> (In reply to comment #9)
> > (b) Can you test out a 3.7-based kernel?
> I suppose I can.  Let me know if it's critical for you to proceed with your
> work.  I'd rather wait for some more of your thoughts/tests/results _if
> possible_.  However, I'll jump to it immediately if you say the word.

Well, the situation is that I don't have any HDMI devices at all (either with HDMI outputs or inputs, forget HDMI audio), nor do I know anything about it. So if this doesn't work, that means that someone else needs to (a) reproduce your issue [and note, hdmi audio does work for some other people, so there must be something a bit more special about your situation, be it EDID data or more missed register setup], and (b) do the RE work to figure out what we're missing.

It seems like testing out an old kernel is easy by comparison. However I don't hold out a huge amount of hope for it, since like you said, eld_valid = 0, which more likely indicates an EDID issue.

If you're interested, some minor code inspection shows that at least some of the logic is in nv50_display.c:nv50_audio_mode_set. You could add prints in there to see what it's detecting stuff as. You could also add prints to drm_edid.c:drm_detect_monitor_audio, perhaps your monitor's EDID is different than what it expects.

Looks like there are a few prints already, you could see what happens when you boot with drm.debug=0x06 which should output nouveau- and kms-related debug statements.

> It seems like testing out an old kernel is easy by comparison. However I
> don't hold out a huge amount of hope for it, since like you said, eld_valid
> = 0, which more likely indicates an EDID issue.
> 
> If you're interested, some minor code inspection shows that at least some of
> the logic is in nv50_display.c:nv50_audio_mode_set. You could add prints in
> there to see what it's detecting stuff as. You could also add prints to
> drm_edid.c:drm_detect_monitor_audio, perhaps your monitor's EDID is
> different than what it expects.
> 
> Looks like there are a few prints already, you could see what happens when
> you boot with drm.debug=0x06 which should output nouveau- and kms-related
> debug statements.

Just to stay in sync:
I'll start compiling
linux-3.7.tar.xz of 12/11/12
and report the results.
I suppose "linux-3.7.tar.xz" is actually (in retrospect) linux-3.7.0
but who (in their right mind) would have predicted in those days that there would ever be a 3.7.1, i.e., a real follow up to 3.7 !!!???
Same for 3.8, etc.
Anyway, we'll talk about those "drm.debug=0x06" later.

> perhaps your monitor's EDID is different than what it [drm_edid.c] expects

I'm far from an expert in EDIDs but the EDID parameters as reported by NVIDIA in its eld#3.0 and the Xorg log look pretty good (to my untrained eye).
The monitor is relatively new (of this year, I suppose) made by a reputable manufacturer so they should know their way around what EDIDs must look like.

SURPRISE, SURPRISE

alex[~]% uname -a
Linux AlexP5 3.7.0 #1 SMP Thu Jul 18 21:38:56 EDT 2013 i686 i686 i386 GNU/Linux

alex[~]% cat /proc/asound/card1/eld#3.0
monitor_present         1
eld_valid               1
monitor_name            ASUS VE258
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0x6904
product_id              0x25f1
port_id                 0x0
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0x1] FL/FR
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x4e0] 32000 44100 48000 96000
sad0_bits               [0xe0000] 16 20 24

alex[~]% aplay -D plughw:1,9 test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
MUSIC TO MY HDMI EARS

I'm attaching the respective dmesg and Xorg log.

Ilia:

Thank you for your relentless troubleshooting.
Please, please, don't make me find out (bisect or otherwisw) at what 3.7.x somebody messed up royally.
(In merchandising circles kernels 3.7+ (up to current 3.10.1) are called
"NEW AND IMPROVED")

Please have those guys clean up their mess as soon as possible (if they have any professional molecule in their blood).
Thanks again, best wishes,
-- Alex

Created attachment 82644 [details]
3.7.0 DMESG

Created attachment 82645 [details]
Xorg log

Hm, I see a minor discrepancy in commit a4feaf4ea5359db96a253154eafca358d16152b2.

Could you test the (soon-to-be-attached) hdmi-1.patch on top of 3.10 (or later)?

If that doesn't work, please try hdmi-2.patch on top of 3.10 (it includes the changes in hdmi-1.patch). I'm hoping that hdmi-1.patch will be sufficient.

Created attachment 82647 [details] [review]
hdmi-1.patch

Created attachment 82648 [details] [review]
hdmi-2.patch

Hi Ilia,

alex[~]% uname -a
Linux AlexP5 3.10.1 #1 SMP Fri Jul 19 11:17:28 EDT 2013 i686 i686 i386 GNU/Linux

alex[~]% cat /proc/asound/card1/eld#3.0
monitor_present         1
eld_valid               1
monitor_name            ASUS VE258
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0x6904
product_id              0x25f1
port_id                 0x0
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0x1] FL/FR
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x4e0] 32000 44100 48000 96000
sad0_bits               [0xe0000] 16 20 24

alex[~]% aplay -D plughw:1,9 test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

NO SOUND !!!

NOTES:
1.  I applied only the hdmi-1 patch.
2.  The original patch (of yesterday, hdminva3.c) has still been in place.

I'll apply hdmi-2 now and see what happens.

I've exhausted all new 3.10.1 combinations (see below).
All have a clean, complete card1/eld#3.0 now but NONE has HDMI SOUND.

1.  hdmi-1 + hdminva3-patch
2.  hdmi-1 + hdmi-2 + hdminva3-patch
3.  hdmi-1 + hdmi-2
4.  hdmi-1

Please note that I repeatedly checked if there still was HDMI SOUND on 3.7.0
(on the possibility that, say, the cat ate the cable in the interim - I don't
have a cat, BTW :).

There must still be something, somewhere missing from the original, good 3.7.0 logic.

Hi Ilia,

I've built 3.7.10 (I was in the neighborhood, so I said, what the heck ...).
Like 3.7.0, the same nice 'eld#3.0' file, the same nice HDMI sound.

Since it looks to me that 3.7.10 is the last "official" release before 3.8.0
it appears that the ugly mistake was committed (so to speak) in between those two (as I mentioned, 3.8.0 already contains the bug - no HDMI sound).

-- Alex

Alex, thanks for your thorough testing. Sad to hear that those patches don't do anything :(

3.7.10 is not in between 3.7 and 3.8, it is on the "stable" release branch. But it's good to know that it works fine. (And you should definitely stay on 3.7.10 vs 3.7 -- there were a couple of annoying bugs fixed in there, both nouveau- and security-related.)

I'm afraid it might be bisect time -- if there are more differences, I don't see them. Knowing the exact commit may be able to refocus things. However this is not nearly as painful as you might think. I think it makes most sense to only bisect in drivers/gpu/drm/nouveau. Here's a basic guide: https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html (you'll obviously need a linux git checkout, as well as the git tool).

You'll want to do something like

git bisect start v3.8 v3.7 -- drivers/gpu/drm/nouveau

This should start you off (there will be ~7 kernel compiles, so really not that bad). Then you mark the kernels as good/bad and proceed. Please provide the full bisection log when you're done.

Oh wait, interesting, I misread one of your comments.

So with hdmi-1.patch, you *do* get the correct eld data. But still no sound, even with the hdminva3 file patched up as well. So I was right... but not enough.

Forget the bisect, it probably won't tell me anything, sorry about that.

Please test out the following things:

(a) does f7960736d0b8647fd149687d15deb79e47122d69 work fine?
(b) does a4feaf4ea5359db96a253154eafca358d16152b2 break?
(c) does a4feaf4ea5359db96a253154eafca358d16152b2 + hdmi-1.patch work fine?
(d) does 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3 patch work fine?

[no need to try other patch combinations, these are the ones to test]

You'll obviously need a linux git tree for this. I'm very curious to hear the answers. If you hit a "no" on one, no need to do the "later" questions (e.g. if (a) doesn't work, no need to do b/c/d).

Hi Ilia,

I was once bisecting left and right.  Not in the past two years or so.
I can be back in shape relatively easy (I suppose) but it would obviously save me
a lot of time and effort if you can give me some quick, clear and precise instructions, including

1.  Version to stay on (3.7.10, 3.8.0, 3.10.1 - I have them ready)
2.  If on 3.10.1 (my guess), which of the three patches should be on exactly
3.  How to get a good copy of the tree to work on locally
4.  How do I get to those commits (say, f7960736d0b8647fd149687d15deb79e47122d69)
5.  (a) and (b):  what patches (if any)
6.  etc.

Thanks,
-- Alex

(In reply to comment #25)
> Hi Ilia,
> 
> I was once bisecting left and right.  Not in the past two years or so.
> I can be back in shape relatively easy (I suppose) but it would obviously
> save me
> a lot of time and effort if you can give me some quick, clear and precise
> instructions, including
> 
> 1.  Version to stay on (3.7.10, 3.8.0, 3.10.1 - I have them ready)
> 2.  If on 3.10.1 (my guess), which of the three patches should be on exactly

None of the above, you'll need a git tree. Whenever you see a version like a.b.c with c != 0, it's not a "clean" version but one that contains backported patches.

> 3.  How to get a good copy of the tree to work on locally

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

> 4.  How do I get to those commits (say,
> f7960736d0b8647fd149687d15deb79e47122d69)

cd linux
git checkout f7960736d0b8647fd149687d15deb79e47122d69

> 5.  (a) and (b):  what patches (if any)

None. It's a shortcut to the bisect, the two commits are sequential, and my guess is that that's where things break. If I'm wrong, I'll have you do the full bisect. Unfortunately both of the commits in (c) and (d) have known defects, which is what the patches are for. It sounds like those patches are incomplete, and I need to know which commit has left-over defects.

So basically you need to do

git checkout f7960736d0b8647fd149687d15deb79e47122d69
<build, test, make sure it works>

git checkout a4feaf4ea5359db96a253154eafca358d16152b2
<build, test, make sure it doesn't work>

<apply hdmi-1.patch>
<build, test, make sure it works>

git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891
<verify that the hdmi-1.patch is still applied, if not, apply it>
<apply hdminva3.patch>
<build, test, see whether it works or not>

When testing whether things work, please record both whether you see the correct data in eld, as well as whether sound plays.

# All versions are 3.7.0-rc4+
# Four builds, tests:

1.  f7960736d0b8647fd149687d15deb79e47122d69
     <build, test, make sure it works>

2.  a4feaf4ea5359db96a253154eafca358d16152b2
     <build, test, make sure it doesn't work>

3.  a4feaf4ea5359db96a253154eafca358d16152b2  <apply hdmi-1.patch>
     <build, test, make sure it works>

4.  8e9e3d2deacc460fbb8a4691140318f6e85e6891
     <verify that the hdmi-1.patch is still applied, if not, apply it>
     <apply hdminva3.patch>
     <build, test, see whether it works or not>

# Results (keyed to the numbers above):
 
     eld#3.0              HDMI sound
     =======              ==========
1.    Good                   Good

2.    Bad*                   Good (!)
  
3.    Good                   Good

4.    Good                   No sound


*
 monitor_present  1
 eld_valid        0

(!) = puzzled

That's all very interesting. I suspect that the way that things are implemented, there's no correlation between "eld data showing" and "things actually work". OK, so my hdmi-1.patch fixes the ELD stuff, I'll send that off. I'm going to include your name/email (as you have it listed here) as Reported-and-tested-by in the patch description; let me know soon if you'd rather I left you off.

But 8e9e3d2deacc460fbb8a4691140318f6e85e6891 has some second regression which matters for your card. I'll look at that change harder, looks like there's some other diff that my hdminva3 patch didn't cover.

As always, thanks for testing.

Created attachment 82712 [details] [review]
hdminva3-2.patch

OK, I did find a little discrepancy. Let's try this:

8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch + hdminva3-2.patch

(hdminva3.patch is commit bf03d1b293cc556df53545e318110505014d805e, not attached here)

If this works, try the same thing but on top of a 3.10 kernel (or later).

(In reply to comment #30)
> Let's try this:
> 
> 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch +
> hdminva3-2.patch
> 
> If this works, try the same thing but on top of a 3.10 kernel (or later).

I didn't work:

eld#3.0 Good but NO HDMI sound.

(In reply to comment #31)
> (In reply to comment #30)
> > Let's try this:
> > 
> > 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch +
> > hdminva3-2.patch
> > 
> > If this works, try the same thing but on top of a 3.10 kernel (or later).
> 
> It didn't work:
> 
> eld#3.0 Good but NO HDMI sound.

Created attachment 82740 [details] [review]
hdminva3-3.patch

OK, how about

8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch + hdminva3-3.patch

If that works, try restoring the two writes that I removed from the video infoframe section.

Hi Ilia,

> 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + 
> hdmi-1.patch + hdminva3.patch + hdminva3-3.patch

Not good news:  Good 'eld#3.0',  No HDMI sound

I'd like you to take a little time to review my procedure, correct it if
necessary, and thus keep us in sync.

cd /root/linux                                  # Linus directory
make mrproper
git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891
# At this point, files to be patched are each copied ('cp -p') to <name>-orig.
cd /root/Temp                                   # Patch directory
cp -p ../linux/drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c-orig hdanva3.c
cp -p ../linux/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c-orig hdminva3.c
cp -p ../linux/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c-orig hdminv84.c
#
patch -Np8 -i hdmi-1.patch ; echo $?
patch -Np8 -i hdminva3.patch ; echo $?
patch -Np8 -i hdminva3-3.patch ; echo $?
cp -p {hdanva3,hdminva3,hdminv84}.c                   /root/linux/drivers/gpu/drm/nouveau/core/engine/disp/
# Build, reboot, test:
cat /proc/asound/card1/eld#3.0                  # Good, Bad?
aplay -D plughw:1,9 test.wav                    # HDMI sound?

-- Alex

(In reply to comment #35)
> Hi Ilia,
> 
> > 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + 
> > hdmi-1.patch + hdminva3.patch + hdminva3-3.patch
> 
> Not good news:  Good 'eld#3.0',  No HDMI sound

OK. That means there's something else still that I'm missing :(

> 
> I'd like you to take a little time to review my procedure, correct it if
> necessary, and thus keep us in sync.
> 
> cd /root/linux                                  # Linus directory
> make mrproper
> git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891
> # At this point, files to be patched are each copied ('cp -p') to
> <name>-orig.
> cd /root/Temp                                   # Patch directory
> cp -p ../linux/drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c-orig
> hdanva3.c
> cp -p ../linux/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c-orig
> hdminva3.c
> cp -p ../linux/drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c-orig
> hdminv84.c
> #
> patch -Np8 -i hdmi-1.patch ; echo $?
> patch -Np8 -i hdminva3.patch ; echo $?
> patch -Np8 -i hdminva3-3.patch ; echo $?
> cp -p {hdanva3,hdminva3,hdminv84}.c                  
> /root/linux/drivers/gpu/drm/nouveau/core/engine/disp/

That does seem like it would work, but definitely not the way that I'd do it. I'd do more like

cd linux
git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891
git checkout drivers/gpu/drm/nouveau (this should remove any local changes you have in that dir on tracked files)
patch -p1 < hdmi-1.patch
patch -p1 < hdminva3.patch
patch -p1 < hdminva3-3.patch

> # Build, reboot, test:
> cat /proc/asound/card1/eld#3.0                  # Good, Bad?
> aplay -D plughw:1,9 test.wav                    # HDMI sound?
> 
> -- Alex

Created attachment 82754 [details] [review]
hdminva3-4.patch

Same as before, but now with:

8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch + hdminva3-4.patch

BTW, do make sure that you're booting the right kernels/installing modules (I assume nouveau is a module in your case). In case you weren't doing that, and this patch works, please go back and re-test the various patch versions.

If this doesn't work, I think the next logical move is to run mmiotrace on a working kernel and the above patched up kernel, and compare the traces to see what it is that we're messing up. I think that the old logic accidentally read random garbage off the stack and wrote it to registers, so perhaps that random garbage happened to be correct.

(In reply to comment #38)

Just a quick thought

> BTW, do make sure that you're booting the right kernels/installing modules
> (I assume nouveau is a module in your case).

1.  After 'make' I do a 'make install'.  Should be fool-proof.  Or not?
2.  As for sound, my truly full-proof method is to go back to 3.7.10 every once in a while and confirm it.

(In reply to comment #39)
> (In reply to comment #38)
> 
> Just a quick thought
> 
> > BTW, do make sure that you're booting the right kernels/installing modules
> > (I assume nouveau is a module in your case).
> 
> 1.  After 'make' I do a 'make install'.  Should be fool-proof.  Or not?

Don't know what "make install" really does, I've never used it. I think it tends to hook into distro stuff. Hopefully it also installs modules, not just the kernel. I usually run "make modules_install". But I don't know if that's the right thing to do on your distro/the way that you're setting up kernels.

> 2.  As for sound, my truly full-proof method is to go back to 3.7.10 every
> once in a while and confirm it.

That doesn't say anything about your procedure though. Perhaps do a 

git checkout drivers/gpu/drm/nouveau
git checkout a4feaf4ea5359db96a253154eafca358d16152b2

And re-build/install in the same way as you've been doing and make sure that HDMI sound works (and that the eld file doesn't, as you had verified earlier).

> Don't know what "make install" really does, I've never used it. 

My bad (my "quick thought" was way too quick).
I was talking about 'make module_install'.

Anyway, to make it more precise and not affected by my state of exhaustion,
I present my script I use"

#!/bin/bash -e
# AFTER 
#  cd /root/linux
#  git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891
#  Make changes (apply, remove patches, etc.)
cd /root/linux
make mrproper &&
cp -p /boot/config/config-3.7.0-rc4+-1-P5E-74G .config
make menuconfig
make oldconfig && ls -ogtr .config*
time make -j4 ; echo $?
make modules_install &&
ls -ogtr /lib/modules
cd /boot &&
 cp -p /root/linux/arch/i386/boot/bzImage LFSkernel-3.7.0-1 &&
 cp -p /root/linux/System.map System.map-3.7.0-1 &&
 ln -fs LFSkernel-3.7.0-1 LFSkernel &&
 ln -fs System.map-3.7.0-1 System.map && ls -ogtr
set +e
read -s -n1 -t20 -p "(Hit a key to continue)" ; echo
reboot

and attach the standard '.config' (see above).  Not perfection by any standards but it is based on the 3.7.10 version and it adequate for these tests.

Created attachment 82755 [details]
Config for tests

8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch + hdminva3-4.patch

eld#3.0 Good   NO HDMI sound

(In reply to comment #43)
> 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch +
> hdminva3-4.patch
> 
> eld#3.0 Good   NO HDMI sound

Just to make sure we're talking about the same thing, mind uploading your hdminva3.patch to the bugtracker?

Created attachment 82756 [details]
hdminva3.patch

Just to make sure my procedure is correct (or, say, at least consistent) I redid

3.  a4feaf4ea5359db96a253154eafca358d16152b2  <apply hdmi-1.patch>

(see Comment 27)

and I got the same result:

     eld#3.0              HDMI sound
     =======              ==========
3.    Good                   Good

Note:  for my spot check I used the criteria:

a.  Old (maybe possible corrupted) stuff
b.  Good sound (a feeling missing on recent tests)
c.  A file to be patched (while working with other clean, original files)

Well, I'm not sure what the remaining differences are.

The only thing I can think of is to compare mmio traces between working and non-working kernels to observe the difference that I seem to be missing. There's a guide at https://wiki.ubuntu.com/X/MMIOTracing except that instead of tracing the nvidia blob, you need to trace nouveau. Add nouveau to your module blacklist, and boot into text mode. Then start tracing, load nouveau, and stop tracing. (No need to start X.) Collect such a trace file for both a kernel with working hdmi sound and non-working.

Actually wait, there's an easier way of achieving this.

boot both the kernel from the last attempt (with hdaminv-4.patch) and a working kernel, e.g. 3.7.10 with a "nouveau.config=PDISP=spam" parameter. This should produce a very large quantity of logs in your dmesg. In fact it might overflow your dmesg buffer, but it should all go through syslog. Let me know if that boot parameter doesn't cause the logs to show up...

(In reply to comment #48)
> Actually wait, there's an easier way of achieving this.
> 
> boot both the kernel from the last attempt (with hdaminv-4.patch) and a
> working kernel, e.g. 3.7.10 with a "nouveau.config=PDISP=spam" parameter.
> This should produce a very large quantity of logs in your dmesg. In fact it
> might overflow your dmesg buffer, but it should all go through syslog. Let
> me know if that boot parameter doesn't cause the logs to show up...

Hi Ilia,

I'm back in action.
Are you talking about hdminva_3_-4.patch?
Anyway, please quickly clarify the two(?) configurations you want me to test and compare (?) (I said I was back in action;  I didn't say I was fully awake).

BTW, (informational) speaking of dmesg overflow, you may have noticed I routinely started the kernel with "log_buf_len=1M" lately.

-- Alex

(In reply to comment #49)
> (In reply to comment #48)
> > Actually wait, there's an easier way of achieving this.
> > 
> > boot both the kernel from the last attempt (with hdaminv-4.patch) and a
> > working kernel, e.g. 3.7.10 with a "nouveau.config=PDISP=spam" parameter.
> > This should produce a very large quantity of logs in your dmesg. In fact it
> > might overflow your dmesg buffer, but it should all go through syslog. Let
> > me know if that boot parameter doesn't cause the logs to show up...
> 
> Hi Ilia,
> 
> I'm back in action.
> Are you talking about hdminva_3_-4.patch?
> Anyway, please quickly clarify the two(?) configurations you want me to test
> and compare (?) (I said I was back in action;  I didn't say I was fully
> awake).

Sorry, I should have been clearer.

1. 8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch + hdminva3-4.patch

2. f7960736d0b8647fd149687d15deb79e47122d69

The second one is the revision without the two problematic commits that are the reason for the patches. This should ensure that they are as similar as possible.

> 
> BTW, (informational) speaking of dmesg overflow, you may have noticed I
> routinely started the kernel with "log_buf_len=1M" lately.

Ah, that's good. BTW, you might consider going into #nouveau on freenode IRC to avoid some of this back-and-forth.

As requested.

Each with a "nouveau.config=PDISP=spam" parameter.

f7960736d0b8647fd149687d15deb79e47122d69
   eld#3.0  Good       Good HDMI sound

8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch +
 hdminva3-4.patch
   eld#3.0  Good       NO HDMI sound

Created attachment 82798 [details]
Kernel Log f79...

Created attachment 82799 [details]
Kernel Log 8e9

Well that didn't work. Looks like you need to build with

CONFIG_NOUVEAU_DEBUG=7

I'm looking for *TONS* of output of the form nv_wr32(...)/etc. Please do this with both kernels. Don't bother uploading logs if you're not seeing that.

(In reply to comment #54)
> Well that didn't work. Looks like you need to build with
> 
> CONFIG_NOUVEAU_DEBUG=7
> 
> I'm looking for *TONS* of output of the form nv_wr32(...)/etc. Please do
> this with both kernels. Don't bother uploading logs if you're not seeing
> that.

Oh, and also looks like it should be nouveau.debug=PDISP=debug

(In reply to comment #55)
> (In reply to comment #54)
> > Well that didn't work. Looks like you need to build with
> > 
> > CONFIG_NOUVEAU_DEBUG=7
> > 
> > I'm looking for *TONS* of output of the form nv_wr32(...)/etc. Please do
> > this with both kernels. Don't bother uploading logs if you're not seeing
> > that.
> 
> Oh, and also looks like it should be nouveau.debug=PDISP=debug

ugh, i'm tired. nouveau.debug=PDISP=spam

Created attachment 82833 [details]
f7 dmesg with DEBUG=7

Created attachment 82834 [details]
e8 dmesg with DEBUG=7

Created attachment 82835 [details]
config with DEBUG=7

The '.config' file used during the two tests (f7 and e8) for your perusal and critique.

Looks like you were booting with nouveau.config=PDISP=spam. As per my later comments, can you do nouveau.debug=PDISP=spam ?

Created attachment 82839 [details]
dmesg on f79

Created attachment 82840 [details]
dmesg on 8e9

On these two kernel logs you'll have to _trust_ me that I booted with nouveau._debug_=PDISP=spam :)

Yes, you sure did. Unfortunately the interesting information has scrolled off. Ugh. Unless you can get that stuff, you'll have to go for the mmiotrace instead (see my earlier instructions). You can reset CONFIG_NOUVEAU_DEBUG to its earlier value too (having it this high slows things down).

Created attachment 82846 [details]
dmesg 8e9

Created attachment 82848 [details]
dmesg f79

I cranked "log_buf_len" up all the way to 2M.
the noise was so intense it felt like a tornado.
I reassured the neighbors all the racket was from the crowd frenzy over the Duchess of Cambridge giving birth to a boy.

On a more serious vein (while experiencing the same excitement) I just noticed that after hdmi-1.patch + hdminva3.patch + hdminva3-4.patch,
file 'hdminv84.c' retains the same size, although a quite different content:

[]$ diff hdminv84.c-orig hdminv84.c     

47,48d46
<       nv_wr32(priv, 0x616534 + hoff, 0x00000000);
<       nv_wr32(priv, 0x616538 + hoff, 0x00000000);
54c52
<       nv_wr32(priv, 0x61650c + hoff, 0x00000071);
---
>       nv_wr32(priv, 0x61650c + hoff, 0x00000170);
55a54,55
>       nv_wr32(priv, 0x616514 + hoff, 0x00000000);
>       nv_wr32(priv, 0x616518 + hoff, 0x00000000);
64c64
<       nv_mask(priv, 0x6165a4 + hoff, 0x5f1f007f, data | 0x1f000000 /* ??? */);
---
>       nv_mask(priv, 0x6165a4 + hoff, 0x5f1f003f, data | 0x1f000000 /* ??? */);

Just checkin'.

(In reply to comment #65)
> Created attachment 82848 [details]
> dmesg f79
> 
> I cranked "log_buf_len" up all the way to 2M.

Well you definitely have all the stuff in there now. However I don't see the things I expected to see. Which means that for reasons beyond me they're not under PDISP :( Sorry for making you go through all this and have it end up a waste. I really think that mmiotrace is the way to go at this point.

> 
> On a more serious vein (while experiencing the same excitement) I just
> noticed that after hdmi-1.patch + hdminva3.patch + hdminva3-4.patch,
> file 'hdminv84.c' retains the same size, although a quite different content:
> 
> []$ diff hdminv84.c-orig hdminv84.c     
> 
> 47,48d46
> <       nv_wr32(priv, 0x616534 + hoff, 0x00000000);
> <       nv_wr32(priv, 0x616538 + hoff, 0x00000000);
> 54c52
> <       nv_wr32(priv, 0x61650c + hoff, 0x00000071);
> ---
> >       nv_wr32(priv, 0x61650c + hoff, 0x00000170);
> 55a54,55
> >       nv_wr32(priv, 0x616514 + hoff, 0x00000000);
> >       nv_wr32(priv, 0x616518 + hoff, 0x00000000);
> 64c64
> <       nv_mask(priv, 0x6165a4 + hoff, 0x5f1f007f, data | 0x1f000000 /* ???
> */);
> ---
> >       nv_mask(priv, 0x6165a4 + hoff, 0x5f1f003f, data | 0x1f000000 /* ??? */);
> 
> Just checkin'.

Yep. Just changing some values to be more in line with what they were before the refactor, vainly hoping that they would fix your issue.

> I really think that mmiotrace is the way to go at this point.

I can see this is the beginning of a _long_ and beautiful friendship (actually I saw it from the start - this is a little heavy).
On a warning note: unless a heart atack and/or a plane crash, I can outlast you.

Now if you give me precise instructions about what I have to do.  I don't need anything beyond if the mmiotrace "happens" to go nowhere.  Just the mmio instructions.

(In reply to comment #67)
> > I really think that mmiotrace is the way to go at this point.
> 
> I can see this is the beginning of a _long_ and beautiful friendship
> (actually I saw it from the start - this is a little heavy).
> On a warning note: unless a heart atack and/or a plane crash, I can outlast
> you.
> 
> Now if you give me precise instructions about what I have to do.  I don't
> need anything beyond if the mmiotrace "happens" to go nowhere.  Just the
> mmio instructions.

See comment 47. Should be sufficient, but feel free to ask if you're still confused.

I've gone over the MMIO procedure and I think I got the gist of it.

Just to make sure I'm in sync:

1.  The material ends in ". Generally"
Now, the stuff was signed "2010-04-21" (which in Linux years means yesterday), so this can be interpreted by an outside reader as meaning either
 1.1.  In such a short time no inside (Ubuntu (?)) reader had time to remove the  loose word "Generally", or
 1.2.  There is a real/important continuation somewhere.

2.  Adapted for "nouveau", I'll never have to go to X (level 5) for this trace purpose;  I can just stay at level 3 (console/text/VGA mode) for ever - so to speak.

Correct. All you have to do is start up mmiotrace, load nouveau, and then echo nop > /sys/.../current_tracer (I forget the exact file, but it's on that wiki page). And I wouldn't worry about that trailing Generally. I just look at the page to remember what I have to echo into what files.

Note that mmiotrace has to be started *before* nouveau is loaded, so make sure that it's (a) a module and (b) blacklisted from loading on startup. And it goes without saying, but the HDMI device with audio support needs to be plugged in while you're doing this.

> echo nop > /sys/.../current_tracer (I forget the exact file, but it's on
> that wiki page).

Speaking of that, I don't have '/sys/kernel/debug/'
Looking around I do have
DEBUG_KERNEL and DEBUG_DRIVER both on "yes".
What gives?

(In reply to comment #71)
> > echo nop > /sys/.../current_tracer (I forget the exact file, but it's on
> > that wiki page).
> 
> Speaking of that, I don't have '/sys/kernel/debug/'
> Looking around I do have
> DEBUG_KERNEL and DEBUG_DRIVER both on "yes".
> What gives?

I've figured it out.
Debug Filesystem: yes
CONFIG_DEBUG_FS --> /sys/kernel/debug/  !!!???

Who'd have thunk it?

Created attachment 82871 [details]
"working hdmi sound" trace (30 sec.)

Created attachment 82872 [details]
"non-working hdmi sound" trace

These two traces look very much alike (to my untrained eye).
Looking forward to the next thing we'll have to do.

Well that was a failure. These traces should be a bit longer :) Like 10-100MB.

Are you sure that you did (a) start mmiotrace (b) load nouveau (in that order)? If so I don't know what else to do.

Created attachment 82876 [details]
working HDMI sound mmio trace (30 sec.)

Created attachment 82877 [details]
non-working HDMI sound mmio trace (30 sec.)

All is not lost :)
I had used the NVIDIA-install nouveau blacklist blindly.  My bad.
Its second line was
"options nouveau modeset=0"

These last two traces are based on just
"blacklist nouveau"

I had to compress them (22 MB original).  This site was not happy otherwise.

Created attachment 82878 [details]
Same as above but "auto-detect"

Well, I can tell you why it doesn't work -- you know that code that I've been poring over every bit of? It doesn't even get run in the bad kernel! Now to figure out why that is...

Created attachment 82880 [details] [review]
debug-1.patch

Well, an analysis of both of the mmio logs shows that outside of PTIMER, the only MMIO differences is that nothing in the new nva3_hdmi_ctrl gets run. Reading the code... it should work :) So here's a patch that adds some nv_info's all over and tries to identify where my logic breaks down.

So try this:

8e9e3d2deacc460fbb8a4691140318f6e85e6891 + hdmi-1.patch + hdminva3.patch + hdminva3-4.patch + debug-1.patch

No need to run it under mmiotrace, or run the old kernel. Just provide the dmesg that results from this.

Created attachment 82881 [details] [review]
debug-2.patch

oops, a small bug in the debug patch. use debug-2.patch instead.

Created attachment 82882 [details] [review]
debug-3.patch

not my day... debug-3.patch instead of debug-2.patch (and debug-1.patch). compile-tested this time.

Hi Ilia,

It's a little late for me;  I'm just playing for the time being to get in shape for tomorrow:
Please help me with this (I had already applied successfully, per your instructions, the hdmi-1.patch + hdminva3.patch + hdminva3-4.patch,
but I'm stumbling at this step:

# In an attempt to restore (after it failed originally)
[~/linux]$ git checkout drivers/gpu/drm/nouveau ; echo $?
0

[~/linux]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
Hunk #2 succeeded at 77 with fuzz 1.
patching file drivers/gpu/drm/nouveau/nv50_display.c
Hunk #1 FAILED at 1657.
Hunk #2 FAILED at 1666.
2 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/nouveau/nv50_display.c.rej
1

Thanks,
-- Alex

(In reply to comment #83)
> Hi Ilia,
> 
> It's a little late for me;  I'm just playing for the time being to get in
> shape for tomorrow:
> Please help me with this (I had already applied successfully, per your
> instructions, the hdmi-1.patch + hdminva3.patch + hdminva3-4.patch,
> but I'm stumbling at this step:
> 
> # In an attempt to restore (after it failed originally)
> [~/linux]$ git checkout drivers/gpu/drm/nouveau ; echo $?
> 0

Correct.

> [~/linux]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
> patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
> patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
> Hunk #2 succeeded at 77 with fuzz 1.
> patching file drivers/gpu/drm/nouveau/nv50_display.c
> Hunk #1 FAILED at 1657.
> Hunk #2 FAILED at 1666.
> 2 out of 2 hunks FAILED -- saving rejects to file
> drivers/gpu/drm/nouveau/nv50_display.c.rej
> 1

Blast... I made the change on top of a much more recent kernel, and I guess my patches don't apply. You should be able to do this test on top of a recent kernel -- e.g. 3.10, or 3.11-rc2. You can get this by just doing "git checkout master" (or "origin" instead of "master", I forget)

Alternatively you could look at where I put the prints in and plop them in manually. I guess the classy thing for me to do would be to create a debugging patch that'll apply to that revision... perhaps I'll do that later if you run into trouble with this or the results are nonsensical.

> ... I made the change on top of a much more recent kernel, and I guess
> my patches don't apply. You should be able to do this test on top of a
> recent kernel -- e.g. 3.10, or 3.11-rc2. You can get this by just doing "git
> checkout master" (or "origin" instead of "master", I forget)
> 
> perhaps I'll do that [whatever] later
> if you run into trouble with this or the results are nonsensical.

This is a really quick and not necessarily rigorous update.
I did run into trouble:

I went for 'git checkout _master_' - got something like 3.11.0-rc1+;
the patches (including the last one, debug-3), worked OK.
It's possible my "standard" '.config' file (circa 3.7.0-rc4+) I'd been using for the tests (without any of my "massaging" it during the 'make menuconfig' - for lack of time and energy) was a bit too long in the tooth for the "master" kernel to "adapt" to.
The end result was after boot-up I couldn't even go into X at all and the system got almost frozen and unmanageable.  In short, as you'd put it, nonsensical.
Right now I'm back on my tried and true 3.7.10 (i.e., standard <-> git), the last "official" with the HDMI sound, ready to resume the patches and any tests in a more organized and less frantic way.  For better or worse, that will happen not sooner than Wednesday, July 24, 6-7 PM EDT.
At least you get a chance to go over them mmio traces more thoroughly (if you haven't done that already).

STATUS UPDATE as of 07/25/2013 1 PM EDT

SUMMARY
After extensive tests, discussions, changes, etc.,
still at square ONE (i.e., at subject of this Bug Report - NO HDMI sound).

DETAILS (latest tests)

The mmio nouveau traces of the
 8e9e3d2deacc460fbb8a4691140318f6e85e6891 ("BAD" commit)
and
 f7960736d0b8647fd149687d15deb79e47122d69 ("GOOD" commit)
were presented to the Bug analyst (Ilia Mirkin) two days ago.

Patches proposed by Ilia (based on trace analysis):
 hdmi-1.patch + hdminva3.patch + hdminva3-4.patch + debug-3.patch

1.  On "standard" 3.10.1 (i.e., as opposed to "git"):

 hdmi-1.patch FAILS
 The remaining three OK.
 Build OK
 Boot-up OK
 X OK
 Good edl#3.0, NO HDMI sound.

2.  On "git" master (circa, 3.11.0-rc1+)
 All four patches OK
 Build OK
 Boot-up (to level 3) OK
 X (level 5) a mess.  Frozen system.

3.  On "git" 8e9e3d2deacc460fbb8a4691140318f6e85e6891 (the "BAD" commit)
 Last patch (debug-3) fails.
 Agreed not to proceed with the build ('debug-3' was the latest hope of a fix)

COMMENTS

4.  "Standard" 3.7.10 and "git" f7960736d0b8647fd149687d15deb79e47122d69
   eld#3.0  Good       Good (normal, as expected) HDMI sound

This shows that at one point ( < 3.8.0 ) things were normal (HDMI-sound wise).
This eliminates the typical Linux lame excuse that the video card might not be
"standard".  The manufacturer, EVGA, is one of the most reputable NVidia OEM
vendors.  As a reminder, no HDMI-sound problems on NVIDIA proprietary driver,
nor on Win 7.

CONCLUSION

Somewhere after 3.7.10 (to the untrained eye) and/or after
f7960736d0b8647fd149687d15deb79e47122d69 (to the expert eye) somebody
(probably in an typical attempt to "improve" the product, the nouveau driver) messed up (i.e., among other things, eliminated the HDMI sound).

-- Alex

Let's worry about X dying later... it has nothing to do with HDMI video or audio. Do you have the dmesg from the boot that had my debug patch applied? (Also, my hdminva3.patch should already be part of 3.11, so I'm surprised you didn't get a conflict of some sort when applying it.)

Let's worry about X dying later...
 it has nothing to do with HDMI video or audio.

The X comment was just for completeness.
X was lost at that time (so video and/or audio situation would've been
academical, anyway).
-------------------------------------------------------------------------------
Also, my hdminva3.patch should already be part of 3.11, so I'm surprised you
didn't get a conflict of some sort when applying it.

Are you talking about my linux "master" (circa 3.11.0-rc1+)?
If so, I'll double check and report on problems with hdminva3.patch (if any).
Please advise.

Otherwise, there's no "real" 3.11.0 available to me.
I see the latest one for me (the "official") would be 3.10.3.
(I've had and ran 3.10.1 for this bug submission).
-------------------------------------------------------------------------------
Do you have the dmesg from the boot that had my debug[-3] patch applied?

As aluded to in my Comment 86:

[~/linux]$ git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891 ; echo $?
0
[~/linux]$ git checkout drivers/gpu/drm/nouveau ; echo $?
0
[~/linux]$ patch -p1 < /home/alex/hdmi-1.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c
0
[~/linux]$ patch -p1 < /home/alex/hdminva3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
0
[~/linux]$ patch -p1 < /home/alex/hdminva3-4.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
Hunk #1 succeeded at 44 with fuzz 1.
Hunk #2 succeeded at 61 (offset -4 lines).
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
0
[~/linux]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
Hunk #2 succeeded at 77 with fuzz 1.
patching file drivers/gpu/drm/nouveau/nv50_display.c
Hunk #1 FAILED at 1657.
Hunk #2 FAILED at 1666.
2 out of 2 hunks FAILED -- saving rejects to file
drivers/gpu/drm/nouveau/nv50_display.c.rej
1

------
Should I go ahead and compile this commit (despite debug-3 failure)
and post the dmesg?
Please advise.

Hi Ilia,

As promised:

(> my hdminva3.patch should already be part of 3.11, so I'm surprised
 you didn't get a conflict of some sort when applying it.)

These are the steps I did then and reproduced now to answer your question.
(Note: today, the git state machine is right after the debug-3 failure on
 88e9e3d2deacc460fbb8a4691140318f6e85e6891)

[~/linux]$ git checkout master ; echo $?
error: Your local changes to the following files would be overwritten by checkout:
        drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
        drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
        drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
Please, commit your changes or stash them before you can switch branches.
Aborting
1

[~/linux]$ git checkout drivers/gpu/drm/nouveau ; echo $?
0
[~/linux]$ git checkout master ; echo $?
Checking out files: 100% (24444/24444), done.
Previous HEAD position was 8e9e3d2... drm/nv84/disp: move hdmi control into
coreSwitched to branch 'master'
0

[~/linux]$ patch -p1 < /home/alex/hdmi-1.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c
0
[~/linux]$ patch -p1 < /home/alex/hdminva3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c.rej
1
[~/linux]$ patch -p1 < /home/alex/hdminva3-4.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
0
[~/linux]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
patching file drivers/gpu/drm/nouveau/nv50_display.c
0

So basically I took the 'hdminva3.patch' skip in stride (then and now).
I agree, I should've mentioned this detail.  Hope it helps.

-- Alex

(In reply to comment #88)
> Let's worry about X dying later...
>  it has nothing to do with HDMI video or audio.
> 
> The X comment was just for completeness.
> X was lost at that time (so video and/or audio situation would've been
> academical, anyway).

Not at all. With KMS, X has nothing to do with modesetting, and thus nothing to do with video or hdmi audio besides asking the kernel to configure one mode or another. You should be able to test everything from the console just fine.

> -----------------------------------------------------------------------------
> --
> Also, my hdminva3.patch should already be part of 3.11, so I'm surprised you
> didn't get a conflict of some sort when applying it.
> 
> Are you talking about my linux "master" (circa 3.11.0-rc1+)?
> If so, I'll double check and report on problems with hdminva3.patch (if any).
> Please advise.
> 
> Otherwise, there's no "real" 3.11.0 available to me.
> I see the latest one for me (the "official") would be 3.10.3.
> (I've had and ran 3.10.1 for this bug submission).

Right. So the patch is in 3.11-rc1 and 3.10.x (3, I think). So if you're using a version later than that, you should see apply failures with hdminva3.patch -- no need to even try it though.

> -----------------------------------------------------------------------------
> --
> Do you have the dmesg from the boot that had my debug[-3] patch applied?
> 
> As aluded to in my Comment 86:
> 
> [~/linux]$ git checkout 8e9e3d2deacc460fbb8a4691140318f6e85e6891 ; echo $?
> 0
> [~/linux]$ git checkout drivers/gpu/drm/nouveau ; echo $?
> 0
> [~/linux]$ patch -p1 < /home/alex/hdmi-1.patch ; echo $?
> patching file drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c
> 0
> [~/linux]$ patch -p1 < /home/alex/hdminva3.patch ; echo $?
> patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
> 0
> [~/linux]$ patch -p1 < /home/alex/hdminva3-4.patch ; echo $?
> patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminv84.c
> Hunk #1 succeeded at 44 with fuzz 1.
> Hunk #2 succeeded at 61 (offset -4 lines).
> patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
> 0
> [~/linux]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
> patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
> patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
> Hunk #2 succeeded at 77 with fuzz 1.
> patching file drivers/gpu/drm/nouveau/nv50_display.c
> Hunk #1 FAILED at 1657.
> Hunk #2 FAILED at 1666.
> 2 out of 2 hunks FAILED -- saving rejects to file
> drivers/gpu/drm/nouveau/nv50_display.c.rej
> 1
> 
> ------
> Should I go ahead and compile this commit (despite debug-3 failure)
> and post the dmesg?
> Please advise.

No. My debug patch would have to be redone for a kernel that old. Instead, please take a recent kernel and apply my debug patch to it, and boot. The other patches are actually probably not necessary either -- they just change what gets written where, whereas I'm trying to figure out a potential issue with the execution flow. You don't even have to go into X or test anything (but you can) -- I just want to see the dmesg that happens when nouveau loads with that debug patch. (But obviously make sure that your hdmi-audio-capable device is plugged in at the time.)

>> Should I go ahead and compile this commit (despite debug-3 failure)
>> and post the dmesg?
>> Please advise.

> No. My debug patch would have to be redone for a kernel that old. Instead, please take a recent kernel and apply my debug patch to it, and boot. The other patches are actually probably not necessary either -- they just change what gets written where, whereas I'm trying to figure out a potential issue with the execution flow. You don't even have to go into X or test anything (but you can) -- I just want to see the dmesg that happens when nouveau loads with that debug patch. (But obviously make sure that your hdmi-audio-capable device is plugged in at the time.)

Please give me an exact kernel version you'd be comfortable with.
Most likely my Linus copy is already a little old;  OTOH, I can
easily go out and get 3.10.3 (or whatever kernel du jour there might be);  etc.

For dmesg, I assume (but please confirm):

NOUVEAU_DEBUG=7
nouveau.debug=PDISP=spam

For patches:  only dmesg-3? or what else exactly?.

BTW:  Don't worry about X.  I ain't gonna touch it this time :)

Thanks,
-- Alex

(In reply to comment #91)
> >> Should I go ahead and compile this commit (despite debug-3 failure)
> >> and post the dmesg?
> >> Please advise.
> 
> > No. My debug patch would have to be redone for a kernel that old. Instead, please take a recent kernel and apply my debug patch to it, and boot. The other patches are actually probably not necessary either -- they just change what gets written where, whereas I'm trying to figure out a potential issue with the execution flow. You don't even have to go into X or test anything (but you can) -- I just want to see the dmesg that happens when nouveau loads with that debug patch. (But obviously make sure that your hdmi-audio-capable device is plugged in at the time.)
> 
> Please give me an exact kernel version you'd be comfortable with.
> Most likely my Linus copy is already a little old;  OTOH, I can
> easily go out and get 3.10.3 (or whatever kernel du jour there might be); 
> etc.

3.10.3 is fine. As is 3.10.1. Anything that the debug patch applies cleanly to.

> 
> For dmesg, I assume (but please confirm):
> 
> NOUVEAU_DEBUG=7
> nouveau.debug=PDISP=spam

No -- just regular boot. Reset NOUVEAU_DEBUG to its original value (4, I think).

> 
> For patches:  only dmesg-3? or what else exactly?.

Only debug-3.

> 
> BTW:  Don't worry about X.  I ain't gonna touch it this time :)
> 
> Thanks,
> -- Alex

Created attachment 83105 [details]
3.10.1 DMESG

I used 3.10.1:
 it is mutually acceptable and
 is the kernel of this bug submission.

For the record:
[/linux-3.10.1]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
patching file drivers/gpu/drm/nouveau/nv50_display.c
0

NOUVEAU_DEBUG is at its default value: 5

NO "nouveau.debug=PDISP=spam"

FWIW, no HDMI sound.

cat /proc/asound/card1/eld#3.0
monitor_present         1
eld_valid               0

Created attachment 83106 [details]
For good measure

Created attachment 83108 [details] [review]
mthd-1.patch

OK, one more time (with a new patch):

3.10.1 + hdmi-1.patch + hdminva3.patch + debug-3.patch + mthd-1.patch

does this make hdmi audio work? if not, please supply dmesg.

Hi Ilia,

VERY GOOD NEWS.  PROBLEM SOLVED!!!  TERRIFIC HDMI SOUND.
And that despite my being continuously in your way!

You deserve at least two tickets to Sochi (if still available).

Quote:
The Olympic Games give a powerful boost to the development of television technology.  The Games in Sochi will be shown entirely in HD format and, in addition, advanced Ultra High Definition technology will be used in Sochi.

Now if you could somehow procure an NVIDIA card and HDMI cable... (sound included).
Later, even a monitor and/or television _with_ HDMI input.  True,
they are relatively new, not even six years old...

For the record:
[/linux-3.10.1]$ patch -p1 < /home/alex/hdmi-1.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdanva3.c
0
[/linux-3.10.1]$ patch -p1 < /home/alex/hdminva3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
0
[/linux-3.10.1]$ patch -p1 < /home/alex/debug-3.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
patching file drivers/gpu/drm/nouveau/nv50_display.c
0
[/linux-3.10.1]$ patch -p1 < /home/alex/mthd-1.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/include/core/class.h
0

cat /proc/asound/card1/eld#3.0
monitor_present         1
eld_valid               1
monitor_name            ASUS VE258
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0x6904
product_id              0x25f1
port_id                 0x0
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0x1] FL/FR
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x4e0] 32000 44100 48000 96000
sad0_bits               [0xe0000] 16 20 24

Thank you very much,
-- Alex

PS As agreed, no dmesg.

Perfect, thanks for confirming. This is likely not quite the right patch as I effectively caused a check to get skipped, but we'll figure out what the right thing to do is... for some reason that check is failing. I'll update the bug with more patches to test, assuming you're up for it, as they become available.

And don't worry -- I have an HDMI cable. All I need are the other two ends :)

Created attachment 83110 [details] [review]
mthd-2.patch

Am I correct in understanding that you have a DVI-I, HDMI, and VGA connector on your card?

Would you mind testing out

3.10.1 + hdmi-1.patch + hdminva3.patch + debug-1.patch + mthd-2.patch

and see if it still works? If not, I'd like to see the dmesg, and vbios (/sys/kernel/debug/dri/0/vbios.rom)

(so basically same thing as last time, but mthd-2.patch instead of mthd-1.patch... if you don't want to blow away your entire tree, you can do

patch -R -p1 < mthd-1.patch
patch -p1 < mthd-2.patch
)

I'm back in action; just a few preliminary words:
> And don't worry -- I have an HDMI cable. All I need are the other two ends :)

As almost an aside:
It so happens I just got rid of a 19-in. Magnavox LCD TV.
(circa 2009 - Probably a Philips inside)
What has amazed me to this day, the quality/richness of picture 
(720p - for example) and _all_ inputs including HDMI.  About < $200 US.
One of the best pieces of machinery I've ever owned.
Hopefully it ended up used by orphans in Uganda (making Bram Moolenaar
(of vim fame) proud and happy).
http://www.amazon.com/gp/product/B001QXDLNS/ref=wms_ohs_product?ie=UTF8&psc=1

> if you don't want to blow away your entire tree
I rarely keep trees around;  for safety and lack of space.

I always start a kernel build from scratch.  For example,
 time tar xJf /usr/local/downloads/linux-3.10.1.tar.xz
takes roughly 15 sec. - negligible compared to the time I waste in life.
So I don't have to bother with reverses and such.

> Am I correct in understanding that you have a DVI-I, HDMI, and VGA connector on your card?
Right on the money.
I never buy a card without VGA.  Nor, for that matter, a PC without the green analog output (to use in those very rare cases - almost unheard of, but one never knows, do one? -  where the HDMI sound might not work).

This is strange.  The compile (make) fails.
I've compiled a few kernels in my life.  Never happened before:
Twice.

First:
 ....
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o
  CC [M]  drivers/net/wireless/b43legacy/pio.o
  CC [M]  drivers/net/wireless/b43/wa.o
  CC [M]  drivers/net/wireless/b43/dma.o
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/btcoex.o
  LD [M]  drivers/net/wireless/b43legacy/b43legacy.o
  CC [M]  drivers/net/wireless/b43/pio.o
  CC [M]  drivers/net/wireless/b43/rfkill.o
  LD [M]  drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o
  LD [M]  drivers/net/wireless/b43/b43.o
  LD      drivers/net/built-in.o
make: *** [drivers] Error 2

real    4m8.390s
user    7m39.033s
sys     0m27.441s
2

Second time:
 ....
  CC      net/xfrm/xfrm_sysctl.o
  CC      net/xfrm/xfrm_replay.o
  LD      drivers/input/input-core.o
  LD      drivers/input/built-in.o
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
  CC [M]  net/xfrm/xfrm_algo.o
  CC [M]  net/wireless/ethtool.o
  CC [M]  net/xfrm/xfrm_user.o
  LD      net/xfrm/built-in.o
  CC [M]  net/wireless/mesh.o
  CC [M]  net/wireless/ap.o
  CC [M]  net/wireless/trace.o
  LD      net/wireless/built-in.o
  LD [M]  net/wireless/cfg80211.o
  LD      net/built-in.o

real    3m53.609s
user    7m11.009s
sys     0m26.165s
2

Note:  (FWIW) typical successful completion time: about 5m 28s
------

1.  I re-tried the compile of yesterday (with mthd-1).  Perfect again.
I then retraced the very same steps, except with the new mthd-2.
As shown above, still bad.

Comments (I'm still in shock):
2. Is it possible that you really meant debug-_1_ (Comment 98)?
(I've gone with debug-3 exclusively so far, assuming that was a typo)

3. To troubleshoot (if need be) I can do just 'make' (as opposed to make -j4)
Slower but more explicit.

4. For clarity/completeness, this is what I always do:

cd /
rm -fr linux-3.10.1
time tar xJf /usr/local/downloads/linux-3.10.1.tar.xz ; echo $?
cd linux-3.10.1
make mrproper ; echo $?
cp -p /boot/config/config-3.10.1-3-P5E-74G .config
make menuconfig
make oldconfig ; echo $?
*** Apply the indicated patches ***
time make -j4 ; echo $?
*** If the 4th patch is mthd-2:  twice (consistently) fail.
*** If the 4th patch is mthd-1:  always OK

Any ideas, suggestions?

Sorry, I did mean debug-3.patch.

This indicates some sort of compile failure, but since you're using -jN, it's long gone. What I usually do in these situations is just run make after the failure, which will hopefully be hit at some point early on.

OH, I know what's going on -- the debug patch prints "link", which I removed -- can you just remove that part of the print? Or do I need to send an updated debug patch?

> OH, I know what's going on -- the debug patch prints "link", which I removed
> -- can you just remove that part of the print? Or do I need to send an
> updated debug patch?

Issue another patch please.  So as to stay in sync at all times.

Created attachment 83153 [details] [review]
Remove dcb_outp_match()

Ilia as mentioned previously - the way I see it, only mthd-1.patch is needed to resolve this bug. And as a side effect the following nice cleanup can be made

Note for Alex
The attached patch will also resolve your issue (not guaranteed to apply cleanly), due to the fact that it purges some code unnecessary code, which you were (unintentionally) hitting :)

> Note for Alex
> The attached patch will also resolve your issue (not guaranteed to apply
> cleanly)

Confirmed:)
[/linux-3.10.1]$ patch -p1 < /home/alex/EmilVelikov.patch ; echo $?
patching file drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c
Hunk #2 FAILED at 56.
1 out of 2 hunks FAILED -- saving rejects to file
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c.rej
1

> due to the fact that it purges some code unnecessary code, which you were (unintentionally) hitting :)

As to the compile (make) step:

Whether:
1. hdmi-1 + hdminva3 + debug-3 + EmilVelikov
or
2. hdmi-1 + hdminva3 + debug-3 + mthd-1 + EmilVelikov

the compile fails (unintentionally:) with

  CC [M]  drivers/gpu/drm/nouveau/core/engine/disp/sornv50.o
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c: In function
'nv50_sor_mthd':drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:60:1:
error: 'type' undeclared (first use in this function)
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:60:1: note: each undeclared
identifier is reported only once for each function it appears in
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:60:1: error: 'link'
undeclared (first use in this function)
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:61:30: error: 'bios'
undeclared (first use in this function)
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:61:42: error: 'mask'
undeclared (first use in this function)
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:61:49: error: 'ver'
undeclared (first use in this function)
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:61:55: error: 'hdr'
undeclared (first use in this function)
drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c:61:61: error: 'outp'
undeclared (first use in this function)
make[4]: *** [drivers/gpu/drm/nouveau/core/engine/disp/sornv50.o] Error 1

Both the patch to fix the ELD situation, as well as the actual audio working are now in the nouveau/master repository (http://cgit.freedesktop.org/nouveau/linux-2.6/). Closing this bug, thanks for doing all the testing, sorry it took so many tries to nail down the issue.

Ideally these patches will make it into some later 3.10.x, and almost definitely into 3.11.