[13:24] |MA|: yt? [13:25] <|MA|> Mauro , Hi [13:25] hi [13:25] patch almost finished [13:25] <|MA|> just came in [13:25] <|MA|> cool, i will need to make the changes for the rate and others for the demods [13:25] yes [13:26] the only remaining trouble is that [13:26] wait_event_interruptible_timeout [13:26] is not timing out... [13:26] <|MA|> i will check on that [13:26] maybe due some scanning to an inexistent addr [13:27] (since this is a dual processor machine, I'm up) [13:27] anyway, both cpus are with low usage [13:28] I'll email the current patch [13:28] <|MA|> with bit banging you have a higher usage .. ? [13:28] <|MA|> cool [13:29] <|MA|> another problem that i came up with taht demod is that , it sleeps in kernel [13:29] <|MA|> ie, the sleep is not dependant upon the user application [13:30] sent [13:30] <|MA|> so once you set a parameter, it will follow it's own ideas .. which might be a slight problem [13:30] probably not. the point is: waiting states might increase one cpu usage [13:30] <|MA|> since the demod will be still doing something even after the scanning application has stopped [13:31] <|MA|> usually polling takes a higher CPU [13:31] <|MA|> a waitqueue, what it does id that, it becomes kind of dormant there, till the ISR wakes it up [13:32] i think you may replace sleep to schedule() [13:32] <|MA|> s/id/is [13:32] <|MA|> i don't have any sleep [13:32] i mean waitqueue [13:32] you may do something like: [13:33] <|MA|> what Johannes suggested me for the 878 was what i did for the mantis [13:33] <|MA|> which is the same that i did for the cx88 [13:33] int time=jiffies; [13:34] schedule() [13:34] <|MA|> that 's what i am doing [13:34] then check for irq [13:34] then check if time>timeout [13:34] instead of creating a work queue. [13:34] <|MA|> that what you are saying will cause to poll [13:35] <|MA|> what i am doing is to avoid a poll [13:35] this will give control back to app. isn~t it you said you needed? [13:35] <|MA|> It should be ISR --> wakeup routine [13:35] <|MA|> it should never poll [13:36] <|MA|> and once awake, it will continue with the rest [13:36] <|MA|> whether Read or Write [13:36] <|MA|> It will give control back, yes [13:36] hmm.. what if we use msleep_interruptible() instead of work queue? [13:37] <|MA|> that will not work .. [13:37] why not? [13:37] <|MA|> since sleep is only one way [13:37] it will wake up at any int [13:37] <|MA|> so it will miss all the interrupts [13:37] we just need to check if it is the right one [13:38] <|MA|> ? [13:38] <|MA|> both events won't happen in the same time frame [13:38] <|MA|> so you can't use sleep [13:39] <|MA|> the biggest, problem is that if you use a sleep, then you need to use a while loop and a break, in case of a timeout [13:39] <|MA|> which is polling again [13:40] <|MA|> and moreover it is ugly [13:40] <|MA|> and a higher CPU usage because of the while() [13:41] <|MA|> in the current scenario what i proposed, it is completely Interrupt driven .. [13:41] <|MA|> and times out in case of no interrupt [13:41] <|MA|> so the CPu usage is _very_ minimal [13:41] <|MA|> and more over the timing would be the native bus timing [13:42] i'm meaning something like [13:42] <|MA|> rather than the timing created by the handler or the driver code [13:42] int timeout=jiffies+mstojiffies(100); [13:42] while (jiffies msleep_interruptible (timeout-jiffies); [13:42] if (core->i2c_int_status & (MO_INT_I2CDONE|MO_INT_I2CRACK) ) [13:42] break; [13:42] } [13:42] <|MA|> ah, there you have the while loop [13:42] <|MA|> that is what i meant [13:42] <|MA|> you should never poll for an interrupt [13:42] <|MA|> that is the basic advantage of having interrupts [13:42] we are not polling [13:42] <|MA|> 2 methodologies [13:43] the issue is that work queue is not working [13:43] <|MA|> 1) polling 2) interrupt driven [13:43] it is not polling. [13:43] <|MA|> It is [13:43] it is interrupt driven, since it will wake up at irq [13:43] we just need to check if it is the right one [13:43] <|MA|> because you *are* constantly checking for the value in a register .. [13:44] <|MA|> that is what poll() does internally [13:44] no. it will check only on some IRQ [13:44] <|MA|> you have created a crude version of poll [13:44] <|MA|> where are you handling the IRQ ? [13:44] ok, but this will not fail. [13:44] work queue is failing [13:44] <|MA|> IMO, that code is wrong for Interrupt driven handling [13:45] <|MA|> it us what you call, poll a register .. [13:45] <|MA|> is [13:45] manu, if we got no int after 100ms, it should timeout [13:45] but it isn't [13:45] <|MA|> It does [13:45] <|MA|> maybe something went wrong at your side [13:45] so, even if IRQ code is wrong, it is not timing out [13:45] <|MA|> i will check that [13:45] I added a print to check for timeout [13:46] no timeout is happening [13:46] <|MA|> i will check that [13:46] <|MA|> it worked for me .. [13:46] <|MA|> i will check why it did not work for you [13:47] <|MA|> the problem in polling is that, it will again additionall change the timings which is again back to square one [13:47] <|MA|> i mean constantly checking a register .. [13:47] <|MA|> to make you happy ..:) [13:48] <|MA|> i need the timings to be very much perfect for that device [13:48] <|MA|> that's why it worked on the Mantis and not on the cx88 [13:49] <|MA|> I saw another post from Steve Toth as well [13:49] the timing won't be affected [13:49] <|MA|> which is also the very same issue [13:49] let me check my code [13:49] <|MA|> It will [13:49] <|MA|> if you constantly check a register manually, timing will be affected [13:50] it is not constantly checking a register [13:50] <|MA|> [13:42] while (jiffies [13:42] msleep_interruptible (timeout-jiffies); [13:50] <|MA|> [13:42] if (core->i2c_int_status & (MO_INT_I2CDONE|MO_INT_I2CRACK) ) [13:50] <|MA|> [13:42] break; [13:50] <|MA|> [13:42] } [13:50] it is doing it only on a IRQ [13:50] <|MA|> Huh ? [13:50] msleep_interruptible [13:50] it will wait an IRQ [13:50] <|MA|> why are you doing a while on a IRQ, completely wrong [13:50] no it isn~t [13:50] <|MA|> IRQ means Interrupt Request [13:51] <|MA|> you don't do any while loops when you implement Interrupt Driven methods [13:51] anyway, after working, we can finetune [13:51] let me boot my machine [13:51] bbl [13:51] <|MA|> if you do, that means you are wrong [13:51] <-- mchehab has left this server. (Remote closed the connection) [13:54] --> {ma} has joined this channel. (n=root@auh-b114936.alshamil.net.ae) [13:55] --> mchehab has joined this channel. (n=mchehab@201.73.174.210) [13:56] the problem seems to be on another place [13:56] even with the 'crude' version, it is stopping [13:56] I should add some printk at master xfer [13:56] maybe is really a bug on cx88 dma [13:57] (the first probed i2c addr is not present at this board) [13:57] <{ma}> you can't do a probe with HW I2C [13:58] <{ma}> AFAIK [14:00] manu, why do you have this: [14:00] msleep_interruptible [14:00] after each cx_write.... [14:00] <{ma}> ok, so this was the change that needed to add to the cx88 infrastructure .. ? [14:00] <{ma}> + core->i2c_adap.algo_data = &core->i2c_algo; [14:00] before ackwait? [14:01] manu, no. there are also other fixes at your code [14:01] <{ma}> It has to, that's how the hardware works, it needs a small delay [14:01] yes, but you are checking for delays at ack_wait [14:01] <{ma}> i am interested in knowing what it is [14:01] <{ma}> no, i am not checking for delays [14:02] <{ma}> that 's timeout event [14:02] i mean you are waiting for i2c to happen at ack_wait [14:02] <{ma}> my code is very simple and it is very effecient ... works very nicely with the 878 and with the manytis [14:02] <{ma}> mantis [14:02] if it fails before 1ms, you won't catch [14:02] <{ma}> no [14:03] <{ma}> i think, you don't understand how it works [14:03] <{ma}> i mean you are not understanding what it is doing [14:04] i'm understanding [14:05] you are waiting for IRQ or 1 ms after sending something to I2C [14:05] then, you call your work queue [14:05] and wait for another IRQ or 100 ms [14:05] the second irq should be the specific cx88 irq [14:06] so, you are timing out on 100ms [14:06] on faster i2c buses [14:06] <{ma}> take a look here .. http://pastebin.ca/131099 .. It has more or less the perfect timings [14:06] anyway, i need to reboot [14:06] <{ma}> the code what i have for the cx88 is derived from this [14:06] --> finalbeta has joined this channel. (n=finalbet@d5152A68A.access.telenet.be) [14:06] I'm almost without time to work on this for now