Re: FSO Milestone 5.1
Nils Faerber schrieb: > OK, here is the console patch ;) > It introduces a new kernel config option which should then NOT be set in > order to avoid VT switch upon suspend. > The defconfig-gta01 in the source tarball seems to be a little outdated > and that's why I cannot really give a good new defconfig. > > Feel free to push that patch upstream (or tell me where best to push > it). This patch is against > > git_git.openmoko.org.git.kernel.git_fb42ce6724576fc173faf8abfb04aa2c36d213b7.tar.gz > > (which is the 2.6.24 shipped with MS5.1). I just tried the same "trick" with 2.6.29 from GIT for GTA02 (andy-tracking) and it failed - more or less. It works as expected but the kernel seems to crash short after resume, i.e. the GUI is displayed again but nothing work anymore, not touchscreen and not USB networking so I cannot really tell (yet) what exactly fails. So with GTA02 something needs to have the console switch on suspend or resume - perhaps GLAMO? Cheers nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Nils Faerber schrieb: > Michael 'Mickey' Lauer schrieb: >> Am Dienstag, den 03.03.2009, 02:17 +0100 schrieb Nils Faerber: >>> Michael 'Mickey' Lauer schrieb: Am Dienstag, den 03.03.2009, 01:59 +0100 schrieb Nils Faerber: > ... > So this looks pretty sane to me? Good to hear, so it works for 01 and 2.6.24. >>> Well - to a certain extend since the battery applet does not cooperate >>> with it. >> Ah that, well, that's Enlightenment using the wrong driver or so :) > Oh well - that took a while ;) > I don't know enlightenment enough - does it have a runtime config that > could be tweaked to make it work again? > It must have been a change introduced from MS4.1 to MS5.0... I tried to find something like a config file for the battery applet but to no avail. The only file I could find was a .cfg file but that was a binary file!? The sysfs for the battery work correctly and also "apm" (yuk) reports the battery correctly. > Cheers > nils Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Michael 'Mickey' Lauer schrieb: > Am Dienstag, den 03.03.2009, 02:17 +0100 schrieb Nils Faerber: >> Michael 'Mickey' Lauer schrieb: >>> Am Dienstag, den 03.03.2009, 01:59 +0100 schrieb Nils Faerber: ... So this looks pretty sane to me? >>> Good to hear, so it works for 01 and 2.6.24. >> Well - to a certain extend since the battery applet does not cooperate >> with it. > Ah that, well, that's Enlightenment using the wrong driver or so :) Ah! Oh well - that took a while ;) I don't know enlightenment enough - does it have a runtime config that could be tweaked to make it work again? It must have been a change introduced from MS4.1 to MS5.0... Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Mike (mwester) schrieb: > Michael 'Mickey' Lauer wrote: >> To make it more complicated, GTA02 can work with both the new ones (for >> which we have a power class supply driver), but also with the old ones. >> Since GTA02 has a different PMU, we need a completely different driver >> for GTA01's dumb batteries in GTA02. >> >> I don't know whether mike is still interested in working on that. > > Alas, Mike is lacking in free time. :-( > > I did take a look at the drivers; it's non-trivial because we cannot > simply "graft" in a new dumb-battery driver to take over for the GTA02's > smart battery driver -- it would be necessary to make the GTA02's > existing driver understand the situation where it has no smart battery > and have it synthesize the appropriate information from the PMU instead. > > If someone would like to take a hack at doing this, I'll be happy to > provide what help I can. I have a couple of GTA01 batteries and a bl-6c > that I'd like to see working in the GTA02 as well! Ah, OK, slowly I start to understand. Pitily I won't be able to help here since I do not have a GTA02, just the GTA01B-V3 and -V4 (which I would like to revive as development devices a little, hence my hacking ;) My questions around batteries just came up because while updating from MS4.1 to MS5.0 and MS5.1 caused the battery indicator (on the GUI panel) to display a false "charging" state regardless of the actual state. So I suspect that we are actually not seeing a kernel problem here but rather a problem of the framework not finding the GTA01 battery anymore? Again this is an actual GTA01 device not a GTA01 battery in a GTA02 device ;) > -Mike (mwester) Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Am Dienstag, den 03.03.2009, 02:17 +0100 schrieb Nils Faerber: > Michael 'Mickey' Lauer schrieb: > > Am Dienstag, den 03.03.2009, 01:59 +0100 schrieb Nils Faerber: > BTW: Could you briefly explain the battery class problem? Probably I can > fix that too... > >>> mwester did a power class supply driver for the GTA01's dumb batteries > >>> once -- I'm not sure whether this needs adjusting for 2.6.28. > >>> > >>> To make it more complicated, GTA02 can work with both the new ones (for > >>> which we have a power class supply driver), but also with the old ones. > >>> Since GTA02 has a different PMU, we need a completely different driver > >>> for GTA01's dumb batteries in GTA02. > >>> > >>> I don't know whether mike is still interested in working on that. > >> Hmm...I am not fully familiar with those class interfaces but looking at > >> > >> /sys/devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 > >> > >> seems to output pretty reasonable values and > >> > >> /sys/class/power_supply/ > >> > >> has > >> > >> bat-th-gta01 -> > >> ../../devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 > >> > >> So this looks pretty sane to me? > > > > Good to hear, so it works for 01 and 2.6.24. > > Well - to a certain extend since the battery applet does not cooperate > with it. Ah that, well, that's Enlightenment using the wrong driver or so :) -- :M: ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Michael 'Mickey' Lauer schrieb: > Am Dienstag, den 03.03.2009, 01:59 +0100 schrieb Nils Faerber: BTW: Could you briefly explain the battery class problem? Probably I can fix that too... >>> mwester did a power class supply driver for the GTA01's dumb batteries >>> once -- I'm not sure whether this needs adjusting for 2.6.28. >>> >>> To make it more complicated, GTA02 can work with both the new ones (for >>> which we have a power class supply driver), but also with the old ones. >>> Since GTA02 has a different PMU, we need a completely different driver >>> for GTA01's dumb batteries in GTA02. >>> >>> I don't know whether mike is still interested in working on that. >> Hmm...I am not fully familiar with those class interfaces but looking at >> >> /sys/devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 >> >> seems to output pretty reasonable values and >> >> /sys/class/power_supply/ >> >> has >> >> bat-th-gta01 -> >> ../../devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 >> >> So this looks pretty sane to me? > > Good to hear, so it works for 01 and 2.6.24. Well - to a certain extend since the battery applet does not cooperate with it. > What we'd love to have now is confirmation (or patches ;) for: > > 01 and 2.6.29 > > 02 and 2.6.29 Uh, OK. Never tried any newer kernel on my GTA01s. And beware - the before mentioned console patch was also for 2.6.24 not 2.6.29 (though it should almost apply or be simple to make it apply). > Cheers, Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Am Dienstag, den 03.03.2009, 01:59 +0100 schrieb Nils Faerber: > >> BTW: Could you briefly explain the battery class problem? Probably I can > >> fix that too... > > > > mwester did a power class supply driver for the GTA01's dumb batteries > > once -- I'm not sure whether this needs adjusting for 2.6.28. > > > > To make it more complicated, GTA02 can work with both the new ones (for > > which we have a power class supply driver), but also with the old ones. > > Since GTA02 has a different PMU, we need a completely different driver > > for GTA01's dumb batteries in GTA02. > > > > I don't know whether mike is still interested in working on that. > > Hmm...I am not fully familiar with those class interfaces but looking at > > /sys/devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 > > seems to output pretty reasonable values and > > /sys/class/power_supply/ > > has > > bat-th-gta01 -> > ../../devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 > > So this looks pretty sane to me? Good to hear, so it works for 01 and 2.6.24. What we'd love to have now is confirmation (or patches ;) for: 01 and 2.6.29 02 and 2.6.29 Cheers, -- :M: ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
>> BTW: Could you briefly explain the battery class problem? Probably I can >> fix that too... > > mwester did a power class supply driver for the GTA01's dumb batteries > once -- I'm not sure whether this needs adjusting for 2.6.28. > > To make it more complicated, GTA02 can work with both the new ones (for > which we have a power class supply driver), but also with the old ones. > Since GTA02 has a different PMU, we need a completely different driver > for GTA01's dumb batteries in GTA02. > > I don't know whether mike is still interested in working on that. Hmm...I am not fully familiar with those class interfaces but looking at /sys/devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 seems to output pretty reasonable values and /sys/class/power_supply/ has bat-th-gta01 -> ../../devices/platform/bat-th-gta01.0/power_supply/bat-th-gta01 So this looks pretty sane to me? Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
OK, here is the console patch ;)
It introduces a new kernel config option which should then NOT be set in
order to avoid VT switch upon suspend.
The defconfig-gta01 in the source tarball seems to be a little outdated
and that's why I cannot really give a good new defconfig.
Feel free to push that patch upstream (or tell me where best to push
it). This patch is against
git_git.openmoko.org.git.kernel.git_fb42ce6724576fc173faf8abfb04aa2c36d213b7.tar.gz
(which is the 2.6.24 shipped with MS5.1).
Cheers
nils
Michael 'Mickey' Lauer schrieb:
> Am Dienstag, den 03.03.2009, 00:53 +0100 schrieb Nils Faerber:
>> Michael 'Mickey' Lauer schrieb:
>>> Am Dienstag, den 03.03.2009, 00:36 +0100 schrieb Nils Faerber:
> I agree and I'd love to see that as well. It's a ... drum-roll... kernel
> thing :) At some time in kernel 2.5 the console suspend/resume code
> gained the infamous property to change to a dedicated VT where the
> suspend/resume progress gets output. Garmin once released sources for
> one of their Linux-based PMN devices where they patches this away --
> perhaps you find this or can patch it out on your own. We'd be
> interested.
OK, I can confirm now that the VT switch disappears with the kernel
config change I posted earlier.
Though of course this also eliminates the kernel startup messages on the
screen. But well, they are flying by that fast that I doubt anyone is
really able to read them. Suspend/resume is much faster now.
>>> That sounds pretty cool, although it means we also have to give up on
>>> the VT consoles at all, which is not quite what I had in mind.
>>>
>>> Can't we just have the VT consoles without the switching on
>>> suspend/resume?
>> The VT terminals are still there, just not the console.
>
> Sure, but I really mean the console. I have systems with hardware
> keyboards where the VT console with a login prompt comes in handy.
>
>> Of course we could also introduce a new kernel config option for just
>> disabling the console suspend but that would mean a real kernel patch.
>
> Don't be shy ;)
>
>> As you like, I can surely also create such a new kernel config option -
>> should be pretty easy but brings the kernel a bit more away from mainline.
>
> I don't think that's a problem. First, I think it's a patch that would
> be welcome upstream, since all Linux-based polished devices have to
> worry about that. Second, have a look how many custom patches we carry
> in andy-tracking... one more won't hurt ;)
>
>> BTW: Could you briefly explain the battery class problem? Probably I can
>> fix that too...
>
> mwester did a power class supply driver for the GTA01's dumb batteries
> once -- I'm not sure whether this needs adjusting for 2.6.28.
>
> To make it more complicated, GTA02 can work with both the new ones (for
> which we have a power class supply driver), but also with the old ones.
> Since GTA02 has a different PMU, we need a completely different driver
> for GTA01's dumb batteries in GTA02.
>
> I don't know whether mike is still interested in working on that.
>
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48 Fax: +49-271-771091-19
D-57072 Siegen Mob: +49-176-21024535
--
--- git/kernel/power/Kconfig-o 2009-03-03 01:34:28.0 +0100
+++ git/kernel/power/Kconfig2009-03-03 01:34:10.0 +0100
@@ -61,6 +61,17 @@
CAUTION: this option will cause your machine's real-time clock to be
set to an invalid time after a resume.
+config PM_SUSPEND_CONSOLE
+ bool "Switch to a virtual console upon suspend"
+ default y
+ ---help---
+ If console on virtual terminal support is available then the kernel
+ will switch to a free virtual terminal upon suspend and return to
+ the current virtual terminal after resume.
+ This might make some suspend debug or error output visible to the
+ user but might incur the additional delay of VT switch and probably
+ also switch away from a running GUI on the framebuffer etc.
+
config PM_SLEEP_SMP
bool
depends on SUSPEND_SMP_POSSIBLE || HIBERNATION_SMP_POSSIBLE
--- git/kernel/power/console.c-o2009-03-03 01:34:47.0 +0100
+++ git/kernel/power/console.c 2009-03-03 01:26:55.0 +0100
@@ -20,12 +20,17 @@
orig_fgconsole = fg_console;
+#if defined(CONFIG_PM_SUSPEND_CONSOLE)
if (vc_allocate(SUSPEND_CONSOLE)) {
/* we can't have a free VC for now. Too bad,
* we don't want to mess the screen for now. */
release_console_sem();
return 1;
}
+#else
+ release_console_sem();
+ return 1;
+#endif
if (set_console(SUSPEND_CONSOLE)) {
/*
___
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Am Dienstag, den 03.03.2009, 00:53 +0100 schrieb Nils Faerber: > Michael 'Mickey' Lauer schrieb: > > Am Dienstag, den 03.03.2009, 00:36 +0100 schrieb Nils Faerber: > >>> I agree and I'd love to see that as well. It's a ... drum-roll... kernel > >>> thing :) At some time in kernel 2.5 the console suspend/resume code > >>> gained the infamous property to change to a dedicated VT where the > >>> suspend/resume progress gets output. Garmin once released sources for > >>> one of their Linux-based PMN devices where they patches this away -- > >>> perhaps you find this or can patch it out on your own. We'd be > >>> interested. > >> OK, I can confirm now that the VT switch disappears with the kernel > >> config change I posted earlier. > >> Though of course this also eliminates the kernel startup messages on the > >> screen. But well, they are flying by that fast that I doubt anyone is > >> really able to read them. Suspend/resume is much faster now. > > That sounds pretty cool, although it means we also have to give up on > > the VT consoles at all, which is not quite what I had in mind. > > > > Can't we just have the VT consoles without the switching on > > suspend/resume? > > The VT terminals are still there, just not the console. Sure, but I really mean the console. I have systems with hardware keyboards where the VT console with a login prompt comes in handy. > > Of course we could also introduce a new kernel config option for just > disabling the console suspend but that would mean a real kernel patch. Don't be shy ;) > As you like, I can surely also create such a new kernel config option - > should be pretty easy but brings the kernel a bit more away from mainline. I don't think that's a problem. First, I think it's a patch that would be welcome upstream, since all Linux-based polished devices have to worry about that. Second, have a look how many custom patches we carry in andy-tracking... one more won't hurt ;) > BTW: Could you briefly explain the battery class problem? Probably I can > fix that too... mwester did a power class supply driver for the GTA01's dumb batteries once -- I'm not sure whether this needs adjusting for 2.6.28. To make it more complicated, GTA02 can work with both the new ones (for which we have a power class supply driver), but also with the old ones. Since GTA02 has a different PMU, we need a completely different driver for GTA01's dumb batteries in GTA02. I don't know whether mike is still interested in working on that. -- :M: ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Michael 'Mickey' Lauer schrieb: > Am Dienstag, den 03.03.2009, 00:36 +0100 schrieb Nils Faerber: >>> I agree and I'd love to see that as well. It's a ... drum-roll... kernel >>> thing :) At some time in kernel 2.5 the console suspend/resume code >>> gained the infamous property to change to a dedicated VT where the >>> suspend/resume progress gets output. Garmin once released sources for >>> one of their Linux-based PMN devices where they patches this away -- >>> perhaps you find this or can patch it out on your own. We'd be >>> interested. >> OK, I can confirm now that the VT switch disappears with the kernel >> config change I posted earlier. >> Though of course this also eliminates the kernel startup messages on the >> screen. But well, they are flying by that fast that I doubt anyone is >> really able to read them. Suspend/resume is much faster now. > That sounds pretty cool, although it means we also have to give up on > the VT consoles at all, which is not quite what I had in mind. > > Can't we just have the VT consoles without the switching on > suspend/resume? The VT terminals are still there, just not the console. Of course we could also introduce a new kernel config option for just disabling the console suspend but that would mean a real kernel patch. Do you really want a VT console, i.e. for kernel messages? Since it will not switch to VT upon suspend/resume the only messages you will see are the kernel bootup messages. As you like, I can surely also create such a new kernel config option - should be pretty easy but brings the kernel a bit more away from mainline. > Thanks, You're welcome! BTW: Could you briefly explain the battery class problem? Probably I can fix that too... Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Am Dienstag, den 03.03.2009, 00:36 +0100 schrieb Nils Faerber: > > I agree and I'd love to see that as well. It's a ... drum-roll... kernel > > thing :) At some time in kernel 2.5 the console suspend/resume code > > gained the infamous property to change to a dedicated VT where the > > suspend/resume progress gets output. Garmin once released sources for > > one of their Linux-based PMN devices where they patches this away -- > > perhaps you find this or can patch it out on your own. We'd be > > interested. > > OK, I can confirm now that the VT switch disappears with the kernel > config change I posted earlier. > Though of course this also eliminates the kernel startup messages on the > screen. But well, they are flying by that fast that I doubt anyone is > really able to read them. Suspend/resume is much faster now. That sounds pretty cool, although it means we also have to give up on the VT consoles at all, which is not quite what I had in mind. Can't we just have the VT consoles without the switching on suspend/resume? Thanks, -- :M: ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
> I agree and I'd love to see that as well. It's a ... drum-roll... kernel > thing :) At some time in kernel 2.5 the console suspend/resume code > gained the infamous property to change to a dedicated VT where the > suspend/resume progress gets output. Garmin once released sources for > one of their Linux-based PMN devices where they patches this away -- > perhaps you find this or can patch it out on your own. We'd be > interested. OK, I can confirm now that the VT switch disappears with the kernel config change I posted earlier. Though of course this also eliminates the kernel startup messages on the screen. But well, they are flying by that fast that I doubt anyone is really able to read them. Suspend/resume is much faster now. > Cheers, > :M: Cheers nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Michael 'Mickey' Lauer schrieb: > Hi Nils, Hi Mickey, and others ;) Although it was not the weekend, I think I still found one of the kernel "issues": >> As a side note, I tried to figure out a minor issue I found with >> suspend/resume... when suspending something changes to text-console >> before actually suspending the device. I think this is not necessary >> with GTA01, maybe it is with GTA02. Where could I possibly disable this? >> I could not find any suspend script doing that. I think it would simply >> look nicer (so it is just cosmetics) if the screen would not change to >> textmode before being switched off (same for the reusme case first >> shwoing the text console and then the GUI). And it may also speed up >> things a little... > I agree and I'd love to see that as well. It's a ... drum-roll... kernel > thing :) At some time in kernel 2.5 the console suspend/resume code > gained the infamous property to change to a dedicated VT where the > suspend/resume progress gets output. Garmin once released sources for > one of their Linux-based PMN devices where they patches this away -- > perhaps you find this or can patch it out on your own. We'd be > interested. Actually it turns out not to be a real kernel code problem but rather a kernel config thing. The problem tracks down to kernel/power/console.c right at the beginning are two functions to prepare and restore a suspend console - BINGO! This is it, the suspend console. This is intended to show suspend information. Well - this might be useful but I think in most cases it is not. This can be pretty easily disabled if we do not support a real console on the virtual terminals. Do we want that anyway? I don't think so. The file sais: #if defined(CONFIG_VT) && defined(CONFIG_VT_CONSOLE) so disabling CONFIG_VT_CONSOLE should help. This again can only be disabled if CONFIG_EMBEDDED is set. After that it can be disabled in the kernel config and we should not see the console switch anymore. Strangely the change using menuconfig involved some subtle other changes in the defconfig as well - I did a diff and attached it anyway. I have not tested this kernel yet... > Cheers, > :M: Cheers nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 -- --- defconfig-gta01-o 2009-03-03 00:07:02.0 +0100 +++ defconfig-gta01 2009-03-03 00:07:09.0 +0100 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 -# Mon Feb 25 07:03:56 2008 +# Mon Mar 2 23:58:30 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -55,7 +55,7 @@ CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y -# CONFIG_EMBEDDED is not set +CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y @@ -160,7 +160,6 @@ # # Power management # -# CONFIG_S3C2410_PM_DEBUG is not set # CONFIG_S3C2410_PM_CHECK is not set CONFIG_S3C_LOWLEVEL_UART_PORT=0 @@ -209,6 +208,7 @@ CONFIG_MACH_HXD8=y CONFIG_MACH_NEO1973_GTA02=y # CONFIG_NEO1973_GTA02_2440 is not set +# CONFIG_MACH_M800 is not set CONFIG_CPU_S3C2442=y # @@ -919,6 +919,7 @@ # CONFIG_SERIO=y # CONFIG_SERIO_SERPORT is not set +# CONFIG_SERIO_LIBPS2 is not set # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set @@ -926,7 +927,7 @@ # Character devices # CONFIG_VT=y -CONFIG_VT_CONSOLE=y +# CONFIG_VT_CONSOLE is not set CONFIG_NR_TTY_DEVICES=4 CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y @@ -990,6 +991,7 @@ # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set CONFIG_SENSORS_TSL256X=m +# CONFIG_PCA9632 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set @@ -1021,9 +1023,9 @@ # CONFIG_PDA_POWER is not set # CONFIG_APM_POWER is not set # CONFIG_BATTERY_DS2760 is not set -CONFIG_BATTERY_GTA01=y CONFIG_BATTERY_BQ27000_HDQ=y CONFIG_GTA02_HDQ=y +CONFIG_BATTERY_GTA01=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set @@ -1139,6 +1141,7 @@ CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m +CONFIG_SND_RAWMIDI=m # CONFIG_SND_SEQUENCER is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m @@ -1179,6 +1182,7 @@ CONFIG_SND_S3C24XX_SOC=m CONFIG_SND_S3C24XX_SOC_I2S=m CONFIG_SND_S3C24XX_SOC_NEO1973_WM8753=m +# CONFIG_SND_S3C24XX_SOC_NEO1973_WM8753_DEBUG is not set CONFIG_SND_S3C24XX_SOC_NEO1973_GTA02_WM8753=m # @@ -1383,9 +1387,10 @@ # CONFIG_USB_GADGET_DUALSPEED is not set # CONFIG_USB_ZERO is not set CONFIG_USB_ETH=m -CONFIG_USB_ETH_RNDIS=m +CONFIG_USB_ETH_RNDIS=y CONFIG_USB_GADGETFS=m CONFIG_USB_FILE_STORAGE=m +# CONFIG_USB_FILE_STORAGE_TEST is not set CONFIG_USB_G_SERIAL=m CONFIG_USB_MIDI_GADGET=m @@ -1513,6 +1518,7 @@ CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=m +CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems @@ -1545,16 +1551,6 @@ # CONFIG_B
Re: FSO Milestone 5.1
Luca Capello schrieb: > Hi Nils! Hi Luca! > On Fri, 27 Feb 2009 12:25:28 +0100, Nils Faerber wrote: >> Michael 'Mickey' Lauer schrieb: >>> I just release a refresh of FSO milestone5 to fix some bugs that crept >>> into the release, notably the "not working on bootloaders that mount the >>> root partition read-only". > [...] >> Apart from that I also miss the auto-upping of the usb-net interface >> that used to work with MS4.1. > I have experienced the same in the past, especially after having flashed > a new image (both Om and FSO ones). This is usually solved with a > reboot, i.e. the first time you boot after the flashing USB is not > automatically upped, while the second (and later on) times it is. > However, this was on GTA02. Sorry, does not help... >> As a side note, I tried to figure out a minor issue I found with >> suspend/resume... when suspending something changes to text-console >> before actually suspending the device. I think this is not necessary >> with GTA01, maybe it is with GTA02. Where could I possibly disable this? >> I could not find any suspend script doing that. I think it would simply >> look nicer (so it is just cosmetics) if the screen would not change to >> textmode before being switched off (same for the reusme case first >> shwoing the text console and then the GUI). And it may also speed up >> things a little... > FWIW, while I agree that it would be nicer to have not the switch to the > console, on my Debian sid uswsusp does the same if you do not have > Splashy. Switching to text console on PCs is kind of a safekeeper in order to keep the graphics card and X-server happy sind switching from and to X will reinitialise the graphics mode in most cases. This can help if your suspend/resume is buggy. But here we have an embedded system which is pretty much aware of everthing inside and no crappy BIOS code. I could still think of reasons to do, e.g. with Glamo being in the way, if this has some nastynesses requiring to reinit the GUI system (I do not have a GTO02 so cannot comment here). But also there this should be solvable in a nicer way. On the GTA01 the framebuffer is a dumb framebuffer inside the S3C SOC and switching from X11 to "text" console is not actually switching anything but only exchanging the memory location of the X11 framebuffer for the text console buffer. So this is in my opinion completely useless - on GTA01 at least. It only causes one detail that might be of interest, namely an X-server redraw of everything. This might be needed if the framebuffer contents does not survive the suspend/resume (although here I would not understand why this should be the case?). Anyway force redrawing X on resume would still be much more desireable than this X-to-text-to-X switching. Hopefully I will have some time over the weekend to pull a matching kernel tree and try to find the guilty driver ;) > Thx, bye, > Gismo / Luca Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
g...@ergoarte.ch schrieb: > On Fri, Feb 27, 2009 at 12:25:28PM +0100, Nils Faerber wrote: >> As a side note, I tried to figure out a minor issue I found with >> suspend/resume... when suspending something changes to text-console >> before actually suspending the device. I think this is not necessary >> with GTA01, maybe it is with GTA02. Where could I possibly disable this? >> I could not find any suspend script doing that. I think it would simply >> look nicer (so it is just cosmetics) if the screen would not change to >> textmode before being switched off (same for the reusme case first >> shwoing the text console and then the GUI). And it may also speed up >> things a little... > > Check your kernel log-level. I'm not sure if it won't change to textmode > at all with loglevel=0, with higher level you see kernelmessages scrolling. > See the wiki-faq under "why is suspending so slow" or something like > that. Well, to some extent it is a little faster now but still it switches to framebuffer text console and I think that the loglevel does not cause this (it simply limits the kind of printk()s actually hitting the log device). Anyway, good thinking! > Gyelt Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Michael 'Mickey' Lauer schrieb: > Hi Nils, Hi Mickey! >> Though I still see the issue that the battery applet does not work, i.e. >> it always displays the charging symbol (flashing "+"), regardless if >> externally powered or not. On a commandline "apm" tells the correct >> state and values (again GTA01V4). > Yeah, the power class device seems broken for 01. That's a kernel thing > i'm afraid. Hmm... I think this is the same kernel as with MS4.1 where it worked? >> Apart from that I also miss the auto-upping of the usb-net interface >> that used to work with MS4.1. > This is supposed to work -- it does with 02. Again probably a kernel > thing. I will try this reboot-trick too. >> As a side note, I tried to figure out a minor issue I found with >> suspend/resume... when suspending something changes to text-console >> before actually suspending the device. I think this is not necessary >> with GTA01, maybe it is with GTA02. Where could I possibly disable this? >> I could not find any suspend script doing that. I think it would simply >> look nicer (so it is just cosmetics) if the screen would not change to >> textmode before being switched off (same for the reusme case first >> shwoing the text console and then the GUI). And it may also speed up >> things a little... > I agree and I'd love to see that as well. It's a ... drum-roll... kernel > thing :) At some time in kernel 2.5 the console suspend/resume code > gained the infamous property to change to a dedicated VT where the > suspend/resume progress gets output. Garmin once released sources for > one of their Linux-based PMN devices where they patches this away -- > perhaps you find this or can patch it out on your own. We'd be > interested. Hmm... and me being rather a kernel guy puts me in the unlucky position to have that ball in my court now ;) OK - I guess you should know best if this would be a FSO or app thing so I will try to dig out the kernel sources and fiddle with them. Many thanks to all for all the pointers! PS: On a slightly realted topic I also played a bit with the suspend times on GTA01 - it is actually not *that* bad and theoretically it should survive 24h even with some usage. Strangely some days this works perfectly well with ~30% battery loss within 12h but some days it does not even survive 6h. And yes, latest modem firmware, latest uboot and the transistor too many removed. > Cheers, > :M: Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Hi Nils! On Fri, 27 Feb 2009 12:25:28 +0100, Nils Faerber wrote: > Michael 'Mickey' Lauer schrieb: >> I just release a refresh of FSO milestone5 to fix some bugs that crept >> into the release, notably the "not working on bootloaders that mount the >> root partition read-only". [...] > Apart from that I also miss the auto-upping of the usb-net interface > that used to work with MS4.1. I have experienced the same in the past, especially after having flashed a new image (both Om and FSO ones). This is usually solved with a reboot, i.e. the first time you boot after the flashing USB is not automatically upped, while the second (and later on) times it is. However, this was on GTA02. > As a side note, I tried to figure out a minor issue I found with > suspend/resume... when suspending something changes to text-console > before actually suspending the device. I think this is not necessary > with GTA01, maybe it is with GTA02. Where could I possibly disable this? > I could not find any suspend script doing that. I think it would simply > look nicer (so it is just cosmetics) if the screen would not change to > textmode before being switched off (same for the reusme case first > shwoing the text console and then the GUI). And it may also speed up > things a little... FWIW, while I agree that it would be nicer to have not the switch to the console, on my Debian sid uswsusp does the same if you do not have Splashy. Thx, bye, Gismo / Luca pgphNbwaqNb9m.pgp Description: PGP signature ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Hi Nils, > Though I still see the issue that the battery applet does not work, i.e. > it always displays the charging symbol (flashing "+"), regardless if > externally powered or not. On a commandline "apm" tells the correct > state and values (again GTA01V4). Yeah, the power class device seems broken for 01. That's a kernel thing i'm afraid. > Apart from that I also miss the auto-upping of the usb-net interface > that used to work with MS4.1. This is supposed to work -- it does with 02. Again probably a kernel thing. > As a side note, I tried to figure out a minor issue I found with > suspend/resume... when suspending something changes to text-console > before actually suspending the device. I think this is not necessary > with GTA01, maybe it is with GTA02. Where could I possibly disable this? > I could not find any suspend script doing that. I think it would simply > look nicer (so it is just cosmetics) if the screen would not change to > textmode before being switched off (same for the reusme case first > shwoing the text console and then the GUI). And it may also speed up > things a little... I agree and I'd love to see that as well. It's a ... drum-roll... kernel thing :) At some time in kernel 2.5 the console suspend/resume code gained the infamous property to change to a dedicated VT where the suspend/resume progress gets output. Garmin once released sources for one of their Linux-based PMN devices where they patches this away -- perhaps you find this or can patch it out on your own. We'd be interested. Cheers, :M: ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO Milestone 5.1
Hello! Michael 'Mickey' Lauer schrieb: > I just release a refresh of FSO milestone5 to fix some bugs that crept > into the release, notably the "not working on bootloaders that mount the > root partition read-only". Ah, that might have been the reason for the busy-looping-something I saw with 5.0 and that kept up the sysload to 2 while idle ;) This is fixed now (on GTA01V4), great! Though I still see the issue that the battery applet does not work, i.e. it always displays the charging symbol (flashing "+"), regardless if externally powered or not. On a commandline "apm" tells the correct state and values (again GTA01V4). Apart from that I also miss the auto-upping of the usb-net interface that used to work with MS4.1. As a side note, I tried to figure out a minor issue I found with suspend/resume... when suspending something changes to text-console before actually suspending the device. I think this is not necessary with GTA01, maybe it is with GTA02. Where could I possibly disable this? I could not find any suspend script doing that. I think it would simply look nicer (so it is just cosmetics) if the screen would not change to textmode before being switched off (same for the reusme case first shwoing the text console and then the GUI). And it may also speed up things a little... Anyway, great! > Cheers, Cheers nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
