**** BEGIN LOGGING AT Fri Jul 29 02:59:58 2016 Jul 29 03:14:29 m_w, I have sent you the patch Jul 29 03:15:11 Also working on getting that tree up Jul 29 03:15:22 okay Jul 29 03:15:46 Please mail me as when you can test it out Jul 29 03:15:49 m_w, Jul 29 03:15:58 okay Jul 29 03:16:58 m_w, You might need to use configure-pin to configure pins Jul 29 03:17:12 I can do that Jul 29 03:17:13 Like configure-pin P8_11 pruout Jul 29 03:17:32 Okay thank you so much for your help!! Jul 29 03:17:38 yeah I had to do that for the beaglescope testing too Jul 29 03:17:48 Ohh Jul 29 03:18:11 I hope that my code works too. Jul 29 03:18:32 well the one liner patch looks pretty simple Jul 29 03:20:02 but I am guessing it will have a problem finding the symbol Jul 29 03:20:13 :( Jul 29 03:20:49 whats the way out then m_w ? Jul 29 03:21:35 putting your driver in the kernel tree perhaps Jul 29 03:25:02 okay the same way what ds2 was suggesting then? Like clone a working tree and then making changes to a branch Jul 29 03:25:07 m_w, ^^ Jul 29 03:25:14 yeah Jul 29 03:25:29 Okay I will do that today m_w . Jul 29 03:25:55 So I would first clone a tree in my repo on github Jul 29 03:26:10 and then make a branch..clone it to my machine Jul 29 03:26:22 and then make changes and push them back right? Jul 29 03:26:28 there are few ways to do it Jul 29 03:26:53 Okay my net speed sucks so I want to avoid cloning to my machine Jul 29 03:27:17 m_w, Any way which doesn't invlove that? Jul 29 03:27:36 not really Jul 29 03:27:58 don't you already have a repository locally though? Jul 29 03:28:12 the kernel repository Jul 29 03:28:23 no I downloaded the tar version of it Jul 29 03:28:32 so the repo doesn't exist Jul 29 03:28:37 did wget Jul 29 03:28:41 ah Jul 29 03:29:07 that is gonna make things difficult Jul 29 03:29:12 Should have realized it then m_w Jul 29 03:29:33 Arre no problem. If this is the only way I will do it Jul 29 03:29:47 how did you create this patch? Jul 29 03:30:04 I extracted the tar Jul 29 03:30:08 then git init Jul 29 03:30:18 in the folder Jul 29 03:30:22 git add -A Jul 29 03:30:27 ah Jul 29 03:30:31 then changed the file Jul 29 03:30:35 then git diff Jul 29 03:30:46 makes sense Jul 29 03:31:53 You see there is no difference between the source I have locally and that which is on github Jul 29 03:31:58 do you have a place to go that has a better internet connection Jul 29 03:32:00 ? Jul 29 03:32:13 Yeah I can go to my college Jul 29 03:32:16 and do it there Jul 29 03:32:23 okay good Jul 29 03:32:26 But that I can do only tomorrow Jul 29 03:32:41 the kernel can wait till tomorrow Jul 29 03:33:01 Right now 9 am here.And I am dropping with sleep :P Jul 29 03:33:01 I should be able to piece together from what you gave me Jul 29 03:33:14 go to sleep then Jul 29 03:33:15 Okay m_w . Jul 29 03:33:49 I can't . I am sleepy but too excited at the same time :P Jul 29 03:34:08 m_w, I need to know whether it will work or not :P Jul 29 03:34:59 okay lemme work on it a bit now then Jul 29 03:35:10 Childlike enthusiasm is still alive :p Jul 29 03:35:52 Okay m_w . I can keep awake for maybe an hour I think Jul 29 03:44:31 network dropped me again :/ Jul 29 04:08:47 Hey m_w Any luck? Jul 29 04:16:56 not yet Jul 29 04:17:37 Okay m_w . Am going to sleep. Will talk to you tonight. Jul 29 04:17:51 Bye and thanks once again!! Jul 29 04:18:28 Meanwhile I will continue to work on the I2C firmware Jul 29 06:55:45 ZeekHuge... 600k! Not a bad start at all. Jul 29 06:56:03 Morning jic23 ! Jul 29 06:56:26 Few quick thoughts on absolutely nailing down bottlenecks... Jul 29 06:56:27 I am working on it ... I think it can go a bit more higher. Jul 29 06:56:42 Cool aim is a lot higher :) Jul 29 06:57:13 jic23: Just one reminder, I haven't received any main. Can you please check . Jul 29 06:57:36 *mail Jul 29 06:58:01 Does the interrupt rate /proc/interrupts correspond to what you get just hammering rpmsg? I think you tested that a while back.. Jul 29 06:58:26 Hmm original mail had a typo in address. Maybe there were two! Jul 29 06:58:59 ahh .. no i didnt check that /proc/interrupt thing. Jul 29 06:59:57 Maybe a test to run... There are other overheads here obviously! Jul 29 07:00:37 Mail had a garbage additional address so was stuck in outbox. Think it has finally sent now. Jul 29 07:00:47 Thanks for following up! Jul 29 07:01:11 Other easy one is reduce message size. Jul 29 07:02:03 Can't trivially increase it so let's go the other way. Should give some feel for benefits available... Jul 29 07:02:20 From increasing. Jul 29 07:03:46 Plus try doubling overhead in driver for equivalent that end... Can push all data twice for starters to check that loop isn't the bottleneck. Jul 29 07:05:36 As a side note there to abhishek beagle logic has come up a couple of times on kernel-summit discuss list... Jul 29 07:07:33 I haven't dug into the code but to speed up rpmsg it might be possible to do what network drivers do and switch to a polled mode when interrupt rate gets too high Jul 29 07:07:40 okay so first - interrupts in /proc/interrupts and then message length. Jul 29 07:08:24 jic23: These two ^^ things to test. roght ? Jul 29 07:08:43 Also afraid I am going to be offline more or less from tomorrow until the 15th (the reason I didn't want to mentor formally!) Jul 29 07:10:06 ZeekHuge, yeah but quick and dirty numbers will be fine. It's to guide your work a little rather than an end in itself. Might make a decent blog post if you want to do it a little more thoroughly. Jul 29 07:12:31 okay . Jul 29 08:05:19 jic23: I got it upto 900900Hz it did hang a bit, but worked for about 3 seconds. Then I tried 1Mhz and the board just freezed up and rebooted. Jul 29 08:08:01 and the way I am testing it is echo 1 > buffer/enable && sleep 3 && echo 0 > buffer/enable. while in the other terminal ' watch -n0.1 --no-title cat /proc/interrupts' and noting down the initial and final interrupt number Jul 29 08:08:12 any better and more accurate way to do this ? Jul 29 08:08:15 Wormo_: ^ Jul 29 08:08:21 nerdboy: ^ Jul 29 10:44:08 jic23: there ? Jul 29 11:19:32 tests : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/interrupt_frequency_beaglescope_driver.txt Jul 29 14:38:10 Wormo_ there ? Jul 29 14:38:15 ds2: ? Jul 29 18:31:55 Hey m_w , There? Jul 29 18:34:03 I have made some changes to the driver. I think it should work now Jul 29 18:34:24 you apply the changes that I sent? Jul 29 18:36:58 yup Jul 29 18:37:19 did you get the driver to probe? Jul 29 18:38:22 I got everything in that except as to the part #address cell and # size cell thing Jul 29 18:38:32 in the device tree Jul 29 18:43:09 Just give me a sec m_w . I am doing it right now. I spent the entire day just reading about device tree Jul 29 19:14:19 m_w, I did everything. Jul 29 19:14:35 Where would it show up as a device? m_w Jul 29 19:14:42 I am not sure Jul 29 19:15:31 towards the userland side, it would use spidev right? Jul 29 19:15:57 yes I added a spidev registration Jul 29 19:16:45 so it should have a spidev node and entries /sys/bus/platform Jul 29 19:21:35 Yeah I can see the entries in /sys/bus/platform Jul 29 19:21:36 m_w, Jul 29 19:21:58 pru0_spi_vc? Jul 29 19:22:19 yup Jul 29 19:22:37 in drivers Jul 29 19:22:41 m_w, Jul 29 19:22:50 okay do you see the /dev/spidev3.0 node? Jul 29 19:23:10 yup Jul 29 19:23:31 So echo and read from this node Jul 29 19:23:32 ? Jul 29 19:23:39 m_w, Jul 29 19:23:52 no Jul 29 19:24:13 Some protocol driver will use this node Jul 29 19:24:13 you will need a program to access the device node Jul 29 19:24:17 Right Jul 29 19:24:23 Okay Jul 29 19:24:33 luckily for you I have such a program already Jul 29 19:24:44 Okay.. Jul 29 19:24:58 https://github.com/mwelling/spi-test Jul 29 19:25:14 you can build it right on the target Jul 29 19:25:34 git clone https://github.com/mwelling/spi-test.git Jul 29 19:25:39 cd spi-test Jul 29 19:25:41 make Jul 29 19:28:17 done Jul 29 19:28:36 try it out Jul 29 19:29:00 Don't have an oscilloscope to see the output Jul 29 19:29:05 But I can try Jul 29 19:29:20 to send the command to see if it works Jul 29 19:29:49 you can loop back the MOSI to the MISO and see if it returns what is sent perhaps Jul 29 19:31:18 yup I think it is working Jul 29 19:32:45 dev/spidev3.0 -l 1 -m 12AB Jul 29 19:32:46 Sending to /dev/spidev3.0 at 8000000 Hz Jul 29 19:32:46 MOSI MISO Jul 29 19:32:46 12 : 4D Jul 29 19:32:48 m_w, Jul 29 19:33:13 Though I don't get how is it getting MISO Jul 29 19:33:54 that is what your driver is returning Jul 29 19:35:28 did you configure the pru lines? Jul 29 19:35:29 It is always returning 4D only...must be some garbage value left in the miso section Jul 29 19:36:57 Ohh...no I didn't. But even then the transfer function wouldn't complete without miso be written by the firmware Jul 29 19:37:05 there is a blocking loop Jul 29 19:37:22 So that the firmware first writes miso Jul 29 19:37:32 and then the driver reads it Jul 29 19:37:52 m_w, It would be best if I tested this with a oscilloscope Jul 29 19:38:02 I will go to my lab tomorrow and then do it Jul 29 19:40:00 Also here I am not calling the setup function? I am not giving the values for cpol, cpha and all m_w Jul 29 19:41:22 setup should be called by the spi core Jul 29 19:41:58 you can add a pr_info to the setup function and see if it shows in the kernel messages Jul 29 19:42:52 But values of these parameters have to come from user-land right? Like the protocol driver dictates the parameters? Jul 29 19:43:01 btw you show replace printk(KERN_INFO with pr_info Jul 29 19:43:12 Okay m_w Jul 29 19:43:50 how's pr_info different from printk m_w ? Jul 29 19:44:13 it is the new way of doing it Jul 29 19:44:22 Ohh.. Jul 29 19:44:28 same thing but new sytle Jul 29 19:44:33 style Jul 29 19:45:28 pr_debug, pr_err, pr_info Jul 29 19:45:46 http://lxr.free-electrons.com/source/include/linux/printk.h#L263 Jul 29 19:46:24 Okay m_w Jul 29 19:47:27 m_w, I still don't get how are we going to be setting the values of all parametres from the userland? Or SPI-core has some default values it gives? Jul 29 19:47:49 Because the firmware won't work otherwise Jul 29 19:50:05 the mode is 0,0 by default Jul 29 19:50:53 And what about LSB first and CS ? m_w Jul 29 19:51:28 So the spi core will call setup on its own Jul 29 19:51:46 I think so Jul 29 19:52:29 https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/SPI_Driver/pru0_spi-subsystem.c#L88 Jul 29 19:52:49 you have to handle more than just one byte per transfer Jul 29 19:53:17 https://www.kernel.org/doc/htmldocs/device-drivers/API-struct-spi-transfer.html Jul 29 19:53:46 there is a length of the buffer Jul 29 19:53:57 len Jul 29 19:56:53 m_w, that will be a problem Jul 29 19:57:19 um why? Jul 29 19:57:27 Because then ioread and iowrite at the moment are configured for transferring 8 bits Jul 29 19:57:56 and then the buffers I am using are also allocated for sending 8 bits Jul 29 19:57:57 try a for loop perhaps? Jul 29 19:59:51 Hmmn, that also has problems. Then their will be a timing issue with the firmware. Jul 29 19:59:53 It can be done m_w Jul 29 20:00:09 But I would have to modify a major chunk of my code Jul 29 20:01:19 hmmn I will ask mdp, if I can maybe only do a single byte transfer for the moment Jul 29 20:01:36 you could reserve a portion of the shared memory for multiple word transactions Jul 29 20:05:04 Yes I could m_w . I would have to rewrite the for loops in my firmware. ah maybe a switch statement could decide which kind of loops I am going to be using. Jul 29 20:05:35 But it will take time m_w . I think I should get I2C up first Jul 29 20:06:48 I really think that you need to have something that works before switching to i2c Jul 29 20:11:13 m_w, Okay. I will do it Jul 29 20:11:33 But I need to be sure that what right now workd Jul 29 20:11:36 works Jul 29 20:11:53 Like even for a single byte transfer Jul 29 20:14:40 good idea Jul 29 20:15:38 m_w, I would request you to please test out my code for a single byte transfer whenever you can. I will also go to college tomorrow and do it. But you seem to have a much better hang of testing than I do Jul 29 20:17:02 sure I can try it with the scope today Jul 29 20:18:31 But MISO will be issue therem Jul 29 20:18:34 m_w, Jul 29 20:18:47 Nobody to talk back to the PRU there Jul 29 20:19:16 Hmmn I can modify the firmware if you want? Jul 29 20:19:39 Like make make mosi=miso m_w ? Jul 29 20:19:48 ah miso=mosi Jul 29 20:20:27 I can test it Jul 29 20:21:34 Okay m_w . Please do mail me or perhaps you could take a video. As you wish Jul 29 20:21:57 no problem Jul 29 20:23:10 m_w, I will talk to bradfa and mdp and ask them about this multiple byte transfer thing and also about other features they would expect I finish Jul 29 20:23:29 good idea Jul 29 20:23:49 Okay m_w . Jul 29 20:24:07 Thanks a lot for your help. I would be totally lost without your help Jul 29 20:24:24 np Jul 29 20:25:29 And m_w I have modified the driver a bit again right now. So you would have to git pull again I guess Jul 29 20:25:42 okay Jul 29 21:00:36 Jul 29 21:01:32 ds2: no hmmmmm? Jul 29 21:07:54 lol m_w Jul 29 21:08:46 I have again pushed some changes. Some how my earlier commit didn't make the necessary change Jul 29 21:08:53 m_w, Jul 29 21:09:14 Sorry for the inconvenience. Jul 29 21:17:32 np Jul 29 21:20:23 /root/PRU-I2C_SPI_master/SPI_Driver/pru0_spi-subsystem.c:104:11: error: ‘miso_flag’ undeclared (first use in this function) Jul 29 21:23:19 Ah just one sec Jul 29 21:27:05 Pushed changes should compile now m_w Jul 29 21:27:14 Please tell me if it doesn't Jul 29 21:28:18 Just wait m_w one more mistake I found Jul 29 21:31:14 okay m_w all done Jul 29 21:31:26 Should compile now without any problems Jul 29 21:31:43 okay Jul 29 21:31:46 I messed up on one of my commits that's why the error. Jul 29 21:56:00 the console locks up when I do a transfer Jul 29 21:58:16 the clock continues to toggle Jul 29 22:02:58 hmmnn..okay locks up means MOSI is not being shown by the oscilloscope m_w ? Jul 29 22:05:38 lemme see Jul 29 22:07:09 the mosi toggles only with the first set of clock pulse Jul 29 22:07:34 then the clock keeps going forever and the mosi stops toggling Jul 29 22:07:44 Okay m_w If there is no miso response it is possible that the transfer function won't complete Jul 29 22:08:05 that is not how SPI works Jul 29 22:08:36 do not make any assumptions on the behavior of MISO/MOSI Jul 29 22:08:52 Okay so even if no miso response the transfer function would still complete. Jul 29 22:09:04 yes Jul 29 22:09:12 some devices are write only Jul 29 22:09:16 this is the SPI master Jul 29 22:09:17 others are readonly Jul 29 22:09:27 it controls the transaction Jul 29 22:09:52 But MOSI should work correctly. It is not displaying what you are sending from the console right? m_w Jul 29 22:10:09 Can you upload just a picture Jul 29 22:10:19 the console is locking up Jul 29 22:10:57 it displays the correct MOSI output on the scope one time Jul 29 22:11:12 but then the clock keeps going forever Jul 29 22:11:34 Okay that means the driver is communicating with the firmware correctly Jul 29 22:11:34 and linux locks up Jul 29 22:11:43 I know what the problem is m_w Jul 29 22:11:51 Three actually: Jul 29 22:12:21 1)First the transfer function never completes . I will rectify this Jul 29 22:12:33 This is why console is hanging up Jul 29 22:13:31 2) The clock is going on forever because I have put the entire function in a while 1 loop. It's a logical error on my part Jul 29 22:13:53 So two only. Jul 29 22:13:56 while(!(*miso_flag)); <===== perhaps this!!! Jul 29 22:14:04 Yes Jul 29 22:14:41 Ah it won't take me much time to rectify this, will you up online for some more time m_w ? Jul 29 22:16:11 yes Jul 29 22:20:37 m_w, Hmmn but if there is no miso response, do I need to tell the userland that there was none? Jul 29 22:21:10 whatever is returned Jul 29 22:21:32 if you read 0's, return 0. if you read 0xff, return 0xff, if you read .... return .... Jul 29 22:21:33 :D Jul 29 22:21:59 there is no handshaking with SPI Jul 29 22:22:49 yeah okay no miso response will be 0 Jul 29 22:22:53 true that Jul 29 22:23:07 just return the value no matter what it is Jul 29 22:23:11 that is all Jul 29 22:25:57 do not modify the value Jul 29 22:26:08 you are never setting miso_flag=1 in the firmware Jul 29 22:30:25 yes Jul 29 22:30:30 I noticed that Jul 29 22:31:03 Also m_w after we have started transferring we wouldn't want to change the cpol and cpha right? Jul 29 22:31:30 probably not Jul 29 22:31:53 Okay just a moment Jul 29 22:36:35 okay m_w made changes to the firmware Jul 29 22:36:40 should work this time Jul 29 22:38:28 Just wait again m_w Jul 29 22:38:31 one moment Jul 29 22:39:47 hangs still Jul 29 22:44:57 Okay made more changes Jul 29 22:45:21 m_w, Jul 29 22:47:45 Please check . If this does not work, then the problem is something else itself Jul 29 22:51:20 I think atleast the clock would not be going infinitely now Jul 29 22:51:24 still hangs Jul 29 22:51:31 I think I see an issue Jul 29 22:51:34 :( Jul 29 22:51:41 Ah what? Jul 29 22:52:02 while(!(*miso_flag)); <==== Jul 29 22:52:17 But i am setting the miso fag 1 Jul 29 22:52:21 flag Jul 29 22:52:27 try this : while(!ioread8(miso_flag)); Jul 29 22:52:30 1 by the firmware Jul 29 22:52:52 or read relaxed Jul 29 22:53:13 Yeah that is an issue m_w Certainly m_w Jul 29 22:53:34 :) Jul 29 22:55:40 got another update? Jul 29 22:57:17 :P Jul 29 22:57:23 yup Jul 29 22:57:28 just one moment Jul 29 22:57:38 lemme give it a whirl Jul 29 23:00:19 still hangs Jul 29 23:00:45 you didn't do the change I suggested Jul 29 23:01:22 ya just pushed it Jul 29 23:01:24 sorry Jul 29 23:01:27 okay Jul 29 23:01:32 trying again Jul 29 23:01:33 my net is behaving weirdly Jul 29 23:01:50 Debugging is so much fun :P Jul 29 23:03:16 you fixed it wrong Jul 29 23:03:27 you have to do the ioread in the loop Jul 29 23:03:28 :( Jul 29 23:03:52 the variable is not going to update itself Jul 29 23:04:12 while(!ioread8(miso_flag)); Jul 29 23:04:55 ahh so sorry m_w . I don't know what is wrong with me today Jul 29 23:07:29 you may also want to add a timeout to the loop so the kernel doesn't hang when the firmware is not responding as expected Jul 29 23:11:22 Changed it the way you have said Jul 29 23:11:24 m_w, Jul 29 23:11:39 And pushed Jul 29 23:15:15 I don't think you would have ever compiled one code so many times m_w . Jul 29 23:16:14 okay I see another issue in the firmware Jul 29 23:16:28 what m_w ? Jul 29 23:17:04 miso_flag need to be set to 0 in the beginning of the loop Jul 29 23:17:25 (for future purposes - busy wait is not a good thing in the kernel) Jul 29 23:17:38 certainly not Jul 29 23:18:08 *mosi_flag=0; Jul 29 23:18:17 after the following line: Jul 29 23:18:35 while ((*mosi_flag == 0)) ; Jul 29 23:18:52 m_w, The driver sets the miso flag back to 0 after it writes Jul 29 23:18:56 reads Jul 29 23:18:59 sorry Jul 29 23:19:08 oh it does? Jul 29 23:19:12 from the shared memloc Jul 29 23:19:40 if (miso != NULL) { Jul 29 23:19:41 *rx_buf = ioread8(miso); Jul 29 23:19:41 iowrite8(miso_flag_val, miso_flag); //set value for the flag back to 0 Jul 29 23:19:41 } Jul 29 23:19:54 ah Jul 29 23:20:01 lets try this puppy Jul 29 23:21:05 root@beaglebone:~/PRU-I2C_SPI_master/SPI_Driver# ~/spi-test/spi_test -d /dev/spidev3.0 -m de -l 1 Jul 29 23:21:08 Sending to /dev/spidev3.0 at 8000000 Hz Jul 29 23:21:11 MOSI MISO Jul 29 23:21:13 DE : 00 Jul 29 23:21:17 it came back!! yay!! Jul 29 23:21:27 finally Jul 29 23:21:41 Thank God it worked Jul 29 23:22:40 m_w, Maybe upload a pic with the waveforms Jul 29 23:22:50 I would like to show my profs and friends Jul 29 23:23:11 okay lets loop the MOSI to MISO and see if it returns what we sent Jul 29 23:23:35 yeah that would be awesome if it does Jul 29 23:24:40 MOSI MISO Jul 29 23:24:40 DE : 6F Jul 29 23:25:38 okay this is in he right m_w ? Jul 29 23:25:42 hex Jul 29 23:25:44 6f = de >> 1 Jul 29 23:25:56 yeah I got that :( Jul 29 23:28:20 m_w, When you echo in hex it will send in the ascii value right? Jul 29 23:28:46 echo does not work Jul 29 23:30:05 I am sorry when you transmit in hex so itgoes as hex to the my driver or does it go in ascii Jul 29 23:30:14 spidev uses ioctl calls Jul 29 23:33:39 m_w, Can you please send in something else and check it it is the same error with all the numbers sent in Jul 29 23:33:40 ? Jul 29 23:34:50 MOSI MISO Jul 29 23:34:50 02 : 01 Jul 29 23:35:12 it is always shifting right by one Jul 29 23:43:56 you may want to add back the: miso &= ~(bit); Jul 29 23:44:22 or clear miso before the transaction starts Jul 29 23:45:39 miso is being cleared at the bottom when everything is read in the loop Jul 29 23:46:00 okay Jul 29 23:46:02 I can't think of any reason why an extra shift is comming from Jul 29 23:46:57 it may be progation delay from MOSI to MISO Jul 29 23:47:30 to really test this I will have to use an actual SPI slave device Jul 29 23:48:33 perhaps I can whip something up in my FPGA Jul 29 23:54:13 hmmn propagationdelay will give a constant error m_w ? Jul 29 23:54:40 May be you are right. Because I can't think ofany error in my logic Jul 29 23:58:48 m_w, I have to sleep now as I have to go to college in about 4 hours. If you get anything please do inform me via mail Jul 29 23:59:00 Thanks once again m_w ! Jul 29 23:59:51 If you are online tomorrow, I will talk to you then m_w Jul 30 00:03:11 later **** ENDING LOGGING AT Sat Jul 30 02:59:58 2016