| *** M4rtinK has quit IRC | 00:13 | |
| *** dhbiker has joined #maemo-ssu | 00:45 | |
| freemangordon | sailus: ping | 00:46 |
|---|---|---|
| freemangordon | Pali: some news - seems there is a bug in clock framework, on 2.6.28 SSI clock chain is: | 00:47 |
| freemangordon | "/sys/kernel/debug/clock/virt_19_2m_ck/osc_sys_ck/sys_ck/dpll3_ck/dpll3_x2_ck/dpll3_m2x2_ck/corex2_fck/ssi_ssr_fck/ssi_sst_fck/" | 00:47 |
| freemangordon | on 3.10 it is: | 00:48 |
| freemangordon | well, different :) | 00:48 |
| freemangordon | I fixed that, but still no joy :( | 00:48 |
| freemangordon | Pali: any idea what notion m2x2 (in clock names) means? | 00:49 |
| Pali | no idea | 00:49 |
| Pali | freemangordon: another question: is audio working with 3.10? | 00:50 |
| freemangordon | I am out of ideas, I see cawake interrupts (which IMO means the modem is alive and trying to communicate) | 00:50 |
| freemangordon | Pali: no | 00:50 |
| Pali | ok | 00:50 |
| freemangordon | ... but I see no port interrupts | 00:50 |
| Pali | in 3.5 or 3.8 audio worked | 00:51 |
| Pali | I remember that I heard nokia welcome video | 00:51 |
| freemangordon | I see errors from PA | 00:51 |
| freemangordon | well, that means DSP was working too | 00:51 |
| DocScrutinizer05 | freemangordon: do you have a IRQ-handler set up for that IRQ? | 00:51 |
| freemangordon | yes | 00:51 |
| freemangordon | and I see it in /proc/interrupts | 00:52 |
| Pali | yes, dsp worked before 3.10 (or 3.9) before multiarch for omap3 was introduced | 00:52 |
| freemangordon | but with count of 0 | 00:52 |
| DocScrutinizer05 | is it ever executed? | 00:52 |
| freemangordon | no | 00:52 |
| DocScrutinizer05 | check your IRQ settings | 00:52 |
| DocScrutinizer05 | IRQ on OMAP are... weird | 00:52 |
| Pali | freemangordon: for audio you can try to revert my two audio patches in git tree and then manually load audio kernel modules | 00:53 |
| freemangordon | but cawake interrupt handler is executed | 00:53 |
| freemangordon | port interrupt is not connected to gpio | 00:53 |
| freemangordon | they are fine, it is irq 67 | 00:53 |
| Pali | maybe there is problem | 00:53 |
| freemangordon | Pali: I want SSI working :) | 00:53 |
| DocScrutinizer05 | e.g the IRQ dispatcher/mux needs *clock* to even notice a IRQ, unless it's a wakeup IRQ, afaik | 00:53 |
| Pali | I tried to migrate audio driver/configuration to new format with hotplug and module autoload support | 00:53 |
| Pali | ok | 00:53 |
| freemangordon | DocScrutinizer05: do you have SSI documentation by chance? | 00:54 |
| freemangordon | I hate to work blindly | 00:54 |
| DocScrutinizer05 | sorry nope, lost it with my last job | 00:54 |
| freemangordon | do the guys with gta04 have it? | 00:54 |
| freemangordon | I mean, SSI os a part of OMAP | 00:55 |
| freemangordon | *is | 00:55 |
| *** Martix_ has quit IRC | 00:55 | |
| DocScrutinizer05 | had several 1000 pages of printed docu about MIPI HSI, IRQ in OMAP4 (or the lack of...), SSI, UART, whatnot else | 00:55 |
| freemangordon | DocScrutinizer05: BTW for sure 3.x sets MUX incorrectly for rx51 | 00:55 |
| DocScrutinizer05 | I'm not surprised | 00:56 |
| freemangordon | but this is internal IRQ, MUX config should not matter IMO | 00:56 |
| freemangordon | irq 67, any bell? | 00:56 |
| DocScrutinizer05 | right, it's internal interrupt | 00:56 |
| DocScrutinizer05 | nope | 00:56 |
| freemangordon | ssi_p1_mpu_irq0 | 00:57 |
| freemangordon | shit | 00:57 |
| DocScrutinizer05 | IroN900:~# grep "67:" /proc/interrupts | 00:57 |
| DocScrutinizer05 | 67: 204730 INTC ssi_p1_mpu_irq0 | 00:57 |
| freemangordon | yep, the same with 3.10, but count is 0 | 00:58 |
| freemangordon | honestly, no idea where else to look at | 00:58 |
| freemangordon | maybe I need to set some consumer? | 00:59 |
| DocScrutinizer05 | hmm, 67 not listed in /sys/kernel/debug/omap_gpio | 00:59 |
| freemangordon | it is not gpio | 00:59 |
| DocScrutinizer05 | err, THAT rings a bell. Though absolutely nothing more than that | 00:59 |
| DocScrutinizer05 | "consumer" | 01:00 |
| DocScrutinizer05 | think I heard coleagues bitch about that | 01:00 |
| freemangordon | yep, of some power supply | 01:00 |
| freemangordon | but that makes no sense either, as driver seems to communicate with SSI core | 01:00 |
| DocScrutinizer05 | aaah right | 01:00 |
| freemangordon | ? | 01:00 |
| DocScrutinizer05 | "power supply consumer" | 01:01 |
| freemangordon | yep | 01:01 |
| freemangordon | for RAPU/GAZOO | 01:01 |
| freemangordon | but if cmt is not powered I won;t have cawake interrupts, right? | 01:02 |
| DocScrutinizer05 | consider using a different GPIO/IRQ, just for testing purposes. Like GPIO_68 cam-focus | 01:03 |
| freemangordon | hmm, what for? | 01:03 |
| DocScrutinizer05 | well, I think THAT is a given fact | 01:03 |
| freemangordon | for sure this is the correct IRQ, see 2.6.28 | 01:03 |
| DocScrutinizer05 | sure, I just thought you could press button and see if IRQ-handler jumps | 01:04 |
| freemangordon | 67: 0 INTC ssi_p1_mpu_irq0 | 01:04 |
| DocScrutinizer05 | if you can't debug that pin, just debug another one ;-) | 01:04 |
| freemangordon | I see in init code IRQ handler attached | 01:05 |
| freemangordon | oh, got it | 01:05 |
| freemangordon | but I think this will be just a waste of time | 01:05 |
| freemangordon | BTW in dsp driver there is a code laying with SSI clocks | 01:06 |
| freemangordon | *playing | 01:06 |
| DocScrutinizer05 | I could tell you a lot about "set this bit, clear that bit2 but it's useless since not applicable for the level you're working on | 01:06 |
| DocScrutinizer05 | and I have no clue about all those kernel macros used for IRQ and the like | 01:07 |
| freemangordon | in case you are interested, http://pastebin.com/ji3m5He3 | 01:08 |
| freemangordon | gpios | 01:08 |
| DocScrutinizer05 | I definitely can debug and hack a kernel driver, but I can't write one, or find the huge missing elephant | 01:08 |
| freemangordon | MUX config http://pastebin.com/8P1e7M18 | 01:09 |
| DocScrutinizer05 | I wouldn't even notice it's missing | 01:09 |
| freemangordon | the elephant? :) | 01:09 |
| freemangordon | clocks http://pastebin.com/PR4Vn5Au | 01:10 |
| DocScrutinizer05 | yep, the elephant. I don't know where it's supposed to show up | 01:12 |
| DocScrutinizer05 | but I will notice the peanut that's laying there despite it should've been eaten. Never heard it's elephant to eat it | 01:13 |
| DocScrutinizer05 | yay, MUCH better: http://pastebin.com/raw.php?i=PR4Vn5Au (the format) | 01:15 |
| *** Martix_ has joined #maemo-ssu | 01:16 | |
| freemangordon | yep | 01:16 |
| DocScrutinizer05 | felt nausea from seasickness from http://pastebin.com/PR4Vn5Au | 01:16 |
| DocScrutinizer05 | wtf is "rate"? | 01:17 |
| DocScrutinizer05 | oh nm | 01:18 |
| freemangordon | Hz | 01:18 |
| freemangordon | frequency | 01:18 |
| DocScrutinizer05 | sure | 01:18 |
| DocScrutinizer05 | no idea | 01:19 |
| *** dhbiker has quit IRC | 01:19 | |
| DocScrutinizer05 | except.... use F-Bus to get modem bootlog | 01:20 |
| DocScrutinizer05 | ;-) | 01:20 |
| freemangordon | well, the only thing I didn't play with is regulator consumers | 01:20 |
| DocScrutinizer05 | there are regulators in linux for BB5? | 01:21 |
| freemangordon | DocScrutinizer05: I am sure modem works (cawake changes) | 01:21 |
| freemangordon | see schematics, most of power supplies are connected to GAZOO | 01:21 |
| *** dhbiker has joined #maemo-ssu | 01:21 | |
| DocScrutinizer05 | sure, but gazoo I'd think is under control of BB5 firmware, not APE | 01:22 |
| freemangordon | yes, but power is controlled by omap (via twl) | 01:22 |
| DocScrutinizer05 | main modem power, yeah prolly | 01:22 |
| DocScrutinizer05 | some "CMT_EN" or whatever | 01:23 |
| freemangordon | so if linux *thinks* the regulator is not used, it shuts it down | 01:23 |
| freemangordon | cmt_en is a gpio | 01:23 |
| DocScrutinizer05 | I think it shuts whole modem down | 01:23 |
| DocScrutinizer05 | BB5 is a complete ARM system | 01:23 |
| DocScrutinizer05 | quite similar to OMAP3 | 01:24 |
| DocScrutinizer05 | GAZOO == GAIA | 01:24 |
| freemangordon | no, I mean - the hard way, by shutting the regulators down | 01:24 |
| freemangordon | look at p11 in schematics | 01:24 |
| DocScrutinizer05 | the regulators are not even connected to OMAP I'd guess | 01:24 |
| freemangordon | VANA,VIO, V!* etc | 01:24 |
| freemangordon | V18 | 01:24 |
| freemangordon | yes, but are controlled by omap | 01:24 |
| freemangordon | and this is the whole idea behind hwmod DT iiuc | 01:25 |
| DocScrutinizer05 | how are they controlled when not connected? per RF? | 01:25 |
| DocScrutinizer05 | or IrDA? | 01:25 |
| freemangordon | hwmod/DT | 01:25 |
| freemangordon | regulators are controlled by kernel via TWL | 01:25 |
| freemangordon | iiuc if usage count drops to 0 , the regulator is shut down | 01:26 |
| freemangordon | the same goes for clocks | 01:26 |
| DocScrutinizer05 | I can't see a single data line from OMAP to GAZOO | 01:26 |
| freemangordon | there is no | 01:27 |
| freemangordon | if we dont count gpios as data lines ofc | 01:27 |
| DocScrutinizer05 | then you can't control the regulators in GAZOO from OMAP | 01:27 |
| freemangordon | yes, but VANA,V18,VIO, etc are *inputs* to GAZOO iiuc | 01:28 |
| DocScrutinizer05 | they are controlled by RAPU like the regulators in GAIA are controlled by OMAP | 01:28 |
| DocScrutinizer05 | nope | 01:28 |
| freemangordon | sure? | 01:28 |
| DocScrutinizer05 | those are power line *outputs* from GAZOO | 01:28 |
| freemangordon | oh | 01:28 |
| freemangordon | VANA is output from GAZOO? | 01:29 |
| freemangordon | ok, if you say so | 01:29 |
| *** Martix_ has quit IRC | 01:29 | |
| freemangordon | hmm, coorect | 01:29 |
| freemangordon | *correct | 01:29 |
| freemangordon | these are outgoing arrows | 01:30 |
| DocScrutinizer05 | and no VANA anywhere outside BB5 domain (except camera) | 01:30 |
| DocScrutinizer05 | those are the power supplies fro BB% | 01:30 |
| DocScrutinizer05 | 5 | 01:30 |
| DocScrutinizer05 | dang | 01:30 |
| freemangordon | ok, got it :) | 01:30 |
| freemangordon | hmm, well... | 01:31 |
| freemangordon | NFC where to look then :( | 01:31 |
| DocScrutinizer05 | check the single signal lines from OMAP to RAPU | 01:32 |
| DocScrutinizer05 | check the (one?) databus from OMAP to RAPU | 01:32 |
| freemangordon | I don't have HF scope here | 01:33 |
| DocScrutinizer05 | that's all that connects those two worlds | 01:33 |
| DocScrutinizer05 | is'l <10 lines | 01:33 |
| DocScrutinizer05 | it's | 01:33 |
| freemangordon | not to say I don;t want to disassemble my devel n900 | 01:33 |
| DocScrutinizer05 | Imeant check linux kernel what it does to those lines, compare to 2.6.28 | 01:34 |
| freemangordon | the same driver works with 3.5 | 01:34 |
| DocScrutinizer05 | strace cmt | 01:34 |
| DocScrutinizer05 | or libisi | 01:34 |
| freemangordon | DocScrutinizer05: it doesn;t work on lower layer | 01:35 |
| freemangordon | BOOT INFO REQ fails. Or rather receives no answer | 01:35 |
| freemangordon | And I think the reason is because IRQ is not triggered | 01:35 |
| DocScrutinizer05 | yes, maybe. but anything not working on lower layer should throw an erro on higgher layer. Great diagnose tool | 01:36 |
| freemangordon | well, I have the errors, something like - "timeout trying to power the modem", etc | 01:36 |
| DocScrutinizer05 | strace working system | 01:36 |
| freemangordon | no need, sscd (the one that powers the modem up) traces what it does in syslog | 01:37 |
| freemangordon | whne started with -d 3 | 01:37 |
| DocScrutinizer05 | timeout trying to power modem most likely means the APE waits for a "Hello, here I am!" from modem after doing cmt_en | 01:37 |
| freemangordon | yep | 01:37 |
| DocScrutinizer05 | you need to set up your interface prior tp powering up modem, otherwise "hello, here i am" gets lost. | 01:38 |
| DocScrutinizer05 | and maybe you need to send a "^Q" to make the modem start to talk at all | 01:39 |
| DocScrutinizer05 | ^Q == $random-init-sequence | 01:39 |
| DocScrutinizer05 | for coldflash bootloader it's "." afaik | 01:40 |
| DocScrutinizer05 | ascii 2." | 01:40 |
| DocScrutinizer05 | "." even | 01:40 |
| DocScrutinizer05 | a series of dots | 01:40 |
| DocScrutinizer05 | which tells bootloader that a "terminal" is attached | 01:40 |
| DocScrutinizer05 | for BB5 I guess you need to follow ISI specs on how to establish a communication between APE and BB5 | 01:41 |
| DocScrutinizer05 | wirelssmodemapi stuff | 01:42 |
| DocScrutinizer05 | http://www.cncmods.net/files/ | 01:42 |
| dos1 | wireless modem... lego? :) | 01:43 |
| DocScrutinizer05 | http://www.cncmods.net/files/Wireless%20Modem%20API%20G1%20V2%2010w49.zip | 01:43 |
| DocScrutinizer05 | initializing that ISI interface is not exactly trivial | 01:44 |
| freemangordon | hmm, wait, wtf? | 01:44 |
| * freemangordon is going to check something :) | 01:44 | |
| jon_y | DocScrutinizer05: why are the wireless docs on a game modding site? :) | 01:45 |
| DocScrutinizer05 | it's not like BB5 is supposed to send some plaintext ascii "hello!" via a 192kb UART | 01:45 |
| DocScrutinizer05 | jon_y: that's a misconception | 01:45 |
| jon_y | how so? | 01:46 |
| DocScrutinizer05 | in reality they are on wirelessmodemapi.com | 01:46 |
| jon_y | oh ok, vhost | 01:46 |
| jon_y | well, not vhost | 01:46 |
| DocScrutinizer05 | if you want to call it a vhost, I guess we're fine with that :-) | 01:46 |
| jon_y | dns pointint to the same | 01:46 |
| DocScrutinizer05 | I'd call it jonwil's mirror | 01:47 |
| jon_y | he does CnC part time> | 01:47 |
| jon_y | ? | 01:47 |
| DocScrutinizer05 | *shrug* | 01:47 |
| DocScrutinizer05 | ~wtf CnC | 01:47 |
| jon_y | just curious how it ended up sharing | 01:47 |
| infobot | Gee... I don't know what CnC means... | 01:47 |
| jon_y | Command and Conquer | 01:48 |
| jon_y | in this case CnC3/4 | 01:48 |
| DocScrutinizer05 | sounds OT | 01:48 |
| jon_y | the site is about game modding | 01:48 |
| DocScrutinizer05 | so what? | 01:48 |
| dos1 | jon_y: I'd guess that's his page, or he has some access to it, and just used it to store those files, nothing to see here | 01:48 |
| dos1 | except some cool lego stuff :) | 01:48 |
| jon_y | just curious how it manage to share the site together with wireless modems | 01:49 |
| dos1 | it's just a personal mirror | 01:49 |
| jon_y | probably | 01:49 |
| dos1 | for sure :P | 01:49 |
| DocScrutinizer05 | wirelessmodemapi.com is down since years | 01:50 |
| DocScrutinizer05 | actually I guess since decease of meego | 01:51 |
| *** Martix_ has joined #maemo-ssu | 02:03 | |
| DocScrutinizer05 | freemangordon: the SSI input buffer may be filled, thus the "ready" signal to BB5 not set, thus BB5 not sending new stuff, thus no IRQ associated with new stuff, thus no handler ever cleaning/flushing the input buffer | 02:03 |
| *** M4rtinK has joined #maemo-ssu | 02:16 | |
| *** Pali has quit IRC | 02:20 | |
| *** M4rtinK has quit IRC | 02:25 | |
| *** oldtopman has joined #maemo-ssu | 02:28 | |
| *** xes has quit IRC | 02:47 | |
| *** Martix_ has quit IRC | 03:03 | |
| *** nox- has quit IRC | 03:13 | |
| *** jonwil has joined #maemo-ssu | 03:21 | |
| *** DrCode has quit IRC | 03:22 | |
| *** dos1 has quit IRC | 04:10 | |
| *** X-Fade has quit IRC | 04:15 | |
| *** X-Fade has joined #maemo-ssu | 04:16 | |
| *** DrCode has joined #maemo-ssu | 04:16 | |
| *** mkaindl has left #maemo-ssu | 04:25 | |
| *** LauRoman has joined #maemo-ssu | 04:41 | |
| *** freemangordon has quit IRC | 05:04 | |
| *** freemangordon has joined #maemo-ssu | 05:04 | |
| *** LauRoman has quit IRC | 05:18 | |
| *** freemangordon has quit IRC | 05:31 | |
| *** freemangordon has joined #maemo-ssu | 05:31 | |
| *** amiconn_ has joined #maemo-ssu | 05:57 | |
| *** amiconn has quit IRC | 05:57 | |
| *** amiconn_ is now known as amiconn | 05:57 | |
| *** dhbiker has quit IRC | 06:22 | |
| *** n900-dk has joined #maemo-ssu | 07:21 | |
| *** n900-dk_ has quit IRC | 07:21 | |
| *** oldtopman has quit IRC | 07:42 | |
| *** dafox has joined #maemo-ssu | 07:56 | |
| *** dafox has quit IRC | 08:37 | |
| *** dion_ has joined #maemo-ssu | 08:58 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 09:08 | |
| *** mkaindl has joined #maemo-ssu | 09:14 | |
| *** Vlad_on_the_road has quit IRC | 09:17 | |
| *** mkaindl has quit IRC | 09:45 | |
| *** mkaindl has joined #maemo-ssu | 09:45 | |
| *** Pali has joined #maemo-ssu | 09:54 | |
| freemangordon | Pali: how nice: "new patch, new email" :( | 10:03 |
| freemangordon | WTF is with those guys?!? | 10:03 |
| Pali | no idea | 10:03 |
| freemangordon | maybe you should start writing to linus directly :D | 10:04 |
| Pali | I think I will copy that hunk from previous mail to new and write somethig like guy XYZ was not able to do that | 10:05 |
| Pali | freemangordon: do you remember why mass storage support for g_nokia.ko was rejected? | 10:05 |
| Pali | I think that all usb maintainer do not have everything in head... | 10:06 |
| freemangordon | hmm, no. Wasn't it you that tried to upstream it? | 10:06 |
| Pali | yes I tried to upstream and it | 10:06 |
| Pali | and it was rejected because "only nokia can do any change in his g_nokia.ko driver" | 10:07 |
| freemangordon | oh | 10:07 |
| freemangordon | what is that supposed to mean | 10:07 |
| freemangordon | ? | 10:08 |
| Pali | this means that they do not accept any change to g_nokia.ko driver | 10:08 |
| Pali | maybe only from somebody with @nokia.com email address | 10:08 |
| freemangordon | BTW even with your patches it doesn't work | 10:08 |
| freemangordon | Pali: but how is that possible? | 10:08 |
| Pali | it worked with 3.9 or 3.8 | 10:08 |
| Pali | but in 3.10 is g_nokia.ko totally broken | 10:09 |
| freemangordon | hmm | 10:09 |
| Pali | and I disabled lot of g_nokia.ko code because it I got always kernel panic | 10:09 |
| Pali | usb networking is still enabled and worked | 10:09 |
| freemangordon | it doesn't work for me | 10:09 |
| Pali | I used only rescueos | 10:10 |
| Pali | and manually loading driver + setting ip address it worked | 10:10 |
| freemangordon | tried on both Win XP and Ubuntu 12.04 (my desktop PC and my laptop) | 10:10 |
| Pali | btw, now because usb subsystem (and musb) has bug which cause that charging drivers are non functional, that my patch for usb is required | 10:10 |
| Pali | otherwiese battery charging will not work | 10:10 |
| freemangordon | Pali: I really don;t understand, this Tony guy was rejecting smc3 patchset for an year, now everything is fine, he says "because of DT move, bla, bla" | 10:12 |
| Pali | Tony did not have time... | 10:12 |
| Pali | and he wait until arm guys accept it | 10:12 |
| freemangordon | "This file will be gone as soon as we're moving to device | 10:13 |
| freemangordon | tree based booting. So let's do this in more future proof | 10:13 |
| freemangordon | way. | 10:13 |
| Pali | and only now Dave added: Acked-by | 10:13 |
| freemangordon | this ^^^ | 10:13 |
| Pali | I know | 10:13 |
| freemangordon | I know you know :) | 10:13 |
| freemangordon | sailus: ping | 10:14 |
| freemangordon | no use :) | 10:15 |
| freemangordon | BTW I see no way board code to go. Because of the cameras | 10:16 |
| Pali | freemangordon: can you write some good looking "education" email to that usb patch? Because If I send this which I'm writing now it will not be very good :-) | 10:17 |
| jonwil | http://wiki.maemo.org/Porting/Audio :) | 10:17 |
| Pali | copy paste full second hunk of patch to new mail is stupid | 10:17 |
| jonwil | wrote some stuff on audio for Neo900 | 10:17 |
| freemangordon | You means a a reply? | 10:18 |
| freemangordon | *as a | 10:18 |
| Pali | yes | 10:18 |
| freemangordon | by "education" you mean to share my thoughts on the matter? | 10:18 |
| Pali | write what do you think | 10:19 |
| freemangordon | ok | 10:19 |
| freemangordon | but later, not now | 10:19 |
| Pali | ok | 10:19 |
| freemangordon | have to run | 10:19 |
| jonwil | Pali: Feel free to read http://wiki.maemo.org/Porting and add anything you got :) | 10:20 |
| Pali | ok | 10:20 |
| jonwil | Audio in particular :) | 10:21 |
| jonwil | We need to find someone who has really good pulseaudio knowledge | 10:21 |
| *** dhbiker has joined #maemo-ssu | 10:28 | |
| *** M4rtinK has joined #maemo-ssu | 10:53 | |
| *** sarha has joined #maemo-ssu | 10:56 | |
| Pali | freemangordon: now I'm fed up with that usb guy and going to send not very good looking email | 10:59 |
| *** dagb has quit IRC | 11:00 | |
| *** dagb_ has joined #maemo-ssu | 11:00 | |
| *** mkaindl has left #maemo-ssu | 11:03 | |
| *** Martix_ has joined #maemo-ssu | 11:07 | |
| *** tg has quit IRC | 11:27 | |
| *** tg` has joined #maemo-ssu | 11:28 | |
| * jonwil is glad he doesn't do kernel stuff | 11:28 | |
| jonwil | that way I dont have to deal with all the mess going on | 11:28 |
| *** tg` is now known as tg | 11:29 | |
| Pali | jonwil: I think only usb developers are assholes | 11:29 |
| jonwil | heh | 11:29 |
| Pali | I sent patches to more other subsystems and I never had any problem | 11:29 |
| Pali | only two patches are rejected and both usb | 11:30 |
| jonwil | Its clear now that audio will be the hardest part of the Fremantle porting efforts | 11:31 |
| *** M4rtinK has quit IRC | 11:31 | |
| Pali | now I sent email for that usb guy (also CCed mailinglists) | 11:34 |
| * Pali waiting for ban on all mailinglists | 11:34 | |
| * jonwil wishes he knew more about PulseAudio and ALSA | 11:37 | |
| * jonwil wishes more people cared about the | 11:45 | |
| * jonwil wishes more people cared about the FPTF :( | 11:45 | |
| Pali | FatPhil_: do you know somebody who can still use @nokia.com email address for sending kernel patches? | 11:47 |
| Pali | having @nokia.com address is enough, nothing more is needed | 11:47 |
| Pali | FatPhil_: usb subsystem maintainers rejected patch for g_nokia.ko usb gadget driver because "only nokia can change this part" | 11:48 |
| Pali | and also they did not understand that nokia is not going to update and use linux g_nokia.ko usb gadget anymore... | 11:49 |
| kerio | freemangordon: apt wants me to reinstall python2.5 from the repo :( | 11:54 |
| kerio | why didn't you add a +thumb to the version | 11:54 |
| FatPhil_ | No results found for "only nokia can change this part". | 11:56 |
| FatPhil_ | 1 result found for "Guys, WHY ARE YOU SO STUPID AND ARROGANT?" | 11:56 |
| kerio | the fuck is ke-recv-extra | 11:57 |
| kerio | D: | 11:57 |
| *** freemangordon has quit IRC | 11:57 | |
| kerio | wtf is hulda | 11:57 |
| *** freemangordon has joined #maemo-ssu | 11:57 | |
| Pali | FatPhil_: https://lkml.org/lkml/2013/1/21/66 | 11:58 |
| Pali | FatPhil_: "so unless someone from Nokia says this is how they want to use nokia.c from now on" | 11:59 |
| Pali | and here is patch: https://lkml.org/lkml/2013/1/19/165 | 12:00 |
| FatPhil_ | I can't simply risk | 12:01 |
| FatPhil_ | breaking all other users for your own convenience. | 12:01 |
| Pali | it adding optional/additional support for usb mass storage mode | 12:01 |
| Pali | it is composite usb gadget | 12:03 |
| Pali | and does not break anything if you do not add any device to export | 12:03 |
| FatPhil_ | Then if it wasn't for Felipe's final sentence, I'd say it belongs in a new separate file | 12:04 |
| FatPhil_ | But if they're moving gadget drivers out of the kernel, it's a step in the wrong direction. | 12:04 |
| Pali | all gadget drivers are still in kernel | 12:05 |
| Pali | and I think they will not be removed, because it break userspace and anything... | 12:05 |
| jonwil | At least the N900 kernel isn't as bad as the kernel from my old Motorola Z6 linux phone which was a mess | 12:08 |
| jonwil | this was long before Android | 12:08 |
| jonwil | gotten real quiet in here all of a sudden :P | 12:40 |
| *** Martix_ has quit IRC | 12:41 | |
| *** iDont has joined #maemo-ssu | 13:11 | |
| *** freemangordon has quit IRC | 13:16 | |
| *** freemangordon has joined #maemo-ssu | 13:16 | |
| freemangordon | Pali: nice reading :). | 13:28 |
| *** oooaaaooo has joined #maemo-ssu | 13:36 | |
| *** oooaaaooo has left #maemo-ssu | 13:36 | |
| *** DrCode has quit IRC | 13:50 | |
| *** DrCode has joined #maemo-ssu | 13:53 | |
| freemangordon | FatPhil_: IDK if you follow n900 upstreaming efforts, but honestly, it looks to me kernel maintainers don;t wan't to take n900 patches for some political reasons. For sure I do not support "the conspiracy theory" but something is fishy there | 13:59 |
| jonwil | Perhaps they are uninterested in taking (and then having to maintain) patches that the original maintainers/creators have abandoned | 14:02 |
| jonwil | anyone here know of someone who has pulseaudio skills? :P | 14:03 |
| *** dos1 has joined #maemo-ssu | 14:03 | |
| Pali | jonwil: ask lennart directly :P | 14:15 |
| jonwil | :P | 14:18 |
| jonwil | in any case I think we need to get more interest in FPTF from anyone out there who can contribute :) | 14:20 |
| freemangordon | jonwil: I give a shit what they are interested in, N900 is (and will be for years to come) the only true linux mobile computer. | 14:20 |
| *** arcean has joined #maemo-ssu | 14:21 | |
| freemangordon | there is no other consumer device like that | 14:21 |
| jonwil | And Neo900 is intended to provide all the good things from the N900 and then a bit more (like potentially better cellular support) | 14:22 |
| jonwil | and like a USB port that wont fail if you look at it wrong | 14:23 |
| dos1 | "the only true linux mobile computer" | 14:24 |
| dos1 | you made my Neo Freerunner sad :P | 14:24 |
| dos1 | sure it's much weaker and without fancy cameras, sensors and what else, but it's still "true linux mobile computer" | 14:25 |
| *** BCMM has joined #maemo-ssu | 14:29 | |
| kerio | dos1: your Neo Freerunner is older than the N900! | 14:30 |
| kerio | and the N900 is an obsolete piece of crap! | 14:30 |
| kerio | think about it! | 14:30 |
| dos1 | so if it's old, it's not true linux anymore? :P | 14:31 |
| kerio | nope | 14:31 |
| kerio | true linux has systemd! | 14:31 |
| dos1 | I have it for more than 5 years already | 14:31 |
| freemangordon | dos1: my point was: "consumer device", not geek's gadget :P | 14:31 |
| kerio | and pulseaudio, for speech synth for logins | 14:31 |
| kerio | because of accessibility | 14:31 |
| dos1 | kerio: surprise! my Freerunner has systemd! :D | 14:31 |
| kerio | ...dafuq | 14:31 |
| dos1 | and it had pulseaudio on Om2007.2, but on SHR we don't use that shit :P | 14:32 |
| jonwil | N9 is a "true linux mobile device" | 14:32 |
| freemangordon | yeah, sure | 14:32 |
| kerio | why the hell does SHR use systemd? D: | 14:32 |
| freemangordon | jonwil: what do you use as your daily phone? | 14:33 |
| jonwil | N900 | 14:33 |
| jonwil | its my only phone | 14:33 |
| freemangordon | why you didn't buy n9? | 14:33 |
| jonwil | because I like hw kbd | 14:34 |
| jonwil | and because I have no need to buy a new phone when the phone I have works just fine | 14:34 |
| dos1 | kerio: well, dunno actually. OE has systemd support, and it makes boot faster for low cost, so maybe that's it | 14:34 |
| jonwil | not like all those Apple sheeple who have to have the latest and greatest always :) | 14:34 |
| freemangordon | :) | 14:34 |
| jonwil | just look at the crap that is the iPhone 5S and 5C :P | 14:35 |
| freemangordon | jonwil: and how aegis fits with the "true linux mobile device" statement? | 14:35 |
| dos1 | is 5 years already enough to start thinking about helping with creating new device and getting it many months later? :) | 14:36 |
| dos1 | I feel kinda hipsterish | 14:36 |
| dos1 | heck, I'm probably the last gta02 user in my country | 14:36 |
| dos1 | aegis does not fit at all into any "true linux device". N9 is Android-tier for me | 14:38 |
| freemangordon | my point exactly | 14:39 |
| freemangordon | Pali: could you spend some time later on, teaching me how to send patches to the ML. It is too much of a work for you to do it alone and now I have a laptop with ubuntu, I guess it won;t be much of a hassle for me to set it up as it needs to be and help you | 14:41 |
| Pali | freemangordon: no problem | 14:41 |
| freemangordon | ok, I'll ping you when I am back home, maybe i 3 hours | 14:41 |
| freemangordon | *in | 14:41 |
| Pali | ok | 14:41 |
| freemangordon | maybe we can convince FatPhil_ to help too :P | 14:42 |
| Pali | hm, Sunday, March 24 2013 Sakari Ailus created new rx51-009 branch in omap3camera | 14:44 |
| Pali | I did not know about it | 14:44 |
| Pali | I used camera patches from rx51-007 branch | 14:45 |
| Pali | https://gitorious.org/omap3camera/rx51/activities | 14:45 |
| *** sunny_s has joined #maemo-ssu | 14:47 | |
| Pali | freemangordon look at rx51-009 branch ^^^^ | 14:47 |
| sailus | Pali: pong. | 14:48 |
| Pali | sailus: hi | 14:48 |
| sailus | I noticed you'd pinged me some time ago. -EBUSY. :-P | 14:49 |
| Pali | sailus: freemangordon trying to get n900 cameras to work | 14:49 |
| Pali | but he only see green output | 14:49 |
| Pali | for both back & front | 14:49 |
| sailus | I haven't tried out the camera on the N900 for some time. | 14:49 |
| Pali | do you know where can be problem? | 14:49 |
| sailus | Do you know how did he test them and which kernel did he use? | 14:50 |
| sailus | I haven't updated the patches for quite some time, but I recently rebased them. | 14:50 |
| sailus | They probably don't work. | 14:50 |
| Pali | he used my modified 3.10 tree | 14:50 |
| Pali | and used mediactl for setting connections | 14:50 |
| Pali | and mplayer | 14:50 |
| sailus | Which entities were involved? | 14:51 |
| sailus | The resizer can't be used in that setup. | 14:51 |
| Pali | sailus: my 3.10 tree contains patches from your branch rx51-007 (+ modified) | 14:51 |
| sailus | And... the interfaces that the et8ke8 driver uses are mostly obsolete. | 14:51 |
| sailus | I don't remember if it even uses the pad ops. | 14:52 |
| Pali | sailus: he tested both front and back cameras and both green output | 14:52 |
| sailus | Probably it does, but it's definitely not entirely up to date in terms of the V4L2 subdev API. | 14:52 |
| Pali | I'm going to find pastebin of mediactl outputs | 14:52 |
| sailus | I've tested the smiapp driver on N950 and N9. | 14:53 |
| sailus | Not on N900. Although it should work. | 14:53 |
| Pali | sailus: http://pastebin.com/st0phiUm | 14:54 |
| Pali | other pastebin exired... | 14:54 |
| Pali | so for more info we need to wait until freemangordon will be back | 14:54 |
| sailus | Looks fine for me. | 14:55 |
| *** dhbiker has quit IRC | 14:55 | |
| sailus | I'd still use yavta just to have less modifiers in the setup compared to a known working one. | 14:56 |
| *** dhbiker has joined #maemo-ssu | 14:56 | |
| sailus | yavta is quite nice and simple. | 14:56 |
| Pali | what is yavta? | 14:57 |
| sailus | Yet another V4L2 test application. | 14:58 |
| freemangordon | sailus: hi | 14:58 |
| sailus | freemangordon: Hi! | 14:58 |
| freemangordon | sailus: first of all I had to fix omap3isp code :) | 14:58 |
| sailus | Was there something wrong with it? :-) | 14:58 |
| freemangordon | yes, clk frequency calculation | 14:59 |
| sailus | Has the patch already been submitted to mainline? | 14:59 |
| sailus | I thought there were some uncertainties regarding the 3430 clock rate. | 14:59 |
| sailus | So those have been resolved now? | 15:00 |
| freemangordon | no, recently we have some, errr... problems with mainline :) | 15:00 |
| sailus | :-P | 15:00 |
| freemangordon | anyway , I'll send the patch soon | 15:00 |
| sailus | Cool! :-) | 15:00 |
| freemangordon | but the main problem is that all I get is green rectangle | 15:00 |
| sailus | Have you tested using yavta? | 15:01 |
| freemangordon | with no error messages in dmesg | 15:01 |
| freemangordon | no | 15:01 |
| sailus | I'd suggest to do that first to minimise the difference to a known working setup. | 15:01 |
| freemangordon | this is what I use: | 15:01 |
| sailus | Which is N9(50) + yavta. | 15:01 |
| freemangordon | sailus: the other thing I had to fix is to restore the xshutdown callback | 15:02 |
| sailus | I'd also use only as much of the pipeline inside the ISP that you actually need to, i.e. capture it straight from the CCP2 receiver. | 15:02 |
| sailus | That's wrong. | 15:02 |
| freemangordon | tried that, no difference | 15:02 |
| sailus | There should be GPIOs... | 15:02 |
| sailus | Albeit the hardware is quite strange. It's visible in the schematics. | 15:02 |
| sailus | :-P | 15:02 |
| sailus | Please try with yavta again. | 15:03 |
| sailus | The last time I checked mplayer it used V4L1. :-) | 15:03 |
| freemangordon | sailus: well, maybe I don;t know enough, but I dont see how you'll switch the mux gpio without having the callback | 15:03 |
| sailus | But that was a long time ago. | 15:03 |
| freemangordon | in the correct way that is | 15:03 |
| sailus | I think there would need to be another driver that provides a single gpio that actually translates to two. | 15:03 |
| sailus | And that driver would be specific to N900. | 15:04 |
| freemangordon | and who'll call this driver? | 15:04 |
| freemangordon | some userspace? | 15:04 |
| sailus | It'd provide a single gpio, I suppose. | 15:04 |
| sailus | But I don't know the GPIO framework well --- whether it'd even allow doing that. | 15:05 |
| freemangordon | do you have rx51 schematics near you? to see how the cameras are connected | 15:05 |
| sailus | Actually toggling the gpio is the responsibility of the sensor driver. | 15:05 |
| sailus | I think they can be easily found using Google. | 15:05 |
| sailus | I don't think I have them around myself. | 15:05 |
| freemangordon | xshutdown gpio of front camera is used to switch between cameras too | 15:07 |
| freemangordon | and I can't see how this can be workarounded having a separate driver | 15:08 |
| freemangordon | unless this driver (or board code) is called from smiapp and et8ek8 | 15:09 |
| freemangordon | sailus: ^^^ | 15:10 |
| freemangordon | thus my "restore xshutdown callback" patch | 15:10 |
| sailus | The GPIO API is how you'd call it. | 15:11 |
| Pali | freemangordon: if you have some uncommited/unpushed changes in your tree, can you push them to gitorious? | 15:12 |
| freemangordon | sailus: i have a terrible lag as I am connected through gprs, I'll ping you again later when I am back home and try to explain all over why "separate driver" approach won't work | 15:13 |
| freemangordon | Pali: I think I pushed all camera patches, lemme check | 15:13 |
| *** dagb_ is now known as dagb | 15:13 | |
| Pali | ok | 15:13 |
| sailus | Pali: I don't think I have any. | 15:14 |
| sailus | The GPIO framework seems to be fine btw. | 15:14 |
| sailus | gpiochip_add() and so on... | 15:14 |
| *** iDont has quit IRC | 15:15 | |
| Pali | sailus: problem is that n900 has two gpios, one is for switching between cameras and second is for turning camera on/off | 15:15 |
| Pali | while omap3isp support only on/off gpio | 15:15 |
| Pali | and cannot interact between more cameras | 15:16 |
| sailus | I don't think it's a problem anymore if you use another driver to toggle them. | 15:16 |
| sailus | The sensor driver will still see a single one. | 15:16 |
| Pali | so to create new virtual gpio? | 15:16 |
| Pali | and handle changes of this gpio to read two gpios? | 15:16 |
| Pali | s/read/real/ | 15:17 |
| infobot | Pali meant: and handle changes of this gpio to real two gpios? | 15:17 |
| Pali | and how to force omap3isp to allow only one camera to be turned on at same time? | 15:17 |
| sailus | Although the GPIO framework seems to assome that the GPIOs are independent. That's not quite the case here. | 15:18 |
| sailus | They already use the same bus. | 15:18 |
| sailus | The omap3isp driver handles that already. | 15:19 |
| sailus | (And the mux is switched using on of these gpios.) | 15:19 |
| Pali | ok, but in platform data we need to specify gpio which is used for on/off not switch gpio | 15:20 |
| Pali | I still do not understand how to handle it | 15:20 |
| sailus | A new driver showing up as a GPIO chip will request these two GPIOs. | 15:22 |
| sailus | Both drivers should access only the newly exported GPIO. | 15:22 |
| sailus | Hmm. | 15:23 |
| Pali | ah, so as I wrote create new virtual GPIO | 15:23 |
| sailus | That was my though, yes. | 15:23 |
| Pali | but this is overkill | 15:23 |
| freemangordon | we'd rather need 2 gpios | 15:23 |
| sailus | I actually wonder whether the switch GPIO should be controlled by the ISP driver, not a sensor driver. | 15:24 |
| sailus | It switches the CSI bus between the sensors. | 15:24 |
| sailus | The other one is the xshutdown GPIO. | 15:24 |
| sailus | The solution that's currently in use is somewhat workable but probably will never be accepted to mainline. | 15:25 |
| freemangordon | Pali: 1 virtual gpio would not suffice, as smiapp does gpio_get... and does not free it | 15:25 |
| sailus | I think this will need some experimentation. | 15:25 |
| freemangordon | so et8ek8 gpio_get will fail. or vice versa | 15:25 |
| Pali | so two new virtual gpios | 15:26 |
| *** LauRoman has joined #maemo-ssu | 15:26 | |
| freemangordon | Pali: sailus: having a driver with 2 virtual gpios will do the job with the current framework imo | 15:27 |
| Pali | I think that omap3isp should be fixed to handle this problem | 15:27 |
| Pali | and not to be too creative and create new virtual gpio driver for omap3isp | 15:28 |
| freemangordon | so instead of having xshutdown callback call, we'll have xshutdown gpio | 15:28 |
| Pali | freemangordon: first use callback and when everyting else start working, then we can start writing new gpio driver.... | 15:28 |
| freemangordon | ooh, sure :) | 15:29 |
| Pali | I think that higher priority has non working camera, non working modem, non working audio and not upstreamed charging | 15:29 |
| freemangordon | :nod: | 15:29 |
| Pali | and for me new gpio driver for funny omap3isp has lower priority | 15:30 |
| freemangordon | gitorious is FUBAR again :( | 15:30 |
| freemangordon | Pali: we should move to github ;) | 15:30 |
| Pali | freemangordon: I think this is irrelevant for me :-) I'm using command line git tools | 15:31 |
| *** iDont has joined #maemo-ssu | 15:31 | |
| Pali | freemangordon: or we can ask merlin for hosting git repositories :-) | 15:31 |
| freemangordon | Pali: I wanted to show the patches to sailus | 15:32 |
| Pali | ah, right | 15:33 |
| Pali | freemangordon: use: https://gitorious.org/linux-n900/linux-n900/commit/<sha1> | 15:33 |
| Pali | freemangordon: or your tree: https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/<sha1> | 15:34 |
| freemangordon | sailus: https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/fd8e4d517284adc7ec1d038e5312142025bf18b7 | 15:34 |
| freemangordon | omap3isp fix for 3430 | 15:34 |
| freemangordon | this chunk somehow disappeared after 3.1 or 3.2 | 15:35 |
| freemangordon | sailus: btw another problem with framework - you can't have more than one device connected to xclka for example :) | 15:36 |
| freemangordon | https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/323664abc42aa0161cfbd750ba24e97b5b546f4f | 15:37 |
| sailus | "omap3isp: Set cam_mclk rate directly" --- that probably broke 3430. | 15:37 |
| freemangordon | yep | 15:38 |
| freemangordon | but IDK if this missing divisor is the only thing broken by that patch. | 15:39 |
| sailus | Laurent wrote a patch to fix that. | 15:39 |
| sailus | What's your e-mail? I'll send it to you. | 15:39 |
| sailus | It hasn't been sent to a public list since it's completely untested. | 15:39 |
| freemangordon | sailus: freemangordon at abv dot bg | 15:40 |
| freemangordon | sailus: fix what? | 15:40 |
| sailus | (Or I could push it to a public git tree.) | 15:40 |
| sailus | To fix the clock back-propagation. | 15:40 |
| freemangordon | it is upstreamed | 15:40 |
| sailus | It is? | 15:40 |
| freemangordon | just a second | 15:41 |
| *** oooaaaooo has joined #maemo-ssu | 15:41 | |
| sailus | Doesn't look like that, but I could be mistaken. | 15:41 |
| sailus | I have linux-media tree here. | 15:42 |
| sailus | I doubt Laurent would accept it. :-) | 15:42 |
| oooaaaooo | hi guys ive installed a couple of apps that dont seem to show up in the app screen; other than command line is there a graphical way to find them? | 15:42 |
| freemangordon | sailus: https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/7b2e1277598e4187c9be3e61fd9b0f0423f97986 | 15:42 |
| oooaaaooo | also is "faster app manager" any good? | 15:42 |
| freemangordon | oooaaaooo: ECHAN, try on #maemo | 15:43 |
| sailus | That's for 3630 only. | 15:43 |
| sailus | A similar change is required for 3430. | 15:43 |
| *** oooaaaooo has left #maemo-ssu | 15:43 | |
| freemangordon | oh, right, my bad | 15:44 |
| freemangordon | https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/92d6ac650784d9e4cdf9e5d219aa1060fae081cd | 15:44 |
| freemangordon | not upstreamed | 15:44 |
| freemangordon | sailus: see, my tree has all the needed fixes, drivers load without errors, etc | 15:46 |
| freemangordon | so I guess it is either omap3isp or MUX config | 15:46 |
| freemangordon | to blame that is | 15:46 |
| freemangordon | but I have NFC where and what to look for :)( | 15:47 |
| freemangordon | s/:)(/:)/ | 15:47 |
| infobot | freemangordon meant: but I have NFC where and what to look for :) | 15:47 |
| sailus | Here: | 15:47 |
| sailus | https://gitorious.org/omap3camera/rx51/commit/0878c44382021a8eaf870458c3805f8997356d12 | 15:47 |
| sailus | freemangordon: With that, you shouldn't need to hack anymore. | 15:48 |
| freemangordon | isn't it the same as my patch, just using DEFINE_STRUCT_CLK_FLAGS instead of defining the struct? | 15:49 |
| freemangordon | sailus: ^^^ | 15:51 |
| *** iDont has quit IRC | 15:52 | |
| *** sunny_s has quit IRC | 16:00 | |
| *** arcean has quit IRC | 16:01 | |
| sailus | freemangordon: What matters here is the CLK_SET_RATE_PARENT flag. It was missing. | 16:01 |
| *** sunny_s has joined #maemo-ssu | 16:01 | |
| Pali | sailus: another question: et8rk8 driver using some "firmware", but when I looked into source code of firmware it was only some kernel C structure, it is true? | 16:02 |
| freemangordon | sailus: it was not, in my tree :) https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/92d6ac650784d9e4cdf9e5d219aa1060fae081cd | 16:04 |
| freemangordon | .flags = CLK_SET_RATE_PARENT, | 16:04 |
| sailus | Pali: true. | 16:05 |
| *** RST38h has quit IRC | 16:06 | |
| Pali | sailus: old smia-sensor driver used also some firmware, but new smiapp not using, how it was fixed? | 16:06 |
| Pali | structures was moved to driver? | 16:07 |
| sailus | The "firmware" is not really firmware but hand-written register values that correspond to some sensor configuration. | 16:07 |
| sailus | In the smiapp driver the same configuration is passed using a standard IOCTL interface. | 16:07 |
| sailus | The et8ek8 "firmware" should be moved back to the driver. | 16:08 |
| Pali | sailus: so we need some configuration for smiapp driver to work? | 16:08 |
| sailus | It has a default configuration which is functional. | 16:10 |
| sailus | Not necessarily what you really want, but a working one. | 16:10 |
| freemangordon | Pali: once we have that working, we can forward-port resolutions from omap1/KP | 16:10 |
| sailus | So you have the corresponding patch to Laurent's. Do you still need the other change? | 16:10 |
| freemangordon | sailus: I think I have everything in my tree, it uses clock frameworks, drivers load and init the HW, etc | 16:11 |
| freemangordon | now I cloned and compiled yavta, will try it when i am back home | 16:11 |
| sailus | Ack. | 16:12 |
| freemangordon | sailus: unless you think there is something else needed | 16:12 |
| freemangordon | sailus: please look at the last 10 or so commits here https://gitorious.org/linux-n900/freemangordons-linux-n900/commits/4e272703339f84e65c063c8969e5a69652c0dbda | 16:13 |
| freemangordon | done by "Ivaylo Dimitrov" | 16:13 |
| freemangordon | all those are camera/isp fixes | 16:14 |
| *** RST38h has joined #maemo-ssu | 16:18 | |
| *** oldtopman has joined #maemo-ssu | 16:24 | |
| *** arcean has joined #maemo-ssu | 16:27 | |
| sailus | freemangordon: Thanks! | 16:29 |
| freemangordon | sailus: hmm? what for? | 16:32 |
| freemangordon | sailus: I don't think those could be upstreamed, I just did a quick hacks to have the drivers working. for example - the correct way to handle multiple devices sharng the same xclk is to use list | 16:35 |
| freemangordon | not an array | 16:35 |
| freemangordon | I'll make a patch for that when i have the cameras working :) | 16:35 |
| *** arcean_ has joined #maemo-ssu | 16:42 | |
| *** arcean has quit IRC | 16:46 | |
| *** Martix_ has joined #maemo-ssu | 16:55 | |
| Pali | freemangordon: I moved et8ek8 firmware into kernel driver | 16:59 |
| Pali | so driver does not need external "firmware" from userspace | 16:59 |
| *** Martix_ has quit IRC | 16:59 | |
| freemangordon | Pali: great :) | 17:00 |
| freemangordon | Pali: does it work? :P | 17:00 |
| Pali | only tested compilation | 17:00 |
| Pali | but it must work | 17:01 |
| *** Martix_ has joined #maemo-ssu | 17:01 | |
| Pali | I just replaced pointer from firmware to included structure | 17:01 |
| freemangordon | sure, I was kidding | 17:01 |
| * freemangordon is on his way home, bbl | 17:01 | |
| *** oldtopman has quit IRC | 17:02 | |
| *** iDont has joined #maemo-ssu | 17:03 | |
| *** dos1 has quit IRC | 17:05 | |
| *** dos1 has joined #maemo-ssu | 17:07 | |
| freemangordon | sailus: any recommended cmd line parameters to use for yavta? | 17:51 |
| *** Martix_ has quit IRC | 18:05 | |
| freemangordon | sailus: yavta hangs in ioctl(3, VIDIOC_DQBUF... | 18:05 |
| *** Martix_ has joined #maemo-ssu | 18:08 | |
| *** NIN101 has joined #maemo-ssu | 18:18 | |
| *** BCMM has quit IRC | 18:25 | |
| *** Martix_ has quit IRC | 18:32 | |
| sailus | freemangordon: That likely mean you don't get any buffers back from the driver. | 18:46 |
| sailus | Do you get interrupts? | 18:46 |
| freemangordon | any idea which gpoi/irq to check? | 18:47 |
| freemangordon | *gpio | 18:47 |
| freemangordon | sailus: BTW: | 18:47 |
| sailus | /proc/interrupts | 18:47 |
| freemangordon | :) | 18:47 |
| freemangordon | I know that, but which particular gpio | 18:47 |
| sailus | omap3isp, I guess. | 18:47 |
| freemangordon | btw: | 18:47 |
| freemangordon | cam_xclka 1 1 5760000 | 18:47 |
| freemangordon | is that normal? the frequency I mean | 18:48 |
| sailus | That looks very low to me. | 18:48 |
| sailus | What does it have in the platform data? | 18:48 |
| freemangordon | 40: 0 INTC OMAP3 ISP | 18:48 |
| sailus | No interrupts then. | 18:49 |
| sailus | Something definitely is wrong. | 18:50 |
| freemangordon | .ext_clk= 9.6 * 1000 * 1000, | 18:50 |
| freemangordon | .op_sys_clock= (s64 []){ 12000000 * 10 / 2, 0 }, | 18:50 |
| sailus | On both? | 18:50 |
| freemangordon | this is for smiapp | 18:50 |
| sailus | ext_clk is the one you should be concerned about. | 18:50 |
| sailus | Are you using the smia one? | 18:51 |
| sailus | Ok. | 18:51 |
| freemangordon | smia has it hardcoded in the driver iirc | 18:51 |
| sailus | It doesn't. | 18:51 |
| sailus | It comes from the platform data. | 18:52 |
| freemangordon | #define ET8EK8_XCLK_HZ9600000 | 18:52 |
| freemangordon | unsigned int hz = ET8EK8_XCLK_HZ; | 18:52 |
| freemangordon | rval = clk_set_rate(sensor->ext_clk, hz); | 18:52 |
| freemangordon | sailus: ^^^ | 18:53 |
| sailus | et8ek8 isn't smia compatible. | 18:54 |
| freemangordon | well, it is in i2c/smia dir :) | 18:54 |
| freemangordon | anyway | 18:54 |
| sailus | The problem could be related to discrepancies in how the divisor is chosen. | 18:55 |
| Pali | I can move it from i2c/smia to i2c/ | 18:55 |
| sailus | The information on the parent clock frequency could be wrong. | 18:55 |
| freemangordon | sailus: I saw similar bug on clock framework for SSI clocks | 18:55 |
| sailus | That frequency must be exactly 9,6 MHz. | 18:55 |
| freemangordon | :nod: | 18:55 |
| sailus | :-P | 18:55 |
| * freemangordon is going to check how it is on Nokia kernel | 18:56 | |
| sailus | The frequency is the same. | 18:56 |
| sailus | That has not changed. | 18:56 |
| freemangordon | I meant in /sys/kernel/debug/clk | 18:56 |
| sailus | What has changed.... well, is the clock framework. | 18:56 |
| sailus | Ack. | 18:57 |
| freemangordon | what is reported there and what is the clock tree | 18:57 |
| sailus | Excellent | 18:57 |
| freemangordon | Nokia-N900:~# cat /sys/kernel/debug/clock/virt_19_2m_ck/osc_sys_ck/sys_ck/dpll4_ck/dpll4_m5_ck/dpll4_m5x2_ck/cam_mclk/rate | 19:00 |
| freemangordon | 172800000 | 19:00 |
| *** dos1 has quit IRC | 19:00 | |
| freemangordon | this is on 2.6.28 | 19:00 |
| *** dos1 has joined #maemo-ssu | 19:01 | |
| freemangordon | on 3.10: | 19:01 |
| freemangordon | Nokia-N900:~# cat /sys/kernel/debug/clock/virt_19_2m_ck/osc_sys_ck/sys_ck/dpll4_ck/dpll4_m5_ck/dpll4_m5x2_ck/cam_mclk/rate | 19:01 |
| freemangordon | 172800000 | 19:01 |
| freemangordon | shit | 19:01 |
| freemangordon | cam_mclk 0 0 172800000 | 19:01 |
| freemangordon | but I don;t have xclka child of cam_mclk on 2.6.28 | 19:02 |
| freemangordon | hmm, maybe I should revert my divider patch | 19:03 |
| *** dos1 has quit IRC | 19:08 | |
| *** dos11 has joined #maemo-ssu | 19:08 | |
| *** dos11 has quit IRC | 19:10 | |
| *** dos1 has joined #maemo-ssu | 19:10 | |
| *** dos1 has quit IRC | 19:16 | |
| *** dos1 has joined #maemo-ssu | 19:16 | |
| *** dion_ has left #maemo-ssu | 19:18 | |
| freemangordon | sailus: hmm, with that patch reverted I see "unexpected cam_mclk rate:.." from isp driver | 19:19 |
| Pali | freemangordon: is there any other problem except green output? | 19:19 |
| freemangordon | yep, yavta hangs while trying to get video buffer | 19:20 |
| freemangordon | and there are no interrupts from ISP | 19:20 |
| Pali | because maybe there is one commit which you can try to revert | 19:20 |
| *** LaoLang_cool has joined #maemo-ssu | 19:20 | |
| Pali | 450460412ce758f79d02e9f5db720aa09bd8e6ad | 19:20 |
| freemangordon | which one? | 19:20 |
| *** LaoLang_cool has quit IRC | 19:21 | |
| Pali | I do not know if this commit it in upstream or not, but sailus send me it months ago via email | 19:21 |
| freemangordon | "smiapp-pll: Take existing divisor into account in minimum divisor check"? | 19:21 |
| Pali | yes, can you check if this commit is in upstream? | 19:22 |
| Pali | sailus, can you comment above your patch? ^^^ | 19:22 |
| Pali | and there is another commit which changing some color matrix: 3532af7ad45e54e000dfa7f2b7536e7a58ecc61d | 19:22 |
| Pali | "isppreview: new default coeffs for more ambient independent quality" | 19:23 |
| Pali | freemangordon look (and maybe try to revert it) ^^^^ | 19:23 |
| freemangordon | Pali: ok | 19:30 |
| freemangordon | Pali: reverting 450460412ce758f79d02e9f5db720aa09bd8e6ad made it worse :) | 19:47 |
| Pali | ok, so that patch is really needed :-) | 19:48 |
| freemangordon | yep | 19:48 |
| Pali | without it driver loading failed, right? | 19:48 |
| freemangordon | yep | 19:48 |
| freemangordon | can't find pll div/mul | 19:49 |
| Pali | sailus should comment if that patch is correct ^^^ | 19:49 |
| freemangordon | I can try to hack it and feed pll calculations with doupled frequency :) | 19:50 |
| Pali | freemangordon: look also at second commit | 19:51 |
| freemangordon | Pali: frequency is incorrect, it should be 9.6Mhz not half of that | 19:52 |
| sailus | cam_mclk isn't in the clock framework in 2.6.28 --- the clock is produced by the ISP itself, not PRCM. | 19:54 |
| freemangordon | sailus: no idea who produces it, but it has the same frequency on 2.6.28 and 3.10, according to /sys/kernel/debug/... | 19:55 |
| sailus | That's a good sign then. | 19:55 |
| sailus | Is the divisor also the same? | 19:55 |
| sailus | Based on what we discussed a few hours ago the xclk frequency seemed wrong. | 19:56 |
| freemangordon | how to check the divisor on 2.6.28, any idea? | 19:56 |
| freemangordon | this is my daily device :) | 19:56 |
| freemangordon | (the one with 2.6.28) | 19:57 |
| sailus | :-) | 19:57 |
| sailus | I'm not sure if the driver prints it. | 19:57 |
| freemangordon | wait, can't we just divide mclk freq with 9600000 to get the correct diviso? | 19:57 |
| sailus | You might need to use printk() to print it instead. | 19:57 |
| sailus | But... you can calculate it as well. | 19:57 |
| freemangordon | :nod: | 19:58 |
| sailus | :-) | 19:58 |
| sailus | This assumes the frequency really is what the clock framework suggests. | 20:00 |
| sailus | Now that the parent clock handling bug has been supposedly fixed, I guess that's ok. | 20:00 |
| freemangordon | hmm, could it be that clock framework reports bogus values for xclk? | 20:02 |
| freemangordon | because it is tweaked for 3630, not 3430 | 20:02 |
| sailus | Not really tweaked, but there was the bug that the divisor between cam_mclk and its parent wasn't accounted for on either one. | 20:03 |
| sailus | And only 3430 really worked. | 20:03 |
| freemangordon | well: | 20:04 |
| freemangordon | cam_mclk 0 0 172800000 | 20:04 |
| freemangordon | this looks fine to me | 20:04 |
| freemangordon | the same on 2.6.28 | 20:04 |
| freemangordon | cam_xclkb 0 0 5760000 | 20:04 |
| freemangordon | is deffinitely wrong, lets check the divisor | 20:04 |
| sailus | Just by quick check, you should have 18. | 20:05 |
| sailus | And... why's cam_xclkb? | 20:05 |
| sailus | Both cameras use xclka. | 20:05 |
| freemangordon | :nod: | 20:06 |
| freemangordon | sailus: copy/paster error | 20:06 |
| *** Vlad_on_the_road has joined #maemo-ssu | 20:06 | |
| freemangordon | but xclka is the same | 20:06 |
| sailus | The divisor would be 30 in that case. | 20:06 |
| sailus | That's a strange number. | 20:07 |
| freemangordon | sailus: http://pastebin.com/UgdYDUQn | 20:08 |
| freemangordon | NFC at which value to look at :) | 20:09 |
| DocScrutinizer05 | hah, clock divisors. real fun | 20:09 |
| DocScrutinizer05 | no surprise when new kernel msses it up | 20:10 |
| *** jonwil has quit IRC | 20:10 | |
| freemangordon | sailus: "mul 25 / div 2"? | 20:11 |
| sailus | Ah --- now I think I remember. | 20:12 |
| sailus | The case was that the original configuration from the "firmware" used slightly off-spec frequencies. | 20:12 |
| sailus | And that might not be taken into account in the current quirks in smiapp driver. | 20:12 |
| sailus | It isn't. | 20:13 |
| freemangordon | there are no quirks for vs6555 | 20:13 |
| freemangordon | :) | 20:13 |
| sailus | That's the probable reason for the PLL calculator failure. | 20:13 |
| *** bsdmaniak has joined #maemo-ssu | 20:14 | |
| freemangordon | but it doesn't fail, just calculates wrong values IMO :) | 20:14 |
| freemangordon | sailus: can I just hardcode the correct values? | 20:14 |
| freemangordon | to prove/not if this is the real problem | 20:14 |
| sailus | Indeed --- if it doesn't fail, then that message can be ignored. | 20:15 |
| sailus | Perhaps it was another mode. | 20:15 |
| *** dos11 has joined #maemo-ssu | 20:16 | |
| sailus | You're right --- if there was a failure, you'd see this: | 20:16 |
| sailus | dev_info(dev, "unable to compute pre_pll divisor\n"); | 20:16 |
| freemangordon | which I get if I revert your "smiapp-pll: Take existing divisor into account in minimum divisor check" patch | 20:16 |
| *** dos1 has quit IRC | 20:16 | |
| freemangordon | sailus: btw, which value in the log I should look at? for divisor that is | 20:17 |
| sailus | That's the sensor clock tree calculation. | 20:18 |
| sailus | If it succeeds you should be fine. | 20:18 |
| sailus | What matters whether the ISP produces the clock it should to the sensor. | 20:19 |
| sailus | The cam_xclka frequency suggests it does not. | 20:19 |
| freemangordon | :nod: | 20:19 |
| sailus | But why, is unknown to me. | 20:19 |
| freemangordon | sailus: which is the value from all those I have to look at? | 20:19 |
| sailus | It should "just work". :-P | 20:19 |
| freemangordon | heh | 20:19 |
| freemangordon | :) | 20:19 |
| sailus | None. | 20:20 |
| sailus | ext_clk is just input to the PLL calculator. | 20:20 |
| sailus | Nothing comes out. | 20:20 |
| sailus | I'd figure out why the divisor is 30 and not 18. | 20:20 |
| freemangordon | where you saw that 30? | 20:20 |
| sailus | 172800000/5760000 | 20:20 |
| freemangordon | where did you see even :) | 20:20 |
| freemangordon | well, is it in dmesg log? | 20:21 |
| sailus | I'm quoting you from 20:04. :-) | 20:21 |
| sailus | 17 minutes ago. | 20:21 |
| sailus | I need to go; I might be back later today. | 20:22 |
| freemangordon | sure, but do we have that value logged from the pll calculator? or it is the clock framework that calculates it? | 20:22 |
| freemangordon | sailus: ok | 20:22 |
| sailus | Sorry. | 20:22 |
| sailus | That's internal ISP divisor. | 20:22 |
| sailus | The sensor driver has no part in that. | 20:23 |
| freemangordon | ok | 20:23 |
| sailus | xclk = cam_mclk / divisor AFAIR. | 20:23 |
| freemangordon | :nod: | 20:23 |
| freemangordon | going to check in the clock framework | 20:23 |
| *** M4rtinK has joined #maemo-ssu | 20:23 | |
| *** Martix_ has joined #maemo-ssu | 20:25 | |
| *** WielkiTost has joined #maemo-ssu | 20:26 | |
| sailus | You should check what the ISP driver does and what frequencies it sees. It calculates the divisor. | 20:26 |
| freemangordon | ok, will do | 20:26 |
| freemangordon | thanks! | 20:26 |
| *** dos11 has quit IRC | 20:27 | |
| *** WielkiTost is now known as dos1 | 20:29 | |
| freemangordon | sailus: I hardcoded 18 in isp_xclk_calc_divider, still the same. And still no ISP interrupts | 20:40 |
| freemangordon | but at least: cam_xclkb 0 0 9600000 | 20:41 |
| freemangordon | and cam_xclka 0 0 9600000 | 20:41 |
| *** dagb has left #maemo-ssu | 20:42 | |
| *** bsdmaniak has quit IRC | 20:54 | |
| *** bsdmaniak has joined #maemo-ssu | 20:57 | |
| *** bsdmaniak has quit IRC | 20:58 | |
| *** bsdmaniak has joined #maemo-ssu | 21:13 | |
| *** bsdmaniak has quit IRC | 21:23 | |
| *** iDont has quit IRC | 22:16 | |
| *** iDont has joined #maemo-ssu | 22:18 | |
| *** iDont has quit IRC | 22:23 | |
| sailus | It'd be good to know the reason *why* the divisor isn't 18. | 22:37 |
| DocScrutinizer05 | HAH! http://projects.goldelico.com/p/openphoenux/page/PaidDeveloper/ | 22:45 |
| DocScrutinizer05 | Didn't even know of that :-) | 22:45 |
| *** NIN101 has quit IRC | 22:51 | |
| freemangordon | sailus: I bet it is the clock frameworks that screws it | 23:02 |
| freemangordon | As iiuc dpll4_m5x2 on 3630 runs on a different frequency compared to 3430 | 23:03 |
| freemangordon | but there is no difference in cclock3xxx_data.c | 23:03 |
| *** LauRoman has quit IRC | 23:03 | |
| *** amiconn has quit IRC | 23:06 | |
| *** amiconn has joined #maemo-ssu | 23:08 | |
| DocScrutinizer05 | dnag. Is that a result of sw dudes writing code to rerpesent hw? ;-) | 23:10 |
| DocScrutinizer05 | when you write such definitions, you have to start at the very atoms of a hw design, like crystal frequencies etc | 23:11 |
| DocScrutinizer05 | but that knowledge is rarely found in CS-students' heads, while every EE is aware of that | 23:13 |
| DocScrutinizer05 | given the EE also develops sw | 23:14 |
| DocScrutinizer05 | I heard some CS dudes also develop hardware, and those might actually know, but I guess that's quite exotic a critter to be discovered anywhere | 23:15 |
| *** Vlad_on_the_road has quit IRC | 23:17 | |
| DocScrutinizer05 | I guess there's no such thing like "crystal frequency" in DT, eh? ;-) | 23:26 |
| DocScrutinizer05 | the fun thing in such stuff: when you have a (simplified) hw like ocillator * multiplier1 / divider1, there may be a range of 10..100 valid for multiplier and a range of 1..16 for divider, but yet some particular combinations of the two factors are explicitly forbidden | 23:30 |
| DocScrutinizer05 | and the rules are not as simple as "for multiplier >50, no dividers <10 allowed" | 23:31 |
| DocScrutinizer05 | in the end you usually need a table with available output frequencies and the multiplier and divider values you need to use for them. I guess that's a hard thing to implement in DT | 23:32 |
| DocScrutinizer05 | to make stuff less boring, the different clocks in system are often entangled to each other in complex ways | 23:34 |
| DocScrutinizer05 | like "RAMbus clock *2^N == CPUclock * 2^M" with N,M := int | 23:35 |
| DocScrutinizer05 | err | 23:38 |
| DocScrutinizer05 | like "RAMbus/4 clock *2^N == CPUclock/3 * 2^M" with N,M := int | 23:38 |
| *** arcean_ has quit IRC | 23:39 | |
| DocScrutinizer05 | e.g for the S3C2442 this been a terrible pain in the aft section, for scaling frequency of CPU, since all other clocks based on it and simply changing e.g UART clock on the fly is a really poor idea | 23:42 |
| *** sunny_s has quit IRC | 23:42 | |
| DocScrutinizer05 | also we were not able to set RAMbus speed to the max our RAM would allow, without either under- or over-clocking the CPU | 23:43 |
| DocScrutinizer05 | wow, TV is really giving insights: 70% of US-americans believe in a physically existing hell | 23:46 |
| FatPhil_ | "US-americans"? | 23:47 |
| DocScrutinizer05 | I guess at least 50% believe that earth is 5578 years old, and man been made by God, 70 generations ago | 23:47 |
| FatPhil_ | yup, those are the US americans | 23:48 |
| DocScrutinizer05 | if only those 70% would see the truth, which is: they are _living_ in their hell, every day. they made it themselves | 23:49 |
| Pali | freemangordon: I pushed et8ek8 changes to v3.10-n900 branch on gitorious | 23:53 |
| *** nox- has joined #maemo-ssu | 23:54 | |
| freemangordon | Pali: good | 23:57 |
| Pali | I removed code which can oops kernel :-) | 23:57 |
| freemangordon | hmm | 23:57 |
| * freemangordon is going to check | 23:57 | |
| Pali | et8ek8 could oops kernel if you get it working :-) | 23:58 |
| Pali | NULL derefernce | 23:58 |
| Pali | configure_interface | 23:58 |
| Pali | it was removed from isp driver long time ago | 23:58 |
| Pali | I removed also platform_data->set_xclk because it is not used | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!