**** BEGIN LOGGING AT Sun Mar 24 02:59:58 2013 Mar 24 12:10:48 PaulFertser: ping Mar 24 12:54:42 DocScrutinizer05: pong Mar 24 12:55:58 hi! :-) Mar 24 12:56:10 do you remember maemo hostmode? Mar 24 12:57:16 do you remember us discussing upstreaming of all that botches, and whyt were our conclusions on feasibility and desirability of such effort? Mar 24 12:57:29 what* Mar 24 12:58:36 DocScrutinizer05: the conclusion was that it's an n900-specific hack and upstreaming would be quite possible but since noone was using upstream kernel, made no sense. Mar 24 13:00:30 were'nt there layering issues, particularly with conflicts between charger-detection(D+-short)/1707-config/driver and general USB ENUM which was the only way to know when 1707 *must not* switch to charger-detect mode since that would fuckup USB data session? Mar 24 13:01:15 buzzword "printf("some asshole probed fastcharger");" Mar 24 13:02:04 DocScrutinizer05: i think we could have implemented it one way or the other but the main obstacle was that nobody needed it at all, as upstream was useless for day-to-day usage on n900. Mar 24 13:03:25 yep, but now our current powerkernel maintainer tries to push all that pile of crap upstream, for unclear reasons, to wank on "now upstream has a #ifdef N900" maybe Mar 24 13:04:28 Upstreaming is good, i'd be willing to see a nice kernel for n900 myself. Mar 24 13:04:29 I did some obviously false claims that we would've done it when it was feasible, back when Mar 24 13:05:28 DocScrutinizer05: btw, the buzzword was added to musb-core as all the other code actually: https://garage.maemo.org/plugins/ggit/browse.php/?p=h-e-n;a=commitdiff;h=d7f76e505b16f7e9305c59c51d02fb1473ab5b2c Mar 24 13:05:45 :nod: Mar 24 13:07:27 DocScrutinizer05: i think i can attempt to port it upstream provided the upstream kernel is real and actually usable. I'm not sure it's the case, i've heard it had some serious power-related issues and nobody was using it anyway. Mar 24 13:08:13 the problem is, now Pali is trying to push bme-replacement to upstream too, and that does probing for fastcharger in kernel, no more userland control instance involved Mar 24 13:09:01 DocScrutinizer05: but it sounds the right thing to do Mar 24 13:09:27 well, first and foremost any more recent upstream kernel would fuckup all the sysnodes so nothing of maemo closed-blobs userland would work anymore Mar 24 13:09:39 DocScrutinizer05: in fact the hard part was to research how to make reliable hostmode, not how to implement it. The patches are small and comprehensible by any kernel dev. Mar 24 13:10:03 DocScrutinizer05: yes, that's to be expected. Maemo just can't run on sane kernels. Mar 24 13:10:13 yep Mar 24 13:10:37 so any power consumption evaluation is moot based on such preconditions Mar 24 13:11:08 DocScrutinizer05: why? Power consumption depends on the kernel. And then you can use iotop to find and nuke the misbehaving apps. Mar 24 13:11:21 hmm? Mar 24 13:13:24 when maemo is using /sys/*/*/*/lis302dl/* sysnodes to detect accelerometer, then how would you compare that to a kernel that has a different path to different semantics sysnodes for same accelerometer, to compare how much of a power hog the old vs new accel-driver is? Mar 24 13:13:26 DocScrutinizer05: the power consumption issues with upstream kernels were due to some missing implementations of advanced tricks like dynamic voltage control, proper frequency scaling etc. Mar 24 13:13:50 I don't think that's true (anymore?) Mar 24 13:14:05 DocScrutinizer05: i'd just not use maemo at all. I'd estimate power consumption on upstream kernel using simple understandable tools. Mar 24 13:14:32 that's however rather meaningless for real life usage Mar 24 13:14:47 the mere kernel doesn't eat the power Mar 24 13:14:49 DocScrutinizer05: i do not know, i have nobody to ask. I think if the current upstream kernel would be in a useful shape, then many people would dump maemo altogether already. Mar 24 13:14:54 it's the peripherals that do Mar 24 13:14:56 Oh yes it does. Mar 24 13:14:59 SoC does Mar 24 13:15:36 With simple close-to-the-kernel tools you can accurately measure the impact of every single peripheral (if you have lab equipment to measure the current). Mar 24 13:15:59 and no, probably very few people would dump maemo, since most of them still want a usable device rather than a clean linux with xterm only Mar 24 13:16:45 I have a usable device (gta02) without maemo, many others do too. I dislike maemo a lot. Mar 24 13:17:41 yes, you can measure whatever you like when you got the tools to do so (N900 already provides those tools: bq27200), but it's the testbed yu define that changes the results you get Mar 24 13:18:24 I do not see how maemo can help measuring anything particular. Mar 24 13:18:37 hmm? Mar 24 13:19:02 I remember having tried to run SHR with upstream kernel. And the device run hot and fast heh. And it was the kernel guilty, userspace wasn't doing anything nasty for that. Mar 24 13:19:58 haha, well, if userspace enables polling for lis302, then of course kernel will look guilty while actually it's been userland that fucked up Mar 24 13:21:16 No, userspace wasn't polling the accelrs. Mar 24 13:21:49 define/configure lis302 (just as an example for an instance) to report at 400Hz, and watch kernel go thru the roof for IRQ servicing Mar 24 13:22:07 iotop would show that right away Mar 24 13:22:12 powertop Mar 24 13:22:17 sure Mar 24 13:22:20 powertop is the great tool Mar 24 13:22:29 and you'd blame kernel Mar 24 13:22:30 shr wasn't touching the accels at all Mar 24 13:22:32 No Mar 24 13:22:57 Come on, of course i won't blame kernel for 400Hz irqs generated by lis302. Mar 24 13:23:02 I know what an irq is! Mar 24 13:23:17 well, not touching doesn't mean it's OK. maybe it's exactly that "not touching it" that leaves peripherals in a rather undesirable state Mar 24 13:23:49 The irqs would still be visible Mar 24 13:23:58 sure Mar 24 13:24:45 so what else could cause kernel to be power hungry if it wasn't for constant wakeups? Mar 24 13:24:48 If maemo is still maintained, why not simply fix it to work with established kernel APIs? Mar 24 13:25:12 maemo *never* been maintained in that way Mar 24 13:25:32 ~#maemo closed Mar 24 13:25:33 well, #maemo closed is http://wiki.maemo.org/Why_the_closed_packages or https://wiki.maemo.org/Fremantle_closed_packages Mar 24 13:26:24 the kernel never been the problem, and I heard freemangordon ran a 3.7.foo kernel on it or whatever Mar 24 13:26:29 Well, that's one of the reasons i never considered using maemo myself. Mar 24 13:27:07 well, ok Mar 24 13:27:10 Running a kernel is one thing. Using it is another. I thought there were some serious issues with the kernel itself. And i thought they're power-related because some important parts were unimplemented. Mar 24 13:27:16 I'm not sure if something is changed now. Mar 24 13:27:27 I'd be willing to start using n900 myself. Mar 24 13:27:37 If there's a nice upstream kernel now, i'll definitely try it. Mar 24 13:27:42 I'm not here to convince you Mar 24 13:28:07 N900 is an omap3430 device, just like beagleboard Mar 24 13:28:19 Is there somebody who can provide some convincing evidence about the current state of the upstream for n900? Mar 24 13:28:23 now take that info and do with it whatever you seem fit Mar 24 13:29:15 I knew it back then. And i've been told several times that it's not enough to actually fly. Boot -- yes. Use for a day -- yes. Use as a smartphone -- no. And i've never thought that was userspace related. Mar 24 13:29:18 no, since nobody but you is interested in a bare bones linux on his N900 Mar 24 13:29:46 I'm not interested in bare bones. Mar 24 13:29:47 it's *only* userspace related Mar 24 13:30:52 DocScrutinizer05: http://wiki.freesmartphone.org/index.php/Nokia900_Kernels i think my info dates back to the same time this page was created. upstream linux-next had no DVFS Mar 24 13:31:06 No camera drivers Mar 24 13:31:30 SHR is thoroughly fubar regarding proper behaviour of userland apps I'd guess, since nobody even considered exploiting zero-clock. Foundation concept of SHR is suspend-to-ram Mar 24 13:32:15 I'm running plain Debian on my netbook which is Tegra-based. I do not see anything nasty with powertop there. It's properly zero-clocking whenever possible. Mar 24 13:32:26 I've read plenty of code related to zero-clock actually. Mar 24 13:33:00 The least complicated rootfs is the most zero-clock friendly. Mar 24 13:33:10 well, it feels like a useless discussion. i'm not going to convince you about anything, that i'm not personally interested in Mar 24 13:33:18 If you do not run anything at all, not even the X server, the device should just work. Mar 24 13:33:48 DocScrutinizer05: in fact i'm willing to be convinced that it's the time for me to start actually using n900 somehow. Mar 24 13:33:57 I'd like to hear good news about the upstream kernel. Mar 24 13:34:03 I'd like to understand what's going on. Mar 24 13:34:39 since I'm not interested in upstream for N900, you're asking the wrong guy Mar 24 13:34:54 DocScrutinizer05: do you know whom and where i can ask about it? Mar 24 13:35:17 fremangordon, pali, ask in #maemo-ssu Mar 24 13:35:27 Ok, thanks! Mar 24 13:36:00 pali will happily discuss upstreaming of hostmode and bme with you Mar 24 13:41:28 pali probably also could use some mentoring regarding proper API design. E.G. the bq27200.ko driver shouldn't throw read() error when the chip has CI=1 (too long since last calibration) Mar 24 13:41:29 Great Mar 24 13:41:55 I see http://elinux.org/N900 has a nice summary Mar 24 13:42:09 he's inventing quite weird new concepts how APIs might look like Mar 24 13:42:26 and is upstreaming that Mar 24 13:43:30 Well, one usuall can't upstream some real BS. Mar 24 13:44:20 Yes, that page is maintained by Pali himself. Mar 24 13:47:59 [2013-03-24 14:46:39] DocScrutinizer05, here is 3.8 kernel with n900 patches: https://gitorious.org/linux-n900/linux-n900 Mar 24 13:48:01 [2013-03-24 14:46:49] he also denied that there were any insurmountable obstacles with it Mar 24 13:48:02 [2013-03-24 14:46:50] some of them will be included in 3.9/3.10 Mar 24 13:48:04 [2013-03-24 14:47:23] so probably I told BS, sorry Mar 24 13:48:05 [2013-03-24 14:47:32] Pali: btw I rebased your patches to 3.9-rc1, boots :) Mar 24 13:49:41 ( #maemo ) Mar 24 13:52:30 DocScrutinizer05: ok, i've joined #maemo-ssu and pinged Pali. **** ENDING LOGGING AT Mon Mar 25 02:59:59 2013