**** BEGIN LOGGING AT Tue Jun 17 02:59:58 2014
Jun 17 03:09:57 <Abhishek_> morning
Jun 17 04:26:24 <karki> It seems I have dengue :'(
Jun 17 05:09:58 <vvu> morning !
Jun 17 05:27:00 <av500> karki: :(
Jun 17 05:27:05 <av500> praveendath92: pong
Jun 17 05:27:52 <praveendath92> av500: You know how to handle a kernel framebuffer?
Jun 17 05:28:02 <av500> not really :)
Jun 17 05:28:09 <praveendath92> I got a frame but I'm not yet sure how to handle it.
Jun 17 05:28:19 <av500> define "handle" :)
Jun 17 05:28:24 <praveendath92> I mean it's format and stuff.
Jun 17 05:30:17 <av500> did you look into the displaylink driver?
Jun 17 05:31:32 <praveendath92> I'm looking at that too. udlfb.
Jun 17 05:32:54 <av500> that should give you a template on how to create a framebuffer
Jun 17 05:33:07 <av500> copy the driver and remove the usb backend
Jun 17 05:33:08 <praveendath92> In search of some good documentation or something of that sort for both so that we can pick one.
Jun 17 05:33:12 <praveendath92> Hmm.
Jun 17 05:33:18 <av500> so you just create a framebuffer when you load it
Jun 17 05:34:06 <praveendath92> https://github.com/haad/udlfb/blob/master/udlfb.c This one right?
Jun 17 05:34:49 <av500> yes
Jun 17 05:35:49 <av500> see the probe() function
Jun 17 05:37:05 <av500> in fact you can merge that with your usb stuff
Jun 17 05:37:21 <av500> just replace their usb stuff with yours
Jun 17 05:39:32 <praveendath92> I need to get some sense of their code.
Jun 17 05:40:16 <praveendath92> I created separate header files for all adk stuff.
Jun 17 05:40:40 <praveendath92> So, merging shouldn't make it too messy.
Jun 17 05:55:33 <Abhishek_> praveendath92: first glance, https://github.com/haad/udlfb/blob/master/udlfb.h has all the usb-specific stuff there (and bulk transfers). There's sporadic use of control messages but that is the file you would want to touch and replace.
Jun 17 05:55:55 <vvu> we won't need that control transfer
Jun 17 05:56:02 <vvu> they use that to get the edid of the display
Jun 17 05:56:10 <vvu> we should banish that out from the start
Jun 17 05:57:13 <Abhishek_> yeah, but can't we fake an EDID for our display, maybe by using the resolution of the android display screen, or leave some dummy data there?
Jun 17 05:57:23 <av500> yes
Jun 17 05:57:31 <vvu> that too think so
Jun 17 05:57:37 <av500> well, for a start we can use a fixed res
Jun 17 05:57:42 <av500> 1024x768 or so
Jun 17 05:57:46 <av500> android side can resize
Jun 17 05:57:53 <vvu> i say just hexDump on the android side :))
Jun 17 05:58:04 <av500> later you can grab the real resolution
Jun 17 05:58:07 <praveendath92> 1024x768 is a fair choice.
Jun 17 05:58:10 * vvu learned that hexDump is super useful when you don't know what you are doing 
Jun 17 08:35:02 <Abhishek_> mranostay: looks like the downcalls are not messed with -O3 but the SBCO and LBCO instruction get "optimized out"
Jun 17 11:15:00 <Abhishek_> Greetings vmayoral|pc
Jun 17 11:28:08 <vvu> av500: ping
Jun 17 11:29:28 <vvu> av500: http://thread.gmane.org/gmane.linux.usb.general/109974 look a bit what the usb guys are saying.
Jun 17 11:29:50 <vvu> they suggest we should switch to adk from userspace not kernelspace because it will be a pain to handle all the interfaces from the kernel
Jun 17 11:32:34 <vmayoral|pc> Abhishek_: greetings!
Jun 17 11:32:37 <vmayoral|pc> how is it going?
Jun 17 11:33:52 <Abhishek_> the kernel driver has been coded, sysfs stuff seems to be working, I'm making tweaks to the firmware on the PRU side for the actual capture
Jun 17 11:37:57 <Abhishek_> http://git.io/qDB98Q
Jun 17 11:47:47 <Abhishek_> vmayoral|pc: How's it going there? I saw that link about MAVlink sometime ago.
Jun 17 11:49:52 <vmayoral|pc> looking quite good your work :)!
Jun 17 11:50:39 <vmayoral|pc> Abhishek_: on my side, i'm moving forward. I get troubled from time to time with some (out of the gsoc scope) stuff but i guess that's the fun part
Jun 17 11:51:50 <Abhishek_> indeed, the kernel driver was something out of scope too, but quite relevant and the only way forward :)
Jun 17 12:00:52 <Abhishek_> vmayoral|pc: How are you utilizing the PRUs in BeaglePilot right now?
Jun 17 12:02:39 <Abhishek_> panto: The memset seems to increase consistency between first and subsequent copies from the char device
Jun 17 12:03:01 <panto> Abhishek_, I see
Jun 17 12:03:19 <panto> so kzalloc might do some kind of optimization with the mmu
Jun 17 12:03:42 <Abhishek_> yep, set the pages to zero on first fault, something like that
Jun 17 12:04:24 <panto> not quite sure
Jun 17 12:04:31 <panto> it depends on the slab allocator used
Jun 17 12:04:56 <panto> anyway, since touching the memory works there's no point looking at it anymore
Jun 17 12:05:07 <panto> what are your performance figures now?
Jun 17 12:05:41 <Abhishek_> dd if=/dev/beaglelogic bs=128K count=2048 > /dev/null gives around more than 200 MB/s
Jun 17 12:05:56 <Abhishek_> with large bs, seems to level off around 250 MB/s
Jun 17 12:06:16 <panto> looks like the performance is adequate :P
Jun 17 12:06:43 <panto> this is 1.6Gbit/sec on a very very cheap part
Jun 17 12:10:51 <vmayoral|pc> Abhishek_: for now we are generating PWM with them. We also plan to do the RCInput part with it as well as SPI. I'm not in charge of that though so i can't tell exactly when it'll be ready
Jun 17 12:11:12 <Abhishek_> final take for the PRU firmware right now. What I am implementing is something like PRU1 halts and PRU0 feeds it information from the downcall with which it jumps to the appropriate sample loop and delay loop and the next resume call from PRU0 starts the LA operation.
Jun 17 12:28:22 <av500> vvu: I dont read that there
Jun 17 12:28:39 <av500> vvu: what I read is that somebody sees ADK and says "userspace!"
Jun 17 12:30:15 <Abhishek_> vvu: Do the adk mode stuff and the normal mode devices have the same PID/VID?
Jun 17 12:46:47 <Abhishek_> strange, I got a kernel oops while allocating my buffers with devm_kzalloc, switched to kmalloc & memsetting to 0xFF and now it can allocate 304 MB of memory :P
Jun 17 13:57:51 <vvu> Abhishek_: no, but in principle one driver should take care of 2 virtual-devices
Jun 17 13:58:16 <Abhishek_> vvu: How about dynamically changing the match table? Would it work?
Jun 17 13:58:45 <vvu> nop, it's fixed. we can do mathing based on interface class but they have still the same
Jun 17 13:58:52 <vvu> it can be hacked in some way but not super clean
Jun 17 13:59:31 <vvu> in this way the fb driver will be loadead twice
Jun 17 13:59:38 <vvu> and unloadead once when the device is not in adk
Jun 17 13:59:49 <vvu> or i don't even know how it works :)
Jun 17 14:00:07 <vvu> i am now amazed, found a floppy disk at work
Jun 17 14:05:16 <av500> vvu: why twice?
Jun 17 14:06:54 <vvu> when android switches it chenges it's vid/pid so driver needs to attach again
Jun 17 14:07:07 <vvu> and usb+fb are in the same one
Jun 17 14:07:30 <vvu> so create dummy /dev/fb_adk for normal more then the real one for adk mode
Jun 17 14:07:47 <av500> why create a dummy at all?
Jun 17 14:07:58 <av500> why not create only when real adk mode is started?
Jun 17 14:08:04 <vvu> can we do that ?
Jun 17 14:08:31 <vvu> maybe it works, dunno. waiting for praveen to push code so we can see
Jun 17 14:08:46 <vvu> i just did a bit of reading on stuff not to be offguard
Jun 17 14:24:27 <vvu> exit
Jun 17 15:39:54 <Abhishek_> panto: what does this backtrace mean? : http://git.io/WIZJaQ
Jun 17 15:41:04 <panto> something is bad with the pointer you're passing to free
Jun 17 15:42:13 <Abhishek_> bad, as in?
Jun 17 15:43:00 <panto> corrupted somehow
Jun 17 15:43:10 <panto> the return code of free was not 0
Jun 17 15:45:04 <Abhishek_> ah, can that occur while I attempt to free a "null" pointer?
Jun 17 15:46:37 <karki> null pointer, random area of memory not under book keeping etc.
Jun 17 15:48:50 <Abhishek_> fixed it
Jun 17 15:49:08 <karki> great
Jun 17 15:53:03 <Abhishek_> beaglelogic leaching 320MB of the BeagleBone's RAM: http://s17.postimg.org/59tyin1n3/Screenshot_from_2014_06_17_22_51_05.png
Jun 17 15:53:15 <Abhishek_> *leeching
Jun 17 15:59:35 <mranostay> all pointers were born free :)
Jun 17 16:15:58 <Abhishek_> that's why they always have their way :)
Jun 17 16:31:11 <panto> Abhishek_, is that memory in blocks of something like 8MB?
Jun 17 16:31:20 <Abhishek_> yes
Jun 17 16:31:26 <panto> excellent
Jun 17 16:31:51 <panto> if you're allocating same sized chunks of memory you can use mem_cache
Jun 17 16:32:00 <panto> but leave that alone for now :)
Jun 17 16:32:23 <Abhishek_> it's in allocation unit multiples, that I have currently configured as 8 MB. It is changeable from the device tree file
Jun 17 16:32:37 <Abhishek_> (I have to implement reading from there)
Jun 17 16:36:27 <Abhishek_> panto: http://git.io/msaRSA is the device tree entry.
Jun 17 16:36:54 <panto> cool
Jun 17 17:22:07 <Abhishek_> panto: How do I take care of cache coherency in mmaps? Is it safe to unmap buffers from an ISR context, or should it be done through ioctl's?
Jun 17 17:22:36 <panto> Abhishek_, you don't need to
Jun 17 17:23:00 <panto> when you call dma_unmap the ownership of the buffer transfer to the ARM and you can just use it
Jun 17 17:24:05 <Abhishek_> that's what I wanted to ask, is it right to do dma_unmap from an ISR context?
Jun 17 17:24:20 <panto> you can do it, but it's going to take some time
Jun 17 17:24:28 <panto> why don't you use a threaded interrupt handler?
Jun 17 17:24:41 <Abhishek_> how do I do that?
Jun 17 17:25:08 <Abhishek_> wait, I route the pru_handler calls to my kernel drivers, is that a threaded IRQ?
Jun 17 17:26:15 <panto> request_threaded_irq
Jun 17 17:26:30 <panto> probably not
Jun 17 17:26:47 <panto> there's no big problem converting to a threaded irq model
Jun 17 17:27:03 <Abhishek_> I want the interrupts to be taken care of the in the pru_rproc driver
Jun 17 17:27:16 <panto> change the irq to threaded there then
Jun 17 17:27:26 <panto> anyway, time to go to dinner
Jun 17 17:27:28 <panto> l8r
Jun 17 17:27:38 <Abhishek_> k
Jun 17 17:29:32 <Abhishek_> it seems that devm_request_irq is an inline that resolves to devm_request_threaded_irq :P
Jun 17 18:06:14 <Abhishek_> panto: do I need to spinlock state changes as in when I mark a buffer read, I do bldev->bufbeingread->state = STATE_BL_BUF_READ, does it need to be in a spinlock protecting this line?
Jun 18 02:17:24 * mranostay pokes in
**** ENDING LOGGING AT Wed Jun 18 02:59:58 2014