**** BEGIN LOGGING AT Mon Mar 21 02:59:58 2016 Mar 21 04:52:56 where are all other mentors ? alexhiam ? ds2 ? bradfa ? Abhishek_ ? havent seen them in last 2-3 days .. Mar 21 05:04:16 ZeekHuge: you're still not on the google-y review list Mar 21 05:04:35 I have added the draft ! Mar 21 05:04:42 it doesn't have to be "complete" yet... Mar 21 05:04:52 Am i not visible there ? Mar 21 05:07:08 Ohk .. I think it must be there now .. is it ? Mar 21 05:07:46 nerdboy, ? Mar 21 05:24:26 Wormo ? Mar 21 05:34:06 looks good, you'll have to break up your software stack into testable chunks in the timeline Mar 21 05:34:27 yes ... ohk:) Mar 21 05:34:46 nerdboy, you can comment on the doc if you wish to :) Mar 21 05:35:35 and ... I am still worried about the format of the proposal ... ( should I be ? ) Mar 21 05:36:17 not really Mar 21 05:36:32 ohk then :) Mar 21 05:36:37 hmmm Mar 21 05:36:44 Hey ds2 ! Mar 21 05:36:50 hey ZeekHuge Mar 21 05:36:57 can you please see my proposal ! Mar 21 05:37:11 its there on the GSoC website Mar 21 05:38:29 let me find my credentials (too many variants) Mar 21 05:42:32 ZeekHuge: most immediate thing - you might want to give a brief discussion on why GPMC may be better or worse Mar 21 05:45:17 Okay .. Mar 21 05:50:25 ZeekHuge: doc file commented on. Mar 21 05:50:55 ZeekHuge: one thing to keep in mind is how will this project continue to live after GSoC Mar 21 05:51:21 ohk .. Mar 21 05:51:33 I have been talking to the IIO maintainer Mar 21 05:51:41 and? Mar 21 05:51:42 Jonathan Cameron Mar 21 05:51:56 publically or privately? Mar 21 05:52:09 he suggested to make different subsystem for this .. Mar 21 05:52:18 no .. on emails and hangout. Mar 21 05:52:41 as, there was nothing like parallel offload in the tree yet. Mar 21 05:53:41 also, he said that there can be some parts of the project that could be mainlined. Mar 21 05:54:01 but, pruss_remoteproc has .to be considered first Mar 21 05:54:36 okay... did he suggest any other maintainers to talk to? Mar 21 05:54:44 putting that info into the app would be good Mar 21 05:54:48 no .. Mar 21 05:55:01 how should i add that ? Mar 21 05:55:06 I mean .. ahh ? Mar 21 05:55:21 can you describe in the next2 minutes what you are trying to do with this project (want to make sure what I got from reading the app matches what you intended it to say) Mar 21 05:55:57 The primary goal is to expose the PRUs as a parallel interface .. Mar 21 05:56:08 and highly configurable .. Mar 21 05:56:32 like the clock or the bit resolution Mar 21 05:56:58 this will also allow developers use it for simple applications Mar 21 05:57:16 like just toggling the specific pins (at high speed) Mar 21 05:57:51 Okay Mar 21 05:57:56 for the following project, I will be using an ADC Mar 21 05:58:04 now explain to me why you want to use the PRU for it instead of the GPMC? Mar 21 05:58:31 As far as I know about it .. Mar 21 05:58:44 its not that easy to use it .. Mar 21 05:58:53 it will be mostly on baremetal side Mar 21 05:59:32 like staterware or something will be required for that .. Mar 21 06:00:03 also ... using PRUs will allow to use the already present core, that mostly sits idle .. Mar 21 06:00:21 also not sure if DMA can be used over GPMC Mar 21 06:00:38 okay Mar 21 06:00:54 the PRUs can do a LOT more Mar 21 06:01:20 and it is no more difficult to use then the PRUs.... GPMC (if you look at what it stands for... should have no issues with DMA) Mar 21 06:02:04 ZeekHuge: have you had a class on processor buses (esp. older ones like the 6502, 8051, 8086, etc)? Mar 21 06:02:26 yes yes ... but what PRU can do is mostly with their GPIOs Mar 21 06:02:37 and this project tries to use these GPIOs Mar 21 06:02:54 I have 8086 this sem in my course Mar 21 06:03:27 but have already studied and used 8051 as was interested (2 years back ) Mar 21 06:04:19 Also, If time allows, DAC support can be added to the project too .. Mar 21 06:04:37 so, then after, the PRUs will be able to write as well as read .. Mar 21 06:04:58 though it will be half duplex. Mar 21 06:05:47 ZeekHuge: the GPMC is pretty much a configureable bus that can emulate the 8086 or 8051 external buses Mar 21 06:06:16 but this can go further and we can make it full-duplex ( for example reading from 5 pins and writing to other 5 ). Mar 21 06:06:23 a lot of the parallel ADCs are setup to sit on stuff like the GPMC Mar 21 06:07:17 okay .. but what i feel is, its not just about ADC, its about the presence of those two 32bit cores on the SoC Mar 21 06:08:18 infact if we require the PRUs to do some calculation and then give this data to the MPU Mar 21 06:08:52 that will involve just some changes in the firmware and maybe some on the 1st bus-driver side Mar 21 06:09:13 the rest will be fine after this project. Mar 21 06:10:35 ds2 ? Mar 21 06:10:48 okay Mar 21 06:11:13 If I look at this purely from the outside (i.e. deciding if I want to use this for a project), I still don't see a good reason for this Mar 21 06:11:26 if I were to do this, I have to mess with firmware and a whole lot of other things Mar 21 06:12:37 you have a personal project sampling ADC at about 20MHz ! why not use this ? Mar 21 06:12:47 why not use GPMC? Mar 21 06:13:14 GPMC is documented by TI... no silly firmware and other magic bits to deal with (again, arguing as an outsider) Mar 21 06:13:29 maybe i want two ? :) Mar 21 06:13:49 there are multiple chipselects Mar 21 06:15:19 Why are the PRUs there then ? arent they used for their enhanced GPIOs ? Mar 21 06:15:39 and somewhat processing capabilities ? Mar 21 06:16:26 that is what this project aims to bring out.. Mar 21 06:18:03 ZeekHuge: serial stuff is one thing the PRUSS can do that GPMC can't do easily for one thing Mar 21 06:18:10 if you want make a 20MHz blinky... set the bit resolution to 1 and use it. Mar 21 06:18:13 they are enhanced GPIOs Mar 21 06:18:27 there should be a good justitification to use one subsystem or another Mar 21 06:19:14 but then this serial stuff can be done by other peripherals too ... Mar 21 06:19:29 having all features all DMA, interrupts etc Mar 21 06:19:38 not if you want more of them Mar 21 06:19:41 or say you want QSPI Mar 21 06:19:57 give you another example - I wanted to generate NTSC output Mar 21 06:20:01 nothing else on there can do it Mar 21 06:21:21 NTSC ? the video format ? Mar 21 06:22:41 yes Mar 21 06:22:44 analog video Mar 21 06:22:55 the other element is real time Mar 21 06:29:33 what if you need to interface with 11 bit ADC ? :) Mar 21 06:36:39 also I still feel using GPMC is not that easy. Infact, a simple user, take me for example, probably wont even know what GPMC exactly is (I came to know after i did research for this project), but I knew about PRUs already, infact i was able to get them running using UIO. Mar 21 06:38:00 ds2: what say ? this project is really not as much about ADCs as is about PRUs it will provide an example, and will make it much much more easy to use PRUs .. Mar 21 06:38:15 the GPMC is 16bit wide on this, IIRC Mar 21 06:39:17 ZeekHuge: if that is the case, you really need to convince people this project is doable in the GSoC timeframe Mar 21 06:39:37 designing and implementing such a big subsystem is a bit agreesive for the GSoC time frame Mar 21 06:40:35 adding just the ADC ( ie reading ) support too? Mar 21 06:42:00 if you are targeting a general subsystem with the ADC support as a demo, it becomes a much larger project Mar 21 06:42:04 more design is needed Mar 21 06:42:31 and if we would want to add it as an IIO ? Mar 21 06:42:34 OTH, if it is just implementing a fast ADC interface outputing to IIO (as a demo of how the PRU can be tied in with stock subsystem), it is a smaller project Mar 21 06:43:00 you just told me the focus is a general thing... general things needs to be designed Mar 21 06:43:13 yes .. that is true. Mar 21 06:43:51 but are you convinced that this is going to be useful ? Mar 21 06:46:02 as a general thing, I am not Mar 21 06:46:33 the main long term value I see with the other approach is it shows people that the PRUSS can be used with kernel APIs Mar 21 06:47:16 the other approach ? making it a different subsystem ? Mar 21 06:48:22 also, the other day, you were convinced that getting samples from ADC at 40MHz can be useful.. Mar 21 06:48:51 and you encouraged to go ahead on the idea .. Mar 21 06:49:12 were you talking about something different ? Mar 21 06:51:45 no, other as in - making this a demo of using IIO with the PRUSS Mar 21 06:52:15 ZeekHuge: I ran some very rough numbers at one point and about 37-40MHz is about the upper limit Mar 21 06:52:29 I was purely talking about ADC sampling Mar 21 06:52:49 ADC sapling using PRUs Mar 21 06:53:00 *sampling Mar 21 06:53:07 yes Mar 21 06:53:45 ZeekHuge: what you have proposed so far is - a new subsystem using the ADC as a demo; the alt. is using the PRU with a stock subsystem as a demo of how to do that Mar 21 06:54:31 but the alt. would be, as you told, a smaller project. Mar 21 06:55:33 yep Mar 21 06:55:43 so what should be added to that ? Mar 21 06:55:52 maybe we can go with the alt Mar 21 06:56:07 if the original wont fit in the timeline .. Mar 21 06:56:43 what can be added to alt to make it more useful ? Mar 21 06:58:57 not sure what you are asking Mar 21 07:00:25 using PRUs to sample ADCs with stock subsystem will be a smaller project. So other things can we add to make it fit well into the timeline ? Mar 21 07:03:41 ZeekHuge: that in itself should be good enough. The bigger picture is to show how the PRU can be used in a standard context; most usage today has been through oddball hacks in userland. There have been exceptions done by TI for other PRUSS enabled chips but that is old Mar 21 07:05:09 ohk, but isnt this ( using PRUs with other stock subsystem ) what other projects (like the SPI one ) are doing ? Mar 21 07:06:53 pretty close to it - the way I see it is - this is a high speed example Mar 21 07:07:04 SPI/I2C/UART are relatively slow stuff Mar 21 07:07:15 ohk ... Mar 21 07:07:25 so should i modify my proposal ? Mar 21 07:08:08 your call Mar 21 07:08:23 the proposal will be reviewed by other mentors too Mar 21 07:08:30 my opinion is just one of them Mar 21 07:13:10 <_Zeekhuge> Ohk .. I'll ask other mentors too. Mar 21 07:36:04 <_ZeekHuge> nerdboy, you there ? Mar 21 07:36:10 <_ZeekHuge> Wormo ? Mar 21 07:45:54 ds2 you still there ? Mar 21 09:07:45 hey av500 ! can you please review the proposal ! it there on the GSoC website Mar 21 09:07:58 https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 21 09:08:02 and here ^^ Mar 21 09:08:09 will do Mar 21 09:11:52 okay :) Mar 21 09:49:45 morning Mar 21 09:49:57 Hey Abhishek__ ! Mar 21 09:50:29 glad to see you .. after 2 - 3 days ! Mar 21 09:50:53 I have submitted my proposal draft, can you please review it .. Mar 21 09:51:30 link? Mar 21 09:51:53 sure : https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 21 09:53:10 How's it different from what BeagleLogic does? Mar 21 09:53:48 on the PRU side, it will provide an analog extension to beaglelogic. Mar 21 09:54:05 but on linux side.. it will basically be a new subsystem Mar 21 09:54:23 as was suggested by Jonathan Cameron (IIO maintainer) Mar 21 09:54:46 why a new subsystem? Mar 21 09:54:57 the idea is to make it available in complete modules, without hacking into some method . Mar 21 09:55:39 that is basically because there is no subsystem for parallel stuff like this .. Mar 21 09:55:52 so, further development would be possible .. Mar 21 09:56:00 Isn't it what IIO itself is designed for? .. talking to ADCs and DACs, how would it be any different? Mar 21 09:56:33 also, Jonathan said that there can be parts of this project that could be mainlined. Mar 21 09:56:53 how are you planning to go about doing that? Mar 21 09:57:46 yes it is .. but that wont it be over the serial buses like SPI and I2C ? Mar 21 09:58:06 also, it can be used for cameras and other stuff too ! Mar 21 09:58:33 this will basically expose the PRUs as parallel interface to talk upon .. Mar 21 09:59:49 the way I get after going through your proposal, there is significant overlap with stuff that has already been done. Mar 21 10:00:40 yes but the main aim is to make it generic, rather than the 'hacking' approach .. Mar 21 10:00:53 "Hacking"? Mar 21 10:02:07 like.. making a single huge driver that would be used for only one application. and making modules to talk through the drivers .. Mar 21 10:02:45 each driver/module abstracting the details that lie under it.. Mar 21 10:02:50 isn't pruss_remoteproc the "single huge" driver? Mar 21 10:04:58 it isnt providing the parallel bus interface, to the modules that are above it. is it ? Mar 21 10:06:15 it will be based on pruss_remoteproc though .. Mar 21 10:12:08 Abhishek__ ? Mar 21 10:12:54 I think you'll have to choose between the "parallel bus" interface and defining a new subsystem... GSoC might be shorter than you think it is. Mar 21 10:13:28 ah .. ohk . Mar 21 10:13:41 but if you choose the "parallel bus" interface, you'll be ending up repeating from scratch the work that was started 2 years ago. Mar 21 10:14:35 why cant we use the code from beaglelogic ? Mar 21 10:14:49 and modify it if required / Mar 21 10:14:50 ? Mar 21 10:18:30 The point is, the change required to the BeagleLogic code to support analog data capture is trivial. Mar 21 10:18:56 You only need to change the PRU firmware, no change to the kernel module at all. Mar 21 10:19:45 Hi All, just dropped by as this is getting interesting ;) (Jonathan Cameron IIO maintainer) Mar 21 10:19:53 Hey jic23 Mar 21 10:20:15 So, the way this would be done is - assuming the ADC takes in a clock. Mar 21 10:20:23 Beagle logic is a custom module user a non standard kernel interface... Admittedly there isn't really anything standard for fast clocked GPIs Mar 21 10:20:35 Though it gets proposed every now and then. Mar 21 10:20:48 I totally understand that. Mar 21 10:21:26 larsc suggested IIO when I was doing GSoC in 2014 Mar 21 10:21:57 would have needed some additions that have only come along more recently! (mainly becuase Lars took for ever to mainline them ;) Mar 21 10:22:16 I see. Mar 21 10:22:21 Could be done fairly easily now though... Mar 21 10:22:45 Basically the DMA buffer stuff that jumps past the software fifos and stuff. Mar 21 10:23:10 I do know that IIO offers a device file buffer-style interface similar to what BeagleLogic does Mar 21 10:23:17 Anyhow, for what ZeekHuge is suggesting we have another intermediate layer - the parallel offload element. Mar 21 10:23:42 It's a bit of 'magic' on a standard bus. Lars has proposed additions to SPI (SPI Offload) to do the same thing. Mar 21 10:23:51 Only implementation of that so far is on an FPGA though. Mar 21 10:23:56 Zynq? Mar 21 10:24:00 yup. Mar 21 10:24:14 (nice toys the zyncs ;) Mar 21 10:24:17 yeah I remember reading through an ADI tutorial on SDR or something like that Mar 21 10:24:24 yup. Mar 21 10:24:26 I'm getting a Zynq board myself Mar 21 10:24:50 Same problem at the end of the day - kernel can't keep up with short ping-pong type transfers. Mar 21 10:25:11 the main issue is the dma_map and dma_unmap stuff, takes too much time Mar 21 10:25:21 and keeps the CPU hanging Mar 21 10:25:44 in beaglelogic? Mar 21 10:25:49 yeah Mar 21 10:25:57 not just BeagleLogic though Mar 21 10:26:06 Thought you got it ticking along pretty quick? Mar 21 10:26:49 Hmm, I initially started with memory allocated using dma_alloc_coherent but then realized that memcpy is too slow Mar 21 10:26:59 Is it the caching mess that happens when you bring them into the CPU space? Mar 21 10:27:07 yeah. Mar 21 10:27:17 the PRU writes to DDR directly. Mar 21 10:27:22 so cache coherency Mar 21 10:27:29 hmm.. Annoying - guessing gains from larger blocks aren't huge as a result. Mar 21 10:27:36 exactly Mar 21 10:27:48 So what limit did you reach? Mar 21 10:27:54 (how bad is it?) Mar 21 10:28:29 Same issue occurs for the GPMC I would guess. DMA buffers still need to be brought into the caches. Mar 21 10:29:37 it's about 200 MB/s memcpy, just shy of BeagleLogic's max sampling capability Mar 21 10:30:07 the CPU is maxed out thought, so there's little CPU time available to do anything else with the data than dump it to /dev/null Mar 21 10:30:33 *out throughout Mar 21 10:30:46 That's fine for this application as well then as realistic limit is probably 1/4 of that - I'd guess without tuning maybe 20MSPS 8bit is starting point. Mar 21 10:31:24 with beagle logic in continuous mode, cap it at 100MB/S and you'll probably have enough time to do something useful I guess? Mar 21 10:31:45 On a board that is currently under embargo, I've got BeagleLogic to do 20 MSps x2 channels and 8 bits. I did the mod to the existing code within a weekend Mar 21 10:32:17 that's why I know it's a trivial code change Mar 21 10:32:39 yup, PRU side is as you said trivial. Interesting bit from my mind is brining this into the kernel properly. It's really a kernel project in many ways. Mar 21 10:32:53 I agree with you on this point though Mar 21 10:33:21 the rproc_pru stuff needs work to add sensible in kernel registration of users etc. Any idea what status on mainlining that is? Mar 21 10:33:28 Interestingly there was no kernel module code change required at all Mar 21 10:33:45 Just a small patch to the PRU firmware, that's all Mar 21 10:34:31 Yup, just sample the parallel bus. Mar 21 10:34:33 I also agree that the rproc_pru stuff is too beginner-unfriendly Mar 21 10:35:17 Honestly I'm unconvinced there is anything left to do on the pru that isn't really a simple mod of existing examples. Mar 21 10:35:25 The device is simple at the end of the day. Mar 21 10:35:37 You did the hard bits working out how to get data off the thing at speed. Mar 21 10:35:47 Yup, the kernel stuff has a lot of scope of how to do it well Mar 21 10:36:09 spi and i2c will be simple cases, though if spi offload can be in there it might be more fun (mostly kernel as well though) Mar 21 10:36:38 So to sketch out what I think the kernel stuff needs.... Mar 21 10:36:45 mranostay exposed the PRUs as a faux SPI device and used it to control a bunch of WS2812s Mar 21 10:37:09 this was way back in late 2013 Mar 21 10:37:18 Yup, easy stuff at the end of the day. Mar 21 10:37:28 Simple bitbanging. Mar 21 10:37:40 + a few fake registers to control it I would guess. Mar 21 10:37:49 jic23: So what are your suggestions on the kernel interface? Mar 21 10:37:58 Not to say that doing that right won't also provide good example code on the kernel side. Mar 21 10:38:21 For rproc I think I'm right in saying the beaglelogic currently hooks in 'hard' - e.g. puts calls in that driver. Mar 21 10:38:25 ? Mar 21 10:38:31 (not sure I have latest code) Mar 21 10:38:51 yup Mar 21 10:39:01 So we need a nice simple set of registration callbacks for other users. Make the rproc driver service for other drivers. Mar 21 10:39:24 Any userspace direct use should be split off into just another in kernel user (I got this bit wrong with IIO and we are still paying for it!) Mar 21 10:39:25 Yeah, you should check out my notes for last year's idea Mar 21 10:40:17 http://elinux.org/BeagleBoard/GSoC/Ideas-2015 Mar 21 10:40:28 Scroll down to "PRUSS support for newer kernels" Mar 21 10:41:10 That kicked out some good docs. (was reading them on Sat) Mar 21 10:41:26 What was eventual status? (not seen it in mainline ;) Mar 21 10:42:03 lots of changes. The problem is that the stuff is done in one kernel version, and now the version is so different Mar 21 10:42:08 Anyhow, big advantage of messing with in kernel interfaces is we can change them as often as we like to get it right! Mar 21 10:42:13 yeah Mar 21 10:42:32 Not hard to bring up to current I think though... Mar 21 10:42:36 3.14 did not have proper overlay support Mar 21 10:42:58 By the time 4.0 came by it was a huge effort to port the existing work so they just carried on Mar 21 10:43:00 It's still a little 'interesting'. Mar 21 10:43:38 On overlay sure, but at the end of the day for the rest of it, bodging the original devicetree files is trivial and removes that blocker... Mar 21 10:43:53 Have to do that just to get the am335x-adc running on current kernels. Mar 21 10:44:35 From the rproc side not much has changed recently so that side should be fine... Mar 21 10:44:56 ZeekHuge was saying he had it running with 4.1. I built it for 4.4 and ran out of time to actually test it... Mar 21 10:44:57 I don't really know. Things can go topsy-turvy anytime. Mar 21 10:45:17 That's why we need to get it mainlined asap! Mar 21 10:46:00 Given how well beaglebones work with mainline anyway + a few tiny patches... Mar 21 10:47:07 Anyhow, if you ever want to get kernel community buy in it has to be on current mainline. Most people won't even read patches otherwise. Mar 21 10:47:23 Lars might but he's mad and is always doing 100 different things ;) Mar 21 10:48:27 How interesting is mainlining Beaglelogic to you? Mar 21 10:52:17 back in a few mins. Mar 21 10:52:23 jic23: It's on my to-do list, but more important from a GSoC point of view would be getting the PRU interface right, those plug-in things Mar 21 10:52:29 I'm going afk in a few mins as well Mar 21 10:53:26 can speak more about it in ~4-5 hours from now. Mar 21 10:53:50 Right ish... It's in kernel stuff - we can change it later ;) Mar 21 10:53:55 But sure, I agree. Mar 21 10:54:29 Honestly it would be ideal to have that in place before the gsoc really starts - or at least under discussion on relevant lists. Mar 21 10:54:33 Might take a while... Mar 21 10:55:21 Then key thing for zeekhuge is that step 1 is a monolithic non flexible driver linking into that and going all the way up to IIO. Mar 21 10:55:50 That's mergable... Mar 21 10:56:00 ohk ... so it will be in the IIO subsystem first ? Mar 21 10:56:09 and then a different one ? Mar 21 10:56:11 Then work back down splitting out generic bits whilst keeping that top driver working. Mar 21 10:56:20 No ADC will always be in IIO. Mar 21 10:56:38 Trick is to start with a driver that does all the work but isn't flexible. Hooks into rproc. Mar 21 10:56:53 Then break out the reusable bits whilst keeping the top level bit working. Mar 21 10:57:16 Makes it testable at every stage. Also means that we have something useful along the way. Mar 21 10:57:33 ohk, then breaking it down to pru_parallel_interface driver , and then adc driver ? Mar 21 10:57:48 Having ultimate nice architecture in mind is fine, but you want a series of proofs of concept (good old minimum viable product stuff ;) Mar 21 10:58:27 rproc is there already, so will only be acceptable at first step to use that rather than going whole way down. Mar 21 10:58:32 Everything else is up for grabs. Mar 21 10:58:53 ohk, got that ... Mar 21 10:58:54 Anyhow, will leave irc open, but on other stuff mostly. Mar 21 10:59:03 ohk :) Mar 21 10:59:09 thank you :) Mar 21 11:01:17 Abhishek_: ping Mar 21 11:01:33 Abhishek__: there? Mar 21 11:02:04 can anyone look at my proposal and give me their valuable comments?? Mar 21 11:24:28 Abhishek said he'd be back in 4-5 hours a few mins ago. Mar 21 12:01:51 hey bradfa ! I have submitted my proposal draft, can you please review it ! Mar 21 12:06:18 ZeekHuge: I'll try to take a look in the next day or so Mar 21 12:06:50 Ohk :) here's the link https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 21 12:07:06 if you'll need it. Mar 21 13:30:36 back Mar 21 13:36:26 kiran4399: pong Mar 21 13:49:37 Abhishek__: do you have any idea about a kernel driver for PRU servo? Mar 21 13:51:28 have you tried ArduPilot? Mar 21 13:54:03 yeah.. Mar 21 13:54:35 Abhishek_: I was just wondering if Shubhanghi's work can come into play?? Mar 21 13:54:54 look for a standard linux subsystem first Mar 21 13:55:09 There's one for PWM Mar 21 13:55:11 use that Mar 21 13:55:34 link? Mar 21 13:55:45 so a kernel driver that's a PWM subsystem driver but interacts with the remoteproc PRU driver to drive the PRU pins Mar 21 13:55:58 panto has an example for that in the previous PRU driver Mar 21 13:56:43 Abhishek_, would you like to suggest some changes in the proposal to accommodate what jic23 suggested ? Mar 21 13:57:06 your focus should be more on defining the subsystem Mar 21 13:58:28 ohk so need to add more details about the parallel offload subsystem ? Mar 21 13:59:48 If you do not define it clearly, 12 weeks will not be enough Mar 21 14:00:26 ohk... Mar 21 14:03:48 ds2,are you there?I have some questions regarding rpmsg Mar 21 14:53:10 Hi All, I am having some issues with cross-compiling. When I try to compile with the command "CC=arm-angstrom-linux-gnueabi-gcc make". It gives me the following error: /home/burak/GSoC/BeagleBone/setup-scripts/build/tmp-angstrom_v2014_12-glibc/sysroots/beagleboard/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory # include Mar 21 14:53:29 Can anyone help me how to fix it? Mar 21 15:10:03 what are you trying to compile? Mar 21 15:20:52 I am trying to compile the hello world application for the demo Mar 21 15:21:08 just a simple c file which include hello world Mar 21 15:21:31 okay Mar 21 15:22:17 check the compiler flags Mar 21 15:25:01 what do you mean by check the compiler flags? Mar 21 15:25:17 -mfloat-abi=hard -mfpu=neon Mar 21 15:25:50 CFLAGS Mar 21 15:26:05 ok let me look into that Mar 21 15:27:39 m_w: can you please go through my proposal? Mar 21 15:27:47 link? Mar 21 15:33:29 kiran4399? Mar 21 15:52:19 without a link I cannot review your proposal Mar 21 16:40:33 https://docs.google.com/document/d/1bc2T1tu-WAkzB8M_SXzTmzQ7yzkAR1O_2jPslNjfO1c/edit?usp=sharing Mar 21 16:40:38 m_w: ^^ Mar 21 16:40:47 thanks Mar 21 16:43:49 looks pretty good Mar 21 16:44:14 s of comments addressed.. Mar 21 16:44:29 stupid wireless keyboard... Mar 21 16:44:34 *lots Mar 21 16:44:47 already developed the MPU-9250 driver? Mar 21 16:45:18 hat was done last year i think, at least for 3.8 Mar 21 16:45:47 * nerdboy still not quite sure what got into 4.1/4.4 Mar 21 16:45:52 but did kiran really write the driver? Mar 21 16:46:17 no, that was part of beaglepilot? Mar 21 16:47:07 then it should not read: "I have already developed the kernel driver for MPU-9250 which is nothing but MPU-6050 and AKM8963." Mar 21 16:47:09 maybe that was only in 3.8? Mar 21 16:47:40 there's no mpu9250 in the kernel Mar 21 16:47:54 only 6050 and the older one Mar 21 16:48:26 the beaglepilot stuff was done against 3.8 Mar 21 16:49:11 the key thing is that he is taking credit for developing the driver Mar 21 16:49:38 if the driver was already written then he did not develop the driver Mar 21 16:50:25 that's what i'm saying, he probably did what he said Mar 21 16:51:06 if you say so Mar 21 16:51:13 * nerdboy still trying to figure out current state Mar 21 16:51:53 the 6050 driver is supposed to more-or-less work with the new sensor i think Mar 21 16:52:11 yeah I have proven that myself Mar 21 16:52:11 at least for the parts it knows about Mar 21 16:52:38 but that doesn't mean that I developed the driver Mar 21 16:52:53 no, that needs to be clarified... Mar 21 16:52:56 I compiled and provided feedback on the IIO mailing list Mar 21 16:53:32 * nerdboy was about to comment but firefox took another dump Mar 21 16:53:54 ha Mar 21 16:54:17 what is going on with the mentor invites? Mar 21 17:01:17 you never got one? Mar 21 17:01:25 nope Mar 21 17:05:45 Can any of the mentors please help me with rpmsg?If I were to use to communicate between ARM and PRU,it basically exposes a character device file.Now if my SPI driver were to expose a spidev file,would it write to this character device file Mar 21 17:07:52 ? And also regarding ioctl,can't we just send the parameters to a specific buffer in the vring data structure and get the PRU to read that rather than defining particular ioctl functions for it? Mar 21 17:08:59 I am bit confused about how the ioctl fits into communication using rpmsg?Could any mentor please help me with this? Mar 21 17:25:58 * nerdboy not really a kernel dev but i thought your driver would "replace" char device with spidev device... Mar 21 17:26:44 am i missing something? Mar 21 17:29:16 You would hook in to rproc driver and provide an spi driver. Spidev will then sit on that. It is just a userspace interface to the spi subsystem. Mar 21 17:30:27 Was talking with abhishek earlier about this. Mar 21 17:30:53 Rproc driver needs proper in kernel interface... Mar 21 17:30:57 the interface behind rpmsg not the msg interface itself Mar 21 17:31:44 Yup. Interface to users in the kernel. Mar 21 17:32:01 too many acronyms flying around and not enough diagrams... Mar 21 17:32:40 Right now you have to hack the driver every time you want to use it. See what beagle logic is having to do. Mar 21 17:32:43 Agreed needs diags! Mar 21 17:33:03 Back later. School run Mar 21 17:33:23 Thanks jic23,Are you also a mentor? Mar 21 17:36:35 he is a mentor mentor Mar 21 17:38:23 :) Mar 21 17:39:49 Thanks m_w :) Mar 21 17:40:46 m_w, Do you have any idea when alexhiam, would be online.I guess he hasn't for quite some time now ? Mar 21 17:43:00 jic23: hey Mar 21 17:43:38 m_w: true :) Mar 21 17:45:37 hey Abhishek_ Could you please help with the ioctl part? Mar 21 17:46:11 chanakya_vc: What exactly? which ioctl? Mar 21 17:48:36 My project is exposing PRU as an I2C,UART,SPI device.So as I said before that I was thinking about using rpmsg for commn between ARM and PRU. Now as jic23 mentioned that spidev file basically sit above the character device file,if I wanted to set the parameters for SPI,couldn't I just write that to a buffer via Rpmsg and have the PRU read it? Mar 21 17:49:29 In my understanding ,ioctl are basically functions specific to a certain devices. Mar 21 17:50:00 There's a well-defined way of exposing a SPI device Mar 21 17:50:23