parazyd has quit [Read error: Connection reset by peer]
parazyd has joined #maemo-leste
enyc has quit [Ping timeout: 260 seconds]
enyc has joined #maemo-leste
neimsaci has quit [Quit: WeeChat 4.0.1]
pere has quit [Ping timeout: 248 seconds]
Daanct12 has joined #maemo-leste
SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
ashley has quit [Server closed connection]
ashley has joined #maemo-leste
ashley is now known as Guest2870
Juest has joined #maemo-leste
mp107 has quit [Ping timeout: 246 seconds]
<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 :)
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
pere has joined #maemo-leste
macros_ has quit [Ping timeout: 244 seconds]
macros_ has joined #maemo-leste
fab_ has joined #maemo-leste
mp107 has joined #maemo-leste
Guest2870 is now known as Elektra
Elektra has quit [Changing host]
Elektra has joined #maemo-leste
Elektra is now known as ashley
uvos__ has joined #maemo-leste
<freemangordon>
tmlind: right
<freemangordon>
the visible difference is that ir-rx51 is using hrtimer, while pwm-ir-tx does usleep_range(delta, delta + 10); :)
<freemangordon>
no way this can do precisely timed emission
<freemangordon>
hmm, usleep_range is backed by hrtimer
ceene has joined #maemo-leste
<freemangordon>
but! IIUC every call to usleep_range might set new hrtimer, and that takes a lot
<freemangordon>
so, to me issue is the new driver sets hrtimer for every pulse
fab_ has quit [Ping timeout: 246 seconds]
<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()"
<tmlind>
probaly the long term solution is to use a periodic dmtimer for the pulse rather than a timer
<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..
Juest has quit [Quit: Client closed]
<sicelo>
oh gosh! N900 is now completely dropped from u-boot mainline
parazyd has quit [Ping timeout: 246 seconds]
<sicelo>
tmlind: yes, i am in full agreement about pwm-ir-tx, if it can be made to work well for us
brabo has quit [Server closed connection]
brabo has joined #maemo-leste
parazyd has joined #maemo-leste
fab_ has joined #maemo-leste
parazyd has quit [Ping timeout: 250 seconds]
<freemangordon>
tmlind: I don't see how would you integrate omap-specific dmtimer into generic driver like pwm-ir-tx
<freemangordon>
tmlind: do you see any issue in using hrtimer in pwm-ir-tx the same way it is done now in ir-rx51?
<tmlind>
freemangordon: how long is the delay? fsleep uses udelay for short ones
parazyd has joined #maemo-leste
<tmlind>
pwm-ir-tx could just do clk_get() if configured in the dts
<freemangordon>
tmlind: hard to say predict, it is the uiserspace that sends a buffer with PWM parameters
<tmlind>
don't see issues using hrtimer in pwm-ir-tx
<freemangordon>
so, we have a carrier of lets say 50kHz
<freemangordon>
lemme do some calculations
<tmlind>
if it's a longer sleep then yeah fsleep won't help
<freemangordon>
so, if I am not mistaken, the period is 20 uS
<freemangordon>
so, the rang is 1<->20 uS for 50kHz carrier
<freemangordon>
*range
<freemangordon>
unless my calculations are wring
<freemangordon>
*wrong
<tmlind>
ok so fsleep could possibly help
<freemangordon>
not really, becaus in > 10uS interval fsleep does usleep_range(usecs, 2 * usecs);
<freemangordon>
udelay() is busy loop, no?
<freemangordon>
also, on ompa hrtimer is implementd by using dmtimer, no?
<freemangordon>
*omap
<freemangordon>
ah, scratch my calculations
<freemangordon>
carrier has nothing to do with time interval
<freemangordon>
you can enable it for as long as you wish, with 1uS resolution
<tmlind>
yeah hrtimer is using a dmtimer on omaps, later ones use arm timer for that
<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
<tmlind>
as dmtimer in periodic pwm mode can toggle a gpio pin automatically with no kernel register tinkering
maxwelld has left #maemo-leste [Error from remote client]
SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
elastic_dog has quit [Ping timeout: 246 seconds]
pere has quit [Ping timeout: 246 seconds]
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
parazyd has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
parazyd has joined #maemo-leste
[TheBug] has joined #maemo-leste
neimsaci has joined #maemo-leste
alex1216 has joined #maemo-leste
pere has joined #maemo-leste
alex1216 has quit [Ping timeout: 245 seconds]
arno11 has joined #maemo-leste
alex1216 has joined #maemo-leste
Blikje has quit [Server closed connection]
Blikje has joined #maemo-leste
SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
maxwelld has left #maemo-leste [#maemo-leste]
SuperMarioSF_ has joined #maemo-leste
SuperMarioSF has quit [Ping timeout: 245 seconds]
SuperMarioSF has joined #maemo-leste
SuperMarioSF_ has quit [Ping timeout: 250 seconds]
<freemangordon>
tmlind: we already toggle that gpio pin using dmtimer (pwm is dmtimer backed)
<freemangordon>
but, we need another timer to measure the pule width, thus, hrtimer
maxwelld has joined #maemo-leste
<tmlind>
freemangordon: you can also capture the time, there was some patch posted for dmtimer for that
<tmlind>
not currently supported, i think it was posted by ladislav a few years ago
<freemangordon>
with higher precision than dmtimer?
<freemangordon>
*then hrtimer
<freemangordon>
argh
<freemangordon>
than hrtimer :)
<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
neimsaci has quit [Quit: WeeChat 4.0.1]
<freemangordon>
I don't think it matters, as we should precisely get the event to be able to switch pwm on or off accurately
arno11 has left #maemo-leste [#maemo-leste]
Daanct12 has quit [Quit: WeeChat 4.0.4]
<tmlind>
ok
ahmed_sam has joined #maemo-leste
arno11 has joined #maemo-leste
<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)
<arno11>
locking freq at 850 and disabling hildon compo make pierogi working like a charm
<arno11>
now i'm able to control a device @ 2 meters
ahmed_sam has quit [Read error: Connection reset by peer]
<arno11>
i might try similar test with pwm-ir-tx to see if it works
<arno11>
or not
<bencoh>
if you feel like cpu goes to idle when it shouldn't, then you might want to disable idle for testing purposes
<bencoh>
and you should be able to use cpu_latency_qos_add_request() to prevent it from entering deep idle states during critical tasks