**** BEGIN LOGGING AT Tue Jul 26 02:59:58 2016 Jul 26 07:45:51 Wormo_: nerdboy there ? Jul 26 08:59:51 ZeekHuge ? Jul 26 09:02:59 hmmm missed you again... Jul 26 09:03:11 heading for bed then Jul 26 09:11:04 Wormo_: goof night :) Jul 26 09:11:07 *good Jul 26 15:02:29 foreverska_: can you help with iio drivers ? Jul 26 15:03:28 No promises but lay it on me and I'll see what I know. Jul 26 15:07:18 okay ... so I am trying to understand the use of .. scan_elements/in_voltage0_en Jul 26 15:08:43 foreverska_: ^^ Jul 26 15:09:16 the documentation says that its used to enable the scan _elements for triggered read Jul 26 15:12:19 Right, when you enable scan elements in the filesystem the kernel makes the values available in the fs Jul 26 15:13:49 so we do not need to bind any function for this in our driver ? Jul 26 15:14:16 and if that is true .. why is giving oops when I am writing 1 to it. Jul 26 15:14:18 ? Jul 26 15:14:27 foreverska_: ^^ Jul 26 15:15:15 I don't think so... stupid question are you writing to it as a priviledged user? Jul 26 15:15:16 probably some thing else is messing up... Jul 26 15:15:25 yes Jul 26 15:15:35 let me reboot and try again Jul 26 15:17:25 Yea, it's pretty rare that subsystem fails, have you tried reading it raw? Jul 26 15:19:04 yes . Jul 26 15:19:08 its working now Jul 26 15:19:14 thank you :) Jul 26 15:19:41 lol, glad I could help. Jul 26 15:25:51 foreverska_: and writing 1 to buffer/enable will start the capture ? Jul 26 15:26:19 but it says invalid argument Jul 26 15:26:41 though writing 0 was successful Jul 26 15:27:24 It comes back with invalid argument when you write 1 to enable? Jul 26 15:30:10 is invalid argument when you write to enable or in_voltage0_en? Jul 26 15:32:58 Wait, are you writing 1 to buffer? That may need to be a bit bigger. Jul 26 15:33:35 echo 1 > /sys/bus/iio/devices/iio\:device0/buffer/enable Jul 26 15:33:36 0/buffer/enable Jul 26 15:33:48 -bash: echo: write error: Invalid argument Jul 26 15:34:12 And you're setting up in_voltage0_en and buffer before you enable, right? Jul 26 15:34:13 this is what i am getting ... it should actually start data capture .. isnt it? Jul 26 15:34:50 i am setting in_voltage0_en but .. how to set buffer ? Jul 26 15:35:15 Give it a 100 just for test, you can tune that as you go. Jul 26 15:35:35 it ?? Jul 26 15:35:40 echo 100 > /sys/bus/iio/devices/iio\:device0/buffer/length Jul 26 15:36:54 okay so user sets the buffer length ... Jul 26 15:36:57 got it .. Jul 26 15:40:01 but I am still unable to invoke preenable and such buffer associated function s Jul 26 15:40:04 foreverska_: ^ Jul 26 15:46:34 Oh, you're going through their API. So it works through the FS but not their API? Jul 26 15:48:52 foreverska_: this is the code I am using https://github.com/ZeekHuge/BeagleScope/blob/wip/driver/beaglescope_driver.c#L247 Jul 26 15:49:05 and I am trying to start a buffer capture Jul 26 15:49:24 but note that I havent used any triggers yet Jul 26 15:49:42 not sure if we need triggers on not ... Jul 26 15:54:43 Where is it actually failing? Jul 26 15:55:36 I want to start buffer capture Jul 26 15:56:54 Right, what is the exit condition, how do you know it's failing? Jul 26 16:33:27 anybody worked on kernel drivers? I created sysfs entry for a custom servo driver.. Jul 26 16:33:37 I get the main servo directory in /sys/class/ Jul 26 16:33:48 but I don't get any sysfs entry inside the directory.. Jul 26 16:33:57 can anybody help me out? Jul 26 16:43:26 foreverska_: there needs to be a trigger too .. only then the enabling will work Jul 26 16:43:32 alexhiam: Hi ! there > Jul 26 16:43:35 ? Jul 26 16:43:54 ahoy! at work, but sorta here Jul 26 16:44:28 I am working on the IIO driver for the board . Jul 26 16:44:34 and have some questions Jul 26 16:44:49 so .. the buffer capture always needs a trigger .. Jul 26 16:46:05 you mean in general? IIO drivers can poll as well Jul 26 16:46:05 for a buffered device .. there can actually be no trigger in sense of an external event Jul 26 16:46:45 yeah poll using read_raw ? .. already have that support Jul 26 16:48:01 so like this driver does : https://github.com/beagleboard/linux/blob/d62bb62b198882688c53d685b45967c4087e7668/drivers/iio/adc/ti_am335x_adc.c#L286 Jul 26 16:48:14 do we always need an IRQ ? Jul 26 16:48:28 if yes how to setup an IRQ ? Jul 26 16:48:32 alexhiam: ^ Jul 26 16:52:01 hmm... I'm not really the person to ask... has jic23 been around? Jul 26 16:53:01 that function is for setting up an irq though: https://www.kernel.org/doc/htmldocs/kernel-api/API-request-threaded-irq.html Jul 26 17:54:42 nerdboy: /goto -20 Jul 26 17:54:48 oops hehe Jul 26 17:55:39 ZeekHuge: you got a script checked in that shows exactly what you're doing with the sysfs stuff? Jul 26 17:56:29 Wormo_: ahh ? I was working on the IIO stuff .. Jul 26 17:56:41 IIO sysfs files, right? Jul 26 17:56:49 yes ,, Jul 26 17:57:21 I wanted to take a quick check over before I have to head out to work Jul 26 17:57:35 . /sys/bus/iio/devices/iio:device0 Jul 26 17:58:18 okay ... So its the driver .. I have registered the buffer .. was now going on to get data into it .. after I did some research Jul 26 17:58:45 the latest work is on wip branch Jul 26 17:59:10 actually its not a good correct driver ... and therefore in on wip .. Jul 26 17:59:19 ah Jul 26 17:59:25 right fair enough Jul 26 17:59:30 https://github.com/ZeekHuge/BeagleScope/blob/wip/driver/beaglescope_driver.c Jul 26 18:00:30 was testing the functions .. and when do they actually get called .. so added those 'non-sense empty' functions Jul 26 18:00:52 it's good idea to make stubs first and fill in later Jul 26 18:01:59 as far as the ADC is related .. I haven't touched it .. after ds2 said that it seems to work Jul 26 18:02:10 (and was very happy that it is working ) Jul 26 18:02:15 indeed Jul 26 18:03:51 one cool and awkward thing .. I somewhow caused oops in the evening and immediately after that rebooted it.. and there was no /sys/bus/iio :) Jul 26 18:04:02 rebooted it again .. and it appeared back Jul 26 18:04:12 whoa that is very weird Jul 26 18:04:26 the rpmsg didn't load that one time? Jul 26 18:05:14 since this driver is registered to load when your beaglescope firmware is loaded Jul 26 18:05:34 ahh not sure .. I just loaded the firmware and driver and headed towards /sys/bus/iio Jul 26 18:05:47 i didnt see dmesg Jul 26 18:05:58 and then just rebooted it Jul 26 18:06:23 ok well if you get another weird symptom, stop for a bit and think about what diagnostic data might be collected Jul 26 18:06:46 okay . sure . Jul 26 18:06:56 back to code .. Jul 26 18:07:37 ZeekHuge: do you actually have a pending question currently, or resolved them? Jul 26 18:10:18 just a minute Jul 26 18:11:21 okay I am thinking aloud .. Jul 26 18:11:34 So i need to put data into the iio_buffer ... Jul 26 18:12:09 now I will get the data whenever pru send it and this will invoke that rpmsg_callback Jul 26 18:12:43 yes Jul 26 18:12:59 so, in the postenable function i will reset the iio_buffer (dont know what function to use for this ) Jul 26 18:13:16 and then in the same method, I will send the PRU some configuration data to start sampling Jul 26 18:13:31 now, for every callback there will be 44bytes Jul 26 18:14:04 okay .. so first question .. the value of buffer/length is the capacity of the io_buffer right ? Jul 26 18:14:33 and how can I get that buffer length in the kernel ? Jul 26 18:15:24 probably iio_buffer.length Jul 26 18:15:37 https://www.kernel.org/doc/htmldocs/iio/API-struct-iio-buffer.html Jul 26 18:16:08 Wormo_: ^^ Jul 26 18:16:32 yes looking in the API too :) Jul 26 18:17:22 m_w: ^^ Jul 26 18:18:20 okay so after I have the buffer length .. I will maintain a counter while filling data into the buffer .. Jul 26 18:18:23 yes Jul 26 18:18:54 and how can I reset the iio_buffer in postenable ? Jul 26 18:19:02 its basically a FIFO .. Jul 26 18:19:22 so ? use the normal fifo reset API ? Jul 26 18:19:55 lemme see Jul 26 18:20:59 in the rpmsg_callback, I will use use iio_push_to_buffer API to push data from an array to iio_buffer . Jul 26 18:25:09 and do i actually need to maintain a counter an worry about the length of the iio_buffer ? Jul 26 18:25:10 https://github.com/beagleboard/linux/blob/d62bb62b198882688c53d685b45967c4087e7668/drivers/iio/adc/ti_am335x_adc.c#L185 Jul 26 18:25:42 this driver just puts in the data .. the fifo1count it is using is from the ADC Jul 26 18:27:28 i tried looking into iio_push_to_buffer , and see if the API automatically drops extra data.. but I am not completely able to understand the API Jul 26 18:28:06 basically recursion Jul 26 18:29:17 I am looking for concrete examples in existing iio adc drivers; have you found any particular one useful yet? Jul 26 18:29:23 https://ez.analog.com/thread/64023 Jul 26 18:30:20 https://ez.analog.com/thread/71773 Jul 26 18:32:36 not finding where they continued to work on a iio driver for ADAR7251 though Jul 26 18:41:05 okay so I wll be using iio_buffer_refill( ) as I have only one buffer Jul 26 18:42:08 but still unclear if I need to maintain counter and myself manage iio_push_to_buffer calls and status of the buffer Jul 26 18:43:57 where is this iio_buffer_refill ? I don't see it in linux/iio/buffer.h Jul 26 18:45:05 I was thinking iio_device_attach_buffer() might be more appropriate, look for examples... Jul 26 18:45:10 I have to head out ZeekHuge Jul 26 18:45:27 okay . Jul 26 18:45:33 Wormo_: Thank you. Jul 26 18:46:17 as far as i know, we use iio_push_to_buffer after iio_device_attach_buffer. Jul 26 18:49:30 m_w, There? I have a few doubts Jul 26 18:52:53 I have modified the firmware, but I am not sure with a few things regarding miso transfer Jul 26 18:57:17 alexhiam ^^ Jul 26 19:05:08 chanakya_vc: I am hereish Jul 26 19:06:24 hey m_w , I have a few doubts. I shall write them here. Perhaps you could reply, whenever you are free today. Jul 26 19:08:10 Okay first regarding the spi driver, please take a look here:https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/SPI_Driver/pru0_spi-subsystem.c Jul 26 19:09:14 1) Now I am not sure as how to send in parameters using setup function. I mean where does the spi core write the parameters? Jul 26 19:10:19 Next I am going to be setting up flags which the driver sets as 1 when it has written 1 and then the firmware also writes to a flag when it has written to miso Jul 26 19:11:38 After that the firmware:1) I am not sure as to how I shall take in miso transfer. I mean I would be declaring the pru pin as input, so should I take direct input from the __R31 register? Jul 26 19:12:09 the link:https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/pru0_spi.c Jul 26 19:12:42 alexhiam, mdp,ds2 ,m_w ^^ Jul 26 19:13:08 I am done with SPI, provided this works :P Jul 26 19:14:28 lemme take a look Jul 26 19:19:00 for the PRU firmware R30 is for writing, R31 is for reading Jul 26 19:19:45 so reading the correct bit of R31 will give you the value of MISO input at that particular time Jul 26 19:20:00 Okay m_w , so I can only take input from R31 register right? Jul 26 19:20:06 Got it Jul 26 19:20:32 it looks like you are trying to write to R31 for the chip select which I don't think will work Jul 26 19:20:46 yup I will change that m_w Jul 26 19:20:54 https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/pru0_spi.c#L55 Jul 26 19:21:38 I am also confused as to how to actually take miso input according to cpol and cpha. I mean I can't take values in between clock cycles Jul 26 19:21:51 That would amount to non uniform clock Jul 26 19:22:15 the clocks determine when the values are latched Jul 26 19:22:33 So I am not sure if I take value after the clock toggle is done, whether that would work Jul 26 19:22:37 you read them after the appropriate transition of the clock Jul 26 19:22:38 m_w, ^^? Jul 26 19:23:08 Okay got it. I thought the slave would simply drop the value after the transition Jul 26 19:23:49 Okay. One more thing regarding the firmware. Do you think the way I am setting up flags is the correct way to go? Jul 26 19:23:57 m_w, ^^? Jul 26 19:24:09 look at the bitbanging example on wikipedia for mode 0,0 example Jul 26 19:24:17 https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Jul 26 19:24:17 [WIKIPEDIA] Serial Peripheral Interface Bus | "The Serial Peripheral Interface (SPI) bus is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola and has become a de facto standard. Typical applications include Secure Digital cards and..." Jul 26 19:24:28 https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Example_of_bit-banging_the_master_protocol Jul 26 19:24:28 [WIKIPEDIA] Serial Peripheral Interface Bus#Example of bit-banging the master protocol | "The Serial Peripheral Interface (SPI) bus is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola and has become a de facto standard. Typical applications include Secure Digital cards and..." Jul 26 19:25:09 you are using specific memory locations for configuration registers? Jul 26 19:25:42 that should work Jul 26 19:25:53 Configuration registers== place where cpol and cpha go right? m_w Jul 26 19:25:56 Yes Jul 26 19:26:38 Okay can you take a look at the driver m_w please, if you are free that is? Jul 26 19:26:42 yes Jul 26 19:27:51 the parameter are phase, polarity, frequency, chip select, bits per word, and transaction length Jul 26 19:28:26 m_w, As of now, only working on getting cpol and cpha Jul 26 19:28:34 Rest can be done later. Jul 26 19:28:49 8 bits and fixed frequency of 10 mhz Jul 26 19:29:04 chip select done by the firmware Jul 26 19:29:36 you also want a register that checks the status of the transaction and one the controls the start of the transaction Jul 26 19:30:22 okay, I was thinking that the driver writes to the flag location when it completes writing to the mosi Jul 26 19:30:43 and when it the firmware completed miso, it writes to another mem loc Jul 26 19:30:43 yes something like that Jul 26 19:30:53 polled by the driver Jul 26 19:31:46 m_w, But all this is handeled in the transfer function only, I mean I don't know of any specialized function that does specifically this Jul 26 19:32:23 the tranfer function performs the require communication to perform the transaction Jul 26 19:32:39 it is controller specific Jul 26 19:32:58 m_w, Yes but before writing and reading, it would check these flags Jul 26 19:33:08 I would write a blocking loop Jul 26 19:33:14 so follows the protocol that you have code into the firmware Jul 26 19:33:24 Yes I guess so Jul 26 19:33:31 polling is not a great thing to do in the linux kernel Jul 26 19:33:51 m_w, Okay what would you suggest? Jul 26 19:34:28 I think this will work. Maybe change it later? Jul 26 19:35:08 PRU to ARM interrupt Jul 26 19:35:53 okay so I remove the flags and do the PRU to ARM interrupt? Jul 26 19:36:12 the flags are still necessary Jul 26 19:36:26 but you read them when the interrupt occurs Jul 26 19:36:44 to see what the interrupt was for Jul 26 19:37:06 Okay, so I don't poll the mem locs only read it when the interrupt occurs Jul 26 19:37:19 something like that Jul 26 19:37:32 Okay m_w . Will look into this. Jul 26 19:37:52 My specific question is how to send in values of cpol and cpha Jul 26 19:38:11 Like I know that this happens in setup function Jul 26 19:38:18 okay Jul 26 19:38:38 And the driver will write the values to the mem loc using ioread. Jul 26 19:38:58 I am not sure how does the spi core get the value from the userland Jul 26 19:39:04 *gets Jul 26 19:39:23 Like in case of transfer, it was giving tx_buf and rx_buf Jul 26 19:39:38 yes the setup function will write to the registers based on the parameter that are past to it Jul 26 19:42:19 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L932 Jul 26 19:42:52 l |= OMAP2_MCSPI_CHCONF_POL Jul 26 19:43:04 really didn't understand what this line does^^ Jul 26 19:43:13 m_w, ^^ Jul 26 19:43:43 the spi_device struct with pass the desired parameters to the function Jul 26 19:44:05 then you write your registers accordingly Jul 26 19:44:28 OMAP2_MCSPI_CHCONF_POL is omap2 controller specific Jul 26 19:45:17 you would write the appropriate bits in your defined firmware memory location/register Jul 26 19:51:03 Okay so spi->mode and spi_pol and spi_pha represent what the spi core does m_w ? Jul 26 19:51:23 yes Jul 26 19:51:46 the represent what the spi core wants to do Jul 26 19:51:48 they Jul 26 19:51:54 yeah got it Jul 26 19:52:32 okay, one more doubtm spi-> mode is something different from spi_pol and spi_pha or what? Jul 26 19:53:20 I mean I didn't get the logic there, why two variables, spi->mode and (spi_pol ,spi_pha) Jul 26 19:53:58 they are bitfields in the mode variable Jul 26 19:54:54 http://lxr.free-electrons.com/source/include/linux/spi/spi.h#L147 Jul 26 19:58:03 okay, what's the use of the mode? I mean I get the spi_pol and spi_pha. I think the spi->mode is related to something else other than the cpol and cpha Jul 26 19:58:40 it is a u8 value too Jul 26 19:58:51 u16 sorry Jul 26 19:59:21 Okay I think I get it Jul 26 20:00:06 the defines below the u16 are the possible bitfields Jul 26 20:00:50 Okay so the spi core basically writes the value into the spi->mode using the defined bitfields? Jul 26 20:01:42 I would handle at least the following ones: SPI_CPHA, SPI_CPOL, SPI_CS_HIGH, and SPI_LSB_FIRST Jul 26 20:03:18 m_w, okay. Jul 26 20:04:06 But what I still don't get in the omap thing why are checking for both spi->mode and the required bitfield? Jul 26 20:04:37 I mean are they checking that spi->mode should be defined and not 0? Jul 26 20:06:48 that is checking whether the field bit is set Jul 26 20:07:12 Okay spi->mode is like a register. Okay all clear now Jul 26 20:07:23 yup Jul 26 20:08:15 m_w: we just need to push the data into the iio_buffer to read it from /dev/iio0:device/ right ? Jul 26 20:08:39 ZeekHuge: that is the idea Jul 26 20:09:07 but I am not getting the data out of the device file Jul 26 20:09:08 https://github.com/ZeekHuge/BeagleScope/blob/wip/driver/beaglescope_driver.c#L231 Jul 26 20:09:17 set the buffer length, enable the buffer, and read /dev/iio0:device Jul 26 20:09:21 Last thing m_w , for spi_lsb_first , if it is 0, I need to basically write the entire firmware for MSB first write? Jul 26 20:09:49 *right Jul 26 20:09:52 chanakya_vc: yes Jul 26 20:10:04 chanakya_vc: or make it configurable Jul 26 20:10:42 ZeekHuge: did you define a trigger? Jul 26 20:10:52 Okay, write the option to the shared memory and then let the firmware chose by simple if else would work I guess Jul 26 20:11:32 to start buffer capture : echo 1 > scan_elements/in_voltage0_en && echo 100 > buffer/length && echo 1 > buffer/enable Jul 26 20:11:45 chanakya_vc: yes sounds like the right idea Jul 26 20:11:51 As per the discussion with jic23 that not needed Jul 26 20:12:22 ZeekHuge: okay and how are you accessing the /dev/iio device? Jul 26 20:12:39 as triggers are for per sample. And in my case, I already have a block of data .. so need for per sample trigger Jul 26 20:12:43 cat ? Jul 26 20:13:32 ZeekHuge: cat won't work as it is raw data Jul 26 20:13:44 ZeekHuge: try hexdump -C or similar Jul 26 20:13:54 okay m_w . Thanks for your help. Hopefully after this SPI will be over. Jul 26 20:14:12 m_w, Might need your help with PRU to ARM interrupt Jul 26 20:14:16 chanakya_vc: okay, let me know if you need more testing Jul 26 20:14:50 Wow ! m_w ! you should change your IRC nickname to 'life_saver' Seriously ! Jul 26 20:14:50 I am planning on finishing this in maximum two days. I seriously need to move to I2C now :P Jul 26 20:15:07 xxd -c1 /dev/iio woked Jul 26 20:15:25 woked? Jul 26 20:15:34 *worked Jul 26 20:15:40 what is it printing? Jul 26 20:16:08 root@beaglebone:~# xxd -c 1 /dev/iio\:device0 Jul 26 20:16:09 0000000: 00 . Jul 26 20:16:09 0000001: 00 . Jul 26 20:16:09 0000002: 00 . Jul 26 20:16:09 0000003: 00 . Jul 26 20:16:09 0000004: 00 . Jul 26 20:16:11 0000005: 00 . Jul 26 20:16:13 0000006: 00 . Jul 26 20:16:15 0000007: 00 . Jul 26 20:16:17 0000008: 00 . Jul 26 20:16:19 0000009: 00 . Jul 26 20:16:21 000000a: 00 . Jul 26 20:16:23 000000b: 00 . Jul 26 20:16:25 000000c: 00 . Jul 26 20:16:27 000000d: 00 . Jul 26 20:16:31 000000e: 00 . Jul 26 20:16:33 000000f: 00 . Jul 26 20:16:35 0000010: 00 . Jul 26 20:16:37 0000011: 00 . Jul 26 20:16:53 so you are getting back 0x00 for all of the samples Jul 26 20:17:32 there is also an example userspace program that might help you out Jul 26 20:17:39 http://lxr.free-electrons.com/source/tools/iio/generic_buffer.c Jul 26 20:17:45 yes .. as nothing is on the pru .. Jul 26 20:18:16 also .. how this is just putting the first 32 bits of the data . Jul 26 20:19:59 m_w: it this putting the complete array at once ? https://github.com/torvalds/linux/blob/master/drivers/iio/adc/ti_am335x_adc.c#L191 Jul 26 20:20:13 complete data array .. Jul 26 20:20:34 okay no .. Jul 26 20:20:42 the outer for llop is there .. Jul 26 20:21:20 it is putting one data sample per push Jul 26 20:21:50 so i need a loop for that . No other way i guess. Jul 26 20:21:58 actually @data: Full scan. Jul 26 20:22:21 I think that means 1 data from each channel Jul 26 20:22:50 that is enabled Jul 26 20:24:01 where is the header file ? Jul 26 20:24:16 for? Jul 26 20:24:43 the linux/mfd/ti_am335x_tscadc.h Jul 26 20:25:34 http://lxr.free-electrons.com/source/include/linux/mfd/ti_am335x_tscadc.h Jul 26 20:27:13 okay .. Jul 26 20:39:09 m_w, Okay I got this:http://processors.wiki.ti.com/index.php/PRU-ICSS_FAQ#Q:_How_can_a_PRU_core_interrupt_the_ARM.3F_How_can_the_ARM_interrupt_a_PRU_core.3F Jul 26 20:39:14 hmmmm activity! Jul 26 20:40:00 I am not sure as to how the driver will write to the pru SRSRx register to generate an interrupt Jul 26 20:41:15 ds2, I have got to generate an interrupt from the PRU to the ARM . I am not able to understand how to configure the PRU to generate a system event Jul 26 20:41:37 Like from the above article^^ Jul 26 20:43:29 chanakya_vc: configure the INTC and then write to R31 register , and that will generate interrupt Jul 26 20:45:31 :) Jul 26 20:47:24 chanakya_vc: you need to map the channels and the hosts correctly .. you do this using resource table Jul 26 20:47:45 this is the channel to host mapping Jul 26 20:47:47 https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru1_to_pru0_to_arm/resource_table_pru0.h#L130 Jul 26 20:48:19 which direction do you need the interrupts? ARM->PRU or PRU->ARM? Jul 26 20:49:08 Both ds2 Jul 26 20:49:18 Thanks for the help ZeekHuge Jul 26 20:49:50 Actually I have not had any experience with interrupts Jul 26 20:50:02 chanakya_vc: which PRUSS driver are you using? UIO? old remoteproc, new remote proc? Jul 26 20:50:22 new remoteproc Jul 26 20:50:46 That's what exists in the latest kernel I believe ds2 Jul 26 20:50:56 which kernel is that? Jul 26 20:51:11 4.4.9-r25 Jul 26 20:51:11 I have about 10 versions scattered on different machines Jul 26 20:51:14 ds2 Jul 26 20:51:16 Ohh Jul 26 20:51:45 hmmm that is older but I suspect is the same as 4.7 Jul 26 20:51:56 PRU->ARM is pretty straight forward, you set one of the r3x registers Jul 26 20:52:26 Okay ds2, then? Jul 26 20:52:29 hmmm no remoteproc in the 4.7 tree Jul 26 20:52:36 chanakya_vc: then it happens :D Jul 26 20:52:49 I am not sure how to detect that in the driver? Jul 26 20:53:09 Like how to detect that an interrupt has happened on the ARM side Jul 26 20:53:28 same way you detect any other interrupt Jul 26 20:53:39 if I can find a close enough tree, I can be more specific..... Jul 26 20:53:45 * chanakya_vc has not had a course on micro-controllers so far. Needs to study on interrupts Jul 26 20:55:42 ds2, You don't have 4.4.9 on any of your bbb's? Jul 26 20:55:57 I am still not clear which remoteproc driver but -- it looks like remoteproc should handle it for you Jul 26 20:56:14 chanakya_vc: not that particular one... Ihave 4.7, 3.18, 3.14, 3.2, 3.4, etc :D Jul 26 20:56:25 you got your tree on github yet? Jul 26 20:56:27 Okay wow :P Jul 26 20:56:45 It's an official release from rcn Jul 26 20:57:42 it isn't the top of the RCN tree... in the middle of stuff so Ican't just change it Jul 26 20:57:42 How do you not get confused which version you are working on. I mean I had so many problems cross compiling because of vermagic strings ds2 Jul 26 20:58:03 they are not that different Jul 26 21:01:13 ds2, How do you figure out the difference between old and new remoteproc? Perhaps if you could tell me, I could surely tell you the exact remoteproc I have Jul 26 21:02:53 chanakya_vc: read the source Jul 26 21:02:53 :D Jul 26 21:03:27 Okay ds2 :P Jul 26 21:05:57 ds2 wget https://github.com/RobertCNelson/linux-stable-rcn-ee/archive/4.4.9-ti-r25.tar.gz Jul 26 21:06:08 If you want to see it **** ENDING LOGGING AT Wed Jul 27 02:59:58 2016