| *** Martix_ has joined #maemo-ssu | 00:07 | |
| *** int_ua has quit IRC | 00:18 | |
| *** Martix_ has quit IRC | 00:18 | |
| *** nox- has joined #maemo-ssu | 01:01 | |
| *** kolp_ has quit IRC | 01:20 | |
| *** NIN101 has quit IRC | 01:47 | |
| *** jonwil has joined #maemo-ssu | 02:52 | |
| *** M4rtinK has quit IRC | 03:02 | |
| *** nox- has quit IRC | 03:38 | |
| *** dos1 has quit IRC | 04:20 | |
| *** dos1 has joined #maemo-ssu | 04:25 | |
| *** dos11 has joined #maemo-ssu | 04:27 | |
| *** dos1 has quit IRC | 04:27 | |
| *** LaoLang_cool has joined #maemo-ssu | 04:28 | |
| *** dos11 has quit IRC | 04:33 | |
| *** dos11 has joined #maemo-ssu | 04:41 | |
| *** dos11 has quit IRC | 04:45 | |
| *** LaoLang_cool has quit IRC | 05:06 | |
| *** MetalGearSolid has quit IRC | 05:13 | |
| *** MetalGearSolid has joined #maemo-ssu | 05:13 | |
| *** LaoLang_cool has joined #maemo-ssu | 05:25 | |
| *** amiconn has quit IRC | 05:46 | |
| *** amiconn_ has joined #maemo-ssu | 05:46 | |
| *** amiconn_ is now known as amiconn | 05:46 | |
| *** LaoLang_cool has quit IRC | 05:47 | |
| *** Pali has joined #maemo-ssu | 10:16 | |
| *** discopig has quit IRC | 10:18 | |
| *** DrCode has joined #maemo-ssu | 10:24 | |
| Pali | freemangordon: any news why rtcom-call-ui crashing? | 10:34 |
|---|---|---|
| Pali | maybe it can be that gpio switch which is already used by snd driver? | 10:35 |
| *** DrCode has quit IRC | 10:40 | |
| *** DrCode has joined #maemo-ssu | 10:51 | |
| *** discopig has joined #maemo-ssu | 11:01 | |
| *** Martix_ has joined #maemo-ssu | 11:06 | |
| *** discopig has quit IRC | 11:08 | |
| *** discopig has joined #maemo-ssu | 11:20 | |
| *** discopig has quit IRC | 11:24 | |
| *** discopig has joined #maemo-ssu | 11:29 | |
| *** Martix_ has quit IRC | 11:32 | |
| freemangordon | Pali: didn't have time to debug it | 11:57 |
| freemangordon | but there are more sound switches related errors | 11:58 |
| freemangordon | Jan 1 08:02:30 Nokia-N900 pulseaudio[1547]: voice-sidetone.c: Cannot open /sys/devices/platform/omap-mcbsp.2/st_enable | 12:00 |
| freemangordon | Jan 1 08:02:30 Nokia-N900 pulseaudio[1547]: module-alsa-sink-volume.c: hw:0: Bad mixer mode entry Headphone:off | 12:00 |
| freemangordon | Jan 1 08:02:30 Nokia-N900 pulseaudio[1547]: module-alsa-sink-volume.c: hw:0: Bad mixer mode entry Earphone:off | 12:00 |
| freemangordon | Pali: ^^^ | 12:01 |
| *** Vlad_on_the_road has joined #maemo-ssu | 12:09 | |
| *** NIN101 has joined #maemo-ssu | 12:23 | |
| *** Martix_ has joined #maemo-ssu | 12:35 | |
| *** Vlad_on_the_road has quit IRC | 12:39 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 12:40 | |
| *** Vlad_on_the_road has quit IRC | 12:47 | |
| *** M4rtinK has joined #maemo-ssu | 12:50 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 13:00 | |
| *** Vlad_on_the_road has quit IRC | 13:16 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 13:17 | |
| *** kolp has joined #maemo-ssu | 13:19 | |
| *** delphi is now known as trx | 13:30 | |
| *** Martix_ has quit IRC | 13:53 | |
| *** int_ua has joined #maemo-ssu | 14:10 | |
| *** dos11 has joined #maemo-ssu | 14:15 | |
| *** Martix_ has joined #maemo-ssu | 14:48 | |
| *** Vlad_on_the_road has quit IRC | 14:51 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 15:05 | |
| *** int_ua has quit IRC | 15:19 | |
| *** Martix_ has quit IRC | 16:04 | |
| *** dos11 has quit IRC | 16:36 | |
| *** Pali has quit IRC | 16:47 | |
| *** Martix_ has joined #maemo-ssu | 16:51 | |
| 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 | 17:19 |
| FatPhil | I've converted 3 slightly broken devices into 2 perfect ones, and a "junker". | 17:21 |
| 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. | 17:21 |
| FatPhil | and then the junker should be usable for a developer, just not for your daily device. | 17:22 |
| ShadowJK | how broken is the usb? | 17:26 |
| ShadowJK | traces lifted/missing? | 17:26 |
| FatPhil | To be honest, I didn't even look. It didn't charge, and the socket was visably out of kilter, so presume lifted | 17:29 |
| ShadowJK | aw | 17:30 |
| ShadowJK | I've got two modem-dead devices | 17:30 |
| FatPhil | where in the world are you? | 17:31 |
| jonwil | I am on my 3rd N900 (2 were replaced way back when under warranty) | 17:32 |
| ShadowJK | .fi | 17:32 |
| jonwil | First one had a broken display flex PCB (the one with the status multicolor LED and the front camera on it) | 17:32 |
| jonwil | Then the replacement for that ended up with broken USB | 17:32 |
| FatPhil | Helsinki area? | 17:32 |
| ShadowJK | nop | 17:32 |
| jonwil | then that was replaced under warranty with the third one which I still have | 17:33 |
| 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). | 17:34 |
| 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) | 17:35 |
| ShadowJK | Well also the philips heads are designed to slip and strip | 17:35 |
| FatPhil | yeah, I have a conical indentation that proves that | 17:36 |
| ShadowJK | torx makes more sense, but I suspect some greenpeace hippies drove through philips :P | 17:36 |
| ShadowJK | or hex, when hex goes bad you take torx bit and hammer it in | 17:37 |
| * jonwil has run out of things he can reverse engineer :( | 17:38 | |
| jonwil | Anyone with suggestions on what to reverse engineer next please feel free to suggest them :) | 17:38 |
| FatPhil | jonwil: what's the story on rtcom-call-ui? | 17:39 |
| jonwil | what about it specifically? | 17:39 |
| jonwil | Its closed source and its doing a lot of stuff which I have never been able to fully work out | 17:40 |
| jonwil | mostly because I dont have any knowledge of telepathy | 17:40 |
| 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 | 17:41 |
| jonwil | is there anything specific you want to know about it? | 17:42 |
| FatPhil | I was just told that it was crashing with a new kernel, so was a candidate for reverse engineering | 17:43 |
| jonwil | ok, well as I said, its very complex and hard to reverse engineer | 17:44 |
| jonwil | I need something simpler to fiddle with | 17:45 |
| jonwil | I would fiddle some more with the cellular services daemon but that has been frustrating me too much :( | 17:48 |
| jonwil | Especially since the cellular modem docs I have are quite a few revisions ahead of the cellmo in the N900 | 17:49 |
| jonwil | and since I still cant figure out most of the interface for libisi | 17:51 |
| *** Martix_ has quit IRC | 17:51 | |
| jonwil | maybe I will go back and take another crack at liblocation... | 17:54 |
| *** Martix_ has joined #maemo-ssu | 17:58 | |
| *** dhbiker has joined #maemo-ssu | 18:01 | |
| *** Martix_ has quit IRC | 18:37 | |
| *** amizraa has quit IRC | 18:40 | |
| *** jonwil has quit IRC | 19:03 | |
| *** MetalGearSolid has quit IRC | 19:23 | |
| *** lenoch has joined #maemo-ssu | 19:26 | |
| *** LauRoman has quit IRC | 19:49 | |
| *** dos11 has joined #maemo-ssu | 20:09 | |
| *** dos11 is now known as dos1` | 20:17 | |
| *** dos1` is now known as dos1 | 20:17 | |
| *** sunny_s has quit IRC | 20:35 | |
| *** discopig has quit IRC | 20:39 | |
| *** discopig has joined #maemo-ssu | 20:40 | |
| *** M4rtinK has quit IRC | 20:41 | |
| *** Pali has joined #maemo-ssu | 20:41 | |
| freemangordon | Pali: can't we just rename "avdet-gpio" to "headphone" in rx51.c and solve our problem? | 20:50 |
| 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 | 20:52 |
| Pali | freemangordon: it is not about name but about gpio number | 20:53 |
| freemangordon | #define RX51_GPIO_HEADPHONE177 | 20:53 |
| freemangordon | #define RX51_JACK_DETECT_GPIO177 | 20:54 |
| freemangordon | what is wrong with the number? | 20:54 |
| Pali | freemangordon: still "virtual gpios" needs to be in board data or somwhere... so it will be deleted in DT | 20:54 |
| Pali | freemangordon: renaming is not enough | 20:54 |
| freemangordon | Pali: ok, please, explain what is the peoblem, I don;t get it | 20:55 |
| Pali | only one can use gpio | 20:55 |
| freemangordon | sound driver opens gpio 177 | 20:55 |
| freemangordon | who else need gpio 177? | 20:55 |
| Pali | and for maemo compatibility you need gpios in omap gpio driver | 20:55 |
| Pali | omap gpio switch driver | 20:56 |
| freemangordon | Pali: thus my point | 20:56 |
| freemangordon | maemo needs "headphone" gpio, ain't? | 20:56 |
| Pali | and in upstream kernel sound driver it using too (for jack detection?) | 20:56 |
| Pali | and maemo needs that gpio exported via omap switch driver | 20:56 |
| freemangordon | oh, I see | 20:57 |
| Pali | but only one driver can use it (snd or omap) | 20:57 |
| freemangordon | well, we'll need "virtual gpio" driver then | 20:57 |
| Pali | but I patched omap driver to do not fail if cannot open gpio | 20:57 |
| freemangordon | for sound and for cameras iiuc | 20:57 |
| Pali | and provide fake data to userspace | 20:57 |
| freemangordon | correct? | 20:57 |
| Pali | so apps will see them... | 20:58 |
| freemangordon | ok, got it | 20:58 |
| freemangordon | Pali: where in /sys maemo looks for gpios? | 20:59 |
| freemangordon | "/sys/devices/platform/gpio-switch" ? | 20:59 |
| Pali | yes | 21:00 |
| Pali | but there is already some generic gpio sysfs | 21:00 |
| freemangordon | hmm, can;t we patch omap-gpio driver to make gpios "sharable"? | 21:00 |
| Pali | so maybe we should change omap gpio driver to use that generic sysfs and create symlinks | 21:00 |
| Pali | freemangordon: this is what we should do, but I do not know gpio framework | 21:01 |
| freemangordon | hmm, making symlinks should be easy | 21:01 |
| freemangordon | which driver is "ours"? | 21:02 |
| freemangordon | gpio-omap? | 21:02 |
| freemangordon | oh, it is gpio-switch | 21:03 |
| freemangordon | lemme see what it does | 21:04 |
| freemangordon | Pali: hmm, and how this work in Nokia kernel? | 21:08 |
| freemangordon | Pali: WTF, rx51.c in upstream is missing half of the stuff in KP? who and how upstreamed that?!? | 21:13 |
| Pali | no idea... | 21:13 |
| *** amizraa has joined #maemo-ssu | 21:14 | |
| freemangordon | OMG: "* n810.c -- SoC audio for Nokia RX51" | 21:14 |
| freemangordon | :D:D:D | 21:14 |
| Pali | but snd rx51.c using other separate drivers... | 21:14 |
| Pali | see SELECT in Kconfig | 21:14 |
| freemangordon | the one in KP has select SND_OMAP_SOC_MCBSP more compared to upstream | 21:16 |
| freemangordon | the others are the same | 21:16 |
| freemangordon | hmm, not, equal thing selected | 21:17 |
| freemangordon | no difference | 21:17 |
| Pali | so all subdrivers are similar and main driver rx51.c is smaller? | 21:18 |
| freemangordon | yep | 21:18 |
| Pali | hm, then we maybe missing something | 21:18 |
| Pali | and need to check if tvout detection driver (it is separate in KP) is integrated into rx51.c in upstream or not | 21:19 |
| freemangordon | hmm, I don;t think so | 21:19 |
| freemangordon | seems like upstream has less functionality | 21:19 |
| Pali | ah | 21:19 |
| freemangordon | Pali: http://pastebin.com/2pSFh79f | 21:20 |
| freemangordon | RX51_JACK_MIC and RX51_JACK_ECI are missing from upstream | 21:21 |
| Pali | also need to look at ECI support which Doc wrote... | 21:22 |
| freemangordon | Pali: I guess we should port KP driver | 21:23 |
| freemangordon | and upstream it :( | 21:24 |
| freemangordon | Pali: and it seems upstream is missing fmtx support | 21:27 |
| freemangordon | Pali: http://pastebin.com/1nDCfPrP | 21:28 |
| Pali | freemangordon: when I have notebook back I can look at it :-) | 21:30 |
| freemangordon | ok :) | 21:30 |
| freemangordon | but deffinitely upstream is missing half of the functionality | 21:31 |
| Pali | doc: I do not have any ECI multibutton headset so I cannot do anything :-( | 21:31 |
| dos1 | freemangordon: https://github.com/torvalds/linux/blame/master/sound/soc/omap/rx51.c | 21:32 |
| dos1 | https://github.com/torvalds/linux/commit/49100c98359a56ea4e8c9a76e3d625cdb25f25f5 | 21:32 |
| dos1 | "This is a cut down version based on Maemo kernel sources and earlier patchset by Eduardo Valentin et al." | 21:32 |
| Pali | freemangordon: need to look at meego 2.6.37+ kernel if there are not some patches we need | 21:33 |
| freemangordon | Pali: :nod: | 21:33 |
| freemangordon | dos1: yeah :( | 21:33 |
| Pali | so we will not create new patches which already exists... | 21:33 |
| freemangordon | Pali: ok | 21:33 |
| freemangordon | makes lots of sense :) | 21:33 |
| *** M4rtinK has joined #maemo-ssu | 21:34 | |
| dos1 | freemangordon: some fmtx code is there - https://github.com/torvalds/linux/commit/9d7e584b3fb4d9f581b83c0916e10b91de78e663 | 21:37 |
| freemangordon | yep, but it is different in nokia kernel aiui | 21:38 |
| dos1 | most likely, it seems like updates on that first cut down commit were done independently | 21:38 |
| 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 | 21:40 |
| freemangordon | I wonder why only limited functionality was upstreamed | 21:41 |
| *** lenoch has quit IRC | 21:43 | |
| Pali | ok | 21:45 |
| freemangordon | Pali: ok, I'll focus on bridgedriver while waiting for your laptop :) | 21:49 |
| Pali | ok :-) | 21:49 |
| freemangordon | BTW I almost got it working, but unfortunately as long as it loads baseimage.dof, it spits SYSERROR -102 | 21:49 |
| freemangordon | it is something with the voltages I guess, if I remember correctly what I had to do in KP to have it working | 21:50 |
| freemangordon | DSP doesn't work if OPP < 3 | 21:50 |
| freemangordon | (500 MHz) | 21:51 |
| *** M4rtinK has quit IRC | 21:51 | |
| Pali | freemangordon: can you look at firsts patches in 3.12-rc1-n900 tree? there are some which chaning omap clocks... | 21:53 |
| Pali | and patches are from Skry | 21:53 |
| Pali | freemangordon: and somebody should write some info to LKML about charger patch series, that we really need board hook functions for charger | 21:57 |
| Pali | which is needed for charger detection | 21:57 |
| Pali | and this cannot be in DT, because in DT cannot be C/ASM function | 21:58 |
| freemangordon | Pali: hmm, I tend to agree with the guys that isp1704 could be treated as regulator | 21:58 |
| Pali | this is still not enough... you need to control gpio plus handle boost mode | 21:58 |
| freemangordon | Pali: can't we do regulator_enable/disable? | 21:59 |
| Pali | but this regulator again must be in board code | 21:59 |
| Pali | as new function | 21:59 |
| freemangordon | why in board code? it can be in bq driver | 22:00 |
| Pali | because it is board n900 specific | 22:00 |
| *** DrCode has quit IRC | 22:00 | |
| freemangordon | Pali: see how ISP deal with vaux3 | 22:00 |
| Pali | you need to get data from isp parse them a tell bq2415x what to do | 22:00 |
| *** nox- has joined #maemo-ssu | 22:00 | |
| Pali | and plus enable/disable one gpio | 22:01 |
| freemangordon | in bq driver there could be a check if there is a regulator assigned | 22:01 |
| freemangordon | from DT | 22:01 |
| freemangordon | and enable/disable it | 22:01 |
| Pali | and parsing output from isp to bq format is n900 specific | 22:01 |
| freemangordon | the same for gpio I guess | 22:01 |
| Pali | and gpio too | 22:01 |
| freemangordon | Pali: you can have that gpio in DT | 22:02 |
| freemangordon | correct? | 22:02 |
| freemangordon | along with the regulator | 22:02 |
| freemangordon | Pali: maybe I should look at the code first :D | 22:02 |
| *** Martix_ has joined #maemo-ssu | 22:04 | |
| freemangordon | Pali: I will check if I can convert isp to regulator framework | 22:04 |
| *** DrCode has joined #maemo-ssu | 22:05 | |
| freemangordon | Pali: I don;t think we have an option but to do that if we want bq/isp drivers upstreamed | 22:05 |
| Pali | ok | 22:14 |
| Pali | and need to check if wl1251 fw is in linux-firmware git tree... | 22:15 |
| freemangordon | it is, but in a different location :D | 22:16 |
| freemangordon | iiuc | 22:16 |
| Pali | can you give me link? | 22:16 |
| Pali | or check if it is same version as in maemo? | 22:16 |
| Pali | and... need to check licence of bluetooth firmware | 22:17 |
| freemangordon | https://lkml.org/lkml/2013/9/24/316 | 22:17 |
| Pali | anybody here with law skills? | 22:18 |
| freemangordon | Pali: hmm, isp1704_charger already using power supply framework, correct? | 22:21 |
| Pali | yes | 22:25 |
| Pali | bq2415x too | 22:25 |
| Pali | maybe we can create new driver rx51_charger and move there functions from board code | 22:26 |
| freemangordon | I think there is an easier way, gimme a second | 22:26 |
| Pali | so board charger code will be in new driver rx51_charger | 22:26 |
| Pali | this could be easy | 22:27 |
| Pali | just initialization of charger drivers (platform data) will be in rx51_charger too | 22:27 |
| freemangordon | Pali: see http://lxr.free-electrons.com/source/drivers/power/power_supply_core.c#L497 | 22:35 |
| freemangordon | we can define in dt that isp supplies bq | 22:35 |
| *** okias has joined #maemo-ssu | 22:35 | |
| DocScrutinizer05 | [2013-10-06 20:31:20] <Pali> doc: I do not have any ECI multibutton headset so I cannot do anything :-( | 22:36 |
| DocScrutinizer05 | mere luck that I noticed that, "doc" is nothing that my IRC client highlights | 22:36 |
| freemangordon | and it bq set a listener for POWER_SUPPLY_PROP_CURRENT_MAX prop change | 22:37 |
| freemangordon | *and in | 22:37 |
| freemangordon | Pali: that way no external driver needed iiuc | 22:39 |
| Pali | DocScrutinizer05: if you have some ECI headset, you can try to patch kernel too... | 22:39 |
| DocScrutinizer05 | 1704 a regulator? LOL | 22:39 |
| freemangordon | DocScrutinizer05: my bad, I meant a power supply | 22:39 |
| DocScrutinizer05 | neither | 22:39 |
| Pali | freemangordon: can you pass mA from isp to bq? | 22:39 |
| DocScrutinizer05 | Pali: I don't have any such headset | 22:40 |
| Pali | ok, then nothing to do... | 22:40 |
| 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() | 22:41 |
| freemangordon | Pali: sounds sane to you? | 22:41 |
| *** LauRoman has joined #maemo-ssu | 22:42 | |
| Pali | ok, waiting for property mA event and reading it is OK | 22:43 |
| * DocScrutinizer05 watches his toe nails curl | 22:43 | |
| Pali | but still we need to enable gpio | 22:43 |
| freemangordon | from bq? | 22:44 |
| Pali | now isp calling board function set_power | 22:44 |
| Pali | and it is already in upstream kernel | 22:45 |
| freemangordon | Pali: leaving for a while, ,will check what can be done in 15 minutes | 22:45 |
| DocScrutinizer05 | isp1707 (1704) is a PHY, not a power supply | 22:46 |
| DocScrutinizer05 | those kernel freaks. vibrator is a LED, PHY is a power supply. I wait for CPU becoming a battery | 22:47 |
| Pali | I think that vibrator is LED is only in nokia kernel... | 22:48 |
| DocScrutinizer05 | and possibly LCD a audio device | 22:48 |
| Pali | and I bet that isp driver is written by that mr usb man | 22:49 |
| 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 | 22:53 |
| 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 | 22:55 |
| DocScrutinizer05 | 1704 even worse, this has ZILCH in common with a power supply, ABSOLUTELY nothing at all | 22:56 |
| Pali | it is charger... | 22:57 |
| DocScrutinizer05 | NO | 22:57 |
| DocScrutinizer05 | it is a PHY | 22:57 |
| DocScrutinizer05 | it's hardly _connected_ to any charger | 22:58 |
| DocScrutinizer05 | nor any power supply | 22:58 |
| DocScrutinizer05 | it's a USB bus driver | 22:59 |
| DocScrutinizer05 | you as well could call a NIC a charger or power supply | 22:59 |
| Pali | description: ISP170x USB Charger driver | 23:00 |
| DocScrutinizer05 | even more since it *might* provide PoE and thus actually would supply power, though to external world, not to circuit | 23:00 |
| Pali | this is written in modinfo... | 23:01 |
| DocScrutinizer05 | yeah, terrible absolute BULLSHIT | 23:01 |
| Pali | going to look who wrote that driver | 23:01 |
| DocScrutinizer05 | an idiot | 23:01 |
| okias | DocScrutinizer05: I see lot of optimism :D | 23:03 |
| DocScrutinizer05 | eh? | 23:04 |
| Pali | ISP1704 USB Charger Detection driver | 23:04 |
| Pali | Copyright (C) 2010 Nokia Corporation | 23:05 |
| Pali | name is hidden | 23:05 |
| DocScrutinizer05 | charger DETECTION | 23:05 |
| Pali | and we know why :D | 23:05 |
| okias | time to git blame :D | 23:05 |
| DocScrutinizer05 | it detects wallcharger | 23:05 |
| DocScrutinizer05 | that doesn't make it a charger, nor a power supply | 23:05 |
| Pali | do you have full git repo of kernel near? | 23:06 |
| okias | no :( | 23:06 |
| Pali | ok, going to look at linus git web log | 23:07 |
| 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<<" | 23:07 |
| DocScrutinizer05 | with this logic ALS is a LED | 23:08 |
| Pali | power_supply: Add isp1704 charger detection driver | 23:09 |
| DocScrutinizer05 | since it's light detection | 23:09 |
| Pali | NXP ISP1704 is Battery Charging Specification 1.0 compliant USB transceiver. This adds a power supply driver for ISP1704 and ISP1707 USB transceivers. | 23:09 |
| Pali | Heikki Krogerus <ext-heikki.krogerus@nokia.com> | 23:09 |
| Pali | commit: ec46475f3e3163dd80bfee086fa71b36455ecc0b | 23:10 |
| Pali | you can contact that person :-) | 23:10 |
| DocScrutinizer05 | to do what? | 23:10 |
| DocScrutinizer05 | tell him that ISP170x do not supply power? | 23:11 |
| DocScrutinizer05 | or tell him that it definitely doesn't CHARGE | 23:11 |
| Pali | whatever you want :P | 23:12 |
| DocScrutinizer05 | meh | 23:12 |
| Pali | so because of nokia... | 23:12 |
| DocScrutinizer05 | not because of nokia | 23:12 |
| DocScrutinizer05 | >>ISP1704 USB Charger Detection driver<< sounds correct | 23:13 |
| DocScrutinizer05 | but been already too long and complicated for ADHS of those other guys | 23:13 |
| DocScrutinizer05 | ISP1704 USB Charger Detection driver does exactly one thing: detect Nokia fastcharger via D+/- short | 23:14 |
| DocScrutinizer05 | NOTHING else | 23:14 |
| DocScrutinizer05 | well, s/driver// | 23:15 |
| DocScrutinizer05 | I dunno what the driver does, but I know what charger detection in 1707 does | 23:15 |
| *** Pali has quit IRC | 23:16 | |
| DocScrutinizer05 | >>description: ISP170x USB Charger driver<<" != >>ISP1704 USB Charger Detection driver<< | 23:16 |
| DocScrutinizer05 | first one suggests 1707 is a battery charger, which it clearly isn't | 23:17 |
| DocScrutinizer05 | it's not a charger, it's a detector | 23:17 |
| DocScrutinizer05 | basically a derived object of class sensor_generic | 23:18 |
| freemangordon | DocScrutinizer05: kowing what it is doesn't help much with the upstreaming :) | 23:20 |
| freemangordon | knowing even | 23:20 |
| DocScrutinizer05 | not any member of class internal_function_generic, and particularly not of the subclass of that called power_management | 23:20 |
| freemangordon | hmm, where's pali gone? | 23:20 |
| DocScrutinizer05 | Pali has left this server (Quit: xchat sucks and needs a kick). | 23:21 |
| freemangordon | DocScrutinizer05: any clue what GPIO was Pali talking about? | 23:21 |
| DocScrutinizer05 | when? | 23:21 |
| freemangordon | <Pali> but still we need to enable gpio | 23:21 |
| DocScrutinizer05 | maybe he meant the output of 1707? | 23:22 |
| DocScrutinizer05 | err nope that is always active afaik | 23:22 |
| freemangordon | DocScrutinizer05: which IC is that on the schematic? | 23:22 |
| DocScrutinizer05 | maybe he meant the input of bq24150 | 23:22 |
| freemangordon | N1140? | 23:23 |
| DocScrutinizer05 | which one? 1707? | 23:23 |
| freemangordon | bq24150 | 23:23 |
| freemangordon | and 1707 as well | 23:23 |
| freemangordon | I want to look at how are thoose connected before making conclusions/taking decisions | 23:24 |
| DocScrutinizer05 | 24150 = N1140 | 23:24 |
| freemangordon | hmm, I see no input gpio there | 23:24 |
| DocScrutinizer05 | 1707 = D4280 | 23:25 |
| freemangordon | thanks | 23:26 |
| DocScrutinizer05 | CHRG_DET | 23:26 |
| DocScrutinizer05 | -> OTG | 23:26 |
| DocScrutinizer05 | 24150 OTG can be set to different modes | 23:26 |
| DocScrutinizer05 | you +could* call bq24150 OTG a GPIO | 23:27 |
| freemangordon | hmm, ok, makes sense then | 23:27 |
| DocScrutinizer05 | funny enough on 1707 the CHGR_DET is marked as IO ( <> ) | 23:28 |
| freemangordon | yep | 23:28 |
| DocScrutinizer05 | I wouldn't know how that can act as input | 23:28 |
| DocScrutinizer05 | afaik it's an (open collector?) output only | 23:28 |
| *** lenoch has joined #maemo-ssu | 23:28 | |
| DocScrutinizer05 | but you also can program it maybe, to either stay inactive or actually signal D+- short | 23:29 |
| DocScrutinizer05 | all this is only used during emergency charge anyway | 23:30 |
| DocScrutinizer05 | so you basically can ignore it | 23:30 |
| DocScrutinizer05 | 1707 sends "D+- short" message via ULPI bus to musb-hdrc core | 23:30 |
| freemangordon | gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on); | 23:31 |
| freemangordon | #define RX51_USB_TRANSCEIVER_RST_GPIO67 | 23:31 |
| DocScrutinizer05 | ooh, PHY reset | 23:31 |
| freemangordon | "ISP_RST" | 23:31 |
| DocScrutinizer05 | I don't see such reset on 1707 | 23:32 |
| freemangordon | CHIP_SEL | 23:32 |
| freemangordon | or DIR? | 23:33 |
| freemangordon | yep, CHIP_SEL | 23:33 |
| freemangordon | this should be a part of ISP driver IMO | 23:34 |
| DocScrutinizer05 | chip_sel is not reset | 23:34 |
| DocScrutinizer05 | afaik | 23:35 |
| freemangordon | well, don;t ask me | 23:35 |
| freemangordon | :) | 23:35 |
| freemangordon | I didn't write that code | 23:35 |
| DocScrutinizer05 | NB schem tells "GAIA HS-USB transceiver" which is bogus legacy | 23:35 |
| DocScrutinizer05 | nah, schem as well has "ISP_RST" | 23:36 |
| freemangordon | do you have the datasheet? (I guess you have it) | 23:36 |
| DocScrutinizer05 | which might have been the case when it been GAIA's PHY and not a dedicated 1707 | 23:37 |
| freemangordon | ok, so for the log: | 23:37 |
| DocScrutinizer05 | 1707 datasheet not available, you need to use 1704 and keep in minf that one pin has switched active polarity | 23:37 |
| DocScrutinizer05 | mind* | 23:37 |
| 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 | 23:38 |
| DocScrutinizer05 | http://www.google.de/search?q=isp1704 | 23:38 |
| freemangordon | so, if we have that provided (by either board code or DT), set it in the driver, instead of calling set_power | 23:39 |
| freemangordon | yep, deffinitely CHIP_SEL | 23:40 |
| DocScrutinizer05 | when either the CHIP_SEL or CHIP_SEL_N pin is deasserted, ULPI pins will be i n3-state and the ISP1704A is in power-down mode; both CHIP_SEL and CHIP_SEL_ Nmust be asserted for the ULPI interface to operate normally; when not in use, connect t oVCC(I/O )plain input | 23:41 |
| freemangordon | hmm, putting pins in high-impedance is not a reset in my book | 23:42 |
| DocScrutinizer05 | nope | 23:42 |
| freemangordon | however | 23:42 |
| DocScrutinizer05 | definitely not | 23:42 |
| freemangordon | oh, power-down | 23:42 |
| freemangordon | well, we can fix the naming | 23:43 |
| DocScrutinizer05 | yep, the schematics has an erratum there | 23:44 |
| DocScrutinizer05 | CHGR_DET_EN_N is at gnd level, hardwired | 23:46 |
| DocScrutinizer05 | automatic charger detect enable; connect to VCC when the automatic charger detection is not required; connect to GND when the automatic charger detection is needed i nperipheral mode | 23:47 |
| freemangordon | hmm, this time it seems uptream devs have a point | 23:47 |
| *** M4rtinK has joined #maemo-ssu | 23:47 | |
| DocScrutinizer05 | hmm? | 23:48 |
| freemangordon | isp driver has (or can acwuire) all the needed data without having to call the board code | 23:48 |
| freemangordon | *acquire | 23:48 |
| DocScrutinizer05 | nfc | 23:49 |
| 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 | 23:49 |
| freemangordon | will discuss it with Pali when he is back online | 23:50 |
| DocScrutinizer05 | again, this is only relevant for emergency-charging | 23:50 |
| DocScrutinizer05 | 1707 sends "D+- short" message via ULPI bus to musb-hdrc core | 23:51 |
| DocScrutinizer05 | and this is what you see in the sysnode for "charger" | 23:52 |
| DocScrutinizer05 | >> /sys/devices/platform/musb_hdrc/charger (SIC!) | 23:53 |
| DocScrutinizer05 | musb_hdrc is the only correct location for this | 23:53 |
| DocScrutinizer05 | no friggin powersupply or even charger | 23:54 |
| *** Martix_ has quit IRC | 23:57 | |
| 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 | 23:57 |
| freemangordon | cool https://lkml.org/lkml/2013/10/6/127 | 23:57 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!