Linux Kernels for OpenFrame

[roobarb!]

• Apply HDA: Fix Joggler sound switching patch to a 3.10 kernel
• Enable CONFIG_SND_HDA_PATCH_LOADER in kernel config
• Copy the joggler-sound.patch file to /lib/firmware
• Set the corresponding kernel parameter snd_hda_intel.patch=joggler-sound.patch (or add it to /etc/modprobe.d/joggler.conf)

Fantastic! I will give that a try this afternoon...

BTW, I had no idea about your Android release - I'm definitely going to check that out. I'll make sure it gets added to the list of available operating systems!

[roobarb!]

Right... well, it's changed the behaviour, but not quite correctly!

With kernel 3.10.22, following your instructions, I now have a situation whereby playback from the internal speakers works fine and when I insert a jack into the socket, the audio on the internal speakers is muted. Good, except that the audio is then not routed out to the headphones!

Interestingly, if I go into alsamixer and disable auto-mute mode, that DOES allow audio out to the headphones - but at the same time as from the internal speakers. So it seems that when the headphones are inserted, both the outputs are muted. Erm... help!

[roobarb!]

FIXED IT!

I've been trying to work this out in fits and starts over the past few days. The solution is super-simple, but good grief, it's taken some work to nail it down. The short version is that the joggler-sound.conf patch in pkirchhofer's instructions doesn't seem to be right for any of the Jogglers I have here - they all have the problem described in my previous post. The following, however, is correct for all of the Jogglers I have tested:

Code: Select all

[codec]
0x83847632 0x100 0

[pincfg]
0x07 0x01110014
0x08 0x01410013
0x0a 0x02111011
0x0d 0x02214012
0x0c 0x01810022
0x0b 0x01a10021
0x10 0x01010031
0x11 0x01310023
0x15 0x01d10024

[verb]
0x06 0x701 0x0000
0x07 0x70c 0x0002
0x14 0x390 0x0000
0x14 0x3a0 0x0000
0x0f 0x707 0x0000

[hint]

Using that, along with an ever-so-slightly tweaked (but ultimately tiny) patch to the kernel, I have properly working audio with auto-mute on kernel 3.10. I'll be testing it with 3.12 soon as well and I'll get the patches out as soon as I've tidied the whole mess up.

I am so glad I sorted this one out. For some reason it was an absolute nightmare - everything that could go wrong in the process, did!

[BuZz]

Nice work!

[roobarb!]

Nice work!

Cheers, BuZz!

Okay, folks; here's my whizz-bang kernel with working GMA500 kernel drivers and working STAC9202 audio. I've made a couple of changes to the GMA500 backlight code too, so it stops complaining about not being able to read it's own psb-bl interface and uses the openframe-bl one instead. In fact, it doesn't even bother compiling its own interface any more.

http://birdslikewires.co.uk/download/jo ... rnel/3.10/

All of the patches and config files are there.

If you want to try out the compiled versions, you'll need to use the joggler-stac9202.patch file and pop it into /lib/firmware, then add:

Code: Select all

patch=joggler-stac9202.patch

To the end of the audio tweak line in /etc/modprobe.d/joggler.conf.

Just make sure you use the Lucid one for sqpOS, the Precise one if you're messing around with 12.04. I've not actually tested it with SqueezePlay on top as yet, but I can't see it would have any troubles.

[roobarb!]

Also, if chris is still around, this kernel should support your Schiit Modi audio interface now.

[BuZz]

I should probably look at my alsa patch and check the pin configs against yours, as it may be possible to do without the .patch file and just have a single kernel patch. This is where I got to - note some of the code is copy and paste and fiddled with, as I was trying to work out all the various parameters etc.

I think this should apply to a 3.10.x

Sorry for not posting it earlier. It's unfinished, but since you made so much progress, might be useful ? doesn't include the pin switch hack, as I was trying to work out how to do it in a different way without that.

http://malus.exotica.org.uk/~buzz/sigmatel.diff

[roobarb!]

Ah, magic! I actually posted to the alsa-dev mailing list looking for a way to do just this, but I don't think I'm cool enough for those guys.

That would make the additional 'softload' patch unnecessary - we'd just have to set model=openpeak, I guess. I haven't tested those pin configs on the OpenFrame 2 yet; must do that this afternoon if I get chance. If we need something different, perhaps we could have 'of1' and 'of2' models in there?

[BuZz]

Ah, magic! I actually posted to the alsa-dev mailing list looking for a way to do just this, but I don't think I'm cool enough for those guys.

That would make the additional 'softload' patch unnecessary - we'd just have to set model=openpeak, I guess. I haven't tested those pin configs on the OpenFrame 2 yet; must do that this afternoon if I get chance. If we need something different, perhaps we could have 'of1' and 'of2' models in there?

model is detected automatically. I (you / someone) just need to understand fix up the rest of the code. This was my attempt of forward porting the old patch. I can confirm my additional function gets called etc, so just a matter of reading all the alsa kernel source and learning what the hell needs doing heh

If you find an alsa dev I'm happy to send them a Joggler.

[roobarb!]

model is detected automatically.

Ooh, I couldn't figure out how the heck that would work.

Yes, if any tame ALSA developers come forward I will definitely introduce them to the forum.

[BuZz]

model is detected automatically.

Ooh, I couldn't figure out how the heck that would work.

Yes, if any tame ALSA developers come forward I will definitely introduce them to the forum.

I think it uses the strcuture with the vendor id in it, or it justs defaults to it?

anyway.. I don't really know apart from the patch_stac9202 does get correctly called. I may have understood it slightly better some weeks back.

[roobarb!]

I haven't tested those pin configs on the OpenFrame 2 yet; must do that this afternoon if I get chance.

Arr, the OpenFrame 2 is different. With and without the patch, it doesn't switch when headphones are inserted. Could well be the hard-coded pin = 0x07 I threw into the ALSA code for EAPD switching.

Would be great if we could find a way of handling that pin better.

[roobarb!]

Sound on this OF2 is a completely different kettle of bananas. An IDT 92HD75B2X5 chip on this one...

Interestingly, with sqpOS no audio works on this device at all! I mustn't have tested it!

[roobarb!]

I should probably look at my alsa patch and check the pin configs against yours, as it may be possible to do without the .patch file and just have a single kernel patch. This is where I got to - note some of the code is copy and paste and fiddled with, as I was trying to work out all the various parameters etc.

I think this should apply to a 3.10.x

Sorry for not posting it earlier. It's unfinished, but since you made so much progress, might be useful ? doesn't include the pin switch hack, as I was trying to work out how to do it in a different way without that.

http://malus.exotica.org.uk/~buzz/sigmatel.diff

I've just compiled a test kernel with this - works a treat, though it does need both the pin = 0x07 and commenting out of that spec->gen.own_eapd_ctl = 1 line in patch_sigmatel.c as well. I tried compiling without that line commented out and I end up with audio coming from both the internal speakers and the headphones at the same time.

Blimey, it's a right faff all this audio stuff, isn't it!

[BuZz]

So you are saying headphone switching is working correctly with the other patch on top? I was closer with my patch than I thought then. I'm pretty sure I tried that, and it had still not switched correctly. Would be nice to be able to get it working without the other change too - possibly by specifying some custom functions etc.

[roobarb!]

So you are saying headphone switching is working correctly with the other patch on top? I was closer with my patch than I thought then. I'm pretty sure I tried that, and it had still not switched correctly. Would be nice to be able to get it working without the other change too - possibly by specifying some custom functions etc.

Ooh, I'll have to compile another one - I just stuck the pin = 0x07 patch in on its own and got the same result as I did with my ALSA-patch file (ie. both outputs, but not switching). If I get chance I'll rustle up another one today and check.

I've been giving the kernel rt2800usb driver some hammer with the Joggler's RT2770 wireless card as well and it seems much better than before. I used to get long periods of 'dead time' where everything would vanish into the ether, then suddenly have the card pop back into existence. None of that now - it's handling huge files and SSH activity perfectly. The latency of rt2870sta does seem lower, though - less lag when doing things over an SSH connection.

Swapping between drivers, rt2870sta has lower latency, but doesn't quite achieve the throughput of rt2800usb. The rt2800usb driver has been getting almost 6MB/s, while I've not got much more than 4MB/s with rt2870sta. They're both beaten by the WNDA3200, though. That gets 7.5MB/s easily at 2.4GHz and 5GHz.

[roobarb!]

Just had a go at reducing the size of the kernel a bit by removing things that are never going to be needed (or even possible to attach!) to a Joggler.

[roobarb!]

I used to get long periods of 'dead time' where everything would vanish into the ether, then suddenly have the card pop back into existence.

Scratch my enthusiasm. The RT2770 card still does it occasionally with the rt2800usb driver. Testing the rt2870sta one now.

UPDATE: In conclusion, rt2870sta > rt2800usb. I think I'll remove rt2800usb from the kernel config now that I'm satisfied, so I'm not having to blacklist it. The latency is lower, the throughput is actually just as good and with the antennae clipped in properly (duh) I'm getting >7MB/s with it.

[roobarb!]

BuZz, thought I'd better let you know that Intel's EMGD driver doesn't compile for the 3.10 kernel. There are patches for 3.8, but create_proc_entry() is gone in 3.10. There are a few places discussing patches for it, but I've not any joy via Google so far.

[BuZz]

Thanks for the info. Emgd is annoying. Hardly ever updated, and binary blobs only for really old xserver. Very badly supported by Intel