Jump to content


Photo

Advent Vega kernel source code now available!


  • Please log in to reply
2860 replies to this topic

#361
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

...

The Speaker issue is a little different, a tearing cone or burned out winding is clearly too much power going to the speaker unit. The ALC5624 has two circuits for the speaker and headphone drivers potentially operating at different voltages (although they do both have an overlap voltage of 3-3.6v, and a nominal voltage of 3.3v is usually used) . I'm not sure if the Vega has a secondary amp but the 1.7W on chip speaker driver, should be plenty. So unless the speakers really are crap, It's odd that the chip should even be able to output enough power to do damage .....
I've had a quick, and I do mean quick skim of the data sheet, so forgive me if this is completely wrong ot unrelated ... but
If the chip was set to the wrong mode Class AD/Class D would this would effect the load to the speakers and, I guess, overload the chip a bit? like adding the wrong impedance speakers to an amp. I'm no speaker/audio expert but doesn't the speaker class also effect things like what state the speaker/amp is in with no signal, so possibly overloading it even if the sound is muted???
I'd be interested to see if swapping the speakers over shows the channel with the damaged speaker to work again, as the headphones run on a different driver this wouldn't show if the internal speaker driver had blown a channel.


No external amplifiers. They use jut the ALC main amplifier for the speakers (1Wrms per channel) and the auxiliary amplifier for the headphones. I will try to measure if DC is present across the speaker coils.. I had no time until now... Busy writing the config-peek module for the .32 kernel.

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#362
brucelee666

brucelee666

    Enthusiast

  • Members
  • PipPipPip
  • 203 posts
  • Devices:Advent Vega
I know your looking into other things but regarding the reboot problem

Have you seen this or tried updating the file mentioned

restore voltage to nominal when reboot patch on 11.2.11 commit



  • 0

#363
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

I know your looking into other things but regarding the reboot problem

Have you seen this or tried updating the file mentioned

restore voltage to nominal when reboot patch on 11.2.11 commit





Well, if we succeed to boot he 11.2.11 nvidia tegra2 kernel, we will get this patch already applied. But, until now, it refuses to boot. Will try to find out why. The reboot failure problably is caused by the same problem that is making LP0 (super low power) suspend not to work ... I will continue investigation


  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#364
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

We can't go incrementally from the working kernel to the 11.2.11 kernel as I have tried that myself, some patches fail and some patches simply result in garbled output on the screen. Our kernel was an older version of 11.2.x and then got updated to 11.2.4.


The kernel we have hasn't got all the patches which were added to the nvidia repo up to 11.2.4. Some patches haven't been merged as there were changes made to the source and they failed to apply.


It doesn't seem like it's so easy to find what broke it. Perhaps we should use git bisect between 11.2.4 and 11.2.11?
What's so special about the 11.2.4+ we have? It easily gets broken by any patch from the repository.
...


two approaches would be great to try:
1) , get the original 11.2.4 and port the vega drivers to it (should require nearly no change at all) ... to make sure that the unmodified 11.2.4 boots as the booting .36 kernel we have... If it does not boot, we could do a diff between the booting .36 and the 11.2.4 to know exactly what has beeen changed.
2) If the unmodified 11.2.4 with added vega support works, then we can do the git bisect...

Either or it is something very silly, or something very severe (such as a gcc bug triggered by some specific sequence of code :( )

Eduardo

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#365
Cass67

Cass67

    Diehard

  • Members
  • PipPipPipPip
  • 408 posts

look into bma150.c, for

ctx->input->name = "bma150"

Instead of "bma150", it should be "accelerometer_tegra" if you want sensors.tegra.so to recognize the accelerometer automatically ..

Or edit the library replacing "accelerometer_tegra" by "bma150" . Be creful there, as there is a "tegra_accelerometer" that must NOT be changed!




Hi Eduardo,

Thanks for the info the other day, seems Android detects the sensor now .. However it still does not work, and after a pile of looking and playing im not sure if its a kernel issue, we are not initializing something or if we have an Android issue that's maybe hard to resolve without source ..

http://pastebin.com/7V24zFKv

Ive tried as many combinations of libs from transformer to iconia builds and i fail ....

Any ideas looking at this if this could be a kernel issue still ?

Im struggling to find anything on the last vendor messages from the paste...


EDIT:- Should also add, Android app AndroSensor detects the sensors now, accel, gyro ,magnetic field and orientation but just is not able to receive events .. so we are advanced a bit from the other day..


Cheers
Cass

Edited by Cass67, 09 August 2011 - 02:14 AM.

  • 0

#366
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

two approaches would be great to try:
1) , get the original 11.2.4 and port the vega drivers to it (should require nearly no change at all) ... to make sure that the unmodified 11.2.4 boots as the booting .36 kernel we have... If it does not boot, we could do a diff between the booting .36 and the 11.2.4 to know exactly what has beeen changed.
2) If the unmodified 11.2.4 with added vega support works, then we can do the git bisect...

Either or it is something very silly, or something very severe (such as a gcc bug triggered by some specific sequence of code :( )

Eduardo



UPDATE!: Very good news! -- Now i finally realized what was the cause preventing the 11.2.11 kernel from booting (thanks video camera! - I had to do a video recording of the framebuffer while it was displaying the boot messages... And the last line was "... disabling unneeded voltage regulators left on by bootloader..." ... I may say... inspiring phrase... I decided to leave the regulators that the bootloader enables, enabled. And that was all that was required.

The 11.2.11 kernel boots, and as a curiosity, the reboot process also started to work :)

I still have to investigate if LP0 suspend is working or not. I left it disabled by now, but, you can try it. Just comment the line
tegra_lp0_vec_start = tegra_lp0_vec_size = 0;
in board-shuttle.c so the kernel command line parser passes the LP0 vector found to the kernel itself. Maybe the LP0 is also working :D

Attached the updated files with the proper tables for the voltage regulators. You should get the 11.2.11 nvidia kernel and just overwrite with the supplied files and compile!

Well, hope we are much closer ... still, we have to investigate the ultra-loud speaker volume issue ...

Regards,
Eduardo

Attached Files


  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#367
a_appleby

a_appleby

    Regular

  • Members
  • PipPip
  • 56 posts

UPDATE!: Very good news! -- Now i finally realized what was the cause preventing the 11.2.11 kernel from booting (thanks video camera! - I had to do a video recording of the framebuffer while it was displaying the boot messages... And the last line was "... disabling unneeded voltage regulators left on by bootloader..." ... I may say... inspiring phrase... I decided to leave the regulators that the bootloader enables, enabled. And that was all that was required.

The 11.2.11 kernel boots, and as a curiosity, the reboot process also started to work :)

I still have to investigate if LP0 suspend is working or not. I left it disabled by now, but, you can try it. Just comment the line
tegra_lp0_vec_start = tegra_lp0_vec_size = 0;
in board-shuttle.c so the kernel command line parser passes the LP0 vector found to the kernel itself. Maybe the LP0 is also working :D

Attached the updated files with the proper tables for the voltage regulators. You should get the 11.2.11 nvidia kernel and just overwrite with the supplied files and compile!

Well, hope we are much closer ... still, we have to investigate the ultra-loud speaker volume issue ...

Regards,
Eduardo


I tried it out. It keeps dying in init with an init: untracked pid 93 exited error. It keeps doing this forever.
The kernel was also unable to set the pclk.

  • 0

#368
BillyBobJoe

BillyBobJoe

    Regular

  • Members
  • PipPip
  • 65 posts
  • Devices:Advent Vega
Hey Ed and everybody,

Couldn't get to sleep last night so started to read the ALC5624 data sheet from Realtek, I haven't finished so don't spoil the ending I'm guessing the butler did it.

After looking at the data sheet and Eduardo's driver have come to the belief that we just need to change one line:
static struct alc5624_platform_data alc5624_pdata = {
#if LINUX_VERSION_CODE == KERNEL_VERSION(2,6,36)
.mclk = "clk_dev1",
#else
.mclk = "cdev1",
#endif
.spkvdd_mv = 5000, /* Speaker Vdd in millivolts */
.hpvdd_mv = 3300, /* Headphone Vdd in millivolts */
};

"Recommended Operating Conditions

Parameter Symbol Min Typ Max Units
Analog AVDD1, AVDD2 2.3 3.3 3.6 V
Headphone HPVDD 2.3 3.3 3.6 V
Speaker SPKVDD1 2.3 3.3 5 V

Note 1: A 10μF Capacitor must be connected from SPKVDD to SPKGND, and should be placed as close as possible to
the SPKVDD pin of the ALC5624.
"


If we change the SPKVdd to 3.3V rather than the 5V as the spec says that this could spike to 8V and still be within normal working range.

Now with the couple of quick changes to the kernel config we should be looking good. If someone else has any suggestions feel free to let me know.

My earlier question regards the headphones was to see if there was a shared 10uF capacitor or if there used a separate one for each output. My concern was that the chip had been damaged but it is very had to tell without actually having a broken one to play with.
I am hoping that the speakers are so bad that they break first.

Billy..

Edited by BillyBobJoe, 09 August 2011 - 08:36 AM.

  • 0

#369
rebel1

rebel1

    Regular

  • Members
  • PipPip
  • 87 posts
  • Gender:Male
  • Devices:PoV Mobii, HTC Desire Z
  • Twitter:@renebensch

I tried it out. It keeps dying in init with an init: untracked pid 93 exited error. It keeps doing this forever.
The kernel was also unable to set the pclk.


Hi,
i can confirm, that we have some problems with the clocks.

<4>[	7.031900] Unable to set parent sclk of clock avp.sclk: -38
<4>[	7.033274] Unable to initialize clock pll_e
<4>[	7.033768] Unable to set clock clk_dev1 to rate 11289600: -38
<4>[	7.033792] Unable to set clock clk_dev2 to rate 24000000: -38
<4>[	7.033908] Unable to set clock dsi to rate 1000000: -22
<4>[	7.034026] Unable to find parent clk_p of clock sdmmc2
.....
<6>[	8.035063] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<3>[	8.035219] Failed to set 1 : 2 pclk divider
<3>[	8.072209] ulpi_phy_power_on: timeout waiting for phy clock to                                               	start
<3>[	8.077982] ulpi_phy_power_on: ulpi write failed
<3>[	8.078008] tegra-ehci tegra-ehci.1: Failed to power on the phy
<4>[	8.078074] tegra-ehci: probe of tegra-ehci.1 failed with error -110
<3>[	8.078181] Failed to set 1 : 2 pclk divider
....
<3>[	8.129385] Failed to set 1 : 2 pclk divider
<3>[	8.129419] Failed to set 1 : 2 pclk divider
....
<3>[   31.321780] tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK



Full paste

  • 0

#370
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

I tried it out. It keeps dying in init with an init: untracked pid 93 exited error. It keeps doing this forever.
The kernel was also unable to set the pclk.



... but the kernel itself boots. There is no hardware lockup. I can confirm that using busybox as the shell, you are able to reach a console, issue commands, etc,etc..
The message you are getting is output by the init process (in userspace)... seems it is trying to launch another process at init time, and that process is dying unexpectly... Now, we should try to find out the process itself. Perhaps some android component depends on an specific version of the kernel ?

Hey Ed and everybody,

Couldn't get to sleep last night so started to read the ALC5624 data sheet from Realtek, I haven't finished so don't spoil the ending I'm guessing the butler did it.

After looking at the data sheet and Eduardo's driver have come to the belief that we just need to change one line:
static struct alc5624_platform_data alc5624_pdata = {
#if LINUX_VERSION_CODE == KERNEL_VERSION(2,6,36)
.mclk = "clk_dev1",
#else
.mclk = "cdev1",
#endif
.spkvdd_mv = 5000, /* Speaker Vdd in millivolts */
.hpvdd_mv = 3300, /* Headphone Vdd in millivolts */
};

"Recommended Operating Conditions

Parameter Symbol Min Typ Max Units
Analog AVDD1, AVDD2 2.3 3.3 3.6 V
Headphone HPVDD 2.3 3.3 3.6 V
Speaker SPKVDD1 2.3 3.3 5 V

Note 1: A 10μF Capacitor must be connected from SPKVDD to SPKGND, and should be placed as close as possible to
the SPKVDD pin of the ALC5624.
"


If we change the SPKVdd to 3.3V rather than the 5V as the spec says that this could spike to 8V and still be within normal working range.

Now with the couple of quick changes to the kernel config we should be looking good. If someone else has any suggestions feel free to let me know.

My earlier question regards the headphones was to see if there was a shared 10uF capacitor or if there used a separate one for each output. My concern was that the chip had been damaged but it is very had to tell without actually having a broken one to play with.
I am hoping that the speakers are so bad that they break first.

Billy..


.. i have still to measure things, but.. there are separate physical outputs for headphones and for speakers. Speakers do not need a capacitor in series (though it shoudn't hurt. I have to measure if there is a capacitor or not in series with speakers) .. The ALC has 2 separate amplifiers. The headphone one is just very standard. Just 2 outputs (left and right), Low power... And uses HPVDD as its power supply. On the Vega, the HPVDD pin of the ALC is tied to +3v
The speaker amplifier has 4 outputs (two for each channel, and can be used as in a half bridge configuration (just connecting , for each channel, left, and right. one of the amplifier outputs through a capacitor to one of the speaker terminat, and the other speaker terminal to ground, or it can be used as a full bridge amplifier, coneecting one terminal of the speaker to one of the terminals of the amplifier, and the other terminal to the other terminal of the same channel amplifier. In tis way, you can reach 1Wrms per speaker. This amplifier uses SPKVDD as power supply, and in the vega, it is tied to +5v.

I have still to measure out the exact connections being used in vega to connect the speakers... This is probably the next task i will do...

Hi,
i can confirm, that we have some problems with the clocks.

<4>[	7.031900] Unable to set parent sclk of clock avp.sclk: -38
<4>[	7.033274] Unable to initialize clock pll_e
<4>[	7.033768] Unable to set clock clk_dev1 to rate 11289600: -38
<4>[	7.033792] Unable to set clock clk_dev2 to rate 24000000: -38
<4>[	7.033908] Unable to set clock dsi to rate 1000000: -22
<4>[	7.034026] Unable to find parent clk_p of clock sdmmc2
.....
<6>[	8.035063] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<3>[	8.035219] Failed to set 1 : 2 pclk divider
<3>[	8.072209] ulpi_phy_power_on: timeout waiting for phy clock to                                   				start
<3>[	8.077982] ulpi_phy_power_on: ulpi write failed
<3>[	8.078008] tegra-ehci tegra-ehci.1: Failed to power on the phy
<4>[	8.078074] tegra-ehci: probe of tegra-ehci.1 failed with error -110
<3>[	8.078181] Failed to set 1 : 2 pclk divider
....
<3>[	8.129385] Failed to set 1 : 2 pclk divider
<3>[	8.129419] Failed to set 1 : 2 pclk divider
....
<3>[   31.321780] tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK



Full paste



You are right... there are still clock issues. The tegra2 clock table should be right as it is right now (it was dumped from a running .32 kernel), but the .36 kernel still does not support some of those combinations. I will take a look to see if they are important or not... But, as i said before, the problems we are having right now are not caused by a non-booting kernel, rather than, they are caused by some android component (probably a daemon that refuses to load at init time) that does not like the new kernel... or perhaps a kernel config issue...

Will continue investigation. Just take into account that my testing platform is busybox, not android at this time ;) (i have to isolate the problems.. either they are kernel related, or android related. Using android to try the kernel does not allow me to separate causes :) )

On a second look, seems the new clock table configuration (extracted from the .32 kernel) that we are now using, is not completely supported by the .36 kernel. So, audio seems not to be initializing properly (i found out by looking at your latest log). As a workaround, you can use an older board-shuttle-clocks.c ... The one we used for the booting .36 kernel. That config was supported by the kernel. Later, i will take a look to either add the missing support for this (.32) clock config to the 11.2.11, or to just revert to the previous clock table (i have no reason to believe the older clock table is worse than current one, quite in fact, i do suspect it is better :) ) ... And the bug of the tps6586x-rtc.. seems someone is trying to set an invalid date :S ... Quite strange thing! - Didn't happebn to me. Will take also a look later.
All the problems we have right now, trust me, they are not big problems at all. What i was mostly worried about was on hardware lookups. But this is not the case right now :) -- All the other things are relatively easy to fix - mostly minor configuration adjustments ... with no guessing involved :)

Edited by ejtagle, 09 August 2011 - 02:04 PM.

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#371
newbe5

newbe5

    Addict

  • Developer Team
  • PipPipPipPipPip
  • 592 posts

... but the kernel itself boots. There is no hardware lockup. I can confirm that using busybox as the shell, you are able to reach a console, issue commands, etc,etc..
The message you are getting is output by the init process (in userspace)... seems it is trying to launch another process at init time, and that process is dying unexpectly... Now, we should try to find out the process itself. Perhaps some android component depends on an specific version of the kernel ?



.. i have still to measure things, but.. there are separate physical outputs for headphones and for speakers. Speakers do not need a capacitor in series (though it shoudn't hurt. I have to measure if there is a capacitor or not in series with speakers) .. The ALC has 2 separate amplifiers. The headphone one is just very standard. Just 2 outputs (left and right), Low power... And uses HPVDD as its power supply. On the Vega, the HPVDD pin of the ALC is tied to +3v
The speaker amplifier has 4 outputs (two for each channel, and can be used as in a half bridge configuration (just connecting , for each channel, left, and right. one of the amplifier outputs through a capacitor to one of the speaker terminat, and the other speaker terminal to ground, or it can be used as a full bridge amplifier, coneecting one terminal of the speaker to one of the terminals of the amplifier, and the other terminal to the other terminal of the same channel amplifier. In tis way, you can reach 1Wrms per speaker. This amplifier uses SPKVDD as power supply, and in the vega, it is tied to +5v.

I have still to measure out the exact connections being used in vega to connect the speakers... This is probably the next task i will do...




You are right... there are still clock issues. The tegra2 clock table should be right as it is right now (it was dumped from a running .32 kernel), but the .36 kernel still does not support some of those combinations. I will take a look to see if they are important or not... But, as i said before, the problems we are having right now are not caused by a non-booting kernel, rather than, they are caused by some android component (probably a daemon that refuses to load at init time) that does not like the new kernel... or perhaps a kernel config issue...

Will continue investigation. Just take into account that my testing platform is busybox, not android at this time ;) (i have to isolate the problems.. either they are kernel related, or android related. Using android to try the kernel does not allow me to separate causes :) )

On a second look, seems the new clock table configuration (extracted from the .32 kernel) that we are now using, is not completely supported by the .36 kernel. So, audio seems not to be initializing properly (i found out by looking at your latest log). As a workaround, you can use an older board-shuttle-clocks.c ... The one we used for the booting .36 kernel. That config was supported by the kernel. Later, i will take a look to either add the missing support for this (.32) clock config to the 11.2.11, or to just revert to the previous clock table (i have no reason to believe the older clock table is worse than current one, quite in fact, i do suspect it is better :) ) ... And the bug of the tps6586x-rtc.. seems someone is trying to set an invalid date :S ... Quite strange thing! - Didn't happebn to me. Will take also a look later.
All the problems we have right now, trust me, they are not big problems at all. What i was mostly worried about was on hardware lookups. But this is not the case right now :) -- All the other things are relatively easy to fix - mostly minor configuration adjustments ... with no guessing involved :)



Are you placing the overheating speaker issue in the "not big problems" pot? Do you think you have a cast iron solution for this? I apologise but I am a little out of the loop right now. My wife is in hospital and I do not have much time to work on Android unfortunately.

newbe5


  • 0

#372
rebel1

rebel1

    Regular

  • Members
  • PipPip
  • 87 posts
  • Gender:Male
  • Devices:PoV Mobii, HTC Desire Z
  • Twitter:@renebensch

... but the kernel itself boots. There is no hardware lockup. I can confirm that using busybox as the shell, you are able to reach a console, issue commands, etc,etc..
The message you are getting is output by the init process (in userspace)... seems it is trying to launch another process at init time, and that process is dying unexpectly... Now, we should try to find out the process itself. Perhaps some android component depends on an specific version of the kernel ?



.. i have still to measure things, but.. there are separate physical outputs for headphones and for speakers. Speakers do not need a capacitor in series (though it shoudn't hurt. I have to measure if there is a capacitor or not in series with speakers) .. The ALC has 2 separate amplifiers. The headphone one is just very standard. Just 2 outputs (left and right), Low power... And uses HPVDD as its power supply. On the Vega, the HPVDD pin of the ALC is tied to +3v
The speaker amplifier has 4 outputs (two for each channel, and can be used as in a half bridge configuration (just connecting , for each channel, left, and right. one of the amplifier outputs through a capacitor to one of the speaker terminat, and the other speaker terminal to ground, or it can be used as a full bridge amplifier, coneecting one terminal of the speaker to one of the terminals of the amplifier, and the other terminal to the other terminal of the same channel amplifier. In tis way, you can reach 1Wrms per speaker. This amplifier uses SPKVDD as power supply, and in the vega, it is tied to +5v.

I have still to measure out the exact connections being used in vega to connect the speakers... This is probably the next task i will do...




You are right... there are still clock issues. The tegra2 clock table should be right as it is right now (it was dumped from a running .32 kernel), but the .36 kernel still does not support some of those combinations. I will take a look to see if they are important or not... But, as i said before, the problems we are having right now are not caused by a non-booting kernel, rather than, they are caused by some android component (probably a daemon that refuses to load at init time) that does not like the new kernel... or perhaps a kernel config issue...

Will continue investigation. Just take into account that my testing platform is busybox, not android at this time ;) (i have to isolate the problems.. either they are kernel related, or android related. Using android to try the kernel does not allow me to separate causes :) )

On a second look, seems the new clock table configuration (extracted from the .32 kernel) that we are now using, is not completely supported by the .36 kernel. So, audio seems not to be initializing properly (i found out by looking at your latest log). As a workaround, you can use an older board-shuttle-clocks.c ... The one we used for the booting .36 kernel. That config was supported by the kernel. Later, i will take a look to either add the missing support for this (.32) clock config to the 11.2.11, or to just revert to the previous clock table (i have no reason to believe the older clock table is worse than current one, quite in fact, i do suspect it is better :) ) ... And the bug of the tps6586x-rtc.. seems someone is trying to set an invalid date :S ... Quite strange thing! - Didn't happebn to me. Will take also a look later.
All the problems we have right now, trust me, they are not big problems at all. What i was mostly worried about was on hardware lookups. But this is not the case right now :) -- All the other things are relatively easy to fix - mostly minor configuration adjustments ... with no guessing involved :)


Hi,
it seems that i have forget to say, that i have tested the "older" clock configuration, too.
But unfortunately:

<4>[	5.413082] Unable to set clock hclk to rate 108000000: -22
<4>[	5.413110] Unable to set clock pclk to rate 54000000: -22
<4>[	5.414597] Unable to set clock clk_dev1 to rate 11289600: -38
<4>[	5.414616] Unable to set clock clk_dev2 to rate 26000000: -38
<4>[	5.414709] Unable to set clock dsi to rate 5000000: -22

Full Log

  • 0

#373
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

Are you placing the overheating speaker issue in the "not big problems" pot? Do you think you have a cast iron solution for this? I apologise but I am a little out of the loop right now. My wife is in hospital and I do not have much time to work on Android unfortunately.

newbe5


Yes, i do not consider that problem as a big problem. Don't take it wrong: The problem is really important, but the solution should not be hard. From all that i have read and heard, seems to be just caused by programming the ALC to a higher volume that was possible with the .32 kernel (probably limited on purpose in the .32 kernel, but there is no way to check that,as the software component responsible of setting the volume in .32 is a closed source daemon called nvrm_daemon.
But, i do recall that the new .36 kernel sound output is much louder than the .32 kernel. And much louder means very much higher power output to the speakers (remember, humans are sensible to the logrithm of real power, so an apparent perceived increase of sound pressure level (=volume) of 3 times, means more than 10 times the original power to the speakers. I cause i will take care of this - Don't worry. It is on my list :)



  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#374
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

Hi,it seems that i have forget to say, that i have tested the "older" clock configuration, too.But unfortunately:

<4>[	5.413082] Unable to set clock hclk to rate 108000000: -22<4>[	5.413110] Unable to set clock pclk to rate 54000000: -22<4>[	5.414597] Unable to set clock clk_dev1 to rate 11289600: -38<4>[	5.414616] Unable to set clock clk_dev2 to rate 26000000: -38<4>[	5.414709] Unable to set clock dsi to rate 5000000: -22
Full Log



Yes, this is also in my todo list. This is more a limitation of the .36 kernel than a real problem.. But, just to be sure, i will take a look :)


UPDATE: I just looked at your log: One line calls my attention:


tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK

Please, do me a favor. Use the old board-shuttle-clocks.c for the booting kernel, and also change the following line in board-shuttle-pinmux.c:
in the line:
{TEGRA_PINGROUP_CDEV1, TEGRA_MUX_OSC, ...
Change
TEGRA_MUX_OSC to TEGRA_MUX_PLLA_OUT

The .36 kernel requires TEGRA_PINGROUP_CDEV1 to output TEGRA_MUX_PLLA_OUT . otherwise, audio stops working. The previous .32 kernel seems not to require it. You should get no ALSA related errors with those modifications

Edited by ejtagle, 09 August 2011 - 03:21 PM.

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#375
a_appleby

a_appleby

    Regular

  • Members
  • PipPip
  • 56 posts

Yes, this is also in my todo list. This is more a limitation of the .36 kernel than a real problem.. But, just to be sure, i will take a look :)


UPDATE: I just looked at your log: One line calls my attention:


tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK

Please, do me a favor. Use the old board-shuttle-clocks.c for the booting kernel, and also change the following line in board-shuttle-pinmux.c:
in the line:
{TEGRA_PINGROUP_CDEV1, TEGRA_MUX_OSC, ...
Change
TEGRA_MUX_OSC to TEGRA_MUX_PLLA_OUT

The .36 kernel requires TEGRA_PINGROUP_CDEV1 to output TEGRA_MUX_PLLA_OUT . otherwise, audio stops working. The previous .32 kernel seems not to require it. You should get no ALSA related errors with those modifications



I have tried, as you recommended, to build a kernel with the old working board-shuttle-clocks.c and the change you said we should make. I've changed TEGRA_MUX_OSC at line 35 of board-shuttle-pinmux.c to TEGRA_MUX_PLLA_OUT.


I couldn't get an adb connection with that setup, the usb device was registering for 0.5-1 seconds and was going away.

Edited by a_appleby, 09 August 2011 - 06:48 PM.

  • 0

#376
rebel1

rebel1

    Regular

  • Members
  • PipPip
  • 87 posts
  • Gender:Male
  • Devices:PoV Mobii, HTC Desire Z
  • Twitter:@renebensch



Please, do me a favor. Use the old board-shuttle-clocks.c for the booting kernel, and also change the following line in board-shuttle-pinmux.c:
in the line:
{TEGRA_PINGROUP_CDEV1, TEGRA_MUX_OSC, ...
Change
TEGRA_MUX_OSC to TEGRA_MUX_PLLA_OUT

The .36 kernel requires TEGRA_PINGROUP_CDEV1 to output TEGRA_MUX_PLLA_OUT . otherwise, audio stops working. The previous .32 kernel seems not to require it. You should get no ALSA related errors with those modifications


Hi,
i tested it with old and new clock table, and can confirm that the alsa device is now online. Unfortunately you can hear it when it is initialized and i can´t see that message about tegra_hifi_hw_params(). ;)

But i found another different problem, the sdcard is not detected by the kernel.

  • 0

#377
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10

Hi,
i tested it with old and new clock table, and can confirm that the alsa device is now online. Unfortunately you can hear it when it is initialized and i can´t see that message about tegra_hifi_hw_params(). ;)

But i found another different problem, the sdcard is not detected by the kernel.


I am tempted to tell you to also try the older board-shuttle-pinmux.c file ... The problems preventing the kernel to boot was in board-shuttle-power.c - nowadays i don't think the pinmux had something to do with the nonbooting kernel :) -- It was just a voltage regulator turning off :D

Thanks a lot for your patience :D

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#378
a_appleby

a_appleby

    Regular

  • Members
  • PipPip
  • 56 posts

I am tempted to tell you to also try the older board-shuttle-pinmux.c file ... The problems preventing the kernel to boot was in board-shuttle-power.c - nowadays i don't think the pinmux had something to do with the nonbooting kernel :) -- It was just a voltage regulator turning off :D

Thanks a lot for your patience :D


I've tried it and the bars are back. It's just like the working one with some random patches applied.

  • 0

#379
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10
In any case, i will try all those mods myself in a few hours (when i return back home from work ;) )

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted

#380
ejtagle

ejtagle

    Addict

  • Members
  • PipPipPipPipPip
  • 871 posts
  • Gender:Male
  • Devices:POV Mobii / N10
So, seems there is a problem with pinmux, after all. Now, that i remember, when i peeked the .32 configuration (using the new written module), i wasn't using the SD card at that time .. :( -- Perhaps, that is the cause for the SDcard not working.. One of the problems with capturing the config of the .32 kernel is that any device not being used, is not enabled, so the pinmux configuration for that device is not set properly... guess i will have to capture it again :(

  • 0
if you feel the urge to send gratitude to me and you want to express it with a donation, you can do so here:

https://www.paypal.c...G.gif:NonHosted




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users