Advent Vega kernel source code now available!

[Guest stiggy2011]

Thanks very much for your continued hard work Eduardo.

I'm in the process of compiling your patches against 11.2.12 now.... This is awesome news.

Could someone please link to the ramdisk/system.img that people have got working so I can test this? I presume it's a standard Xoom image/ramdisk with a few tweaks?

[Guest stiggy2011]

OK! Tried compiling the 11.2.12 kernel with patches above, getting the following error:

CC drivers/video/tegra/host/nvhost_acm.o

drivers/video/tegra/host/nvhost_acm.c:30:27: error: nvhost_syncpt.h:

No such file or directory

make[4]: *** [drivers/video/tegra/host/nvhost_acm.o] Error 1

make[3]: *** [drivers/video/tegra/host] Error 2

make[2]: *** [drivers/video/tegra] Error 2

make[1]: *** [drivers/video] Error 2

make: *** [drivers] Error 2

The problematic file in question isn't even one patched by Eduardo so I'm just about to have a look into why this is happening now, but if anyone has already come across this and fixed it by all means let me know!

Also, got hold of a working image. Wifi seems to have picked up a minor issue: Sometimes I turn the wifi on and it gets stuck at "scanning", never detecting any networks. Switching the wifi on/off enough times solves the problem. dmesg shows:

[ 3885.344425] WARNING: at drivers/video/tegra/dc/dc.c:580 tegra_dc_set_dynamic_emc+0x210/0x268()

[ 3885.344515] Modules linked in: ar6000 [last unloaded: ar6000]

[ 3885.344689] [<c003967c>] (unwind_backtrace+0x0/0xf0) from [<c006a74c>] (warn_slowpath_common+0x4c/0x64)

[ 3885.344872] [<c006a74c>] (warn_slowpath_common+0x4c/0x64) from [<c006a77c>] (warn_slowpath_null+0x18/0x1c)

[ 3885.345014] [<c006a77c>] (warn_slowpath_null+0x18/0x1c) from [<c01e7598>] (tegra_dc_set_dynamic_emc+0x210/0x268)

[ 3885.345162] [<c01e7598>] (tegra_dc_set_dynamic_emc+0x210/0x268) from [<c01f0ca8>] (tegra_fb_flip_worker+0x3a4/0x428)

[ 3885.345311] [<c01f0ca8>] (tegra_fb_flip_worker+0x3a4/0x428) from [<c007ca28>] (process_one_work+0x24c/0x3b8)

[ 3885.345441] [<c007ca28>] (process_one_work+0x24c/0x3b8) from [<c007cf70>] (worker_thread+0x220/0x3d8)

[ 3885.345561] [<c007cf70>] (worker_thread+0x220/0x3d8) from [<c008204c>] (kthread+0x80/0x88)

[ 3885.345701] [<c008204c>] (kthread+0x80/0x88) from [<c0034ba4>] (kernel_thread_exit+0x0/0x8)

[ 3885.345796] ---[ end trace d737b3639d664c33 ]---

It works if I turn wifi on/off a few times, and once it's up it seems stable.

[Guest stiggy2011]

As suspected got around the 11.2.12 compilations issues just by removing:

#include <nvhost_syncpt.h>

from drivers/video/tegra/host/nvhost_acm.c

[Guest ejtagle]

As suspected got around the 11.2.12 compilations issues just by removing:

#include <nvhost_syncpt.h>

from drivers/video/tegra/host/nvhost_acm.c

Yes.. i forgot to tell about that. The other solution is to replace

#include <nvhost_syncpt.h>

by

#include "nvhost_syncpt.h"

Regards,

Eduardo

[Guest ejtagle]

.

...

Also, got hold of a working image. Wifi seems to have picked up a minor issue: Sometimes I turn the wifi on and it gets stuck at "scanning", never detecting any networks. Switching the wifi on/off enough times solves the problem. dmesg shows:

[ 3885.344425] WARNING: at drivers/video/tegra/dc/dc.c:580 tegra_dc_set_dynamic_emc+0x210/0x268()

[ 3885.344515] Modules linked in: ar6000 [last unloaded: ar6000]

[ 3885.344689] [<c003967c>] (unwind_backtrace+0x0/0xf0) from [<c006a74c>] (warn_slowpath_common+0x4c/0x64)

[ 3885.344872] [<c006a74c>] (warn_slowpath_common+0x4c/0x64) from [<c006a77c>] (warn_slowpath_null+0x18/0x1c)

[ 3885.345014] [<c006a77c>] (warn_slowpath_null+0x18/0x1c) from [<c01e7598>] (tegra_dc_set_dynamic_emc+0x210/0x268)

[ 3885.345162] [<c01e7598>] (tegra_dc_set_dynamic_emc+0x210/0x268) from [<c01f0ca8>] (tegra_fb_flip_worker+0x3a4/0x428)

[ 3885.345311] [<c01f0ca8>] (tegra_fb_flip_worker+0x3a4/0x428) from [<c007ca28>] (process_one_work+0x24c/0x3b8)

[ 3885.345441] [<c007ca28>] (process_one_work+0x24c/0x3b8) from [<c007cf70>] (worker_thread+0x220/0x3d8)

[ 3885.345561] [<c007cf70>] (worker_thread+0x220/0x3d8) from [<c008204c>] (kthread+0x80/0x88)

[ 3885.345701] [<c008204c>] (kthread+0x80/0x88) from [<c0034ba4>] (kernel_thread_exit+0x0/0x8)

[ 3885.345796] ---[ end trace d737b3639d664c33 ]---

...

BTW, this is not related to wifi... It is an error in the video driver module. I suspect 11.2.12 fixes it ;)

[Guest stiggy2011]

BTW, this is not related to wifi... It is an error in the video driver module. I suspect 11.2.12 fixes it ;)

It does, I've got 11.2.12 running by using rebel1's config and I'm not seeing the errors anymore! :)

[Guest newbe5]

Strange things happening with Vold (What's new? :/)

I/Vold ( 582): Vold 2.1 (the revenge) firing up

D/Vold ( 582): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media

)

D/Vold ( 582): Volume usb0 state changing -1 (Initializing) -> 0 (No-Media)

D/Vold ( 582): Volume usb1 state changing -1 (Initializing) -> 0 (No-Media)

D/Vold ( 582): Volume usb2 state changing -1 (Initializing) -> 0 (No-Media)

D/Vold ( 582): Volume usb3 state changing -1 (Initializing) -> 0 (No-Media)

E/NetlinkListener( 582): ignoring message with no sender credentials

E/SocketListener( 582): Obtaining file descriptor socket 'vold' failed: No such

file or directory

E/Vold ( 582): Unable to start CommandListener (No such file or directory)

Socket is not being picked up correctly for some reason. Any ideas fellas?

newbe5

[Guest ejtagle]

Strange things happening with Vold (What's new? :/)

I/Vold ( 582): Vold 2.1 (the revenge) firing up

D/Vold ( 582): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media

)

D/Vold ( 582): Volume usb0 state changing -1 (Initializing) -> 0 (No-Media)

D/Vold ( 582): Volume usb1 state changing -1 (Initializing) -> 0 (No-Media)

D/Vold ( 582): Volume usb2 state changing -1 (Initializing) -> 0 (No-Media)

D/Vold ( 582): Volume usb3 state changing -1 (Initializing) -> 0 (No-Media)

E/NetlinkListener( 582): ignoring message with no sender credentials

E/SocketListener( 582): Obtaining file descriptor socket 'vold' failed: No such

file or directory

E/Vold ( 582): Unable to start CommandListener (No such file or directory)

Socket is not being picked up correctly for some reason. Any ideas fellas?

newbe5

Seems no sender credentials were used to send a message... Don't know... Seems to be related to maybe? configuration ? --

[Guest rebel1]

Well... I did the measurements regarding speakers. No, the ALC codec is not configured in a bad way. There is no DC across the speaker terminals. The only thing that has happened here is that we are sending, if volume is set to maximum, way more power than the speakers could handle. I still have to figure out the maximum safe volume, but no ALC codecs were harmed. Just the speakers.

Regarding kernel 11.2.12, i ported the patches and complited the new kernel. It works without issues. No problems at all. I have attached my latest patches against 11.2.12 nvidia kernel. There are some misc changes also:

-Enabled dithering in video, so it should improve shadows and improve color transitions

-An attempt to let the user switch between device and host mode at runtime, for the USB bus. check /sysfs/usbbus ... But i am not sure it is working or not... Seems something is still missing there...

Well, thats all for now,

Eduardo

Hi,

i tested the LP0 mode, but unfortunately my PoV goes not to sleep, it turns completely off.

Any Idea to debug it further ?

Greetings,

rebel1/rene

[Guest Cass67]

Seems no sender credentials were used to send a message... Don't know... Seems to be related to maybe? configuration ? --

Userland issue, resolved : )

Cheers

Cass

[Guest ejtagle]

Hi,

i tested the LP0 mode, but unfortunately my PoV goes not to sleep, it turns completely off.

Any Idea to debug it further ?

Greetings,

rebel1/rene

Well, LP0 will be an strange thing to fix (even if desirable and/or possible). P10AN10 is using a hardware revision of Tegra (model A03) that has a bug in the rom bootloader that does not properly restore the state of the system. LP0 is just Suspend to RAM, and turn off everything except ram. Only DRAM is kept in self refresh mode... So, the bootloader should take out of selfrefresh mode the SDRAM, find a signed memory area that contains the resume information (in the kernel, known as the lp0 vector), and from there restore the system (LP0 = Suspend to RAM). But the bootloader contains a bug preventing that resume operation to work. So, i found a workaround in the .32 kernel, that uses the initial bootloader (bootloader.bin) to implement what the bootrom does not do properly. That is why i patched the suspend.c file... I have also disassembled and verified the signed memory block used for resume, and it seems it is ok... So, somehow, here we depend on the bootloader.bin implementation. Otherwise, LP0 becomes a near turn off ... Id guess this will be hard to fix, as we depend on the implementation of bootloader.bin, and we don-t have the source codo of it :(

Well, tomorrow i will continue with that :)

Attached my latest patchset against 11.2.12. This patchset tries to implement host/slave switching of the USB port without reboots. You just need to write a 1 to /sys/usbbus/host_mode to switch the port to host mode, and writing a 0 will revert it to a slave USB port . Hope it works :)

Tomorrow i will check the maximum allowable volume settings, and also will try to figure out what is happening with the LP0 and if there is a fix for it

11.2.12-LP0-MMC-DITHER-HOST-SLAVE-USB.rar

[Guest ejtagle]

Just as a curiosity, if anyone has access to the source code of the bootloader.bin, it would be nice if they could check if the required workaround for LP0 to work is in place. Even if i dont have access to it, i do suspect the way it works:

1) The bootrom loads a first stage bootloader (probably, that code is in bootloader.bin) into IRAM (instruction RAM is a small piece of fast static RAM inside Tegra2, that does not depend on external (DDR2) to be initialized to work.

2) The bootrom starts execution of the just loaded into IRAM first stage bootloader

3) This first stage bootloader is supposed to initialize the DDR2 SDRAM, enable caches , copy to it a 2nd stage bootloader that is usually much bigger, and jump to it

4) The 2nd stage bootloader loads the linux kernel, and jumps to it

The bootrom should handle the resuming from LP0, but, it contains a bug that does not properly initialze the DDR2, efectively hanging the system. So, instead, NVidia engineers instruct the bootrom to do a regular boot, and then, add code the 1st stage bootloader to handle the LP0 resume.

When the 1st stage bootloader find bit#5 of the PMC_SCRATCH0 register set, then, instead of loading the 2nd stage bootloader, it just uses the PMC_SCRATCH1 register to get the address of the lp0_vector, that contains the restore routines (set up by the last time the system started normally), and jumps to it, effectively resuming the system from the LP0 suspend to RAM (that is what a working bootrom ,but not the buggy one this tegra hw revision has, should do, but instead of using bit#5, it uses bit#0 of the same register)

What i need to know, is if that workaround in the 1st stage bootloader is in place or not. Without it, there is no way LP0 could work with this A03 tegra revision

Thanks in advance,

Eduardo

PS: Otherwise, i will have to reverse engineer the bootloader.bin to find out

[Guest stiggy2011]

Just as a curiosity, if anyone has access to the source code of the bootloader.bin, it would be nice if they could check if the required workaround for LP0 to work is in place. Even if i dont have access to it, i do suspect the way it works:

1) The bootrom loads a first stage bootloader (probably, that code is in bootloader.bin) into IRAM (instruction RAM is a small piece of fast static RAM inside Tegra2, that does not depend on external (DDR2) to be initialized to work.

2) The bootrom starts execution of the just loaded into IRAM first stage bootloader

3) This first stage bootloader is supposed to initialize the DDR2 SDRAM, enable caches , copy to it a 2nd stage bootloader that is usually much bigger, and jump to it

4) The 2nd stage bootloader loads the linux kernel, and jumps to it

The bootrom should handle the resuming from LP0, but, it contains a bug that does not properly initialze the DDR2, efectively hanging the system. So, instead, NVidia engineers instruct the bootrom to do a regular boot, and then, add code the 1st stage bootloader to handle the LP0 resume.

When the 1st stage bootloader find bit#5 of the PMC_SCRATCH0 register set, then, instead of loading the 2nd stage bootloader, it just uses the PMC_SCRATCH1 register to get the address of the lp0_vector, that contains the restore routines (set up by the last time the system started normally), and jumps to it, effectively resuming the system from the LP0 suspend to RAM (that is what a working bootrom ,but not the buggy one this tegra hw revision has, should do, but instead of using bit#5, it uses bit#0 of the same register)

What i need to know, is if that workaround in the 1st stage bootloader is in place or not. Without it, there is no way LP0 could work with this A03 tegra revision

Thanks in advance,

Eduardo

PS: Otherwise, i will have to reverse engineer the bootloader.bin to find out

Sounds like you've got a pretty good handle on the situation! :)

I'm not 100% certain, but I don't think that the source code for the bootloader is available. I've never seen it anywhere anyway!

[Guest rebel1]

Hello Eduardo,

I´m fighting at the moment with the nvec. :(

After a longer or shorter time the battery status fails, because:

Pastebin

rebel1

[Guest ejtagle]

Sounds like you've got a pretty good handle on the situation! :)

I'm not 100% certain, but I don't think that the source code for the bootloader is available. I've never seen it anywhere anyway!

Trust me, i wish i had the source code... I have seen that the bootloader was customized by the Shuttle people (you can find strings related to "fred" there... Abd fred was one of the guys behind adaption of android 2.2 to the P10AN01. My current problem is that if no code to workaround the bootrom bug is in the bootloader, then there wont be a way to enable LP0... :S -- And the bootloader is about 1Mbyte of code to disassemble... A lot just to find if a feature is present. As a tip, the .32 kernel didnt use LP0 at all :(

[Guest brucelee666]

Trust me, i wish i had the source code... I have seen that the bootloader was customized by the Shuttle people (you can find strings related to "fred" there... Abd fred was one of the guys behind adaption of android 2.2 to the P10AN01. My current problem is that if no code to workaround the bootrom bug is in the bootloader, then there wont be a way to enable LP0... :S -- And the bootloader is about 1Mbyte of code to disassemble... A lot just to find if a feature is present. As a tip, the .32 kernel didnt use LP0 at all :(

Forgive mey if this is of no use or you have already seen it but I thought it may be of interest:-

A commit made some time ago for the tegra A03 LP0 (I know its for an old kernel and dates back to last year):-

Updated A03 LP0 WAR so that it is not invoked for A03P chip.

@@ static void tegra_setup_warmboot(bool lp0_ok)

* bootrom into performing a regular boot, but pass a flag to the

* bootloader to bypass the kernel reload and jump to the lp0

* restore sequence */

- if (tegra_is_ap20_a03())

+ if (tegra_is_ap20_a03() && (!tegra_is_ap20_a03p()))scratch0 |= (1<<5);elsescratch0 |= 1;

In the original Advent Vega kernel source code suspend.c file there was this:-

static void tegra_setup_warmboot(bool lp0_ok)

{

if (lp0_ok) {

u32 scratch0;

scratch0 = readl(pmc + PMC_SCRATCH0);

/* lp0 restore is broken in the ap20 a03 boot rom, so fake the

* bootrom into performing a regular boot, but pass a flag to the

* bootloader to bypass the kernel reload and jump to the lp0

* restore sequence */

if (tegra_is_ap20_a03() && (!tegra_is_ap20_a03p())) scratch0 |= (1<<5);

else scratch0 |= 1;

pmc_32kwritel(scratch0, PMC_SCRATCH0);

/* Write the AVP warmboot entry address in SCRATCH1 */

pmc_32kwritel(s_AvpWarmbootEntry, PMC_SCRATCH1);

/* Write the CPU LP0 reset vector address in SCRATCH41 */

writel(virt_to_phys(tegra_lp2_startup), pmc + PMC_SCRATCH41); }

else {

/* Setup LP1 start addresses */

writel(TEGRA_IRAM_CODE_AREA, evp_reset);

writel(virt_to_phys(tegra_lp2_startup), pmc + PMC_SCRATCH1); }}

Edited August 14, 2011 by brucelee666

[Guest ejtagle]

Forgive mey if this is of no use or you have already seen it but I thought it may be of interest:-

A commit made some time ago for the tegra A03 LP0 (I know its for an old kernel and dates back to last year):-

Updated A03 LP0 WAR so that it is not invoked for A03P chip.

@@ static void tegra_setup_warmboot(bool lp0_ok)

* bootrom into performing a regular boot, but pass a flag to the

* bootloader to bypass the kernel reload and jump to the lp0

* restore sequence */

- if (tegra_is_ap20_a03())

+ if (tegra_is_ap20_a03() && (!tegra_is_ap20_a03p()))scratch0 |= (1<<5);elsescratch0 |= 1;

In the original Advent Vega kernel source code suspend.c file there was this:-

static void tegra_setup_warmboot(bool lp0_ok)

{

if (lp0_ok) {

u32 scratch0;

scratch0 = readl(pmc + PMC_SCRATCH0);

/* lp0 restore is broken in the ap20 a03 boot rom, so fake the

* bootrom into performing a regular boot, but pass a flag to the

* bootloader to bypass the kernel reload and jump to the lp0

* restore sequence */

if (tegra_is_ap20_a03() && (!tegra_is_ap20_a03p())) scratch0 |= (1<<5);

else scratch0 |= 1;

pmc_32kwritel(scratch0, PMC_SCRATCH0);

/* Write the AVP warmboot entry address in SCRATCH1 */

pmc_32kwritel(s_AvpWarmbootEntry, PMC_SCRATCH1);

/* Write the CPU LP0 reset vector address in SCRATCH41 */

writel(virt_to_phys(tegra_lp2_startup), pmc + PMC_SCRATCH41); }

else {

/* Setup LP1 start addresses */

writel(TEGRA_IRAM_CODE_AREA, evp_reset);

writel(virt_to_phys(tegra_lp2_startup), pmc + PMC_SCRATCH1); }}

Yes, that is exactly the commit that gives the tipo about non working LP0. My main problem right now is that i don-t know if the bootloader used in p10an01 supports this workaround... And i am also trying to figure out how to force the kernel to go into suspend mode... I don-t want to install a full android image right now, as that would make things even more complex ... because if something fails, would not be able to accurately tell if it was the android image or the linux kernel, or the interaction between them :(

[Guest ejtagle]

Hello Eduardo,

I´m fighting at the moment with the nvec. :(

After a longer or shorter time the battery status fails, because:

Pastebin

rebel1

Sorry, i didnt realize you had posted this. NVEC seems to be a pain, sometimes... I'll take a look at your log ... ;)

[Guest brucelee666]

Yes, that is exactly the commit that gives the tipo about non working LP0. My main problem right now is that i don-t know if the bootloader used in p10an01 supports this workaround... And i am also trying to figure out how to force the kernel to go into suspend mode... I don-t want to install a full android image right now, as that would make things even more complex ... because if something fails, would not be able to accurately tell if it was the android image or the linux kernel, or the interaction between them :(

Following from my post above I see in the bootloader.bin file mention of this:-0€»NVRM Initialized shmoo database

NVRM Got shmoo boot argument (at 0x%x)

ActiveIdleAutoHwRM power state before suspend: %s (%d)

Active Module: 0x%x*** Wakeup from LP0 ***

*** Wakeup from LP1 ***

*** Wakeup after Skipped LP0 ***

Also mention of AP20 in bootloader.bin and the amendments made to the suspend.c file.

My question relates to the ap20 folder that is missing from the new kernel builds but is in the original vega kernel, location "arch/arm/mach-tegra/nv/nvrm/core" the ap15 is there in both kernels.

See orignal kernel:- Ap20 original kernel

Was the ap20 no longer required so not added to the new kernel, could the bootloader.bin require something in this directory ?

Seems another silly question as the kernel is booting but with mentions of this and the directory missing just wondering.

[Guest ejtagle]

Following from my post above I see in the bootloader.bin file mention of this:-0€»NVRM Initialized shmoo database

NVRM Got shmoo boot argument (at 0x%x)

ActiveIdleAutoHwRM power state before suspend: %s (%d)

Active Module: 0x%x*** Wakeup from LP0 ***

*** Wakeup from LP1 ***

*** Wakeup after Skipped LP0 ***

Also mention of AP20 in bootloader.bin and the amendments made to the suspend.c file.

My question relates to the ap20 folder that is missing from the new kernel builds but is in the original vega kernel, location "arch/arm/mach-tegra/nv/nvrm/core" the ap15 is there in both kernels.

See orignal kernel:- Ap20 original kernel

Was the ap20 no longer required so not added to the new kernel, could the bootloader.bin require something in this directory ?

Seems another silly question as the kernel is booting but with mentions of this and the directory missing just wondering.

The old folder AP20 is not required anymore. It was there for the previous implementation of drivers, using NvOS. Now the kernel implements all the required drivers natively, so, there is no need for NvOs. But, the older implementation is much better documented than the new one, and includes some workarounds for older hw revisions, such as the one used in P10AN01. So, i use it as reference material when something in the new kernel does not work... ;) (as you know, detailed hw specifications of tegra are only released under an NDA, and just to selected companies :( - So, the older NvOS is the closest we will be to "documentation"

And, just for rebel1, i am looking at the NvEC code right now. Seems the NcEC controller is overloaded by too much consecutive commands, and stops answering them. Really a piece of s*** we have to live with. Working in a workaround to try to recover from those situations. I have found a way, lets hope it will always work. I am testing it now ;)

[Guest ejtagle]

Well, after analyzing the logs supplied by rebel1, i found several bugs in both the NVEC slave i2c implementation and the NVEC battery driver:

1) NVEC is a fragile beast. We have to live with that. It does not tolerate to receive several commands at the same time, otherwise, it tends to hang. So, now, nvec driver serializes access to the communication channel, and will wait until a given command is completely processed and answered by the NVEC controller before issuing the next queued command. Also, a minimum time between commands is enforced, in order to let the NVEC controller recover. This should improve stability of the NVEC controller.

2) Tegra2 i2c slave peripheral (used to communicate with NVEC) has a hardware bug where the exact timing between receiving an interrupt and processing the bytes must be respected... Otherwise, the i2c slave will hang. Enforce that.

3) Improved the state machine used to handle the i2c slave communication, so it is able to recover from synchronization errors quickly. Also added timeouts to force resetting the i2c tegra slave, if it seems to be stuck (hw bug workaround)

4) Fixed the thread used to periodically query for battery information. It wasn't working, so battery status was not being updated.

5) Sustituted several busy loops calls (mdelays) with sleeps (msleeps), so better utilization of cpu processing power is done

Well, hope it works, as it is doing for me

Eduardo

11.2.12-LP0-MMC-DITHER-HOST-SLAVE-USB-NVEC-BATTERY.rar

[Guest Cass67]

Well, after analyzing the logs supplied by rebel1, i found several bugs in both the NVEC slave i2c implementation and the NVEC battery driver:

1) NVEC is a fragile beast. We have to live with that. It does not tolerate to receive several commands at the same time, otherwise, it tends to hang. So, now, nvec driver serializes access to the communication channel, and will wait until a given command is completely processed and answered by the NVEC controller before issuing the next queued command. Also, a minimum time between commands is enforced, in order to let the NVEC controller recover. This should improve stability of the NVEC controller.

2) Tegra2 i2c slave peripheral (used to communicate with NVEC) has a hardware bug where the exact timing between receiving an interrupt and processing the bytes must be respected... Otherwise, the i2c slave will hang. Enforce that.

3) Improved the state machine used to handle the i2c slave communication, so it is able to recover from synchronization errors quickly. Also added timeouts to force resetting the i2c tegra slave, if it seems to be stuck (hw bug workaround)

4) Fixed the thread used to periodically query for battery information. It wasn't working, so battery status was not being updated.

5) Sustituted several busy loops calls (mdelays) with sleeps (msleeps), so better utilization of cpu processing power is done

Well, hope it works, as it is doing for me

Eduardo

Thanks, god knows where we would be if you were not so much on the ball with this stuff .. so thank you again !!

Without wanting to bust your ass, i know you are doing more than exemplary work with all this stuff, but, can you advise as to what the proper volume level would be so as to not blow up the speakers of users wanting to sample all your outstanding work ? i know we keep banging on about it (sorry) but its a small thing that would give so many users so much joy ;)

Thanks (again)

Cass

[Guest ejtagle]

Thanks, god knows where we would be if you were not so much on the ball with this stuff .. so thank you again !!

Without wanting to bust your ass, i know you are doing more than exemplary work with all this stuff, but, can you advise as to what the proper volume level would be so as to not blow up the speakers of users wanting to sample all your outstanding work ? i know we keep banging on about it (sorry) but its a small thing that would give so many users so much joy ;)

Thanks (again)

Cass

I'll try to do the measurements today. Unfortunately, the maximum volume used in the .32 kernel is harcoded inside NvRM_daemon, which is a closed source program we don't have access to.. So, the easiest way seems to actually measure the speaker signal at maximum volume using .32 and the adjusting .36 levels to match it :(

[Guest stiggy2011]

I'll try to do the measurements today. Unfortunately, the maximum volume used in the .32 kernel is harcoded inside NvRM_daemon, which is a closed source program we don't have access to.. So, the easiest way seems to actually measure the speaker signal at maximum volume using .32 and the adjusting .36 levels to match it :(

Just lowering the maximum by an arbitary ~20% or so should be sufficient. If even that much - I've not been able to damage my speakers using the latest build despite my best efforts! I wonder if the issue is related to the headphone output problems? (Whereby on the latest .36 kernel the headphone output is very weak and distorts very easily compared to on the .32 kernel)

You said that the headphone output is using a different amplifier to the speakers but I wonder if there is an issue with the signal becoming clipped pre-amplification? After all, a clipped output will need a much lower wattage to kill speakers than a clean one!

[Guest ejtagle]

Just lowering the maximum by an arbitary ~20% or so should be sufficient. If even that much - I've not been able to damage my speakers using the latest build despite my best efforts! I wonder if the issue is related to the headphone output problems? (Whereby on the latest .36 kernel the headphone output is very weak and distorts very easily compared to on the .32 kernel)

You said that the headphone output is using a different amplifier to the speakers but I wonder if there is an issue with the signal becoming clipped pre-amplification? After all, a clipped output will need a much lower wattage to kill speakers than a clean one!

I have seen that in the latest image builds they have changed, not only the maximum volume, but also the bias voltage. That is an error that actually CAUSES clipping .. The vdd settings i have used for the kernel must be kept the way they are! --- The ONLY setting that can be adjusted is the maximum volume... vdd is FIXED by the hardware design , and platform data MUST match the hardwre design - That is why vdd settings of the ALC should not be modified.

Regards,

Eduardo!