| Wizzup | arno11: did you upload one directory per commit or something? | 00:30 |
|---|---|---|
| arno11 | what do you mean exactly ? | 00:31 |
| Wizzup | All the commits are 'add files via upload' | 00:35 |
| Wizzup | in any case, I can try to add this on top of pierogy later to get a list of changes | 00:36 |
| arno11 | yes that was my idea too :) | 00:36 |
| arno11 | or i can start over with all changes once i'll get my computer back with all data | 00:45 |
| Wizzup | *nod* | 00:46 |
| Wizzup | i'll try to build it tomorrow | 00:46 |
| tmlind | sicelo, arno11: hmm if there are some pwm-ir-tx bugs let's just fix those in the mainline kernel and we'll have a supported generic driver :) | 06:21 |
| freemangordon | tmlind: right | 07:47 |
| freemangordon | the visible difference is that ir-rx51 is using hrtimer, while pwm-ir-tx does usleep_range(delta, delta + 10); :) | 07:48 |
| freemangordon | no way this can do precisely timed emission | 07:48 |
| freemangordon | hmm, usleep_range is backed by hrtimer | 07:50 |
| freemangordon | but! IIUC every call to usleep_range might set new hrtimer, and that takes a lot | 07:56 |
| freemangordon | so, to me issue is the new driver sets hrtimer for every pulse | 08:00 |
| tmlind | freemangordon: seems using fsleep() instead of usleep_range() may fix it.. see mailing list thread "bus: ti-sysc: Use fsleep() instead of usleep_range() in sysc_reset()" | 08:20 |
| tmlind | probaly the long term solution is to use a periodic dmtimer for the pulse rather than a timer | 08:21 |
| tmlind | i posted some rfc dmtimer clock framework patches a while back, with those pwm-ir-tx could just do clk_get() on a dmtimer.. | 08:21 |
| sicelo | oh gosh! N900 is now completely dropped from u-boot mainline | 08:43 |
| sicelo | tmlind: yes, i am in full agreement about pwm-ir-tx, if it can be made to work well for us | 08:54 |
| freemangordon | tmlind: I don't see how would you integrate omap-specific dmtimer into generic driver like pwm-ir-tx | 09:17 |
| freemangordon | tmlind: do you see any issue in using hrtimer in pwm-ir-tx the same way it is done now in ir-rx51? | 09:18 |
| freemangordon | also, I don;t think fsleep will help: https://elixir.bootlin.com/linux/latest/source/include/linux/delay.h#L87 | 09:21 |
| freemangordon | that's even worse :) | 09:21 |
| tmlind | freemangordon: how long is the delay? fsleep uses udelay for short ones | 09:22 |
| tmlind | pwm-ir-tx could just do clk_get() if configured in the dts | 09:23 |
| freemangordon | tmlind: hard to say predict, it is the uiserspace that sends a buffer with PWM parameters | 09:23 |
| tmlind | don't see issues using hrtimer in pwm-ir-tx | 09:23 |
| freemangordon | so, we have a carrier of lets say 50kHz | 09:23 |
| freemangordon | lemme do some calculations | 09:24 |
| tmlind | if it's a longer sleep then yeah fsleep won't help | 09:24 |
| freemangordon | so, if I am not mistaken, the period is 20 uS | 09:25 |
| freemangordon | so, the rang is 1<->20 uS for 50kHz carrier | 09:26 |
| freemangordon | *range | 09:26 |
| freemangordon | unless my calculations are wring | 09:26 |
| freemangordon | *wrong | 09:26 |
| tmlind | ok so fsleep could possibly help | 09:27 |
| freemangordon | not really, becaus in > 10uS interval fsleep does usleep_range(usecs, 2 * usecs); | 09:27 |
| freemangordon | udelay() is busy loop, no? | 09:28 |
| freemangordon | also, on ompa hrtimer is implementd by using dmtimer, no? | 09:28 |
| freemangordon | *omap | 09:28 |
| freemangordon | ah, scratch my calculations | 09:29 |
| freemangordon | carrier has nothing to do with time interval | 09:29 |
| freemangordon | you can enable it for as long as you wish, with 1uS resolution | 09:29 |
| tmlind | yeah hrtimer is using a dmtimer on omaps, later ones use arm timer for that | 09:36 |
| tmlind | however, hrtimer will not be as accurate as using a dmtimer in a periodic mode to trigger pulses, maybe it does not need to be accurate here though | 09:37 |
| tmlind | as dmtimer in periodic pwm mode can toggle a gpio pin automatically with no kernel register tinkering | 09:38 |
| tmlind | fyi if somebody feels like playing with using dmtimers with request_irq() and clk_get(), here's the link to the earlier rfc patches: https://lore.kernel.org/linux-omap/Y1+6bmuup36ZF3H9@atomide.com/ | 09:40 |
| freemangordon | tmlind: we already toggle that gpio pin using dmtimer (pwm is dmtimer backed) | 14:19 |
| freemangordon | but, we need another timer to measure the pule width, thus, hrtimer | 14:20 |
| tmlind | freemangordon: you can also capture the time, there was some patch posted for dmtimer for that | 14:47 |
| tmlind | not currently supported, i think it was posted by ladislav a few years ago | 14:48 |
| freemangordon | with higher precision than dmtimer? | 14:49 |
| freemangordon | *then hrtimer | 14:49 |
| freemangordon | argh | 14:49 |
| freemangordon | than hrtimer :) | 14:49 |
| tmlind | i guess you'll get the event time captured so should be more accurate for the measurement, not sure if it matters in this case though | 14:58 |
| freemangordon | I don't think it matters, as we should precisely get the event to be able to switch pwm on or off accurately | 15:00 |
| tmlind | ok | 15:07 |
| arno11 | freemangordon: tmlind: sicelo: i made other test with ir-rx51's patch and it works really well, comparable to Fremantle :) i think the main issue is high idle cpu load with Leste (and then troubles to get correct timing) | 15:22 |
| arno11 | locking freq at 850 and disabling hildon compo make pierogi working like a charm | 15:23 |
| arno11 | now i'm able to control a device @ 2 meters | 15:24 |
| arno11 | i might try similar test with pwm-ir-tx to see if it works | 15:27 |
| arno11 | or not | 15:28 |
| bencoh | if you feel like cpu goes to idle when it shouldn't, then you might want to disable idle for testing purposes | 15:29 |
| bencoh | and you should be able to use cpu_latency_qos_add_request() to prevent it from entering deep idle states during critical tasks | 15:29 |
| bencoh | https://docs.kernel.org/power/pm_qos_interface.html | 15:30 |
| arno11 | thx but the cpu is not on idle when it shouldn't i think. just to much power usage with no apps running | 15:31 |
| arno11 | n900 is not entering deep idle states at all iirc | 15:32 |
| arno11 | maybe tweaking realtime cpu priorities could help ? | 15:33 |
| bencoh | it still enters some special idle state (instead of the default arm wfi idle), right/ | 15:33 |
| arno11 | ok | 15:33 |
| bencoh | (I mean, I was asking, I dunno) | 15:34 |
| arno11 | ah ok, me too | 15:34 |
| arno11 | amazing: able to control a samsung tv @ 4 meters ! | 15:49 |
| arno11 | freemangordon: thx a million for your help with the patch :) | 15:53 |
| arno11 | sicelo: now it's time for bluetooth/fmrx stuff :D | 16:01 |
| sicelo | that'd be a dream come true ... practically everything working | 16:07 |
| bencoh | \o/ | 16:08 |
| sicelo | of course there's more stuff, e.g. DSP, PM, etc., but yeah with BT and FM RX, things would be looking really good | 16:09 |
| arno11 | yes indeed :D | 16:11 |
| uvos | sicelo: fyi your patch was mangled somewhere by the tabs being replaced by spaces | 22:28 |
| uvos | please avoid this in the future | 22:28 |
| uvos | also really this should be several patches | 22:29 |
| Wizzup | uvos: this is just a patch to test things :) | 22:32 |
| Wizzup | but not harmful (hence devel) | 22:32 |
| sicelo | my mom still has my droid4 hostage ... may anyone share the output of `cat /sys/class/power_supply/battery/uevent` on droid 4 | 23:17 |
| Wizzup | https://bpa.st/OMTCE | 23:24 |
| sicelo | thanks! | 23:29 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!