**** BEGIN LOGGING AT Fri May 30 03:00:00 2014 May 30 04:26:08 panto: Would it be possible for the kernel driver to just write into a buffer which has been malloc'd by userspace or the kernel driver has to manage memory allocation and give back a pointer to the host? May 30 05:05:11 Abhishek_ : the latter May 30 05:05:38 I'm only thinking if the former is possible May 30 05:06:22 why would you want to do that? May 30 05:38:37 * karki_ explodes May 30 06:52:35 * Abhishek_ feels the impact May 30 06:55:27 * Abhishek_ feels the *heat May 30 07:21:25 panto: is the copy_to_user defined in kernel space any faster than user space? May 30 08:55:34 it is supposed to be optimised May 30 08:55:56 but since you're mostly limited by the memory interface b/w I wouldn't expect huge differences May 30 09:07:37 panto : I got the bin_attribute stuff to work, so I thought I'll focus on the firmware load for now. mmap can be done later as an optimization. currently the same functionality can be managed via read and write calls on the bin sysfs file. May 30 09:08:42 panto : The code for probe is confusing :/ I'm running through a lot of header files and It'll take some time. but I want your views for keeping the mmap for later. May 30 09:11:27 karki_, ok May 30 09:56:29 panto: how could it be possible to malloc a large chunk of memory from userspace and pass a pointer to the kernel driver to fill in the buffer directly, or should the memory allocation be taken care of by the kernel? May 30 10:03:37 user space can not allocated physically contiguous memory May 30 10:03:41 it has to be the kernel May 30 10:03:44 *allocate May 30 10:04:35 but then the UIO driver uses dma_alloc_coherent and it can't obtain more than 8 MB. So which function would have to be used? May 30 10:05:06 you have to use the CMA allocator May 30 10:05:32 note, needing more than 8MB of physically contiguous memory is not a good idea May 30 10:06:54 okay, so maybe I could allocate in chunks of 8 MB using multiple calls to dma_alloc_coherent in that case? May 30 10:19:27 yes you could May 30 10:19:35 but then you'd do scatter gather right? May 30 10:20:30 I was reading up dma api in the kernel documenration (sources) May 30 10:21:41 I found dma_map_sg, but there isn't any sg-alloc method, right? May 30 10:22:29 there is no need May 30 10:23:43 you mean, there's no need of dma_map_sg? May 30 10:25:15 let's take it from the start May 30 10:25:33 dma_alloc_coherent will return memory that does not need to be mapped May 30 10:25:39 it is uncached I/O memory May 30 10:26:16 dma_map_sg will prepare memory to be used for I/O which was not allocated with dma_alloc_coherent May 30 10:26:44 in fact using dma_map_sg with memory returned from dma_alloc_coherent is a bug (and will break in various non-obvious ways) May 30 10:27:51 I see. May 30 10:30:30 So what I could do is, call dma_alloc_coherent several times with sizes, say 4 MB, till I have how much I would need [the userspace app will tell the kernel module how much it needs, or if it needs a stream of values] May 30 10:31:06 you can use it for allocating the chunks of memory to pass to user-space May 30 10:31:27 don't bother with trying to do something complicated May 30 10:31:36 a simple ping-pong scheme should work May 30 10:33:04 and then mmap the buffers to user space? May 30 10:37:31 yes May 30 10:59:10 panto: one more question, can circular buffers be utilized in this case, or it would complicate? May 30 11:05:59 what is a ping pong buffer but a circular one? May 30 11:06:27 nope, I was more inquiring about the circular buffer API present in the kernel May 30 11:07:23 you mean the circular buffers? May 30 11:07:46 yes, that one May 30 11:07:49 that's a byte interface May 30 11:08:13 not going to work May 30 11:08:23 k May 30 13:12:51 panto : I won't be requiring any virtio features for pru-speak (as of now) , so is it safe to modify your driver for my firmware and drop out the virtio support? or is there something else I should be concerned about? May 30 13:21:56 do not drop anything out May 30 13:22:14 make a copy of the driver if you must May 30 13:22:22 but no wild hacking just to get something to work May 30 13:27:28 okay :) May 30 13:28:40 panto : so keep the pwm functionality too? May 30 13:42:58 keep it in for now May 30 13:43:02 add your own stuff May 30 13:57:08 panto : So, I'll just change ".compatible" and "probe" to match my needs? (I'll need a bit of help with the IRQ's if I can't figure it out, everything seems fine uptill now! ) May 30 14:54:48 panto: How is firmware re-uploaded in your remoteproc implementation? May 30 15:06:45 there's a sysfs property that reloads it May 30 15:06:55 but it's not reliable if the h/w configuration changes May 30 15:23:43 panto : what exactly does pm_runtime_enable(device *) do? (other than what I can figure out from the name itself - I specifically want to know how this function acts on the PRU) May 30 15:24:22 ignore it May 30 15:24:27 it's power management related May 30 15:28:06 * karki is happy, finally something to ignore :D only 2822 lines and 10 files to cover now ;) May 30 15:39:31 panto : can I ignore "dma_set_coherent_mask" too? May 30 15:49:05 av500: Ping May 30 16:02:16 hey praveendath92, how's it going? May 30 16:14:49 panto: Is firmware loading through ioctl a good idea? May 30 16:22:14 Abhishek_: Not much progress after the meeting. Had to work a poster for a conference. May 30 16:22:37 Leaving to San Francisco tonight. May 30 16:23:15 cool, Happy Journey :) May 30 16:23:54 Abhishek_, no May 30 16:26:25 Thanks Abhishek_ Flight in 3 hours. I will get going. Ciao all :) May 30 16:57:34 panto: any alternatives for the device tree thing [I have to load different firmware for different sample rates, as I had mentioned earlier]? May 30 17:02:48 sysfs and triggering a reload May 30 17:54:31 panto : "platform_get_irq(pdev, i)" is supposed to register the interrupts, what exactly is the process of "registering" the interrupts? I traced down the call to "platform_get_resource", and it seems to be returning a resource structure...... May 30 17:54:47 whats exactly happening here? May 30 18:03:39 panto : what is the resource pointer of the platform_device (pdev) pointing to, what kinds of resources are there in the case of this driver? May 30 18:07:38 it just pulls out the irq number from there May 30 18:07:53 to register an interrupt, you would use request_irq*(...) May 30 18:09:45 ds2 : what all does the resource array of the pdev contain? May 30 18:09:57 it contains resource information relevant to the device May 30 18:10:12 I have no idea which driver you are looking at so... May 30 18:10:31 so, 0-7 are IRQs right? ( panto 's pru-proc) May 30 18:10:41 0-7 what? May 30 18:11:00 the PRU interrupts May 30 18:11:19 maybe May 30 18:11:23 0-7 indexes May 30 18:11:24 it depends on the mapping of the PICs May 30 18:11:34 the one from the pdev info is the one you use with request_irq May 30 18:11:49 in theory, hwmod should handle the mapping May 30 18:11:58 I don't know how far he has gotten with all that May 30 18:20:04 ds2 : the irq numbers read from "platform_get_irq" would be the ones meant for the PRU (8 numbers are for the PRU, as per TRM) , right? numbers : 20 -27 May 30 20:00:26 they don't show up as actual system interrupts May 30 20:05:02 mranostay: What impedes the new PRU C compiler from building the remoteproc examples May 30 20:05:05 now May 30 20:13:26 something with linking May 30 20:13:32 need to have panto confrim May 30 20:13:36 *confirm May 30 20:15:08 mranostay: How could I expose an mmap interface in the existing remoteproc driver, or should I develop another lean driver (only basic stuff which I need)? May 30 20:16:31 something on the lines of a char device. May 30 20:18:17 ah the spidev part of mine is a character device May 30 20:19:13 mranostay: I'm currently running Koen's kernel, so I have that integrated currently and work on that May 30 20:55:12 panto: What will happen if the PRU firmware does not expose a resource table? **** ENDING LOGGING AT Sat May 31 03:00:00 2014