**** BEGIN LOGGING AT Thu Jul 21 02:59:58 2016 Jul 21 14:15:14 did anybody get any board from seed studio? Jul 21 14:23:00 it has reached my city ... but will be delivered to me tomorrow. Jul 21 14:23:09 kiran4399: ^^ Jul 21 16:16:56 mdp, There? I have a doubt Jul 21 16:16:59 Wormo, ^^ Jul 21 17:09:11 henrix_ : figure anything out yesterday? Jul 21 17:09:44 Hi all. Having some problem with dynamically linking my dsp lib in connection with QT. Problem is opencl. When executing demo app (based on QT) llvm OpenCL is conflicting with TI OpenCL. LLVM OpenCL is included by QT printsupport (which is required) and my lib needs TI OpenCL Some suggestions? Jul 21 17:09:50 Here is my error output: Jul 21 17:10:37 test-libaudio-x15: /build/ti-llvm-3.3-DgVvHD/ti-llvm-3.3-3.3-git20150413/include/llvm/Support/CommandLine.h:674: Jul 21 17:10:37 void llvm::cl::parser::addLiteralOption(const char*, const DT&, const char*) [with DT = llvm::ScheduleDAGInstrs* (*)(llvm::MachineSchedContext*); DataType = llvm::ScheduleDAGInstrs* (*)(llvm::MachineSchedContext*)]: Jul 21 17:10:37 Zusicherung »findOption(Name) == Values.size() && "Option already exists!"« failed. Jul 21 17:11:28 again: Jul 21 17:11:28 test-libaudio-x15: /build/ti-llvm-3.3-DgVvHD/ti-llvm-3.3-3.3-git20150413/include/llvm/Support/CommandLine.h:674: void llvm::cl::parser::addLiteralOption(const char*, const DT&, const char*) [with DT = llvm::ScheduleDAGInstrs* (*)(llvm::MachineSchedContext*); DataType = llvm::ScheduleDAGInstrs* (*)(llvm::MachineSchedContext*)]: Assertion »findOption(Name) == Values.size() && "Option already exists!"« failed. Jul 21 17:13:02 here is a similar bug: https://github.com/Yamakaky/rust-bindgen/issues/89 Jul 21 17:14:42 m_w, found a workaround. no kernel crash anymore Jul 21 17:15:04 good Jul 21 17:15:09 still dsp firmware crash when playing something for the first time Jul 21 17:15:22 :( Jul 21 17:15:28 but everything works so far. can play audio and execute DSP operations Jul 21 17:15:58 so you are try to rebuild the firmware to debug Jul 21 17:16:14 I think if I concentrate on DSP firmware bug, time will be short for my main goals Jul 21 17:16:45 ne, skipped this for now. Actually, I only had to disable recovery for both DSPs. Then everything works. Jul 21 17:16:59 recover paths seem to be buggy Jul 21 17:17:48 okay Jul 21 17:19:19 but no crash and everything works. tested for about a half hour with sound playing all the time. Successfully simultaneously executed DSP operations (FFT, IFFT) several times and output is fine Jul 21 17:19:26 sound also;-) Jul 21 17:19:42 great Jul 21 17:21:15 yeah. sorry for not focusing on DSP firmware anymore but I think I won't finish lib in good quality if I do;-) Jul 21 17:22:20 hey ZeekHuge... how's the project going? Jul 21 17:23:21 ds2: hi ! just removed #1 Jul 21 17:23:41 will be submitting one more report by friday Jul 21 17:23:50 detailing further steps Jul 21 17:24:19 ZeekHuge: so clocking is working? Jul 21 17:24:31 https://github.com/ZeekHuge/BeagleScope/commits/port_to_4.4.12-ti-r31%2B Jul 21 17:25:04 yes completely configurable duty cycle Jul 21 17:25:18 I mean on the HW end Jul 21 17:25:23 the emitter follower to drive it Jul 21 17:25:30 https://github.com/ZeekHuge/BeagleScope/commit/5a84603fc1186d382573d724d9042b9a021410cf Jul 21 17:26:00 that test need to be done. Jul 21 17:26:19 so still no data from the HW yet? Jul 21 17:26:49 I had data using pull down resistors . It was working Jul 21 17:27:07 but at lower frequency Jul 21 17:27:21 right...but not from the ADC yet, right? Jul 21 17:27:27 no. Jul 21 17:27:31 got it Jul 21 17:27:34 not from ADC Jul 21 17:28:01 when are you shooting for actual ADC data? Jul 21 17:28:13 (we are at 3ish weeks left in GSoC) Jul 21 17:29:14 I am a bit afraid of it... but will do it within next 24 hours Jul 21 17:29:25 ZeekHuge: you see this guy? Jul 21 17:29:29 http://www.cnx-software.com/2016/07/21/google-research-prudaq-is-a-40msps-adc-data-acquisition-daq-cape-for-beaglebone-black-green Jul 21 17:29:39 it was all over G+ last night Jul 21 17:29:47 yep ! already :) Jul 21 17:30:00 m_w: I think one of his mentors worked on it Jul 21 17:30:09 yeah ! Jul 21 17:30:21 got to get your firmware to work on this guy eventually Jul 21 17:30:28 Abhishek_: did helped, according to googlle's post Jul 21 17:30:43 if all goes well, by the end of GSOC, we'll have many HW options Jul 21 17:30:52 dev board, that board, and I have my own board Jul 21 17:30:54 the code is posted BTW Jul 21 17:31:05 cool ! Jul 21 17:31:09 probally many others out there Jul 21 17:31:22 ds2: will get this done for sure ! I promise ! Jul 21 17:31:39 https://github.com/google/prudaq Jul 21 17:31:40 I mean .. will do the data from HW thing Jul 21 17:31:51 https://github.com/abhishek-kakkar/BeagleLogic/commit/33c761dfcf0b0a51de52698f85a0c56d664f36cf Jul 21 17:34:11 Getting data out from the ADC is not a lot of work, but the actual work is in defining the framework. Jul 21 17:34:35 m_w, ds2 I have a doubt Jul 21 17:35:02 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L1362 Jul 21 17:35:18 ZeekHuge: *nod* Jul 21 17:35:32 Here I am not able to understand what this structure is doing Jul 21 17:35:39 let me look Jul 21 17:36:07 Abhishek_: do you know what was the goal of the project? just a scope or? Jul 21 17:36:50 chanakya_vc: you don't need that for now... that is DT support related (of_.... is all DT stuff) Jul 21 17:37:06 data acq is a broad term Jul 21 17:39:47 ds2: I was saying that with reference to the parallel bus subsystem that was a part of ZeekHuge's proposal. Jul 21 17:40:33 Abhishek_: I mean the board... Jul 21 17:40:53 I am AC coupling it with a filter to get rid of noise on my end Jul 21 17:41:12 Okay ds2, is this related to the OF style match right? Jul 21 17:42:12 chanakya_vc: that line is a pointer to the node on the device tree for the McSPI stuff Jul 21 17:45:37 One more thing ds2, to export my probe function, I simply have to do EXPORT_SYMBOL_GPL(name of probe func) right? Jul 21 17:46:03 Then a simple function call from the probe function of remoteproc would suffice right? Jul 21 17:46:12 chanakya_vc: for an external module, yes Jul 21 17:46:34 for linked in, that shouldn't be needed... in both cases, you need a header file/function prototype Jul 21 17:46:38 standard C stuff Jul 21 17:47:16 ds2: what's the clock that you're using? Jul 21 17:48:03 I mean the frequency Jul 21 17:53:08 Abhishek_: PRU generated... Jul 21 17:54:13 using a 2 PRU style I/O, you should be able to get that 20MHz figure... I had 1 PRU sampling at about 27MHz before; the killer was pulling out the data Jul 21 17:55:37 I've tried the PRUDAQ board with 2-channel 20 MHz sampling, so I use R30 to toggle the ADC clock in-between samples Jul 21 17:55:40 Abhishek_: I been mostly looking at the analog characteristics, but on paper, this board should work okay up to around 25MHz. Jul 21 17:56:00 I see. Jul 21 17:56:04 that should be fine Jul 21 17:56:15 Raise edge, house keeping, Lower edge, read data, repeat Jul 21 17:56:36 the killer is writing to DDR where the cycles are undefined Jul 21 17:57:19 If it's a dual ADC the data is to be sampled every rising and falling edge Jul 21 17:57:20 saw something about noise... wonder if you have a duty cycle issue. that part (if it is like the sibling AD9201) use that to run the internal sampling statemachine Jul 21 17:58:19 blah... I mean i use the AD9203.... got it backwards Jul 21 17:59:32 I remember reading about sample delay in the AD9201 data sheet, the people I worked with were very conservative with delays at the expense of not able to do full 20 msps both channels and that was a reasonable compromise Jul 21 18:02:34 Not sure... the duty cycle was a sensitive spec on the part I looked at (the 40MS/1channel one) Jul 21 18:02:42 got to go...bbl Jul 21 18:03:59 m_w, There? Jul 21 18:04:11 yes Jul 21 18:04:28 but hit and miss with connectivity Jul 21 18:04:39 could drop out again any time Jul 21 18:05:04 it has been a frustrating day and a half Jul 21 18:05:11 Ohh.. cable not fixed m_w ? Jul 21 18:05:19 not yet Jul 21 18:05:37 they thought it exceptible to wait until Friday morning Jul 21 18:06:00 Anyway just wanted to ask about this:http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L1357 Jul 21 18:06:01 I work from home and it is very frustrating Jul 21 18:06:14 Ohh I can totally understand Jul 21 18:06:42 Just wanted to ask that even I would have to write a similar structure like this particular line? Jul 21 18:06:55 that is the private data for the driver Jul 21 18:07:15 you will need one with specifics for your driver Jul 21 18:07:48 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L132 Jul 21 18:07:56 it is defined at the top of the file Jul 21 18:08:06 m_w, Ohh, so I don't understand why there is a struct spi master there too Jul 21 18:08:55 I don't understand the concept of private data. What do I put there in my case? Jul 21 18:08:59 m_w, Jul 21 18:09:03 ^^ Jul 21 18:09:48 anything that it needed to communicate the device Jul 21 18:10:34 that "is" needed Jul 21 18:11:48 the resources Jul 21 18:12:16 Okay so I do my ioremap declarations here? m_w ? Jul 21 18:12:24 yes Jul 21 18:12:34 Okay. Jul 21 18:16:25 Next doubt m_w , in my char driver I was doing copy_to_user() ©_to_user() to send stuff to and from userspace. Now What I am not able to understand, in the tranfer_one_message() Jul 21 18:16:30 I do the same thing Jul 21 18:17:17 Or spi subsytem does this automatically for me? Jul 21 18:17:47 the spi core takes care of handling userspace Jul 21 18:18:12 Like I was getting data from userspace via a call to copy_from_user() and then getting the kernel to write to the specific address via ioremap Jul 21 18:18:13 you just provide the functions that it calls for your hardware Jul 21 18:18:46 your functions will access the hardware Jul 21 18:18:57 and pass the data back to the spi core Jul 21 18:19:34 the spi core will handle send it to other drivers for userspace interaction Jul 21 18:20:05 m_w, So need to do copy_from_user() and copy_to_user? Jul 21 18:20:15 no Jul 21 18:20:22 not in your code Jul 21 18:20:24 Just get the ioremap to hand out data to the spi core Jul 21 18:20:29 yup Jul 21 18:20:35 Got it. Jul 21 19:02:19 is it just with me ? or google services are really down ? Jul 21 19:03:02 google is working for me Jul 21 19:03:51 Working fine for me too ZeekHuge Jul 21 19:04:58 everything is opening up instantly here .. but not gmail or google.com Jul 21 19:07:05 restarted browser .. working now. 5 windows with i dont know probably 20 tabs in each .. Jul 21 19:19:10 stop stressing that billion lines of c++ code Jul 21 19:19:18 it can only take so much Jul 21 19:22:11 m_w, I can' t seem to understand the part where it gives the message to spi core Jul 21 19:22:13 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L1249 Jul 21 19:23:12 the data is transferred in the spi_transfer struct Jul 21 19:23:59 the tx_buff is filled with the MOSI data Jul 21 19:24:27 the rx_buff need to be filled with the MISO data Jul 21 19:25:25 the len is the length of the transaction Jul 21 19:25:28 http://lxr.free-electrons.com/source/include/linux/spi/spi.h#L731 Jul 21 19:27:20 Okay tx_buf automatically by spi core for us whenever the core calls the tranfer_one? Jul 21 19:27:24 m_w, ^^ Jul 21 19:29:14 So I were to simply write this tx_buf into the memory via ioremap, would it work m_w ? Jul 21 19:51:48 testing testing 1 2 Jul 21 19:51:53 new modem work? Jul 21 19:55:33 I guess so m_w :P Jul 21 19:58:14 m_w, If you there just wanted to ask you:tx_buf automatically by spi core for us whenever the core calls the tranfer_one? Jul 21 19:58:36 is tx_buf called automatically Jul 21 19:58:40 yup Jul 21 19:58:50 So I were to simply write this tx_buf into the memory via ioremap, would it work m_w ? Jul 21 19:59:01 that is the idea Jul 21 19:59:10 Hmmn seems simple Jul 21 19:59:20 But let me try Jul 21 20:00:24 m_w, One more thing :http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L1365 Jul 21 20:00:25 you will have to update the firmware a bit to handle multiple bytes Jul 21 20:00:52 Here the spi_alloc_master is called with Jul 21 20:01:08 the device tree node i.e pdev->dev Jul 21 20:01:20 So What should I do as of now? Jul 21 20:01:43 Should I write say pdev in my case? Jul 21 20:02:20 what kind of probe function do you have? Jul 21 20:02:34 I am just writing it now m_w Jul 21 20:03:06 The probe will be called from the remoteproc's probe function Jul 21 20:03:19 okay Jul 21 20:03:30 So as of need there is no need to get into DT as ds2 told me Jul 21 20:03:46 *now Jul 21 20:04:39 I would get the probe working first and print something using pr_info and then figure out how to get the dev Jul 21 20:05:09 it will likely be passed as argument to your probe function Jul 21 20:07:20 Okay, let me write the code for probe, upload it. Perhaps you could take a look at it tomorrow m_w ? Jul 21 20:07:58 Just one thing this dev are the device parameters right? Jul 21 20:08:22 okay Jul 21 20:08:44 umm Jul 21 20:09:40 I mean what we get from spi_master_get_devdata()? m_w ? Jul 21 20:09:58 https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-device.html Jul 21 20:10:56 this the device struct that is passed Jul 21 20:11:10 http://lxr.free-electrons.com/source/include/linux/spi/spi.h#L398 Jul 21 20:11:22 this is the spi_master struct that is returned Jul 21 20:12:51 http://lxr.free-electrons.com/source/drivers/spi/spi.c#L1731 Jul 21 20:13:06 read the comments it should clear things up Jul 21 20:20:50 So the device struct is already defined in spi_master struct And on calling the spi_alloc_master(), I believe that the dev in the spi_master struct is filled with the data from pdev->dev Jul 21 20:20:57 am I right m_w ? Jul 21 20:21:46 But the question still is where does pdev->dev get its data from? I don't see it declared anywhere in omap2-spi m_w ? Jul 21 20:56:38 the platform registration Jul 21 21:13:48 Hmmn m_w So basically when I am calling the probe from rproc, it would needed to be called with an argument i,e platform device. I guess rproc already has this defined Jul 21 21:28:22 Because it instantiates the PRU right? All I need is to call the probe of my driver with a pointer to that device m_w . Jul 21 21:28:33 Do you think that will work m_w ? Jul 21 21:45:29 yes, using the rproc dev should be fine Jul 21 21:45:37 (for this purpose) Jul 21 21:48:39 Thanks for clearing that up ds2 Jul 21 21:49:26 Just one thing :https://github.com/beagleboard/linux/blob/4.4/drivers/remoteproc/pru_rproc.c#L702 Jul 21 21:49:49 So my call would be something like pru0_spi_probe(pdev)? ds2? Jul 21 21:50:33 yes, probally put it in around line 859 Jul 21 21:50:39 let the rproc stuff set itself up first Jul 21 21:50:50 Yeah got it ds2 Jul 21 21:51:03 This actually feels like cheating :P Jul 21 21:51:06 ds2 Jul 21 21:51:10 it is :D Jul 21 21:51:47 But dw ds2 I will do it the proper way once GSOC is done. I promise you that Jul 21 21:52:28 one step at a time Jul 21 21:53:00 Yup . I had actually not anticipated this while writing the proposal Jul 21 21:53:02 ds2 Jul 21 21:53:16 So that's why this delay has happened Jul 21 21:53:47 real world vs school stuff Jul 21 21:53:55 value of participating in GSoC Jul 21 21:58:46 * nerdboy 's engineering life has closely approximated the ~2.5 rule-of-thumb Jul 21 21:58:59 True that ds2. But I have learnt so much too. My dl/dt might have been a bit less though ,l for learning :P Jul 21 22:00:51 Takes time for me to get a grasp on things. Jul 21 22:36:14 *project estimation rule Jul 21 22:49:09 anybody seen rcn lately? Jul 21 22:50:40 also i made a draft abstract for the uav session Jul 21 22:50:52 oops, wrong channel... **** ENDING LOGGING AT Fri Jul 22 02:59:58 2016