**** BEGIN LOGGING AT Sat Nov 27 02:59:58 2010
Nov 27 11:57:17 <badcloud> anyone know where I can find the dumb bat module that will work fr .34 kernel?
Nov 27 11:57:21 <badcloud> *for
Nov 27 11:57:26 <lindi-> badcloud: I guess we could port one?
Nov 27 11:57:36 <badcloud> that would be stelar
Nov 27 11:58:14 <badcloud> *stellar
Nov 27 11:58:21 <lindi-> unfortunately at least currently I have other openmoko issues to fix
Nov 27 11:58:45 <lindi-> badcloud: what .34 tree are you using?
Nov 27 11:59:03 <badcloud> hmmm, not sure .34.2 (qtmoko v28.2)
Nov 27 11:59:20 <lindi-> badcloud: so radekp's qtmoko-v28 branch I guess
Nov 27 11:59:27 <badcloud> lindi-: right
Nov 27 11:59:32 <gena2x> badcloud: ah, i just forgot about battery problem. can you describe problem, why do you need special module?
Nov 27 11:59:35 <lindi-> my build machine is offline unfortunately
Nov 27 11:59:55 <badcloud> gena2x: I'm using a Nokia BL-6C battery
Nov 27 12:00:12 <badcloud> gta01-battery module works in v26
Nov 27 12:00:17 <badcloud> but not with v28
Nov 27 12:00:27 <lindi-> badcloud: is the module the same?
Nov 27 12:00:29 <gena2x> badcloud: what is definition of 'works'? charging?
Nov 27 12:00:39 <lindi-> smoke?
Nov 27 12:00:53 <badcloud> lindi-: that's the thing. I think the later module is called platform_battery
Nov 27 12:01:00 <badcloud> gena2x: works, charging, yes
Nov 27 12:01:20 <badcloud> gena2x: plus differenciating between charging and only on battery power
Nov 27 12:01:47 <gena2x> badcloud: i just wanted to say that while i were fixing problem with power consumtion, my nokia battery were charging without probelms
Nov 27 12:01:52 <lindi-> badcloud: you mean the module changed its name?
Nov 27 12:01:54 <badcloud> where can I download platform_battery to try it out?
Nov 27 12:02:02 <lindi-> badcloud: it's all in git
Nov 27 12:02:09 <gena2x> badcloud: and i think i did not add anything special to kernel
Nov 27 12:02:20 <badcloud> gena2x: really?
Nov 27 12:02:24 <gena2x> i just connected battery with 2 contacts
Nov 27 12:02:36 <gena2x> without middle one
Nov 27 12:02:51 <badcloud> don't know if I have the proper tools
Nov 27 12:02:54 <radekp> gena2x: it's in git but i have disabled it from config
Nov 27 12:03:09 <gena2x> radekp: any reason?
Nov 27 12:03:29 <radekp> gena2x: because when enabled it was used instead of original openmoko battery driver
Nov 27 12:03:37 <gena2x> badcloud: i can compile kernel for you in few minutes if it is just matter of config
Nov 27 12:03:45 <badcloud> gena2x: hold that thought
Nov 27 12:03:59 <badcloud> radekp: I just installed v28 tarball on my usd
Nov 27 12:04:22 <badcloud> radekp: do I need to put anything else on the fs in order for the module to work?
Nov 27 12:05:08 <radekp> badcloud: we could try compile kernel for you with platform_battery instead of openmoko battery
Nov 27 12:05:18 <radekp> badcloud: as gena2x suggested
Nov 27 12:05:21 <gena2x> radekp: as far as i understand, only ordinary usage difference is ability to see current charge level, so if wrong driver loaded, just can't see what is current charge
Nov 27 12:05:29 <gena2x> radekp: this where question
Nov 27 12:05:34 <gena2x> *were
Nov 27 12:06:02 <badcloud> radekp: I see
Nov 27 12:06:03 <radekp> gena2x: yup i couldnt see current_now and other important sysfs nodes
Nov 27 12:06:25 <radekp> gena2x: do you know how kernel knows which battery driver to select?
Nov 27 12:06:44 <badcloud> couldn't I just dl the module from git and modprobe it?
Nov 27 12:06:49 <gena2x> radekp: no, never tryed dive into battery questions
Nov 27 12:07:13 <radekp> gena2x: strange is that with 2.6.29 it picked the correct driver
Nov 27 12:07:36 <radekp> badcloud: i think the battery driver is compiled in
Nov 27 12:08:25 <gena2x> radekp: actually should be easy to understand this, as it should only on probe level
Nov 27 12:08:38 <badcloud> platform_battery not found...
Nov 27 12:09:00 <gena2x> badcloud: do you want me to compile kernel for you or want to do it on your own?
Nov 27 12:09:07 <badcloud> gena2x: hold on one sec
Nov 27 12:09:11 <gena2x> ok
Nov 27 12:09:16 <badcloud> just located /sys/bus/platform/devices/platform_battery
Nov 27 12:09:28 <badcloud> so why can't I modprobe it
Nov 27 12:10:09 <badcloud> isn't there some command needed to rebuild the module list?
Nov 27 12:10:18 <gena2x> depmod -a
Nov 27 12:10:23 <badcloud> that's the one
Nov 27 12:10:46 <badcloud> $%^& didn't work
Nov 27 12:10:49 <gena2x> but you can avoid it with insmod istead of modprobe. but i am sure this will not help you
Nov 27 12:11:15 <gena2x> if radek told that dumb buttery module disabled it is disabled
Nov 27 12:11:23 <badcloud> I see
Nov 27 12:11:32 <badcloud> I guess I just didn't understand the process
Nov 27 12:12:05 <badcloud> I was just toying again with the idea of upgrading to v28
Nov 27 12:12:13 <badcloud> but I could reinstall v26
Nov 27 12:12:38 <badcloud> after ~1 month it doesn't work as well as in the beginning
Nov 27 12:12:51 <gena2x> about my 'method' you can try to use piece of sticky tape to block middle pin on battery and try my method
Nov 27 12:13:21 <gena2x> badcloud: so, want kernel with compiled module now?
Nov 27 12:13:35 <badcloud> gena2x: it's just that? a piece of sticky tape for the middle pin?
Nov 27 12:13:56 <gena2x> badcloud: i think it may work, and should not damage anything
Nov 27 12:14:26 <badcloud> locating some sticky enough tape now
Nov 27 12:15:50 <gena2x> badcloud: but new kernel installation procedure is easy, it should take may be 15 mins
Nov 27 12:16:14 <badcloud> gena2x: since you're here, can you move part of the udfu fs to usd like we did in v26?
Nov 27 12:16:21 <badcloud> such as /usr
Nov 27 12:16:36 <gena2x> badcloud: of course, just copy and make link
Nov 27 12:16:48 <gena2x> badcloud: and add line to fstab
Nov 27 12:16:54 <radekp> gena2x: btw do you remember your patch for high current in suspend bug? the one witch set regulator to always_on=0
Nov 27 12:17:20 <gena2x> radekp: sure, what's with it?
Nov 27 12:17:22 <radekp> gena2x: i found out that SHR has different patch then qtmoko
Nov 27 12:17:35 <radekp> SHR sets it for other regulator
Nov 27 12:17:45 <radekp> http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commit/aa63b515a0993e46ea3ffdee48a363896eccf8a3
Nov 27 12:17:49 <radekp> https://github.com/radekp/linux-2.6/commit/61ab4e63e59aaf6508ae06112d51ebe97c9c512f
Nov 27 12:18:22 <radekp> so i wonder which one is correct and if it works at all in SHR
Nov 27 12:18:29 <gena2x> hehe
Nov 27 12:18:43 <gena2x> correct is one i posted in bug report
Nov 27 12:18:45 <badcloud> gena2x: rebooting with scotch tape inside
Nov 27 12:19:11 <gena2x> badcloud: just tell me you want to install new kernel if this will not work
Nov 27 12:20:23 <badcloud> gena2x: yeah, it didn't work
Nov 27 12:20:28 * radekp has to go, bbl
Nov 27 12:20:33 <badcloud> maybe I need another layer...?
Nov 27 12:20:49 <gena2x> radekp: ok, i'll tell Jama about your finding
Nov 27 12:20:59 <radekp> badcloud: i will take a look at it in the evening and will try to enable platform_battery for next release
Nov 27 12:21:08 <radekp> gena2x: oki, thanks
Nov 27 12:21:14 <badcloud> radekp: thanks
Nov 27 12:21:46 <gena2x> radekp: i'll try to take a look to it too and leave message if solution be found
Nov 27 12:22:03 <gena2x> before evening :)
Nov 27 12:22:25 <gena2x> badcloud: so, kernel?
Nov 27 12:22:45 <badcloud> gena2x: only if it's not a bother
Nov 27 12:23:10 <gena2x> badcloud: nope, it should be easy, let me compile it....
Nov 27 12:29:36 <gena2x> where is my nokia battery.....
Nov 27 12:48:26 <badcloud> gena2x: I think you may have compiled the kernel for me earlier
Nov 27 12:48:39 <gena2x> i have compiled kernel now
Nov 27 12:48:40 <badcloud> I found it and it seems to be working
Nov 27 12:49:13 <gena2x> badcloud: are you sure?
Nov 27 12:49:24 <gena2x> i can't recall this
Nov 27 12:49:36 <gena2x> now i compiled, but it seem a bit strange
Nov 27 12:49:41 <badcloud> hold on
Nov 27 12:49:50 <gena2x> it always show it is charging
Nov 27 12:50:29 <gena2x> how do you determine it works?
Nov 27 12:50:36 <gena2x> are you looking to dmesg?
Nov 27 12:50:48 <badcloud> no, at the battery panel
Nov 27 12:50:57 <badcloud> worked fine
Nov 27 12:50:58 <gena2x> if battery is really charging, it should be determined by dmesg
Nov 27 12:51:17 <gena2x> 'usb curlim to xxx mA' messages
Nov 27 12:51:18 <badcloud> [  456.020000] pcf50633 0-0073: usb curlim to 0 mA
Nov 27 12:51:20 <badcloud> [  463.365000] pcf50633 0-0073: usb curlim to 1000 mA
Nov 27 12:51:35 <gena2x> so it is charging, no matter what is on indicator
Nov 27 12:52:16 <gena2x> so, check with taped pin
Nov 27 12:52:28 <badcloud> works in both cases
Nov 27 12:52:41 <gena2x> so, you battery should charge
Nov 27 12:52:56 <gena2x> only indidication of it is full may be missing.
Nov 27 12:53:06 <gena2x> but i don't know how it should really work
Nov 27 12:53:29 <gena2x> i mean should it indicate that battery is full
Nov 27 12:53:34 <gena2x> or not
Nov 27 12:53:39 <badcloud> I'll flash udfu and see how that works
Nov 27 12:53:57 <gena2x> i compiled kernel and tried with my nokia battery
Nov 27 12:54:15 <gena2x> but it show constant charging, no matter cable is connected or not
Nov 27 12:54:31 <badcloud> maybe someone else compiled it the first time, not sure
Nov 27 12:54:34 <gena2x> but dmesg is proper, so it should be charged
Nov 27 12:55:16 <gena2x> so your problem is solved? want compiled kernel?
Nov 27 12:56:16 <lindi-> gena2x: note that usb current limit does not mean that battery is charging
Nov 27 12:56:36 <lindi-> gena2x: and 'om usb charger-limit' is a way to poll usb charger limit, no need to read dmesg
Nov 27 12:56:37 <gena2x> lindi-: any ideas not to check it in better way?
Nov 27 12:57:06 <gena2x> lindi-: except multimeter?
Nov 27 12:57:24 <badcloud> gena2x: I'm going to boot udfu after flashing. most likely it will work there too
Nov 27 12:57:46 <gena2x> lindi-: and i bet if charger limit is 0 you battery is for sure not charging
Nov 27 12:57:50 <lindi-> gena2x: 'om battery consumption' is a reliable way to see if battery is really charging
Nov 27 12:58:03 <badcloud> lindi-: more so than dmesg?
Nov 27 12:58:11 <lindi-> gena2x: true but usb charger-limit of 1000 does not mean that the battery is charging either
Nov 27 12:58:27 <gena2x> lindi-: but what else should be turned on expect limit?
Nov 27 12:58:35 <gena2x> *except
Nov 27 12:58:37 <lindi-> gena2x: battery charger-limit
Nov 27 12:58:47 <lindi-> there are two limits
Nov 27 12:58:55 <gena2x> hm. if you have dumb battery
Nov 27 12:58:59 <gena2x> it is not controllable
Nov 27 12:59:09 <gena2x> so charger limit should be enough?
Nov 27 12:59:20 <lindi-> gena2x: you mean 'om usb charger-limit'?
Nov 27 12:59:35 <lindi-> I don't know if 'om battery charger-limit' works with dumb batteries
Nov 27 12:59:56 <lindi-> I assume it does
Nov 27 12:59:59 <gena2x> no, we have pcf which has charger which control chraging current.
Nov 27 13:00:14 <gena2x> and in case of nokia battery - nothing else
Nov 27 13:00:55 <gena2x> so kernel message about limit should be ebough to judge if we are really charging?
Nov 27 13:01:01 <gena2x> *enough
Nov 27 13:01:10 <lindi-> "om usb charger-limit" is e.g. /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim
Nov 27 13:01:21 <gena2x> (we speaking here about dumb battery)
Nov 27 13:01:32 <lindi-> "om battery charger-limit" is e.g. /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc/chg_curlim
Nov 27 13:01:42 <lindi-> both are related to pcf
Nov 27 13:02:03 <lindi-> gena2x: I think the kernel message is about "om usb charger-limit"
Nov 27 13:02:34 <lindi-> gena2x: so it could still be possible that "om battery charger-limit" is zero and prevents the battery from charging
Nov 27 13:02:43 <gena2x> so, should be enough to judge if battery is charging.
Nov 27 13:02:54 <SpeedEvil> I would assume om usb-charger-liit refers to the current limit on the USB connector for use when a charger is plugged in.
Nov 27 13:03:07 <SpeedEvil> I.E. to differentiate from when it's plugged into a host
Nov 27 13:03:21 <gena2x> no, as dumb battery have no i2c bus, you can't ussue cat /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc/chg_curlim
Nov 27 13:03:35 <lindi-> gena2x: aha
Nov 27 13:03:44 <gena2x> or wait stop
Nov 27 13:03:45 <lindi-> gena2x: I should document this
Nov 27 13:03:45 <gena2x> no
Nov 27 13:03:48 <gena2x> wait
Nov 27 13:03:52 <gena2x> i am unsure
Nov 27 13:04:09 <gena2x> PaulFertser: hi, Paul, can you help us on batteries a bit
Nov 27 13:04:21 <PaulFertser> gena2x: i can try
Nov 27 13:04:23 <lindi-> gena2x: easiest way is to probably just test it?
Nov 27 13:04:52 <gena2x> PaulFertser: about charging. we have dumb battery, is kernel message about curlim is ebough to judge that battery is charging?
Nov 27 13:05:01 <gena2x> *enough
Nov 27 13:05:26 <lindi-> gena2x: don't you get the kernel message even if no battery is connected at all?
Nov 27 13:06:18 <gena2x> lindi-: battery presence is related to charger state
Nov 27 13:06:51 <PaulFertser> gena2x: given some assumptions (the overall system consumption is less than the current, specified in the message; the host is actually capable of providing specified current; the battery is present and works properly), i'd say yes.
Nov 27 13:06:55 <gena2x> lindi-: i meant 'not related of course'
Nov 27 13:07:24 <lindi-> PaulFertser: but if I say 'om battery charger-limit 0' then battery is not charging
Nov 27 13:08:00 <gena2x> PaulFertser: thanks.
Nov 27 13:08:24 <PaulFertser> lindi-: of course, "not messing anyhow with the charger chip" is one of the assumptions i missed to specify.
Nov 27 13:08:32 <PaulFertser> lindi-: indeed, thanks.
Nov 27 13:08:38 <lindi-> :)
Nov 27 13:11:21 <gena2x> badcloud: so, in case if you really need recompiled kernel it is here:bsdmn.com/openmoko/dumbbatt platform_battery compiled as module. but stick tape to middle contact and check kernel messages.
Nov 27 13:11:33 <badcloud> thanks
Nov 27 13:11:55 <badcloud> trying the previous diy kernel w/udfu v28 image
Nov 27 13:12:11 <gena2x> badcloud: please tell is something will be still wrong
Nov 27 13:12:42 <SpeedEvil> Use _thin_ tape - as thin as you can
Nov 27 13:12:53 <SpeedEvil> this risks stretching out the battery contacts
Nov 27 13:13:35 <gena2x> s/is/if/
Nov 27 13:13:36 <apt> gena2x meant: badcloud: please tell if something will be still wrong
Nov 27 13:13:56 <badcloud> gena2x: thanks so much
Nov 27 15:01:22 <gena2x> lindi-: ah, finally i got about chg_curlim and usb_curlim, thanks for corrections, sorry i just didn't understood you properly, as both 'chg_curlim' and 'usb_curlim' are pcf properties. thanks for info.
Nov 27 15:01:45 <lindi-> gena2x: can you suggest improvements to 'man om' about these?
Nov 27 15:07:38 <gena2x> lindi-: nothing, it is very clear and informative, i just never read it before. nothing is told about kernel of course (except that changing USB limit involves battery limit), and missing 1000mA (which seem somehow working with USB).
Nov 27 15:08:03 <lindi-> yeah 1000 mA indeed works
Nov 27 15:08:13 <lindi-> I just didn't want to advertise it since I was unsure
Nov 27 15:11:03 <gena2x> i think power provider, not power consumer should be responsible for any overloads
Nov 27 15:11:27 <gena2x> so freerunner should consume as much as it can
Nov 27 15:11:37 <gena2x> of course this is guess
Nov 27 15:12:09 <gena2x> but overwise this sounds like bad design than malfulctioning consumer can fire your system
Nov 27 15:12:46 <gena2x> like it happens with n900 charged from freerunner.
Nov 27 15:28:34 <SpeedEvil> Do that, and for example, plugging a OM into a unpowered hub can cause the hard disk that's also plugged in there to reset.
Nov 27 15:29:35 <SpeedEvil> Also, some devices require a reboot to recover after USB overload.
Nov 27 15:31:21 <gena2x> so, hub should recover from overload if you attach 5 hard drives, but can't handle 1 consumer consuming like 5 hard drives?
Nov 27 15:33:49 <SpeedEvil> It recovers - sure.
Nov 27 15:34:24 <SpeedEvil> But you may have corruption on the hard drive, as it's disconnected without syncing.
Nov 27 15:35:34 <gena2x> and what about negotiation? i thought usb protocal has special fields to request power
Nov 27 15:35:41 <gena2x> *protocol
Nov 27 15:36:19 <SpeedEvil> It does.
Nov 27 15:36:34 <gena2x> and this is a way how it should be managed and way to know for provider to prevent overloads
Nov 27 15:36:53 <gena2x> s/to/how to/
Nov 27 15:36:53 <apt> gena2x meant: and this is a way how it should be managed and way how to know for provider to prevent overloads
Nov 27 15:36:54 <SpeedEvil> Drawing more than your allocation will cause resets
Nov 27 15:37:05 <SpeedEvil> And on plug-in - the allocation is 100mA 
Nov 27 15:37:23 <SpeedEvil> The host has to then configure you to be able to draw more
Nov 27 15:37:38 <SpeedEvil> Also - 500mA is the most a standard port can provide.
Nov 27 15:38:03 <lindi-> SpeedEvil: except in usb 3?
Nov 27 15:38:12 <lindi-> SpeedEvil: or usb charging specification?
Nov 27 15:40:24 <SpeedEvil> standard port
Nov 27 15:40:30 <SpeedEvil> and yes, USB3 is different
Nov 27 15:40:38 * SpeedEvil sighs.
Nov 27 15:41:01 * SpeedEvil wishes USB had a proper USB-high-power mode - that went to 30V@0.5A
Nov 27 15:41:39 <SpeedEvil> Add a 'high power' class hub that could enable 30V per-port, and most computer related wall-warts just go away.
Nov 27 15:42:19 <gena2x> btw as we have no reports about 1000mA, seem it works everywhere
Nov 27 15:42:52 <SpeedEvil> It doesn't.
Nov 27 15:43:18 <SpeedEvil> Drawing more than about 800mA resets one of my notebooks ports, and requires a reboot to clear
Nov 27 15:43:29 <gena2x> i mean not really 'everywhere' but 'in common cheap situations'.
Nov 27 15:43:46 <gena2x> hm. interesting...
Nov 27 15:43:48 <SpeedEvil> possibly
Nov 27 15:59:13 <lindi-> stracho: it does 1.8A I think
Nov 27 15:59:19 <lindi-> sorry meant speedevil
Nov 27 15:59:24 <lindi-> who just /parted
Nov 27 16:02:47 <badcloud> does platform_battery work out of the box in latest shr-u? I'm having a daily phone crisis
**** BEGIN LOGGING AT Sat Nov 27 18:44:20 2010
Nov 27 18:51:26 <PBeck> hi
Nov 27 18:52:36 <PBeck> hi :)
**** ENDING LOGGING AT Sun Nov 28 02:59:57 2010