| 01:25.15 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 01:27.16 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 01:28.30 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@116.253.118.61) |
| 01:41.16 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 02:13.28 | *** join/#maemo-ssu MetalGearSolid (~quassel@115.134.194.93) |
| 02:25.33 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@116.253.118.61) |
| 02:46.46 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 07:16.05 | *** join/#maemo-ssu Pali (~Pali@Maemo/community/contributor/Pali) |
| 07:24.21 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 07:34.36 | Pali | freemangordon: any news why rtcom-call-ui crashing? |
| 07:35.01 | Pali | maybe it can be that gpio switch which is already used by snd driver? |
| 07:51.57 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 08:01.06 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 08:06.01 | *** join/#maemo-ssu Martix_ (~martix@2001:718:2:2905:a288:b4ff:fe50:a6a4) |
| 08:20.23 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 08:29.51 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 08:57.35 | freemangordon | Pali: didn't have time to debug it |
| 08:58.33 | freemangordon | but there are more sound switches related errors |
| 09:00.29 | freemangordon | Jan 1 08:02:30 Nokia-N900 pulseaudio[1547]: voice-sidetone.c: Cannot open /sys/devices/platform/omap-mcbsp.2/st_enable |
| 09:00.31 | freemangordon | Jan 1 08:02:30 Nokia-N900 pulseaudio[1547]: module-alsa-sink-volume.c: hw:0: Bad mixer mode entry Headphone:off |
| 09:00.33 | freemangordon | Jan 1 08:02:30 Nokia-N900 pulseaudio[1547]: module-alsa-sink-volume.c: hw:0: Bad mixer mode entry Earphone:off |
| 09:01.06 | freemangordon | Pali: ^^^ |
| 09:09.24 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 09:23.36 | *** join/#maemo-ssu NIN101 (~NIN@p5DD2A091.dip0.t-ipconnect.de) |
| 09:35.43 | *** join/#maemo-ssu Martix_ (~martix@2001:718:2:2905:a288:b4ff:fe50:a6a4) |
| 09:40.18 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 09:50.15 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 10:00.40 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 10:17.36 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 10:19.52 | *** join/#maemo-ssu kolp (~quassel@212.255.244.88) |
| 11:10.36 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
| 11:16.00 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 11:48.04 | *** join/#maemo-ssu Martix_ (~martix@2001:718:2:2905:a288:b4ff:fe50:a6a4) |
| 12:05.25 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 13:51.40 | *** join/#maemo-ssu Martix_ (~martix@2001:718:2:2905:a288:b4ff:fe50:a6a4) |
| 14:19.45 | FatPhil | would any of you hackers have any use for a proto with a broken USB, a slightly duff screen (not actually missing any pixels though), and a finnish keyboard |
| 14:21.00 | FatPhil | I've converted 3 slightly broken devices into 2 perfect ones, and a "junker". |
| 14:21.52 | FatPhil | Well, I've not actually done it, as I can't get a couple of the screws out, but will buy a decent screwdriver set ASAP to complete the swaps I need to so. |
| 14:22.19 | FatPhil | and then the junker should be usable for a developer, just not for your daily device. |
| 14:26.30 | ShadowJK | how broken is the usb? |
| 14:26.57 | ShadowJK | traces lifted/missing? |
| 14:29.34 | FatPhil | To be honest, I didn't even look. It didn't charge, and the socket was visably out of kilter, so presume lifted |
| 14:30.31 | ShadowJK | aw |
| 14:30.42 | ShadowJK | I've got two modem-dead devices |
| 14:31.39 | FatPhil | where in the world are you? |
| 14:32.04 | jonwil | I am on my 3rd N900 (2 were replaced way back when under warranty) |
| 14:32.05 | ShadowJK | .fi |
| 14:32.32 | jonwil | First one had a broken display flex PCB (the one with the status multicolor LED and the front camera on it) |
| 14:32.50 | jonwil | Then the replacement for that ended up with broken USB |
| 14:32.52 | FatPhil | Helsinki area? |
| 14:32.55 | ShadowJK | nop |
| 14:33.06 | jonwil | then that was replaced under warranty with the third one which I still have |
| 14:34.19 | FatPhil | I will be in .fi next weekend, and I know a mate has a lab with screwdrivers that will take most of my devices apart (as I did part of the switcheroo last weekend there, before I got the third device). |
| 14:35.15 | FatPhil | one of the problem with good screwdrivers is that they will strip shitty screws (which did happen, pliers were needed to complete the job) |
| 14:35.46 | ShadowJK | Well also the philips heads are designed to slip and strip |
| 14:36.08 | FatPhil | yeah, I have a conical indentation that proves that |
| 14:36.55 | ShadowJK | torx makes more sense, but I suspect some greenpeace hippies drove through philips :P |
| 14:37.52 | ShadowJK | or hex, when hex goes bad you take torx bit and hammer it in |
| 14:38.31 | jonwil | has run out of things he can reverse engineer :( |
| 14:38.44 | jonwil | Anyone with suggestions on what to reverse engineer next please feel free to suggest them :) |
| 14:39.45 | FatPhil | jonwil: what's the story on rtcom-call-ui? |
| 14:39.55 | jonwil | what about it specifically? |
| 14:40.08 | jonwil | Its closed source and its doing a lot of stuff which I have never been able to fully work out |
| 14:40.20 | jonwil | mostly because I dont have any knowledge of telepathy |
| 14:41.47 | jonwil | Short of hell freezing over and the source code for it appearing somehow (or some genius with both skills in telepathy AND skills in reverse engineering showing up) I dont think we will ever truly know everything that its doing |
| 14:42.49 | jonwil | is there anything specific you want to know about it? |
| 14:43.26 | FatPhil | I was just told that it was crashing with a new kernel, so was a candidate for reverse engineering |
| 14:44.04 | jonwil | ok, well as I said, its very complex and hard to reverse engineer |
| 14:45.16 | jonwil | I need something simpler to fiddle with |
| 14:48.46 | jonwil | I would fiddle some more with the cellular services daemon but that has been frustrating me too much :( |
| 14:49.15 | jonwil | Especially since the cellular modem docs I have are quite a few revisions ahead of the cellmo in the N900 |
| 14:51.32 | jonwil | and since I still cant figure out most of the interface for libisi |
| 14:54.00 | jonwil | maybe I will go back and take another crack at liblocation... |
| 14:58.34 | *** join/#maemo-ssu Martix_ (~martix@2001:718:2:2905:a288:b4ff:fe50:a6a4) |
| 15:01.16 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 16:26.08 | *** join/#maemo-ssu lenoch (~chatzilla@88.103.110.54) |
| 17:09.58 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 17:40.14 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 17:41.35 | *** join/#maemo-ssu Pali (~Pali@Maemo/community/contributor/Pali) |
| 17:50.33 | freemangordon | Pali: can't we just rename "avdet-gpio" to "headphone" in rx51.c and solve our problem? |
| 17:52.33 | freemangordon | FatPhil: any good idea how to create 'virtual" gpios in the kernel? I was told something like that will be needed in order to have cameras working with DT |
| 17:53.29 | Pali | freemangordon: it is not about name but about gpio number |
| 17:53.48 | freemangordon | #define RX51_GPIO_HEADPHONE177 |
| 17:54.11 | freemangordon | #define RX51_JACK_DETECT_GPIO177 |
| 17:54.22 | freemangordon | what is wrong with the number? |
| 17:54.25 | Pali | freemangordon: still "virtual gpios" needs to be in board data or somwhere... so it will be deleted in DT |
| 17:54.45 | Pali | freemangordon: renaming is not enough |
| 17:55.00 | freemangordon | Pali: ok, please, explain what is the peoblem, I don;t get it |
| 17:55.20 | Pali | only one can use gpio |
| 17:55.21 | freemangordon | sound driver opens gpio 177 |
| 17:55.33 | freemangordon | who else need gpio 177? |
| 17:55.51 | Pali | and for maemo compatibility you need gpios in omap gpio driver |
| 17:56.02 | Pali | omap gpio switch driver |
| 17:56.16 | freemangordon | Pali: thus my point |
| 17:56.29 | freemangordon | maemo needs "headphone" gpio, ain't? |
| 17:56.32 | Pali | and in upstream kernel sound driver it using too (for jack detection?) |
| 17:56.55 | Pali | and maemo needs that gpio exported via omap switch driver |
| 17:57.15 | freemangordon | oh, I see |
| 17:57.19 | Pali | but only one driver can use it (snd or omap) |
| 17:57.23 | freemangordon | well, we'll need "virtual gpio" driver then |
| 17:57.39 | Pali | but I patched omap driver to do not fail if cannot open gpio |
| 17:57.40 | freemangordon | for sound and for cameras iiuc |
| 17:57.47 | Pali | and provide fake data to userspace |
| 17:57.50 | freemangordon | correct? |
| 17:58.03 | Pali | so apps will see them... |
| 17:58.08 | freemangordon | ok, got it |
| 17:59.22 | freemangordon | Pali: where in /sys maemo looks for gpios? |
| 17:59.51 | freemangordon | "/sys/devices/platform/gpio-switch" ? |
| 18:00.17 | Pali | yes |
| 18:00.34 | Pali | but there is already some generic gpio sysfs |
| 18:00.42 | freemangordon | hmm, can;t we patch omap-gpio driver to make gpios "sharable"? |
| 18:01.00 | Pali | so maybe we should change omap gpio driver to use that generic sysfs and create symlinks |
| 18:01.27 | Pali | freemangordon: this is what we should do, but I do not know gpio framework |
| 18:01.52 | freemangordon | hmm, making symlinks should be easy |
| 18:02.07 | freemangordon | which driver is "ours"? |
| 18:02.26 | freemangordon | gpio-omap? |
| 18:03.57 | freemangordon | oh, it is gpio-switch |
| 18:04.02 | freemangordon | lemme see what it does |
| 18:08.17 | freemangordon | Pali: hmm, and how this work in Nokia kernel? |
| 18:13.22 | freemangordon | Pali: WTF, rx51.c in upstream is missing half of the stuff in KP? who and how upstreamed that?!? |
| 18:13.53 | Pali | no idea... |
| 18:14.01 | *** join/#maemo-ssu amizraa (~amizraa@gateway/tor-sasl/amizraa) |
| 18:14.17 | freemangordon | OMG: "* n810.c -- SoC audio for Nokia RX51" |
| 18:14.20 | freemangordon | :D:D:D |
| 18:14.29 | Pali | but snd rx51.c using other separate drivers... |
| 18:14.42 | Pali | see SELECT in Kconfig |
| 18:16.43 | freemangordon | the one in KP has select SND_OMAP_SOC_MCBSP more compared to upstream |
| 18:16.52 | freemangordon | the others are the same |
| 18:17.42 | freemangordon | hmm, not, equal thing selected |
| 18:17.51 | freemangordon | no difference |
| 18:18.00 | Pali | so all subdrivers are similar and main driver rx51.c is smaller? |
| 18:18.06 | freemangordon | yep |
| 18:18.23 | Pali | hm, then we maybe missing something |
| 18:19.05 | Pali | and need to check if tvout detection driver (it is separate in KP) is integrated into rx51.c in upstream or not |
| 18:19.07 | freemangordon | hmm, I don;t think so |
| 18:19.33 | freemangordon | seems like upstream has less functionality |
| 18:19.43 | Pali | ah |
| 18:20.53 | freemangordon | Pali: http://pastebin.com/2pSFh79f |
| 18:21.33 | freemangordon | RX51_JACK_MIC and RX51_JACK_ECI are missing from upstream |
| 18:22.23 | Pali | also need to look at ECI support which Doc wrote... |
| 18:23.49 | freemangordon | Pali: I guess we should port KP driver |
| 18:24.02 | freemangordon | and upstream it :( |
| 18:27.55 | freemangordon | Pali: and it seems upstream is missing fmtx support |
| 18:28.25 | freemangordon | Pali: http://pastebin.com/1nDCfPrP |
| 18:30.42 | Pali | freemangordon: when I have notebook back I can look at it :-) |
| 18:30.52 | freemangordon | ok :) |
| 18:31.12 | freemangordon | but deffinitely upstream is missing half of the functionality |
| 18:31.20 | Pali | doc: I do not have any ECI multibutton headset so I cannot do anything :-( |
| 18:32.32 | dos1 | freemangordon: https://github.com/torvalds/linux/blame/master/sound/soc/omap/rx51.c |
| 18:32.42 | dos1 | https://github.com/torvalds/linux/commit/49100c98359a56ea4e8c9a76e3d625cdb25f25f5 |
| 18:32.53 | dos1 | "This is a cut down version based on Maemo kernel sources and earlier patchset by Eduardo Valentin et al." |
| 18:33.15 | Pali | freemangordon: need to look at meego 2.6.37+ kernel if there are not some patches we need |
| 18:33.26 | freemangordon | Pali: :nod: |
| 18:33.33 | freemangordon | dos1: yeah :( |
| 18:33.33 | Pali | so we will not create new patches which already exists... |
| 18:33.40 | freemangordon | Pali: ok |
| 18:33.47 | freemangordon | makes lots of sense :) |
| 18:34.16 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-37-188-230-228.eurotel.cz) |
| 18:37.30 | dos1 | freemangordon: some fmtx code is there - https://github.com/torvalds/linux/commit/9d7e584b3fb4d9f581b83c0916e10b91de78e663 |
| 18:38.15 | freemangordon | yep, but it is different in nokia kernel aiui |
| 18:38.54 | dos1 | most likely, it seems like updates on that first cut down commit were done independently |
| 18:40.35 | freemangordon | Pali: I think we can remove that "jack gpio" from rx51.c, I guess it is not the driver to decide where to route the sound |
| 18:41.40 | freemangordon | I wonder why only limited functionality was upstreamed |
| 18:45.09 | Pali | ok |
| 18:49.14 | freemangordon | Pali: ok, I'll focus on bridgedriver while waiting for your laptop :) |
| 18:49.30 | Pali | ok :-) |
| 18:49.56 | freemangordon | BTW I almost got it working, but unfortunately as long as it loads baseimage.dof, it spits SYSERROR -102 |
| 18:50.34 | freemangordon | it is something with the voltages I guess, if I remember correctly what I had to do in KP to have it working |
| 18:50.54 | freemangordon | DSP doesn't work if OPP < 3 |
| 18:51.01 | freemangordon | (500 MHz) |
| 18:53.14 | Pali | freemangordon: can you look at firsts patches in 3.12-rc1-n900 tree? there are some which chaning omap clocks... |
| 18:53.23 | Pali | and patches are from Skry |
| 18:57.10 | Pali | freemangordon: and somebody should write some info to LKML about charger patch series, that we really need board hook functions for charger |
| 18:57.31 | Pali | which is needed for charger detection |
| 18:58.00 | Pali | and this cannot be in DT, because in DT cannot be C/ASM function |
| 18:58.18 | freemangordon | Pali: hmm, I tend to agree with the guys that isp1704 could be treated as regulator |
| 18:58.56 | Pali | this is still not enough... you need to control gpio plus handle boost mode |
| 18:59.19 | freemangordon | Pali: can't we do regulator_enable/disable? |
| 18:59.44 | Pali | but this regulator again must be in board code |
| 18:59.49 | Pali | as new function |
| 19:00.06 | freemangordon | why in board code? it can be in bq driver |
| 19:00.12 | Pali | because it is board n900 specific |
| 19:00.44 | freemangordon | Pali: see how ISP deal with vaux3 |
| 19:00.46 | Pali | you need to get data from isp parse them a tell bq2415x what to do |
| 19:00.48 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 19:01.03 | Pali | and plus enable/disable one gpio |
| 19:01.03 | freemangordon | in bq driver there could be a check if there is a regulator assigned |
| 19:01.17 | freemangordon | from DT |
| 19:01.23 | freemangordon | and enable/disable it |
| 19:01.25 | Pali | and parsing output from isp to bq format is n900 specific |
| 19:01.29 | freemangordon | the same for gpio I guess |
| 19:01.33 | Pali | and gpio too |
| 19:02.13 | freemangordon | Pali: you can have that gpio in DT |
| 19:02.17 | freemangordon | correct? |
| 19:02.26 | freemangordon | along with the regulator |
| 19:02.58 | freemangordon | Pali: maybe I should look at the code first :D |
| 19:04.10 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 19:04.18 | freemangordon | Pali: I will check if I can convert isp to regulator framework |
| 19:05.34 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 19:05.37 | freemangordon | Pali: I don;t think we have an option but to do that if we want bq/isp drivers upstreamed |
| 19:14.13 | Pali | ok |
| 19:15.37 | Pali | and need to check if wl1251 fw is in linux-firmware git tree... |
| 19:16.15 | freemangordon | it is, but in a different location :D |
| 19:16.31 | freemangordon | iiuc |
| 19:16.34 | Pali | can you give me link? |
| 19:16.48 | Pali | or check if it is same version as in maemo? |
| 19:17.37 | Pali | and... need to check licence of bluetooth firmware |
| 19:17.57 | freemangordon | https://lkml.org/lkml/2013/9/24/316 |
| 19:18.03 | Pali | anybody here with law skills? |
| 19:21.39 | freemangordon | Pali: hmm, isp1704_charger already using power supply framework, correct? |
| 19:25.37 | Pali | yes |
| 19:25.43 | Pali | bq2415x too |
| 19:26.22 | Pali | maybe we can create new driver rx51_charger and move there functions from board code |
| 19:26.55 | freemangordon | I think there is an easier way, gimme a second |
| 19:26.59 | Pali | so board charger code will be in new driver rx51_charger |
| 19:27.11 | Pali | this could be easy |
| 19:27.53 | Pali | just initialization of charger drivers (platform data) will be in rx51_charger too |
| 19:35.06 | freemangordon | Pali: see http://lxr.free-electrons.com/source/drivers/power/power_supply_core.c#L497 |
| 19:35.45 | freemangordon | we can define in dt that isp supplies bq |
| 19:35.49 | *** join/#maemo-ssu okias (d9c3a136@gateway/web/freenode/ip.217.195.161.54) |
| 19:36.14 | DocScrutinizer05 | [2013-10-06 20:31:20] <Pali> doc: I do not have any ECI multibutton headset so I cannot do anything :-( |
| 19:36.39 | DocScrutinizer05 | mere luck that I noticed that, "doc" is nothing that my IRC client highlights |
| 19:37.35 | freemangordon | and it bq set a listener for POWER_SUPPLY_PROP_CURRENT_MAX prop change |
| 19:37.39 | freemangordon | *and in |
| 19:39.04 | freemangordon | Pali: that way no external driver needed iiuc |
| 19:39.23 | Pali | DocScrutinizer05: if you have some ECI headset, you can try to patch kernel too... |
| 19:39.24 | DocScrutinizer05 | 1704 a regulator? LOL |
| 19:39.42 | freemangordon | DocScrutinizer05: my bad, I meant a power supply |
| 19:39.49 | DocScrutinizer05 | neither |
| 19:39.56 | Pali | freemangordon: can you pass mA from isp to bq? |
| 19:40.16 | DocScrutinizer05 | Pali: I don't have any such headset |
| 19:40.32 | Pali | ok, then nothing to do... |
| 19:41.12 | freemangordon | Pali: you can pass a "property change" event I guess, and you can do power_supply_get_by_name("isp1704") (suppplied from dt) and then you can do get_property() |
| 19:41.36 | freemangordon | Pali: sounds sane to you? |
| 19:42.05 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-91-21.residential.rdsnet.ro) |
| 19:43.30 | Pali | ok, waiting for property mA event and reading it is OK |
| 19:43.41 | DocScrutinizer05 | watches his toe nails curl |
| 19:43.48 | Pali | but still we need to enable gpio |
| 19:44.26 | freemangordon | from bq? |
| 19:44.45 | Pali | now isp calling board function set_power |
| 19:45.01 | Pali | and it is already in upstream kernel |
| 19:45.16 | freemangordon | Pali: leaving for a while, ,will check what can be done in 15 minutes |
| 19:46.34 | DocScrutinizer05 | isp1707 (1704) is a PHY, not a power supply |
| 19:47.43 | DocScrutinizer05 | those kernel freaks. vibrator is a LED, PHY is a power supply. I wait for CPU becoming a battery |
| 19:48.22 | Pali | I think that vibrator is LED is only in nokia kernel... |
| 19:48.26 | DocScrutinizer05 | and possibly LCD a audio device |
| 19:49.27 | Pali | and I bet that isp driver is written by that mr usb man |
| 19:53.42 | DocScrutinizer05 | you know what I'm missing in kernel? A *tiny* bit of decent OO and class hierarchy understanding. Like e.g. it's missing "actor_generic" and "sensor_generic" as basic "object types", and other stuff inheriting from that |
| 19:55.42 | DocScrutinizer05 | but noooo, when we don't have a object class "vibrator2 we look for anything similr, like LED and rape it to service a motor |
| 19:56.24 | DocScrutinizer05 | 1704 even worse, this has ZILCH in common with a power supply, ABSOLUTELY nothing at all |
| 19:57.11 | Pali | it is charger... |
| 19:57.15 | DocScrutinizer05 | NO |
| 19:57.27 | DocScrutinizer05 | it is a PHY |
| 19:58.34 | DocScrutinizer05 | it's hardly _connected_ to any charger |
| 19:58.49 | DocScrutinizer05 | nor any power supply |
| 19:59.11 | DocScrutinizer05 | it's a USB bus driver |
| 19:59.36 | DocScrutinizer05 | you as well could call a NIC a charger or power supply |
| 20:00.43 | Pali | description: ISP170x USB Charger driver |
| 20:00.45 | DocScrutinizer05 | even more since it *might* provide PoE and thus actually would supply power, though to external world, not to circuit |
| 20:01.01 | Pali | this is written in modinfo... |
| 20:01.02 | DocScrutinizer05 | yeah, terrible absolute BULLSHIT |
| 20:01.21 | Pali | going to look who wrote that driver |
| 20:01.38 | DocScrutinizer05 | an idiot |
| 20:03.48 | okias | DocScrutinizer05: I see lot of optimism :D |
| 20:04.45 | DocScrutinizer05 | eh? |
| 20:04.49 | Pali | ISP1704 USB Charger Detection driver |
| 20:05.00 | Pali | Copyright (C) 2010 Nokia Corporation |
| 20:05.05 | Pali | name is hidden |
| 20:05.08 | DocScrutinizer05 | charger DETECTION |
| 20:05.15 | Pali | and we know why :D |
| 20:05.32 | okias | time to git blame :D |
| 20:05.37 | DocScrutinizer05 | it detects wallcharger |
| 20:05.50 | DocScrutinizer05 | that doesn't make it a charger, nor a power supply |
| 20:06.04 | Pali | do you have full git repo of kernel near? |
| 20:06.41 | okias | no :( |
| 20:07.43 | Pali | ok, going to look at linus git web log |
| 20:07.45 | DocScrutinizer05 | confirms my take that it must have been an idiot who reads "charger detection" and thinks "duh, a charger that does detect, so it's >>description: ISP170x USB Charger driver<<" |
| 20:08.39 | DocScrutinizer05 | with this logic ALS is a LED |
| 20:09.01 | Pali | power_supply: Add isp1704 charger detection driver |
| 20:09.02 | DocScrutinizer05 | since it's light detection |
| 20:09.11 | Pali | NXP ISP1704 is Battery Charging Specification 1.0 compliant USB transceiver. This adds a power supply driver for ISP1704 and ISP1707 USB transceivers. |
| 20:09.36 | Pali | Heikki Krogerus <ext-heikki.krogerus@nokia.com> |
| 20:10.05 | Pali | commit: ec46475f3e3163dd80bfee086fa71b36455ecc0b |
| 20:10.15 | Pali | you can contact that person :-) |
| 20:10.28 | DocScrutinizer05 | to do what? |
| 20:11.15 | DocScrutinizer05 | tell him that ISP170x do not supply power? |
| 20:11.49 | DocScrutinizer05 | or tell him that it definitely doesn't CHARGE |
| 20:12.13 | Pali | whatever you want :P |
| 20:12.19 | DocScrutinizer05 | meh |
| 20:12.42 | Pali | so because of nokia... |
| 20:12.50 | DocScrutinizer05 | not because of nokia |
| 20:13.22 | DocScrutinizer05 | >>ISP1704 USB Charger Detection driver<< sounds correct |
| 20:13.49 | DocScrutinizer05 | but been already too long and complicated for ADHS of those other guys |
| 20:14.49 | DocScrutinizer05 | ISP1704 USB Charger Detection driver does exactly one thing: detect Nokia fastcharger via D+/- short |
| 20:14.53 | DocScrutinizer05 | NOTHING else |
| 20:15.12 | DocScrutinizer05 | well, s/driver// |
| 20:15.31 | DocScrutinizer05 | I dunno what the driver does, but I know what charger detection in 1707 does |
| 20:16.32 | DocScrutinizer05 | >>description: ISP170x USB Charger driver<<" != >>ISP1704 USB Charger Detection driver<< |
| 20:17.14 | DocScrutinizer05 | first one suggests 1707 is a battery charger, which it clearly isn't |
| 20:17.47 | DocScrutinizer05 | it's not a charger, it's a detector |
| 20:18.49 | DocScrutinizer05 | basically a derived object of class sensor_generic |
| 20:20.03 | freemangordon | DocScrutinizer05: kowing what it is doesn't help much with the upstreaming :) |
| 20:20.11 | freemangordon | knowing even |
| 20:20.14 | DocScrutinizer05 | not any member of class internal_function_generic, and particularly not of the subclass of that called power_management |
| 20:20.49 | freemangordon | hmm, where's pali gone? |
| 20:21.01 | DocScrutinizer05 | Pali has left this server (Quit: xchat sucks and needs a kick). |
| 20:21.02 | freemangordon | DocScrutinizer05: any clue what GPIO was Pali talking about? |
| 20:21.10 | DocScrutinizer05 | when? |
| 20:21.31 | freemangordon | <Pali> but still we need to enable gpio |
| 20:22.30 | DocScrutinizer05 | maybe he meant the output of 1707? |
| 20:22.41 | DocScrutinizer05 | err nope that is always active afaik |
| 20:22.45 | freemangordon | DocScrutinizer05: which IC is that on the schematic? |
| 20:22.55 | DocScrutinizer05 | maybe he meant the input of bq24150 |
| 20:23.09 | freemangordon | N1140? |
| 20:23.14 | DocScrutinizer05 | which one? 1707? |
| 20:23.30 | freemangordon | bq24150 |
| 20:23.38 | freemangordon | and 1707 as well |
| 20:24.06 | freemangordon | I want to look at how are thoose connected before making conclusions/taking decisions |
| 20:24.15 | DocScrutinizer05 | 24150 = N1140 |
| 20:24.41 | freemangordon | hmm, I see no input gpio there |
| 20:25.43 | DocScrutinizer05 | 1707 = D4280 |
| 20:26.02 | freemangordon | thanks |
| 20:26.03 | DocScrutinizer05 | CHRG_DET |
| 20:26.15 | DocScrutinizer05 | -> OTG |
| 20:26.38 | DocScrutinizer05 | 24150 OTG can be set to different modes |
| 20:27.08 | DocScrutinizer05 | you +could* call bq24150 OTG a GPIO |
| 20:27.20 | freemangordon | hmm, ok, makes sense then |
| 20:28.18 | DocScrutinizer05 | funny enough on 1707 the CHGR_DET is marked as IO ( <> ) |
| 20:28.26 | freemangordon | yep |
| 20:28.30 | DocScrutinizer05 | I wouldn't know how that can act as input |
| 20:28.57 | DocScrutinizer05 | afaik it's an (open collector?) output only |
| 20:28.59 | *** join/#maemo-ssu lenoch (~chatzilla@88.103.110.54) |
| 20:29.35 | DocScrutinizer05 | but you also can program it maybe, to either stay inactive or actually signal D+- short |
| 20:30.07 | DocScrutinizer05 | all this is only used during emergency charge anyway |
| 20:30.16 | DocScrutinizer05 | so you basically can ignore it |
| 20:30.54 | DocScrutinizer05 | 1707 sends "D+- short" message via ULPI bus to musb-hdrc core |
| 20:31.05 | freemangordon | gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on); |
| 20:31.16 | freemangordon | #define RX51_USB_TRANSCEIVER_RST_GPIO67 |
| 20:31.34 | DocScrutinizer05 | ooh, PHY reset |
| 20:31.56 | freemangordon | "ISP_RST" |
| 20:32.18 | DocScrutinizer05 | I don't see such reset on 1707 |
| 20:32.57 | freemangordon | CHIP_SEL |
| 20:33.20 | freemangordon | or DIR? |
| 20:33.42 | freemangordon | yep, CHIP_SEL |
| 20:34.40 | freemangordon | this should be a part of ISP driver IMO |
| 20:34.57 | DocScrutinizer05 | chip_sel is not reset |
| 20:35.05 | DocScrutinizer05 | afaik |
| 20:35.07 | freemangordon | well, don;t ask me |
| 20:35.10 | freemangordon | :) |
| 20:35.18 | freemangordon | I didn't write that code |
| 20:35.59 | DocScrutinizer05 | NB schem tells "GAIA HS-USB transceiver" which is bogus legacy |
| 20:36.26 | DocScrutinizer05 | nah, schem as well has "ISP_RST" |
| 20:36.34 | freemangordon | do you have the datasheet? (I guess you have it) |
| 20:37.00 | DocScrutinizer05 | which might have been the case when it been GAIA's PHY and not a dedicated 1707 |
| 20:37.08 | freemangordon | ok, so for the log: |
| 20:37.37 | DocScrutinizer05 | 1707 datasheet not available, you need to use 1704 and keep in minf that one pin has switched active polarity |
| 20:37.53 | DocScrutinizer05 | mind* |
| 20:38.15 | freemangordon | ISP1707 CHIP_SEL GPIO could be provided for either board code or DT, and set_power board function actually has to be in the ISP driver code |
| 20:38.54 | DocScrutinizer05 | http://www.google.de/search?q=isp1704 |
| 20:39.23 | freemangordon | so, if we have that provided (by either board code or DT), set it in the driver, instead of calling set_power |
| 20:40.20 | freemangordon | yep, deffinitely CHIP_SEL |
| 20:41.49 | DocScrutinizer05 | <PROTECTED> |
| 20:42.04 | freemangordon | hmm, putting pins in high-impedance is not a reset in my book |
| 20:42.18 | DocScrutinizer05 | nope |
| 20:42.20 | freemangordon | however |
| 20:42.22 | DocScrutinizer05 | definitely not |
| 20:42.42 | freemangordon | oh, power-down |
| 20:43.10 | freemangordon | well, we can fix the naming |
| 20:44.30 | DocScrutinizer05 | yep, the schematics has an erratum there |
| 20:46.40 | DocScrutinizer05 | CHGR_DET_EN_N is at gnd level, hardwired |
| 20:47.06 | DocScrutinizer05 | <PROTECTED> |
| 20:47.12 | freemangordon | hmm, this time it seems uptream devs have a point |
| 20:47.57 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-124-88.net.upcbroadband.cz) |
| 20:48.04 | DocScrutinizer05 | hmm? |
| 20:48.10 | freemangordon | isp driver has (or can acwuire) all the needed data without having to call the board code |
| 20:48.22 | freemangordon | *acquire |
| 20:49.14 | DocScrutinizer05 | nfc |
| 20:49.47 | DocScrutinizer05 | CHGR_DET active-HIGH signal to start high current charging; when not in use, leave this pin ope n active-HIGH output; 5 V tolerant; external 100 kΩ pull-down resistor |
| 20:50.04 | freemangordon | will discuss it with Pali when he is back online |
| 20:50.17 | DocScrutinizer05 | again, this is only relevant for emergency-charging |
| 20:51.52 | DocScrutinizer05 | 1707 sends "D+- short" message via ULPI bus to musb-hdrc core |
| 20:52.21 | DocScrutinizer05 | and this is what you see in the sysnode for "charger" |
| 20:53.15 | DocScrutinizer05 | >> /sys/devices/platform/musb_hdrc/charger (SIC!) |
| 20:53.46 | DocScrutinizer05 | musb_hdrc is the only correct location for this |
| 20:54.19 | DocScrutinizer05 | no friggin powersupply or even charger |
| 20:57.37 | DocScrutinizer05 | and this is the reason why musb-hdrc driver needs to be monolithic (no module), since charger detect aka D+- short detect needs to get done very early in boot to not interrupt charging |
| 20:57.53 | freemangordon | cool https://lkml.org/lkml/2013/10/6/127 |
| 21:02.25 | DocScrutinizer05 | sounds good |
| 21:02.39 | DocScrutinizer05 | they finally noticed how cmt_speech works |
| 21:02.57 | DocScrutinizer05 | at least whicj interface it's using |
| 21:24.35 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 21:31.03 | *** join/#maemo-ssu dreamer (~henk@melange.soleus.nu) |
| 21:32.25 | dreamer | lo all. just did a reinstall of my n900, after cssu and powerkernel and such I installed the 'advanced power' application and now the backlight selector has disappeared from the status menu |
| 21:32.38 | dreamer | anyone have an idea where it could have gone? |
| 21:35.08 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 22:31.56 | DocScrutinizer05 | advanced power application? sounds like you better steer clear of it |
| 22:33.24 | DocScrutinizer05 | oh, it's just a battery indicator |
| 22:33.46 | DocScrutinizer05 | it messed up your status bar settings I guess |
| 22:34.00 | DocScrutinizer05 | tricky stuff |
| 22:36.10 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?t=66251 |
| 22:39.59 | DocScrutinizer05 | or you simply didn't scroll down the menu? |
| 22:41.21 | DocScrutinizer05 | btw what's backlight-selector? |
| 22:43.10 | DocScrutinizer05 | dreamer: ^^^ |
| 22:43.12 | psycho_oreos | I was sort of wondering about that, could it be that simple backlight applet where one can tweak backlight brightness from the drop down menu and/or set backlight to be either permanently on or not. |
| 22:43.44 | DocScrutinizer05 | thought as much |
| 22:45.07 | psycho_oreos | In any case I'm pretty sure installing advanced power daemon (that battery monitor thingy) would restart hildon-ui and force a whole bunch of 'applets' to not get loaded. The best idea (imo) is to restart the device so that advanced power monitor daemon would work with the rest of the other hildon 'applets'. |
| 22:46.45 | DocScrutinizer05 | I wonder if it simply has gone "off-screen" into row#6 of the menu |
| 22:47.24 | DocScrutinizer05 | I got it in row#1, anything else is unbearable ;-D |
| 22:48.23 | psycho_oreos | I'm not sure but I'm sure I have had setup advanced power daemon in the past whereby it restarts hildon-ui and a whole bunch of little 'applets' fail to load (things like even the notable cpuload-applet go missing). |
| 22:48.36 | DocScrutinizer05 | I should get rid of the tweaks profile-button |
| 22:49.24 | DocScrutinizer05 | yeah, for sure you need a reboot after messing with status-bar or status-menu config |
| 22:49.28 | psycho_oreos | iinm, advanced power daemon monitor should stick in row one, it replaces that standard battery monitor with a user 'press-able' button along with more information about the battery life, etc. |
| 22:49.47 | psycho_oreos | *nods* |
| 22:49.54 | DocScrutinizer05 | yeah, sounds plausible |
| 22:50.14 | psycho_oreos | Mine is messy as hell, I have a huge drop down list but I'm not particularly fussy about it. :D To each their own. |
| 22:52.34 | DocScrutinizer05 | psycho_oreos: yeah (about advanced power) http://talk.maemo.org/showpost.php?p=884348&postcount=8 |
| 22:56.12 | psycho_oreos | DocScrutinizer05, I guess that's one way to simplify things. I thought the advanced power monitor daemon was made by some other guy. In any case yeah the advanced power monitor daemon is on the top left, row #1, that simple backlight applet thingy is second last on bottom right. |
| 22:56.49 | DocScrutinizer05 | not here :-) |
| 22:56.52 | psycho_oreos | I also suppose that program MohammadAG made was to allow one to customise the list of applets from drop down menu. |
| 22:57.17 | psycho_oreos | Well yeah, seeing as how it's not part of cssu package. :D |
| 22:57.40 | DocScrutinizer05 | nah, it's on row#1 right here |
| 22:57.50 | psycho_oreos | Ahh yeah on the picture. |
| 22:58.07 | psycho_oreos | I have that installed (even though it can be buggy as hell). |
| 22:58.30 | DocScrutinizer05 | buggy? |
| 22:59.33 | DocScrutinizer05 | simple brightness never failed for me |
| 22:59.40 | psycho_oreos | I don't know, it could just be me. I have on certain (or almost every) reboots, apmd shows grey battery bar (meaning battery is either not detected or something). I've had to restart apmd via killing it and letting it redetect the battery. |
| 22:59.50 | psycho_oreos | Nah, the advanced power monitor daemon. |
| 23:00.16 | DocScrutinizer05 | aaah |
| 23:01.05 | psycho_oreos | Simple backlight applet never fails me, apart from that instance when I installed some other applets (like say apmd) made it disappear but hey, that could almost be equated to user error. :D |
| 23:01.35 | DocScrutinizer05 | oh, that's the idiocy about the exclusive opening of the sysnode, or rather the failure to do so, or whatever |
| 23:01.49 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
| 23:03.15 | psycho_oreos | The apmd? I haven't dug far in (and with limited knowledge I'm restricted to "certain level") I thought it was just an issue with python or something. Though I've made an ugly hack to fix apmd, via a small bash script along with queen beecon widget. |
| 23:05.01 | DocScrutinizer05 | I never looked into apmd, but I guess it's the usual problem with bme and stuff exclusively opening some sysnode, and so other apps can't access it |
| 23:05.25 | DocScrutinizer05 | could of course also be related to python |
| 23:06.08 | DocScrutinizer05 | or you even got KP and that battery kernel module |
| 23:06.12 | psycho_oreos | *nods* plausible with sysnode stuff but I have to admit, it's really beyond my depth. I simply resorted to quick (and usually dirty) hacks and be done with it. |
| 23:06.27 | DocScrutinizer05 | that's known to conflict with bme |
| 23:06.28 | psycho_oreos | Hmm I do have KP but not Pali's BME replacement. |
| 23:07.10 | DocScrutinizer05 | lsmod|grep bq27 |
| 23:07.13 | DocScrutinizer05 | I guess |
| 23:07.30 | psycho_oreos | I can imagine if I were to have Pali's BME replacement along with apmd, it would no doubt make a huge mess. ;) figuratively speaking. |
| 23:08.15 | DocScrutinizer05 | dunno what apmd uses to acquire battery data |
| 23:08.20 | psycho_oreos | Hmm crap, and my main N900 is still getting it's battery charged. *sigh* I'll just make do with the other N900 on much older kp and potentially apmd. |
| 23:10.18 | psycho_oreos | I just ran that command on my other N900 and they have returned nothing. I'm guessing bq27 would no doubt be the BME replacement. |
| 23:10.30 | DocScrutinizer05 | wait, it's only the bq27xxx.ko module that does harm when bme starting after it |
| 23:11.11 | *** join/#maemo-ssu piscodig (~discopig@unaffiliated/discopig) |
| 23:11.31 | psycho_oreos | Also thinking about it, bq27xx.ko module was probably available/included into kp50. My spare N900s are running on kp47. |
| 23:11.43 | DocScrutinizer05 | no, it's not exactly bme replacement, it's a deprecated and basically buggy kernel module that apps like apmd use to read out the bq27200 chip |
| 23:11.56 | psycho_oreos | Ahh. hmm. |
| 23:12.27 | DocScrutinizer05 | it's usually blacklisted since it makes bme fail when bme starts after that module got loaded -> reboot |
| 23:15.24 | psycho_oreos | Correction (on my part), I have kp49 not kp47 on spares. I've couldn't find bq27xx.ko but instead found bq27x00_battery.ko |
| 23:15.25 | DocScrutinizer05 | power monitor apps should never use that bq27-battery sysnode, they should either use hal or direct access to bq27200 via i2c, like bq27k-detail.sh does |
| 23:16.43 | psycho_oreos | I'm guessing that's probably where apmd fails, because it probably makes use of sysnode. I've dug into the python script awhile back, though yeah that's ages ago when I did that. |
| 23:16.53 | DocScrutinizer05 | probably apmd is broken in that it's using the bq27x00_battery/* sysnodes |
| 23:21.50 | psycho_oreos | Though wouldn't that be likely cause if say bq27x00_battery.ko is still loaded? I mean in my case bq27x00_battery.ko isn't loaded though it's available. |
| 23:22.19 | psycho_oreos | I just had a quick peek at some of the apmd python stuff, I couldn't quite make sense from out of it. |
| 23:22.54 | psycho_oreos | It doesn't appear to be apmd is making use of bq27x00.ko but I could also be wrong on that part. |