[13:24] <mchehab> |MA|: yt?
[13:25] <|MA|> Mauro , Hi
[13:25] <mchehab> hi
[13:25] <mchehab> 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] <mchehab> yes
[13:26] <mchehab> the only remaining trouble is that
[13:26] <mchehab> wait_event_interruptible_timeout
[13:26] <mchehab> is not timing out...
[13:26] <|MA|> i will check on that
[13:26] <mchehab> maybe due some scanning to an inexistent addr
[13:27] <mchehab> (since this is a dual processor machine, I'm up)
[13:27] <mchehab> anyway, both cpus are with low usage
[13:28] <mchehab> 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] <mchehab> 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] <mchehab> 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] <mchehab> 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] <mchehab> i mean waitqueue
[13:32] <mchehab> 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] <mchehab> int time=jiffies;
[13:34] <mchehab> schedule()
[13:34] <|MA|> that 's what i am doing
[13:34] <mchehab> then check for irq
[13:34] <mchehab> then check if time>timeout
[13:34] <mchehab> 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] <mchehab> 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] <mchehab> hmm.. what if we use msleep_interruptible() instead of work queue?
[13:37] <|MA|> that will not work ..
[13:37] <mchehab> why not?
[13:37] <|MA|> since sleep is only one way
[13:37] <mchehab> it will wake up at any int
[13:37] <|MA|> so it will miss all the interrupts
[13:37] <mchehab> 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] <mchehab> i'm meaning something like
[13:42] <|MA|> rather than the timing created by the handler or the driver code
[13:42] <mchehab> int timeout=jiffies+mstojiffies(100);
[13:42] <mchehab> while (jiffies<timeout) {
[13:42] <mchehab> msleep_interruptible (timeout-jiffies);
[13:42] <mchehab> if (core->i2c_int_status & (MO_INT_I2CDONE|MO_INT_I2CRACK) )
[13:42] <mchehab> break;
[13:42] <mchehab> }
[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] <mchehab> we are not polling
[13:42] <|MA|> 2 methodologies
[13:43] <mchehab> the issue is that work queue is not working
[13:43] <|MA|> 1) polling 2) interrupt driven
[13:43] <mchehab> it is not polling.
[13:43] <|MA|> It is
[13:43] <mchehab> it is interrupt driven, since it will wake up at irq
[13:43] <mchehab> 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] <mchehab> 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] <mchehab> ok, but this will not fail.
[13:44] <mchehab> 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] <mchehab> manu, if we got no int after 100ms, it should timeout
[13:45] <mchehab> but it isn't
[13:45] <|MA|> It does
[13:45] <|MA|> maybe something went wrong at your side
[13:45] <mchehab> so, even if IRQ code is wrong, it is not timing out
[13:45] <|MA|> i will check that
[13:45] <mchehab> I added a print to check for timeout
[13:46] <mchehab> 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] <mchehab> the timing won't be affected
[13:49] <|MA|> which is also the very same issue
[13:49] <mchehab> 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] <mchehab> it is not constantly checking a register
[13:50] <|MA|> [13:42] <mchehab> while (jiffies<timeout) {
[13:50] <|MA|> [13:42] <mchehab> msleep_interruptible (timeout-jiffies);
[13:50] <|MA|> [13:42] <mchehab> if (core->i2c_int_status & (MO_INT_I2CDONE|MO_INT_I2CRACK) )
[13:50] <|MA|> [13:42] <mchehab> break;
[13:50] <|MA|> [13:42] <mchehab> }
[13:50] <mchehab> it is doing it only on a IRQ
[13:50] <|MA|> Huh ?
[13:50] <mchehab> msleep_interruptible
[13:50] <mchehab> it will wait an IRQ
[13:50] <|MA|> why are you doing a while on a IRQ, completely wrong
[13:50] <mchehab> 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] <mchehab> anyway, after working, we can finetune
[13:51] <mchehab> let me boot my machine
[13:51] <mchehab> 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] <mchehab> the problem seems to be on another place
[13:56] <mchehab> even with the 'crude' version, it is stopping
[13:56] <mchehab> I should add some printk at master xfer
[13:56] <mchehab> maybe is really a bug on cx88 dma
[13:57] <mchehab> (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] <mchehab> manu, why do you have this:
[14:00] <mchehab> msleep_interruptible
[14:00] <mchehab> 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] <mchehab> before ackwait?
[14:01] <mchehab> 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] <mchehab> 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] <mchehab> 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] <mchehab> 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] <mchehab> i'm understanding
[14:05] <mchehab> you are waiting for IRQ or 1 ms after sending something to I2C
[14:05] <mchehab> then, you call your work queue
[14:05] <mchehab> and wait for another IRQ or 100 ms
[14:05] <mchehab> the second irq should be the specific cx88 irq
[14:06] <mchehab> so, you are timing out on 100ms
[14:06] <mchehab> 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] <mchehab> 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] <mchehab> I'm almost without time to work on this for now