So why the hell are You submitting thing, that You don't know how it works, and what it does?

/Estel

Well after reading the patch it does look like it could be interesting. I think it implements an IIR filter at the hardware level that is controllable through software. This is an unused hardware feature of the 320aic3x chip. This IIR filter affects the sound coming from the speakers. The part about only supporting 48kHz sample rate also gives me the willies, what are the implications of this?

I think the main beef was that while it was submitted by luke-jr, he has literally no idea what it is or does beyond 'stop n900 speakers from blowing up' (no offense luke-jr, I read your script for getting the nokia binaries for n900 in your gentoo install, it was boss). This in turn aroused suspicion for obvious reasons. It was however written by some other bro in September 2010 who does understand what it is he was creating. I think the original author is still on maemo IRC, he had something to do with chinook version of xchat I think.

Perhaps now that KP49 is in extras testing KP50 can be rolled out to devel so we can start raeping the KP50 bugs?

vi, there are two bugs reported so far against KP49 which are not fixed in pre50. While I can live with wlan bug as long as I am unable to fix it, DSP bug is another beer. Today I am going to chase it, lets see how it will develop.

re audio filter - while it could be interesting, do we really need that? I can bet there is already analog highpass filter somewhere in the path between speakers and DAC. If not the speakers themselves (have no idea what type they are). Another queation is - who will support that when a bug appear?

It's pretty well-known that pulseaudio does the filtering for the builtin media application. But do you want to take the chance that you run some other program (mplayer?) and destroy them? I sure don't.

Sounds like we need someone who knows audio well enough to maintain it. I'm certainly not qualified.

The best will be to find man who wrote that patch and ask him...

@Pali, seems DSP "bug" does not exist (look here). The only thing remaining is wlan issue. Did you get any answer from the author?

Waiting for it...

@Pali - there is a bug after all (although not in DSP driver), will need some time to fix it.

Wifi problem should be with mesh network code, which is buggy. Only one static function (ieee80211_rx_mesh_bss_get) with mesh code which calling memcmp can be inlined to ieee80211_bss_info_update (which is in mtd log). In upstream kernel are more commits which fixing mesh network. lxp suggested to disable mesh support in kernel-power. From our investigation mesh code is only one candidate for this bug...

Who using mesh networking and need it in kernel-power?

If there will be no problem I will disable mesh in rx51_defconfig and build new pre50 version.

Obviously KP50 is your baby however if you wanted a hardware engineers point of view...

Mesh networking is not implemented in this driver to any kind of reasonable extent so it is redundant. In short, you have a piece of code that is buggy, does nothing and is potentially crashing the kernel...disable it.