| 00:21.13 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 01:16.37 | *** join/#maemo-ssu X-Fade (~xfade@d5152FFD8.static.telenet.be) |
| 01:16.51 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 01:25.57 | *** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 01:41.15 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
| 02:04.12 | *** join/#maemo-ssu freemangordon (~freemango@213.137.35.49) |
| 02:31.32 | *** join/#maemo-ssu freemangordon (~freemango@213.137.35.49) |
| 02:57.23 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 04:21.16 | *** join/#maemo-ssu n900-dk (~kgu@freebox.dk) |
| 04:56.17 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
| 05:58.31 | *** join/#maemo-ssu dion_ (~dion_@dion.org.ua) |
| 06:08.39 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 06:14.33 | *** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 06:45.41 | *** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 06:54.24 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 07:03.34 | freemangordon | Pali: how nice: "new patch, new email" :( |
| 07:03.42 | freemangordon | WTF is with those guys?!? |
| 07:03.47 | Pali | no idea |
| 07:04.21 | freemangordon | maybe you should start writing to linus directly :D |
| 07:05.02 | 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 |
| 07:05.40 | Pali | freemangordon: do you remember why mass storage support for g_nokia.ko was rejected? |
| 07:06.08 | Pali | I think that all usb maintainer do not have everything in head... |
| 07:06.17 | freemangordon | hmm, no. Wasn't it you that tried to upstream it? |
| 07:06.54 | Pali | yes I tried to upstream and it |
| 07:07.09 | Pali | and it was rejected because "only nokia can do any change in his g_nokia.ko driver" |
| 07:07.31 | freemangordon | oh |
| 07:07.47 | freemangordon | what is that supposed to mean |
| 07:08.05 | freemangordon | ? |
| 07:08.11 | Pali | this means that they do not accept any change to g_nokia.ko driver |
| 07:08.36 | Pali | maybe only from somebody with @nokia.com email address |
| 07:08.40 | freemangordon | BTW even with your patches it doesn't work |
| 07:08.50 | freemangordon | Pali: but how is that possible? |
| 07:08.55 | Pali | it worked with 3.9 or 3.8 |
| 07:09.06 | Pali | but in 3.10 is g_nokia.ko totally broken |
| 07:09.16 | freemangordon | hmm |
| 07:09.28 | Pali | and I disabled lot of g_nokia.ko code because it I got always kernel panic |
| 07:09.42 | Pali | usb networking is still enabled and worked |
| 07:09.56 | freemangordon | it doesn't work for me |
| 07:10.08 | Pali | I used only rescueos |
| 07:10.31 | Pali | and manually loading driver + setting ip address it worked |
| 07:10.39 | freemangordon | tried on both Win XP and Ubuntu 12.04 (my desktop PC and my laptop) |
| 07:10.51 | 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 |
| 07:10.59 | Pali | otherwiese battery charging will not work |
| 07:12.14 | 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" |
| 07:12.34 | Pali | Tony did not have time... |
| 07:12.53 | Pali | and he wait until arm guys accept it |
| 07:13.16 | freemangordon | "This file will be gone as soon as we're moving to device |
| 07:13.16 | freemangordon | tree based booting. So let's do this in more future proof |
| 07:13.18 | freemangordon | way. |
| 07:13.33 | Pali | and only now Dave added: Acked-by |
| 07:13.33 | freemangordon | this ^^^ |
| 07:13.41 | Pali | I know |
| 07:13.47 | freemangordon | I know you know :) |
| 07:14.12 | freemangordon | sailus: ping |
| 07:15.18 | freemangordon | no use :) |
| 07:16.44 | freemangordon | BTW I see no way board code to go. Because of the cameras |
| 07:17.34 | 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 :-) |
| 07:17.51 | jonwil | http://wiki.maemo.org/Porting/Audio :) |
| 07:17.58 | Pali | copy paste full second hunk of patch to new mail is stupid |
| 07:17.58 | jonwil | wrote some stuff on audio for Neo900 |
| 07:18.14 | freemangordon | You means a a reply? |
| 07:18.22 | freemangordon | *as a |
| 07:18.22 | Pali | yes |
| 07:18.45 | freemangordon | by "education" you mean to share my thoughts on the matter? |
| 07:19.08 | Pali | write what do you think |
| 07:19.12 | freemangordon | ok |
| 07:19.25 | freemangordon | but later, not now |
| 07:19.32 | Pali | ok |
| 07:19.34 | freemangordon | have to run |
| 07:20.16 | jonwil | Pali: Feel free to read http://wiki.maemo.org/Porting and add anything you got :) |
| 07:20.26 | Pali | ok |
| 07:21.30 | jonwil | Audio in particular :) |
| 07:21.54 | jonwil | We need to find someone who has really good pulseaudio knowledge |
| 07:28.35 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 07:53.48 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-124-88.net.upcbroadband.cz) |
| 07:56.05 | *** join/#maemo-ssu sarha (~sarha@kapsi.fi) |
| 07:59.08 | Pali | freemangordon: now I'm fed up with that usb guy and going to send not very good looking email |
| 08:00.48 | *** join/#maemo-ssu dagb_ (~dagb@80.203.63.59) |
| 08:03.32 | *** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 08:07.20 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 08:28.09 | *** join/#maemo-ssu tg` (~x@unaffiliated/tg) |
| 08:28.14 | jonwil | is glad he doesn't do kernel stuff |
| 08:28.27 | jonwil | that way I dont have to deal with all the mess going on |
| 08:29.32 | Pali | jonwil: I think only usb developers are assholes |
| 08:29.50 | jonwil | heh |
| 08:29.53 | Pali | I sent patches to more other subsystems and I never had any problem |
| 08:30.23 | Pali | only two patches are rejected and both usb |
| 08:31.43 | jonwil | Its clear now that audio will be the hardest part of the Fremantle porting efforts |
| 08:34.28 | Pali | now I sent email for that usb guy (also CCed mailinglists) |
| 08:34.50 | Pali | waiting for ban on all mailinglists |
| 08:37.41 | jonwil | wishes he knew more about PulseAudio and ALSA |
| 08:45.09 | jonwil | wishes more people cared about the |
| 08:45.51 | jonwil | wishes more people cared about the FPTF :( |
| 08:47.09 | Pali | FatPhil_: do you know somebody who can still use @nokia.com email address for sending kernel patches? |
| 08:47.33 | Pali | having @nokia.com address is enough, nothing more is needed |
| 08:48.28 | Pali | FatPhil_: usb subsystem maintainers rejected patch for g_nokia.ko usb gadget driver because "only nokia can change this part" |
| 08:49.24 | Pali | and also they did not understand that nokia is not going to update and use linux g_nokia.ko usb gadget anymore... |
| 08:54.55 | kerio | freemangordon: apt wants me to reinstall python2.5 from the repo :( |
| 08:54.59 | kerio | why didn't you add a +thumb to the version |
| 08:56.08 | FatPhil_ | No results found for "only nokia can change this part". |
| 08:56.45 | FatPhil_ | 1 result found for "Guys, WHY ARE YOU SO STUPID AND ARROGANT?" |
| 08:57.01 | kerio | the fuck is ke-recv-extra |
| 08:57.03 | kerio | D: |
| 08:57.45 | kerio | wtf is hulda |
| 08:57.46 | *** join/#maemo-ssu freemangordon (~freemango@213.137.35.49) |
| 08:58.41 | Pali | FatPhil_: https://lkml.org/lkml/2013/1/21/66 |
| 08:59.40 | Pali | FatPhil_: "so unless someone from Nokia says this is how they want to use nokia.c from now on" |
| 09:00.32 | Pali | and here is patch: https://lkml.org/lkml/2013/1/19/165 |
| 09:01.20 | FatPhil_ | I can't simply risk |
| 09:01.21 | FatPhil_ | breaking all other users for your own convenience. |
| 09:01.38 | Pali | it adding optional/additional support for usb mass storage mode |
| 09:03.29 | Pali | it is composite usb gadget |
| 09:03.53 | Pali | and does not break anything if you do not add any device to export |
| 09:04.01 | FatPhil_ | Then if it wasn't for Felipe's final sentence, I'd say it belongs in a new separate file |
| 09:04.44 | FatPhil_ | But if they're moving gadget drivers out of the kernel, it's a step in the wrong direction. |
| 09:05.08 | Pali | all gadget drivers are still in kernel |
| 09:05.23 | Pali | and I think they will not be removed, because it break userspace and anything... |
| 09:08.09 | jonwil | At least the N900 kernel isn't as bad as the kernel from my old Motorola Z6 linux phone which was a mess |
| 09:08.26 | jonwil | this was long before Android |
| 09:40.04 | jonwil | gotten real quiet in here all of a sudden :P |
| 10:11.07 | *** join/#maemo-ssu iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 10:16.36 | *** join/#maemo-ssu freemangordon (~freemango@213.137.35.49) |
| 10:28.10 | freemangordon | Pali: nice reading :). |
| 10:36.29 | *** join/#maemo-ssu oooaaaooo (~rootzilla@d122-109-54-62.per802.wa.optusnet.com.au) |
| 10:36.49 | *** part/#maemo-ssu oooaaaooo (~rootzilla@d122-109-54-62.per802.wa.optusnet.com.au) |
| 10:53.52 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 10:59.08 | 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 |
| 11:02.07 | jonwil | Perhaps they are uninterested in taking (and then having to maintain) patches that the original maintainers/creators have abandoned |
| 11:03.16 | jonwil | anyone here know of someone who has pulseaudio skills? :P |
| 11:03.48 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 11:15.43 | Pali | jonwil: ask lennart directly :P |
| 11:18.50 | jonwil | :P |
| 11:20.24 | jonwil | in any case I think we need to get more interest in FPTF from anyone out there who can contribute :) |
| 11:20.45 | 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. |
| 11:21.01 | *** join/#maemo-ssu arcean (~arcean@aadb186.neoplus.adsl.tpnet.pl) |
| 11:21.08 | freemangordon | there is no other consumer device like that |
| 11:22.35 | jonwil | And Neo900 is intended to provide all the good things from the N900 and then a bit more (like potentially better cellular support) |
| 11:23.14 | jonwil | and like a USB port that wont fail if you look at it wrong |
| 11:24.11 | dos1 | "the only true linux mobile computer" |
| 11:24.17 | dos1 | you made my Neo Freerunner sad :P |
| 11:25.26 | dos1 | sure it's much weaker and without fancy cameras, sensors and what else, but it's still "true linux mobile computer" |
| 11:29.42 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 11:30.36 | kerio | dos1: your Neo Freerunner is older than the N900! |
| 11:30.40 | kerio | and the N900 is an obsolete piece of crap! |
| 11:30.45 | kerio | think about it! |
| 11:31.13 | dos1 | so if it's old, it's not true linux anymore? :P |
| 11:31.20 | kerio | nope |
| 11:31.24 | kerio | true linux has systemd! |
| 11:31.33 | dos1 | I have it for more than 5 years already |
| 11:31.36 | freemangordon | dos1: my point was: "consumer device", not geek's gadget :P |
| 11:31.37 | kerio | and pulseaudio, for speech synth for logins |
| 11:31.44 | kerio | because of accessibility |
| 11:31.48 | dos1 | kerio: surprise! my Freerunner has systemd! :D |
| 11:31.56 | kerio | ...dafuq |
| 11:32.11 | dos1 | and it had pulseaudio on Om2007.2, but on SHR we don't use that shit :P |
| 11:32.23 | jonwil | N9 is a "true linux mobile device" |
| 11:32.31 | freemangordon | yeah, sure |
| 11:32.47 | kerio | why the hell does SHR use systemd? D: |
| 11:33.10 | freemangordon | jonwil: what do you use as your daily phone? |
| 11:33.30 | jonwil | N900 |
| 11:33.37 | jonwil | its my only phone |
| 11:33.51 | freemangordon | why you didn't buy n9? |
| 11:34.01 | jonwil | because I like hw kbd |
| 11:34.19 | jonwil | and because I have no need to buy a new phone when the phone I have works just fine |
| 11:34.34 | dos1 | kerio: well, dunno actually. OE has systemd support, and it makes boot faster for low cost, so maybe that's it |
| 11:34.37 | jonwil | not like all those Apple sheeple who have to have the latest and greatest always :) |
| 11:34.46 | freemangordon | :) |
| 11:35.13 | jonwil | just look at the crap that is the iPhone 5S and 5C :P |
| 11:35.41 | freemangordon | jonwil: and how aegis fits with the "true linux mobile device" statement? |
| 11:36.08 | dos1 | is 5 years already enough to start thinking about helping with creating new device and getting it many months later? :) |
| 11:36.22 | dos1 | I feel kinda hipsterish |
| 11:36.50 | dos1 | heck, I'm probably the last gta02 user in my country |
| 11:38.03 | dos1 | aegis does not fit at all into any "true linux device". N9 is Android-tier for me |
| 11:39.29 | freemangordon | my point exactly |
| 11:41.01 | 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 |
| 11:41.28 | Pali | freemangordon: no problem |
| 11:41.47 | freemangordon | ok, I'll ping you when I am back home, maybe i 3 hours |
| 11:41.50 | freemangordon | *in |
| 11:41.54 | Pali | ok |
| 11:42.55 | freemangordon | maybe we can convince FatPhil_ to help too :P |
| 11:44.48 | Pali | hm, Sunday, March 24 2013 Sakari Ailus created new rx51-009 branch in omap3camera |
| 11:44.55 | Pali | I did not know about it |
| 11:45.14 | Pali | I used camera patches from rx51-007 branch |
| 11:45.19 | Pali | https://gitorious.org/omap3camera/rx51/activities |
| 11:47.39 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 11:47.52 | Pali | freemangordon look at rx51-009 branch ^^^^ |
| 11:48.35 | sailus | Pali: pong. |
| 11:48.46 | Pali | sailus: hi |
| 11:49.03 | sailus | I noticed you'd pinged me some time ago. -EBUSY. :-P |
| 11:49.12 | Pali | sailus: freemangordon trying to get n900 cameras to work |
| 11:49.17 | Pali | but he only see green output |
| 11:49.26 | Pali | for both back & front |
| 11:49.46 | sailus | I haven't tried out the camera on the N900 for some time. |
| 11:49.47 | Pali | do you know where can be problem? |
| 11:50.03 | sailus | Do you know how did he test them and which kernel did he use? |
| 11:50.17 | sailus | I haven't updated the patches for quite some time, but I recently rebased them. |
| 11:50.20 | sailus | They probably don't work. |
| 11:50.24 | Pali | he used my modified 3.10 tree |
| 11:50.47 | Pali | and used mediactl for setting connections |
| 11:50.58 | Pali | and mplayer |
| 11:51.35 | sailus | Which entities were involved? |
| 11:51.43 | sailus | The resizer can't be used in that setup. |
| 11:51.48 | Pali | sailus: my 3.10 tree contains patches from your branch rx51-007 (+ modified) |
| 11:51.58 | sailus | And... the interfaces that the et8ke8 driver uses are mostly obsolete. |
| 11:52.14 | sailus | I don't remember if it even uses the pad ops. |
| 11:52.38 | Pali | sailus: he tested both front and back cameras and both green output |
| 11:52.38 | sailus | Probably it does, but it's definitely not entirely up to date in terms of the V4L2 subdev API. |
| 11:52.46 | Pali | I'm going to find pastebin of mediactl outputs |
| 11:53.06 | sailus | I've tested the smiapp driver on N950 and N9. |
| 11:53.15 | sailus | Not on N900. Although it should work. |
| 11:54.08 | Pali | sailus: http://pastebin.com/st0phiUm |
| 11:54.37 | Pali | other pastebin exired... |
| 11:54.51 | Pali | so for more info we need to wait until freemangordon will be back |
| 11:55.44 | sailus | Looks fine for me. |
| 11:56.09 | sailus | I'd still use yavta just to have less modifiers in the setup compared to a known working one. |
| 11:56.14 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 11:56.22 | sailus | yavta is quite nice and simple. |
| 11:57.35 | Pali | what is yavta? |
| 11:58.04 | sailus | Yet another V4L2 test application. |
| 11:58.12 | freemangordon | sailus: hi |
| 11:58.20 | sailus | freemangordon: Hi! |
| 11:58.33 | freemangordon | sailus: first of all I had to fix omap3isp code :) |
| 11:58.49 | sailus | Was there something wrong with it? :-) |
| 11:59.16 | freemangordon | yes, clk frequency calculation |
| 11:59.44 | sailus | Has the patch already been submitted to mainline? |
| 11:59.59 | sailus | I thought there were some uncertainties regarding the 3430 clock rate. |
| 12:00.07 | sailus | So those have been resolved now? |
| 12:00.20 | freemangordon | no, recently we have some, errr... problems with mainline :) |
| 12:00.31 | sailus | :-P |
| 12:00.37 | freemangordon | anyway , I'll send the patch soon |
| 12:00.46 | sailus | Cool! :-) |
| 12:00.59 | freemangordon | but the main problem is that all I get is green rectangle |
| 12:01.08 | sailus | Have you tested using yavta? |
| 12:01.10 | freemangordon | with no error messages in dmesg |
| 12:01.13 | freemangordon | no |
| 12:01.27 | sailus | I'd suggest to do that first to minimise the difference to a known working setup. |
| 12:01.29 | freemangordon | this is what I use: |
| 12:01.39 | sailus | Which is N9(50) + yavta. |
| 12:02.11 | freemangordon | sailus: the other thing I had to fix is to restore the xshutdown callback |
| 12:02.17 | 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. |
| 12:02.28 | sailus | That's wrong. |
| 12:02.32 | freemangordon | tried that, no difference |
| 12:02.35 | sailus | There should be GPIOs... |
| 12:02.51 | sailus | Albeit the hardware is quite strange. It's visible in the schematics. |
| 12:02.58 | sailus | :-P |
| 12:03.05 | sailus | Please try with yavta again. |
| 12:03.20 | sailus | The last time I checked mplayer it used V4L1. :-) |
| 12:03.23 | freemangordon | sailus: well, maybe I don;t know enough, but I dont see how you'll switch the mux gpio without having the callback |
| 12:03.24 | sailus | But that was a long time ago. |
| 12:03.37 | freemangordon | in the correct way that is |
| 12:03.55 | sailus | I think there would need to be another driver that provides a single gpio that actually translates to two. |
| 12:04.11 | sailus | And that driver would be specific to N900. |
| 12:04.24 | freemangordon | and who'll call this driver? |
| 12:04.29 | freemangordon | some userspace? |
| 12:04.52 | sailus | It'd provide a single gpio, I suppose. |
| 12:05.11 | sailus | But I don't know the GPIO framework well --- whether it'd even allow doing that. |
| 12:05.25 | freemangordon | do you have rx51 schematics near you? to see how the cameras are connected |
| 12:05.29 | sailus | Actually toggling the gpio is the responsibility of the sensor driver. |
| 12:05.41 | sailus | I think they can be easily found using Google. |
| 12:05.47 | sailus | I don't think I have them around myself. |
| 12:07.57 | freemangordon | xshutdown gpio of front camera is used to switch between cameras too |
| 12:08.34 | freemangordon | and I can't see how this can be workarounded having a separate driver |
| 12:09.35 | freemangordon | unless this driver (or board code) is called from smiapp and et8ek8 |
| 12:10.20 | freemangordon | sailus: ^^^ |
| 12:10.54 | freemangordon | thus my "restore xshutdown callback" patch |
| 12:11.08 | sailus | The GPIO API is how you'd call it. |
| 12:12.45 | Pali | freemangordon: if you have some uncommited/unpushed changes in your tree, can you push them to gitorious? |
| 12:13.15 | 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 |
| 12:13.30 | freemangordon | Pali: I think I pushed all camera patches, lemme check |
| 12:13.47 | Pali | ok |
| 12:14.38 | sailus | Pali: I don't think I have any. |
| 12:14.46 | sailus | The GPIO framework seems to be fine btw. |
| 12:14.56 | sailus | gpiochip_add() and so on... |
| 12:15.42 | Pali | sailus: problem is that n900 has two gpios, one is for switching between cameras and second is for turning camera on/off |
| 12:15.56 | Pali | while omap3isp support only on/off gpio |
| 12:16.06 | Pali | and cannot interact between more cameras |
| 12:16.16 | sailus | I don't think it's a problem anymore if you use another driver to toggle them. |
| 12:16.26 | sailus | The sensor driver will still see a single one. |
| 12:16.38 | Pali | so to create new virtual gpio? |
| 12:16.54 | Pali | and handle changes of this gpio to read two gpios? |
| 12:17.03 | Pali | s/read/real/ |
| 12:17.39 | Pali | and how to force omap3isp to allow only one camera to be turned on at same time? |
| 12:18.12 | sailus | Although the GPIO framework seems to assome that the GPIOs are independent. That's not quite the case here. |
| 12:18.50 | sailus | They already use the same bus. |
| 12:19.07 | sailus | The omap3isp driver handles that already. |
| 12:19.22 | sailus | (And the mux is switched using on of these gpios.) |
| 12:20.12 | Pali | ok, but in platform data we need to specify gpio which is used for on/off not switch gpio |
| 12:20.50 | Pali | I still do not understand how to handle it |
| 12:22.37 | sailus | A new driver showing up as a GPIO chip will request these two GPIOs. |
| 12:22.56 | sailus | Both drivers should access only the newly exported GPIO. |
| 12:23.35 | sailus | Hmm. |
| 12:23.37 | Pali | ah, so as I wrote create new virtual GPIO |
| 12:23.45 | sailus | That was my though, yes. |
| 12:23.56 | Pali | but this is overkill |
| 12:23.59 | freemangordon | we'd rather need 2 gpios |
| 12:24.06 | sailus | I actually wonder whether the switch GPIO should be controlled by the ISP driver, not a sensor driver. |
| 12:24.16 | sailus | It switches the CSI bus between the sensors. |
| 12:24.32 | sailus | The other one is the xshutdown GPIO. |
| 12:25.09 | freemangordon | Pali: 1 virtual gpio would not suffice, as smiapp does gpio_get... and does not free it |
| 12:25.10 | sailus | The solution that's currently in use is somewhat workable but probably will never be accepted to mainline. |
| 12:25.24 | sailus | I think this will need some experimentation. |
| 12:25.45 | freemangordon | so et8ek8 gpio_get will fail. or vice versa |
| 12:26.01 | Pali | so two new virtual gpios |
| 12:26.10 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
| 12:27.24 | freemangordon | Pali: sailus: having a driver with 2 virtual gpios will do the job with the current framework imo |
| 12:27.45 | Pali | I think that omap3isp should be fixed to handle this problem |
| 12:28.00 | Pali | and not to be too creative and create new virtual gpio driver for omap3isp |
| 12:28.02 | freemangordon | so instead of having xshutdown callback call, we'll have xshutdown gpio |
| 12:28.54 | Pali | freemangordon: first use callback and when everyting else start working, then we can start writing new gpio driver.... |
| 12:29.03 | freemangordon | ooh, sure :) |
| 12:29.31 | Pali | I think that higher priority has non working camera, non working modem, non working audio and not upstreamed charging |
| 12:29.51 | freemangordon | :nod: |
| 12:30.07 | Pali | and for me new gpio driver for funny omap3isp has lower priority |
| 12:30.39 | freemangordon | gitorious is FUBAR again :( |
| 12:30.51 | freemangordon | Pali: we should move to github ;) |
| 12:31.14 | Pali | freemangordon: I think this is irrelevant for me :-) I'm using command line git tools |
| 12:31.19 | *** join/#maemo-ssu iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 12:31.43 | Pali | freemangordon: or we can ask merlin for hosting git repositories :-) |
| 12:32.56 | freemangordon | Pali: I wanted to show the patches to sailus |
| 12:33.11 | Pali | ah, right |
| 12:33.41 | Pali | freemangordon: use: https://gitorious.org/linux-n900/linux-n900/commit/<sha1> |
| 12:34.19 | Pali | freemangordon: or your tree: https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/<sha1> |
| 12:34.26 | freemangordon | sailus: https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/fd8e4d517284adc7ec1d038e5312142025bf18b7 |
| 12:34.36 | freemangordon | omap3isp fix for 3430 |
| 12:35.14 | freemangordon | this chunk somehow disappeared after 3.1 or 3.2 |
| 12:36.11 | freemangordon | sailus: btw another problem with framework - you can't have more than one device connected to xclka for example :) |
| 12:37.02 | freemangordon | https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/323664abc42aa0161cfbd750ba24e97b5b546f4f |
| 12:37.23 | sailus | "omap3isp: Set cam_mclk rate directly" --- that probably broke 3430. |
| 12:38.11 | freemangordon | yep |
| 12:39.01 | freemangordon | but IDK if this missing divisor is the only thing broken by that patch. |
| 12:39.05 | sailus | Laurent wrote a patch to fix that. |
| 12:39.34 | sailus | What's your e-mail? I'll send it to you. |
| 12:39.48 | sailus | It hasn't been sent to a public list since it's completely untested. |
| 12:40.11 | freemangordon | sailus: freemangordon at abv dot bg |
| 12:40.21 | freemangordon | sailus: fix what? |
| 12:40.27 | sailus | (Or I could push it to a public git tree.) |
| 12:40.33 | sailus | To fix the clock back-propagation. |
| 12:40.40 | freemangordon | it is upstreamed |
| 12:40.51 | sailus | It is? |
| 12:41.03 | freemangordon | just a second |
| 12:41.46 | *** join/#maemo-ssu oooaaaooo (~rootzilla@d122-109-54-62.per802.wa.optusnet.com.au) |
| 12:41.55 | sailus | Doesn't look like that, but I could be mistaken. |
| 12:42.00 | sailus | I have linux-media tree here. |
| 12:42.16 | sailus | I doubt Laurent would accept it. :-) |
| 12:42.25 | 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? |
| 12:42.42 | freemangordon | sailus: https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/7b2e1277598e4187c9be3e61fd9b0f0423f97986 |
| 12:42.49 | oooaaaooo | also is "faster app manager" any good? |
| 12:43.08 | freemangordon | oooaaaooo: ECHAN, try on #maemo |
| 12:43.40 | sailus | That's for 3630 only. |
| 12:43.46 | sailus | A similar change is required for 3430. |
| 12:43.57 | *** part/#maemo-ssu oooaaaooo (~rootzilla@d122-109-54-62.per802.wa.optusnet.com.au) |
| 12:44.33 | freemangordon | oh, right, my bad |
| 12:44.36 | freemangordon | https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/92d6ac650784d9e4cdf9e5d219aa1060fae081cd |
| 12:44.43 | freemangordon | not upstreamed |
| 12:46.17 | freemangordon | sailus: see, my tree has all the needed fixes, drivers load without errors, etc |
| 12:46.38 | freemangordon | so I guess it is either omap3isp or MUX config |
| 12:46.46 | freemangordon | to blame that is |
| 12:47.02 | freemangordon | but I have NFC where and what to look for :)( |
| 12:47.20 | freemangordon | s/:)(/:)/ |
| 12:47.39 | sailus | Here: |
| 12:47.41 | sailus | https://gitorious.org/omap3camera/rx51/commit/0878c44382021a8eaf870458c3805f8997356d12 |
| 12:48.17 | sailus | freemangordon: With that, you shouldn't need to hack anymore. |
| 12:49.02 | freemangordon | isn't it the same as my patch, just using DEFINE_STRUCT_CLK_FLAGS instead of defining the struct? |
| 12:51.13 | freemangordon | sailus: ^^^ |
| 13:01.28 | sailus | freemangordon: What matters here is the CLK_SET_RATE_PARENT flag. It was missing. |
| 13:01.39 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 13:02.39 | 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? |
| 13:04.13 | freemangordon | sailus: it was not, in my tree :) https://gitorious.org/linux-n900/freemangordons-linux-n900/commit/92d6ac650784d9e4cdf9e5d219aa1060fae081cd |
| 13:04.49 | freemangordon | .flags = CLK_SET_RATE_PARENT, |
| 13:05.46 | sailus | Pali: true. |
| 13:06.54 | Pali | sailus: old smia-sensor driver used also some firmware, but new smiapp not using, how it was fixed? |
| 13:07.19 | Pali | structures was moved to driver? |
| 13:07.36 | sailus | The "firmware" is not really firmware but hand-written register values that correspond to some sensor configuration. |
| 13:07.53 | sailus | In the smiapp driver the same configuration is passed using a standard IOCTL interface. |
| 13:08.32 | sailus | The et8ek8 "firmware" should be moved back to the driver. |
| 13:08.45 | Pali | sailus: so we need some configuration for smiapp driver to work? |
| 13:10.08 | sailus | It has a default configuration which is functional. |
| 13:10.19 | sailus | Not necessarily what you really want, but a working one. |
| 13:10.44 | freemangordon | Pali: once we have that working, we can forward-port resolutions from omap1/KP |
| 13:10.54 | sailus | So you have the corresponding patch to Laurent's. Do you still need the other change? |
| 13:11.36 | freemangordon | sailus: I think I have everything in my tree, it uses clock frameworks, drivers load and init the HW, etc |
| 13:11.56 | freemangordon | now I cloned and compiled yavta, will try it when i am back home |
| 13:12.32 | sailus | Ack. |
| 13:12.35 | freemangordon | sailus: unless you think there is something else needed |
| 13:13.41 | freemangordon | sailus: please look at the last 10 or so commits here https://gitorious.org/linux-n900/freemangordons-linux-n900/commits/4e272703339f84e65c063c8969e5a69652c0dbda |
| 13:13.51 | freemangordon | done by "Ivaylo Dimitrov" |
| 13:14.05 | freemangordon | all those are camera/isp fixes |
| 13:18.52 | *** join/#maemo-ssu RST38h (marat@wsip-184-180-40-182.ri.ri.cox.net) |
| 13:24.35 | *** join/#maemo-ssu oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 13:27.57 | *** join/#maemo-ssu arcean (~arcean@aadb186.neoplus.adsl.tpnet.pl) |
| 13:29.32 | sailus | freemangordon: Thanks! |
| 13:32.53 | freemangordon | sailus: hmm? what for? |
| 13:35.15 | 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 |
| 13:35.28 | freemangordon | not an array |
| 13:35.55 | freemangordon | I'll make a patch for that when i have the cameras working :) |
| 13:42.56 | *** join/#maemo-ssu arcean_ (~arcean@aaem72.neoplus.adsl.tpnet.pl) |
| 13:55.17 | *** join/#maemo-ssu Martix_ (~martix@eduroam-224.fi.muni.cz) |
| 13:59.25 | Pali | freemangordon: I moved et8ek8 firmware into kernel driver |
| 13:59.45 | Pali | so driver does not need external "firmware" from userspace |
| 14:00.30 | freemangordon | Pali: great :) |
| 14:00.43 | freemangordon | Pali: does it work? :P |
| 14:00.58 | Pali | only tested compilation |
| 14:01.00 | Pali | but it must work |
| 14:01.06 | *** join/#maemo-ssu Martix_ (~martix@eduroam-224.fi.muni.cz) |
| 14:01.17 | Pali | I just replaced pointer from firmware to included structure |
| 14:01.40 | freemangordon | sure, I was kidding |
| 14:01.58 | freemangordon | is on his way home, bbl |
| 14:03.38 | *** join/#maemo-ssu iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 14:07.13 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 14:51.41 | freemangordon | sailus: any recommended cmd line parameters to use for yavta? |
| 15:05.34 | freemangordon | sailus: yavta hangs in ioctl(3, VIDIOC_DQBUF... |
| 15:08.08 | *** join/#maemo-ssu Martix_ (~martix@eduroam-224.fi.muni.cz) |
| 15:18.37 | *** join/#maemo-ssu NIN101 (~NIN@p5DD288CD.dip0.t-ipconnect.de) |
| 15:46.38 | sailus | freemangordon: That likely mean you don't get any buffers back from the driver. |
| 15:46.43 | sailus | Do you get interrupts? |
| 15:47.07 | freemangordon | any idea which gpoi/irq to check? |
| 15:47.13 | freemangordon | *gpio |
| 15:47.22 | freemangordon | sailus: BTW: |
| 15:47.23 | sailus | /proc/interrupts |
| 15:47.29 | freemangordon | :) |
| 15:47.38 | freemangordon | I know that, but which particular gpio |
| 15:47.40 | sailus | omap3isp, I guess. |
| 15:47.50 | freemangordon | btw: |
| 15:47.54 | freemangordon | cam_xclka 1 1 5760000 |
| 15:48.05 | freemangordon | is that normal? the frequency I mean |
| 15:48.22 | sailus | That looks very low to me. |
| 15:48.29 | sailus | What does it have in the platform data? |
| 15:48.56 | freemangordon | 40: 0 INTC OMAP3 ISP |
| 15:49.58 | sailus | No interrupts then. |
| 15:50.02 | sailus | Something definitely is wrong. |
| 15:50.24 | freemangordon | .ext_clk= 9.6 * 1000 * 1000, |
| 15:50.37 | freemangordon | .op_sys_clock= (s64 []){ 12000000 * 10 / 2, 0 }, |
| 15:50.39 | sailus | On both? |
| 15:50.47 | freemangordon | this is for smiapp |
| 15:50.49 | sailus | ext_clk is the one you should be concerned about. |
| 15:51.07 | sailus | Are you using the smia one? |
| 15:51.13 | sailus | Ok. |
| 15:51.36 | freemangordon | smia has it hardcoded in the driver iirc |
| 15:51.49 | sailus | It doesn't. |
| 15:52.00 | sailus | It comes from the platform data. |
| 15:52.11 | freemangordon | #define ET8EK8_XCLK_HZ9600000 |
| 15:52.36 | freemangordon | unsigned int hz = ET8EK8_XCLK_HZ; |
| 15:52.53 | freemangordon | rval = clk_set_rate(sensor->ext_clk, hz); |
| 15:53.15 | freemangordon | sailus: ^^^ |
| 15:54.09 | sailus | et8ek8 isn't smia compatible. |
| 15:54.42 | freemangordon | well, it is in i2c/smia dir :) |
| 15:54.50 | freemangordon | anyway |
| 15:55.11 | sailus | The problem could be related to discrepancies in how the divisor is chosen. |
| 15:55.19 | Pali | I can move it from i2c/smia to i2c/ |
| 15:55.20 | sailus | The information on the parent clock frequency could be wrong. |
| 15:55.51 | freemangordon | sailus: I saw similar bug on clock framework for SSI clocks |
| 15:55.52 | sailus | That frequency must be exactly 9,6 MHz. |
| 15:55.57 | freemangordon | :nod: |
| 15:55.59 | sailus | :-P |
| 15:56.18 | freemangordon | is going to check how it is on Nokia kernel |
| 15:56.31 | sailus | The frequency is the same. |
| 15:56.34 | sailus | That has not changed. |
| 15:56.51 | freemangordon | I meant in /sys/kernel/debug/clk |
| 15:56.57 | sailus | What has changed.... well, is the clock framework. |
| 15:57.07 | sailus | Ack. |
| 15:57.11 | freemangordon | what is reported there and what is the clock tree |
| 15:57.22 | sailus | Excellent |
| 16:00.40 | 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 |
| 16:00.40 | freemangordon | 172800000 |
| 16:00.50 | freemangordon | this is on 2.6.28 |
| 16:01.01 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 16:01.18 | freemangordon | on 3.10: |
| 16:01.20 | 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 |
| 16:01.20 | freemangordon | 172800000 |
| 16:01.27 | freemangordon | shit |
| 16:01.34 | freemangordon | cam_mclk 0 0 172800000 |
| 16:02.13 | freemangordon | but I don;t have xclka child of cam_mclk on 2.6.28 |
| 16:03.39 | freemangordon | hmm, maybe I should revert my divider patch |
| 16:08.39 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 16:10.32 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 16:16.32 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 16:18.21 | *** part/#maemo-ssu dion_ (~dion_@dion.org.ua) |
| 16:19.16 | freemangordon | sailus: hmm, with that patch reverted I see "unexpected cam_mclk rate:.." from isp driver |
| 16:19.56 | Pali | freemangordon: is there any other problem except green output? |
| 16:20.19 | freemangordon | yep, yavta hangs while trying to get video buffer |
| 16:20.30 | freemangordon | and there are no interrupts from ISP |
| 16:20.40 | Pali | because maybe there is one commit which you can try to revert |
| 16:20.55 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@112.96.127.24) |
| 16:20.58 | Pali | 450460412ce758f79d02e9f5db720aa09bd8e6ad |
| 16:20.58 | freemangordon | which one? |
| 16:21.43 | Pali | I do not know if this commit it in upstream or not, but sailus send me it months ago via email |
| 16:21.57 | freemangordon | "smiapp-pll: Take existing divisor into account in minimum divisor check"? |
| 16:22.12 | Pali | yes, can you check if this commit is in upstream? |
| 16:22.32 | Pali | sailus, can you comment above your patch? ^^^ |
| 16:22.56 | Pali | and there is another commit which changing some color matrix: 3532af7ad45e54e000dfa7f2b7536e7a58ecc61d |
| 16:23.10 | Pali | "isppreview: new default coeffs for more ambient independent quality" |
| 16:23.43 | Pali | freemangordon look (and maybe try to revert it) ^^^^ |
| 16:30.51 | freemangordon | Pali: ok |
| 16:47.47 | freemangordon | Pali: reverting 450460412ce758f79d02e9f5db720aa09bd8e6ad made it worse :) |
| 16:48.25 | Pali | ok, so that patch is really needed :-) |
| 16:48.30 | freemangordon | yep |
| 16:48.37 | Pali | without it driver loading failed, right? |
| 16:48.43 | freemangordon | yep |
| 16:49.00 | freemangordon | can't find pll div/mul |
| 16:49.36 | Pali | sailus should comment if that patch is correct ^^^ |
| 16:50.28 | freemangordon | I can try to hack it and feed pll calculations with doupled frequency :) |
| 16:51.32 | Pali | freemangordon: look also at second commit |
| 16:52.23 | freemangordon | Pali: frequency is incorrect, it should be 9.6Mhz not half of that |
| 16:54.18 | sailus | cam_mclk isn't in the clock framework in 2.6.28 --- the clock is produced by the ISP itself, not PRCM. |
| 16:55.27 | 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/... |
| 16:55.45 | sailus | That's a good sign then. |
| 16:55.51 | sailus | Is the divisor also the same? |
| 16:56.15 | sailus | Based on what we discussed a few hours ago the xclk frequency seemed wrong. |
| 16:56.43 | freemangordon | how to check the divisor on 2.6.28, any idea? |
| 16:56.51 | freemangordon | this is my daily device :) |
| 16:57.01 | freemangordon | (the one with 2.6.28) |
| 16:57.09 | sailus | :-) |
| 16:57.25 | sailus | I'm not sure if the driver prints it. |
| 16:57.49 | freemangordon | wait, can't we just divide mclk freq with 9600000 to get the correct diviso? |
| 16:57.51 | sailus | You might need to use printk() to print it instead. |
| 16:57.56 | sailus | But... you can calculate it as well. |
| 16:58.01 | freemangordon | :nod: |
| 16:58.11 | sailus | :-) |
| 17:00.30 | sailus | This assumes the frequency really is what the clock framework suggests. |
| 17:00.57 | sailus | Now that the parent clock handling bug has been supposedly fixed, I guess that's ok. |
| 17:02.10 | freemangordon | hmm, could it be that clock framework reports bogus values for xclk? |
| 17:02.48 | freemangordon | because it is tweaked for 3630, not 3430 |
| 17:03.34 | 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. |
| 17:03.37 | sailus | And only 3430 really worked. |
| 17:04.01 | freemangordon | well: |
| 17:04.03 | freemangordon | cam_mclk 0 0 172800000 |
| 17:04.08 | freemangordon | this looks fine to me |
| 17:04.15 | freemangordon | the same on 2.6.28 |
| 17:04.22 | freemangordon | cam_xclkb 0 0 5760000 |
| 17:04.34 | freemangordon | is deffinitely wrong, lets check the divisor |
| 17:05.24 | sailus | Just by quick check, you should have 18. |
| 17:05.39 | sailus | And... why's cam_xclkb? |
| 17:05.44 | sailus | Both cameras use xclka. |
| 17:06.03 | freemangordon | :nod: |
| 17:06.21 | freemangordon | sailus: copy/paster error |
| 17:06.23 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 17:06.26 | freemangordon | but xclka is the same |
| 17:06.56 | sailus | The divisor would be 30 in that case. |
| 17:07.02 | sailus | That's a strange number. |
| 17:07.59 | freemangordon | sailus: http://pastebin.com/UgdYDUQn |
| 17:09.10 | freemangordon | NFC at which value to look at :) |
| 17:09.38 | DocScrutinizer05 | hah, clock divisors. real fun |
| 17:10.06 | DocScrutinizer05 | no surprise when new kernel msses it up |
| 17:11.49 | freemangordon | sailus: "mul 25 / div 2"? |
| 17:12.10 | sailus | Ah --- now I think I remember. |
| 17:12.39 | sailus | The case was that the original configuration from the "firmware" used slightly off-spec frequencies. |
| 17:12.56 | sailus | And that might not be taken into account in the current quirks in smiapp driver. |
| 17:13.21 | sailus | It isn't. |
| 17:13.25 | freemangordon | there are no quirks for vs6555 |
| 17:13.51 | freemangordon | :) |
| 17:13.54 | sailus | That's the probable reason for the PLL calculator failure. |
| 17:14.02 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 17:14.22 | freemangordon | but it doesn't fail, just calculates wrong values IMO :) |
| 17:14.37 | freemangordon | sailus: can I just hardcode the correct values? |
| 17:14.52 | freemangordon | to prove/not if this is the real problem |
| 17:15.28 | sailus | Indeed --- if it doesn't fail, then that message can be ignored. |
| 17:15.32 | sailus | Perhaps it was another mode. |
| 17:16.00 | *** join/#maemo-ssu dos11 (~dos@unaffiliated/dos1) |
| 17:16.01 | sailus | You're right --- if there was a failure, you'd see this: |
| 17:16.02 | sailus | <PROTECTED> |
| 17:16.38 | freemangordon | which I get if I revert your "smiapp-pll: Take existing divisor into account in minimum divisor check" patch |
| 17:17.23 | freemangordon | sailus: btw, which value in the log I should look at? for divisor that is |
| 17:18.37 | sailus | That's the sensor clock tree calculation. |
| 17:18.45 | sailus | If it succeeds you should be fine. |
| 17:19.01 | sailus | What matters whether the ISP produces the clock it should to the sensor. |
| 17:19.12 | sailus | The cam_xclka frequency suggests it does not. |
| 17:19.18 | freemangordon | :nod: |
| 17:19.44 | sailus | But why, is unknown to me. |
| 17:19.46 | freemangordon | sailus: which is the value from all those I have to look at? |
| 17:19.51 | sailus | It should "just work". :-P |
| 17:19.56 | freemangordon | heh |
| 17:19.57 | freemangordon | :) |
| 17:20.01 | sailus | None. |
| 17:20.16 | sailus | ext_clk is just input to the PLL calculator. |
| 17:20.19 | sailus | Nothing comes out. |
| 17:20.27 | sailus | I'd figure out why the divisor is 30 and not 18. |
| 17:20.39 | freemangordon | where you saw that 30? |
| 17:20.48 | sailus | 172800000/5760000 |
| 17:20.50 | freemangordon | where did you see even :) |
| 17:21.04 | freemangordon | well, is it in dmesg log? |
| 17:21.31 | sailus | I'm quoting you from 20:04. :-) |
| 17:21.39 | sailus | 17 minutes ago. |
| 17:22.28 | sailus | I need to go; I might be back later today. |
| 17:22.29 | freemangordon | sure, but do we have that value logged from the pll calculator? or it is the clock framework that calculates it? |
| 17:22.38 | freemangordon | sailus: ok |
| 17:22.40 | sailus | Sorry. |
| 17:22.57 | sailus | That's internal ISP divisor. |
| 17:23.04 | sailus | The sensor driver has no part in that. |
| 17:23.11 | freemangordon | ok |
| 17:23.33 | sailus | xclk = cam_mclk / divisor AFAIR. |
| 17:23.42 | freemangordon | :nod: |
| 17:23.53 | freemangordon | going to check in the clock framework |
| 17:23.54 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-124-88.net.upcbroadband.cz) |
| 17:25.03 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 17:26.15 | *** join/#maemo-ssu WielkiTost (~dos@unaffiliated/dos1) |
| 17:26.26 | sailus | You should check what the ISP driver does and what frequencies it sees. It calculates the divisor. |
| 17:26.42 | freemangordon | ok, will do |
| 17:26.47 | freemangordon | thanks! |
| 17:40.57 | freemangordon | sailus: I hardcoded 18 in isp_xclk_calc_divider, still the same. And still no ISP interrupts |
| 17:41.30 | freemangordon | but at least: cam_xclkb 0 0 9600000 |
| 17:41.42 | freemangordon | and cam_xclka 0 0 9600000 |
| 17:42.46 | *** part/#maemo-ssu dagb (~dagb@80.203.63.59) |
| 17:57.08 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 18:13.01 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@88.120.139.80) |
| 19:18.13 | *** join/#maemo-ssu iDont (~iDont@ip4da305b4.direct-adsl.nl) |
| 19:37.44 | sailus | It'd be good to know the reason *why* the divisor isn't 18. |
| 19:45.06 | DocScrutinizer05 | HAH! http://projects.goldelico.com/p/openphoenux/page/PaidDeveloper/ |
| 19:45.38 | DocScrutinizer05 | Didn't even know of that :-) |
| 20:02.15 | freemangordon | sailus: I bet it is the clock frameworks that screws it |
| 20:03.11 | freemangordon | As iiuc dpll4_m5x2 on 3630 runs on a different frequency compared to 3430 |
| 20:03.38 | freemangordon | but there is no difference in cclock3xxx_data.c |
| 20:08.25 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 20:10.29 | DocScrutinizer05 | dnag. Is that a result of sw dudes writing code to rerpesent hw? ;-) |
| 20:11.42 | DocScrutinizer05 | when you write such definitions, you have to start at the very atoms of a hw design, like crystal frequencies etc |
| 20:13.36 | DocScrutinizer05 | but that knowledge is rarely found in CS-students' heads, while every EE is aware of that |
| 20:14.49 | DocScrutinizer05 | given the EE also develops sw |
| 20:15.39 | 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 |
| 20:26.39 | DocScrutinizer05 | I guess there's no such thing like "crystal frequency" in DT, eh? ;-) |
| 20:30.21 | 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 |
| 20:31.13 | DocScrutinizer05 | and the rules are not as simple as "for multiplier >50, no dividers <10 allowed" |
| 20:32.48 | 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 |
| 20:34.08 | DocScrutinizer05 | to make stuff less boring, the different clocks in system are often entangled to each other in complex ways |
| 20:35.54 | DocScrutinizer05 | like "RAMbus clock *2^N == CPUclock * 2^M" with N,M := int |
| 20:38.13 | DocScrutinizer05 | err |
| 20:38.38 | DocScrutinizer05 | like "RAMbus/4 clock *2^N == CPUclock/3 * 2^M" with N,M := int |
| 20:42.17 | 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 |
| 20:43.25 | 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 |
| 20:46.30 | DocScrutinizer05 | wow, TV is really giving insights: 70% of US-americans believe in a physically existing hell |
| 20:47.08 | FatPhil_ | "US-americans"? |
| 20:47.24 | DocScrutinizer05 | I guess at least 50% believe that earth is 5578 years old, and man been made by God, 70 generations ago |
| 20:48.15 | FatPhil_ | yup, those are the US americans |
| 20:49.44 | DocScrutinizer05 | if only those 70% would see the truth, which is: they are _living_ in their hell, every day. they made it themselves |
| 20:53.50 | Pali | freemangordon: I pushed et8ek8 changes to v3.10-n900 branch on gitorious |
| 20:54.14 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 20:57.17 | freemangordon | Pali: good |
| 20:57.41 | Pali | I removed code which can oops kernel :-) |
| 20:57.51 | freemangordon | hmm |
| 20:57.55 | freemangordon | is going to check |
| 20:58.06 | Pali | et8ek8 could oops kernel if you get it working :-) |
| 20:58.13 | Pali | NULL derefernce |
| 20:58.27 | Pali | configure_interface |
| 20:58.45 | Pali | it was removed from isp driver long time ago |
| 20:59.32 | Pali | I removed also platform_data->set_xclk because it is not used |
| 21:02.00 | freemangordon | fine |
| 21:03.05 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 21:03.14 | freemangordon | Pali: now we only need to make it work :D |
| 21:03.26 | Pali | yes :-) |
| 21:03.49 | freemangordon | DocScrutinizer05: iiuc the idea behind DT is that you don;t need to describe clock frequencies in DT |
| 21:04.13 | freemangordon | you only tell the kernel which clock is your driver using |
| 21:04.31 | freemangordon | which is not that bad idea imo |
| 21:05.02 | freemangordon | and there *are* mul/div tables in the clock framework |
| 21:06.27 | freemangordon | Pali: hmm, how familiar are you with the clock framework? |
| 21:06.41 | freemangordon | I wonder how to deal with that wrong frequency: |
| 21:07.02 | freemangordon | 1. reparent cam_mclk on 3430 |
| 21:07.17 | freemangordon | 2. add a divider by 2 |
| 21:07.50 | Pali | freemangordon: I do not know clock framework very good... |
| 21:08.08 | freemangordon | both will work, but I really don;t know if there are real dividers, clocks etc behind those names or some of them are real and some virtual |
| 21:08.38 | freemangordon | Pali: me either, I am trying to figure out what lays bahind it |
| 21:08.42 | freemangordon | *neither |
| 23:07.48 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
| 23:35.52 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 23:36.42 | jonwil | hi |
| 23:38.20 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |