**** BEGIN LOGGING AT Thu May 22 02:59:58 2014
May 22 06:03:08 <Abhishek_> good morning (UGT)
May 22 06:16:44 <praveendath92> Morning Abhishek_
May 22 12:23:28 <vvu> irc
May 22 12:24:00 * Abhishek__ thinks so
May 22 12:24:40 * vvu screwes up again his typing
May 22 13:06:04 * karki feels driver programming is too diverse. Just too many things hitting you from all sides!
May 22 13:41:06 <Abhishek_> Hi jkridner
May 22 13:41:36 <jkridner> hi
May 22 13:41:44 <jkridner> crazy day today. :(
May 22 13:42:29 <Abhishek_> meetings?
May 22 13:42:45 <jkridner> yes
May 22 13:43:01 <jkridner> and trying to get a board design hacked out.
May 22 13:43:09 * jkridner doesn't usually do much hardware.
May 22 13:43:14 <jkridner> not lately anyway.
May 22 13:43:24 * Abhishek_ is more of a hardware guy
May 22 13:44:08 <Abhishek_> what's it for?
May 22 13:45:01 <jkridner> oddly enough, can't really say. helping out a friend doing something Beagle-related, but not public yet.
May 22 13:45:08 <jkridner> looking forward to sharing it though. :-)
May 22 13:46:20 <Abhishek__> k
May 22 13:46:25 <av500> vvu: N5 has ubs host
May 22 13:46:33 <av500> even supports a sound card
May 22 13:46:42 <av500> but it does not charger from QI while in host mode :(
May 22 13:46:58 <av500> so I need to build an ADK audio dock
May 22 13:47:57 <Abhishek__> av500: Did you consider an external power supply by hacking the OTG cable?
May 22 13:48:12 <av500> Abhishek__: I dont think that will wotj
May 22 13:48:18 <av500> in host mode, the phone supplies power
May 22 13:48:23 <av500> so I cannot charge it
May 22 13:50:22 <Abhishek__> yep, true that. I liked the design of the Nokia 701 that supported USB OTG and had the standard 2.5mm jack as well
May 22 13:51:06 <Abhishek__> So you could connect a standard Nokia charger to the phone and use OTG as you like
May 22 13:52:18 <av500> usb host is a zombie on android anyway
May 22 13:52:26 * Abhishek__ has archived his Nokia 701 (Symbian) for the next generation
May 22 13:52:34 <av500> its not mandated, so you cannot rely on it
May 22 13:52:46 <av500> and on most phones you cannot charge while using it
May 22 13:52:55 <av500> so the use is really limited
May 22 13:52:56 <Abhishek__> indeed.
May 22 13:53:38 <Abhishek__> can the phone be forced to charge by kernel hacking?
May 22 13:54:06 * Abhishek__ thinks the effort might not be worth it anyway
May 22 13:54:36 <av500> I dont want to hack the kernel
May 22 16:46:12 <praveendath92> vvu: Ping
May 22 17:01:10 <Abhishek_> mranostay, panto, ds2: For implementing a ring buffer in the code, do you have any suggestions on signalling the user space code regarding half and full transfers so that it can copy over data continuously?
May 22 17:02:09 <Abhishek_> I'm currently firing PRU0_ARM(19) and PRU1_ARM(20) more than once, but unable to catch them more than once if I fire them 10 times and wait for them corresponding in my userspace UIO-based code.
May 22 17:02:12 <mranostay> interrupts?
May 22 17:02:44 <Abhishek_> yep, see above, but I'm not able to detect them more than once if I fire them 10 times in sequence
May 22 17:03:07 <Abhishek_> PRU0, PRU1, PRU0, PRU1, ... 10 times
May 22 17:03:38 <Abhishek_> PRU0 after the first 6K fills and PRU1 after the remaining 6K fills
May 22 17:04:48 <Abhishek_> I'm able to catch them once, but seems as if userspace isn't fast enough to catch subsequent occurrences...
May 22 17:05:32 <Abhishek_> mranostay: ideas?
May 22 17:15:56 <karki> Abhishek_ : modify the driver (to export a counter to userspace) ;) Thanks for pointing this out. I'll keep this in mind while writing my driver!
May 22 17:16:38 <Abhishek_> counter? for what?
May 22 17:17:06 <Abhishek_> counting how many times the interrupt occurs?
May 22 17:17:36 <karki> yes.
May 22 17:17:44 <karki> if thats what you are looking for
May 22 17:17:58 * karki does not know what Abhishek_ really needs
May 22 17:19:06 <karki> panto : does my remote proc driver have to be a platform driver?
May 22 17:19:08 <Abhishek_> nope, I could also count the number of interrupts I miss by hacking my PRU firmware
May 22 17:19:39 <panto> Abhishek_, you don't rely on interrupts to count buffers
May 22 17:19:48 <panto> it is only a signaling mechanism
May 22 17:20:03 <panto> i.e. more data for you
May 22 17:20:17 <Abhishek_> panto: Could you suggest an alternative?
May 22 17:20:19 <panto> karki, what else?
May 22 17:20:37 <panto> there's no need for an alternative
May 22 17:20:50 <panto> implement a ring buffer with counters
May 22 17:20:59 <panto> fire an interrupt whenever there's a new buffer
May 22 17:21:26 <Abhishek_> I'm actually doing that with the PRU shared RAM, 6144 bytes to send at a time
May 22 17:21:30 <panto> the interrupt handler will use the interrupt to look over the counters and figure out how many buffers are available
May 22 17:21:56 <panto> you can pretty much be assured that Linux will occasionally 'merge' interrupt requests
May 22 17:22:03 <Abhishek_> ah
May 22 17:22:12 <panto> since it might not be able to handle back-to-back signaling
May 22 17:22:22 <panto> but, you will still be at sync
May 22 17:22:29 <karki> panto : Do I need to give it a platform interface even if I explicitly load the driver. ( I didn't really understand the concept of a platform driver..... )
May 22 17:22:48 <panto> platform device = anything that doesn't fit anywhere else on a board
May 22 17:22:59 <Abhishek_> panto: I'm not really getting it. Currently what I'm doing is:
May 22 17:23:17 <Abhishek_> 1. PRU1 samples the GPIO pins and forwards it to PRU0 using XOUT
May 22 17:23:43 <Abhishek_> 2. XOUT reads in 32 bytes (R4-R11) on PRU0 and stores them into PRU shared memory
May 22 17:23:54 <panto> you're missing the ack
May 22 17:24:10 <Abhishek_> yep, there's an interrupt too
May 22 17:24:23 <panto> 3. PRU0 acks the read in some manner (i.e. signals an event to PRU1)
May 22 17:24:25 <Abhishek_> 1. PRU1 samples the GPIO pins and forwards it to PRU0 using XOUT and signals PRU0
May 22 17:24:56 <panto> 4. PRU1 should not forward any more data for PRU0 until such time as the ack is received
May 22 17:25:23 <Abhishek_> 2. PRU0 copied the data with XIN and then stores it to PRU shared RAM
May 22 17:26:03 <Abhishek_> 3. Once 6144 bytes have been stored, PRU0_ARM_ is fired to signal to userspace
May 22 17:26:44 <panto> Abhishek_, similarly there's a ack from user-space to PRU0 for when user-space has pick-ed up the data
May 22 17:26:54 <panto> you can't rely on timing solely
May 22 17:27:12 <Abhishek_> PRU1 is free running, I forgot to mention
May 22 17:27:42 <panto> doesn't matter
May 22 17:28:01 <panto> you can increase some counter if you miss events
May 22 17:28:05 <Abhishek_> But then what if the buffer overruns while receiving the ACK from PRU0?
May 22 17:28:12 <karki> panto : But what would happen if I manually loaded the driver? what would be the benefit/need of a platform interface in this case. Won't a normal driver interface do (init, exit)? From what I understood platform interface is used when the devices are not inherently visible to the kernel......
May 22 17:28:16 <panto> increase a counter
May 22 17:28:41 <Abhishek_> what about the lost data?
May 22 17:28:51 <Abhishek_> It's a logic analyzer.
May 22 17:28:51 <panto> it's better to have an overflow condition than getting your producer,consumer out of sync
May 22 17:29:09 <panto> that's something that shouldn't happen often
May 22 17:29:17 <panto> it's failure condition
May 22 17:29:36 <panto> fail gracefully instead of getting into an undefined state
May 22 17:30:12 <panto> plan for errors and try to recover
May 22 17:30:23 <panto> an overflow is better than garbled data
May 22 17:30:30 <Abhishek_> panto: hmm, okay, let me make some changes and get back in some time. Would you have some time to look at the PRU firmware (asm files) when I ping you next?
May 22 17:30:42 <panto> not today I'm afraid
May 22 17:31:13 * Abhishek_ needs to have his PRU firmware reviewed
May 22 17:31:38 <Abhishek_> panto: This weekend maybe?
May 22 17:31:58 <ds2> Abhishek_: are you starting from scratch?
May 22 17:32:47 <karki> panto : so, what would happen if I coded the module an a non-platform dev driver, loaded it explicitly and tried talking to it?
May 22 17:32:52 <panto> and btw, 6K of data is worth how many usec in full data rate?
May 22 17:33:18 <panto> karki, you have to bind to the driver core somehow
May 22 17:33:44 <panto> platform devices is the preferred way to do per board/soc drivers
May 22 17:34:12 <panto> Abhishek_, what's the clock rate on that 6K data
May 22 17:34:15 <ds2> platform drivers are easy
May 22 17:34:25 <Abhishek_> panto: I'm sampling at 100MHz for now
May 22 17:34:34 <Abhishek_> that's too fast I suppose
May 22 17:34:48 <ds2> have init register a structure that has the name of the driver and a probe function (along with exit, etc)
May 22 17:34:50 <Abhishek_> between two MOV R31s, there's a NOP
May 22 17:34:52 <panto> there's no way ARM userspace can consume that data that fast
May 22 17:35:07 <ds2> in your board file (or if you insist, your DT)... add that as a device for your board
May 22 17:35:11 <Abhishek_> ds2: If you're saying with respect to the demo firmware I showed you, yes.
May 22 17:35:33 <ds2> Abhishek_: ah, okay... never did hear a resolution on the licensing...this is safer
May 22 17:35:35 <karki> panto : fine I'll read about it. But in case I don't understand I'm going to bug you about it this week ;)
May 22 17:35:40 <panto> best case is 61us
May 22 17:35:51 <panto> for 1 bit sampling
May 22 17:36:04 <panto> use dram buffering to hide the latency
May 22 17:36:20 <Abhishek_> ds2: The demo firmware is essentially *just* SBBO R31, DDRRAMPointer, number, 1
May 22 17:36:21 <panto> ARM is nowhere near possible handling a buffer each 61us
May 22 17:36:42 <Abhishek_> ds2: I studied it completely
May 22 17:36:50 <ds2> Abhishek_: still...
May 22 17:37:15 <panto> anyway, I'm off
May 22 17:37:46 <Abhishek_> yep, I understood your concern. Did you take a look at the PRU firmware links I sent you yesterday?
May 22 17:37:59 <ds2> Abhishek_: didn't get a chance to
May 22 17:38:21 <ds2> Abhishek_: I might "borrow" some of your code once you have this working
May 22 17:38:32 <ds2> I need to capture a stream at 27MHz
May 22 17:38:33 <ds2> :)
May 22 17:39:08 <Abhishek_> sure, that's the purpose :)
May 22 17:39:44 <ds2> mine is a video stream though
May 22 17:40:46 <Abhishek_> video, as in, composite video signals?
May 22 17:41:54 <karki> panto : what exactly is probe meant for in the platform API?
May 22 18:56:40 <Abhishek_> g'night
**** ENDING LOGGING AT Fri May 23 03:00:01 2014