**** BEGIN LOGGING AT Mon Jul 22 03:02:02 2019
Jul 22 07:53:15 <zeekhuge[m]> pranav_kumar: You do understand that CALL is not a real instruction. right ?
Jul 22 08:16:50 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: You do understand "> @ZeekHuge_:matrix.org: Thanks for the suggestion. Then, can you please suggest anything like that work like call instructions ,as every time i am putting the delay i have to make function with new name
Jul 22 08:24:38 <zeekhuge[m]> pranav_kumar:  No. What I meant was, the CALL is not a real PRU instruction. It gets resolved to JAL instruction. The JAL instruction jumps to the given location, a subroutine, and saves the current + 1 address (the address it will return to when after completing the subroutine) in a register.
Jul 22 08:25:38 <zeekhuge[m]> So, if you do a CALL inside a subroutine that was CALL-ed, then the return address in the register is changed. And hence it will never be able to return back to the first CALL instruction.
Jul 22 08:28:59 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar:  No. What I meant "> Thanks for the suggestion i will try that and update you regarding that
Jul 22 08:37:34 <zeekhuge[m]> pranav_kumar: I remember their was some assembler directive that could loop the code. I don't remember what it was exactly, but maybe you could look into the Assembler guide.
Jul 22 08:38:09 <pranav_kumar[m]> <zeekhuge[m] "So, if you do a CALL inside a su"> As for example, i will have use return address inside that call instructions to so that return pointer get position inside that call function
Jul 22 08:39:48 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: I remember their w"> Yes , there is a LOOP instructions set listed in PRU assembly user guide
Jul 22 08:44:19 <zeekhuge[m]> Ah, so think of how nested method calls work in C++. The program maintains a stack, and puts the return-address it jumped from, each time it jumps. And this stack has length > 1, so you can have multiple nested jumps. When a routine is completed the program will simply pop the address and jump back to that. In case of `CALL` instruction, this stack size (it uses a register here) is 1. So, you can not make nested
Jul 22 08:44:20 <zeekhuge[m]> calls to different subroutines. (of course, if you make your own stack, then you can, but thats not worth doing).
Jul 22 08:45:01 <zeekhuge[m]> pranav_kumar: makes sense ?
Jul 22 08:45:59 <zeekhuge[m]> this LOOP, IIRC is an assembler directive, and not a PRU instruction. So you need to be careful when using it.
Jul 22 08:47:28 <zeekhuge[m]> also, forget about the CALL instruction. Read about JAL instruction. CALL uses JAL internally.
Jul 22 08:48:07 <zeekhuge[m]> JAL must be their in the PRU assembly guide.
Jul 22 08:52:07 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: makes sense ?"> Ok i will try to use jal instructions on the previous code and update you regarding its progress
Jul 22 08:52:47 <pranav_kumar[m]> <zeekhuge[m] "JAL must be their in the PRU ass"> Yes JAL nad JMP are there in the guide
Jul 22 09:03:06 <zeekhuge[m]> > Ok i will try to use jal instructions on the previous code and update you regarding its progress
Jul 22 09:03:07 <zeekhuge[m]> No. I am not asking you to use JAL. Ah. What you need to understand is the working of these instructions. And that nested calls to different subroutines would require more than just using JAL or JMP or CALL instruction. And that you need to weigh in if that effort is worth doing. And then make your code according to that.
Jul 22 09:16:12 * zeekhuge[m] is watching chandrayaan2 launch
Jul 22 09:29:46 <embden> hi, julieng sstabellini. It is interesting why can't Linux find an irq domain for the crossbar. Does xen modify something in device tree?
Jul 22 10:00:34 <zeekhuge[m]> pranav_kumar: It's not about being slow. It will require you to kind of maintain a stack to get nested subroutine work. I don't think its worth putting efforts. Simply, write the code which won't require nested subroutine calls. At max one CALL, and no nesting int that.
Jul 22 10:11:03 <pranav_kumar[m]> <zeekhuge[m] "pranav_kumar: It's not about bei"> Then , the type of code i had already written it yesterday , i am just testing the complete code on the boards
Jul 22 10:26:50 <embden> test
Jul 22 10:27:49 <embden_new[m]> hello, my ssd has died and now I have a new account in matrix
Jul 22 10:28:31 <embden_new[m]> julieng:  ^
Jul 22 14:15:55 <julieng> embden_new[m]: Dom0 device-tree is based on the host device-tree with some not removed/rewritten.
Jul 22 14:16:44 <julieng> embden_new[m]: IIRC, you rewrote the crossbar node in the Dom0 DT. Did Linux detect that node?
Jul 22 14:20:31 <embden_new[m]> julieng:  I believe so, because, it complains: irq: no irq domain found for crossbar !
Jul 22 14:24:01 <julieng> embden_new[m]: Possibly. The best way would be to add debug message in the crossbar driver. So you can see what happen.
Jul 22 14:45:02 <embden_new[m]> ok
Jul 22 15:35:13 <embden_new[m]> julieng:  at least irqcrossbar_init,  crossbar_domain_alloc  and allocate_gic_irq are not called
Jul 22 15:35:49 <embden_new[m]> julieng:  at least irqcrossbar_init,  crossbar_domain_alloc  and allocate_gic_irq are not called
Jul 22 15:35:51 <embden_new[m]> julieng:  at least irqcrossbar_init,  crossbar_domain_alloc  and allocate_gic_irq are not called
Jul 22 15:39:24 <julieng> embden_new[m]: irqcrossbar_init not called clearly means the crossbar node was not found in the Device-Tree.
Jul 22 15:39:32 <julieng> I would recommend to check again how the node is created by Xen.
Jul 22 15:41:03 <embden_new[m]> ok, I will check it today in few hours. What should I do with that patch on hyp mode? There was a messages in ML
Jul 22 15:41:04 <embden_new[m]> julieng: ^
Jul 22 15:50:29 <julieng> embden_new[m]: It would be good to get more input from the other mentors. So I would give a good kick to the other mentors.
Jul 22 15:51:02 <jkridner> vaishnav98_[m]: you around?
Jul 22 15:51:21 <jkridner> I haven't seen any reply, so I'm looking to extend the request.
Jul 22 15:51:36 <jkridner> I'm trying to think through a bit more how greybus should be used for us....
Jul 22 15:51:56 <jkridner> have you tried doing a simple LED blink as a GPIO yet?
Jul 22 15:54:46 <embden_new[m]> julieng:  ok, got it.
Jul 22 15:58:32 <vaishnav98_[m]> jkridner: I'm here,  currently I am able to parse platform data for greybus nodes from device tree and pass it to the corresponding driver, I have tried to get the oledc click up through this method, but I am using a fbtft_platform_data struct at gb_spilib.c attaching the platform data, can you recommend or point me to an example where the platform_data under the spi_board_info can be populated without knowing the
Jul 22 15:58:33 <vaishnav98_[m]> corresponding device_platform_data struct beforehand
Jul 22 16:00:49 <jkridner> can you try to export a simple gpio first?
Jul 22 16:00:58 <jkridner> that is pretty easy, no?
Jul 22 16:01:33 <jkridner> I know it doesn't solve the problem of getting the drivers to load easy, but making sure you can get all of the resources to show up on the "host" would be useful.
Jul 22 16:01:46 <jkridner> so, gpio first.... then spidev....
Jul 22 16:02:11 <jkridner> then,  you might need to make a new "protocol class" driver that combines the resources to build the platform data.
Jul 22 16:02:48 <vaishnav98_[m]> <jkridner "have you tried doing a simple LE"> jkridner: yes , on loading a gpio manifest blob the user LEDs and two P9 header pins are attached to a new   gpiochip506 virtual greybus device, and I can export and control the gpios via sysfs like normal gpios
Jul 22 16:03:16 <jkridner> cool. same for spidev?
Jul 22 16:04:17 <jkridner> the thing is, greybus just gives us transports for these interfaces and the manifests don't provide a generic way of building all the necessary platform data for these drivers....
Jul 22 16:05:02 <jkridner> so, I think we'll need to make a new driver that adds reset and irq gpios to the platform data.
Jul 22 16:05:31 <jkridner> they can still be generic if the members of the various iio device drivers use the same entries for the irq/reset gpios.
Jul 22 16:07:06 <vaishnav98_[m]> jkridner: yes same for spidev also , I also performed a loopback test on the virtual spidev3.0 created by greybus like this: all the transfers on the gb-spi(say spidev3.0) is directed to a hardware spidev1.0 , I connected the SDI and SDO pins together for the hardware SPI and performed a spidev loopback test on spidev3.0 and all the data transferred was received back correctly
Jul 22 16:08:29 <vaishnav98_[m]> <jkridner "so, I think we'll need to make a"> jkridner: is it like the fbttft_device driver which can be used to instantiate the fbtft displays
Jul 22 16:10:12 <pratimugale[m]> zeekhuge abhishek_ Yesterday, I was able to remove all the bugs I was facing and generate waveforms according to samples sent with adjustable time period, https://www.youtube.com/watch?v=3A2SspbW3k8, here 1s. Today I tried adding another channel to it but it still requires some more work. Also, the wave sample integer values need to be 'kicked' multiple times to be written into the PRU DRAm. Right now I'm trying
Jul 22 16:10:12 <pratimugale[m]> to do so in one go
Jul 22 16:10:37 <pratimugale[m]> Or is it recommended to send multiple messages?
Jul 22 16:11:31 <Abhishek_1> GitHub is down, I can't see the code.
Jul 22 16:12:33 <vaishnav98_[m]> <jkridner "so, I think we'll need to make a"> jkridner: should this driver be associated with greybus drivers or a generic one for clickboards? ,
Jul 22 16:13:07 <jkridner> vaishnav98_[m]: so, it seems we still need to add a new driver that will export fairly generic gpios mapped to click headers, rather than the BeagleBone gpios....
Jul 22 16:13:16 <jkridner> then use gbsim to swivel them.
Jul 22 16:13:46 <jkridner> could be Click specific, I suppose, on top of greybus.
Jul 22 16:14:36 <vaishnav98_[m]> <jkridner "they can still be generic if the"> jkridner: can you please provide some more information about the driver you were proposing, as I couldn't  exactly understand how it could handle all the clicks platform data
Jul 22 16:18:13 <vaishnav98_[m]> <jkridner "vaishnav98_: so, it seems we sti"> jkridner: are you talking about a driver like this https://github.com/beagleboard/linux/blob/4.14/drivers/staging/fbtft/fbtft_device.c?
Jul 22 16:28:20 <jkridner> I'm trying to think it out on iio devices first...
Jul 22 16:29:23 <jkridner> is 'irq' a generic thing in SPI?
Jul 22 16:32:25 <vaishnav98_[m]> <jkridner "I'm trying to think it out on ii"> jkridner: so shall I try with the mpu9dof click first? so the driver should be something like fbtft_device for iio devices except fetching the arguments from command line arguments? and the driver will attach a new iio device to the corresponding SPI/i2c master?  do I understand your suggestion correctly?
Jul 22 16:32:54 <vaishnav98_[m]> <jkridner "is 'irq' a generic thing in SPI?"> jkridner: I believe so , spi_board_info struct contains an entry 'int irq'
Jul 22 16:44:17 <jkridner> vaishnav98_[m]: I just posted a follow-up e-mail to summarize my thoughts....
Jul 22 16:44:47 <jkridner> starting with other IIO sensors might be far easier than fbtft_device for now..., though I certainly want to attack that one two.
Jul 22 16:44:49 <jkridner> er, too
Jul 22 16:45:36 <pranav_kumar[m]> <Abhishek_1 "GitHub is down, I can't see the "> Yes
Jul 22 16:46:06 * jkridner has to go afk.
Jul 22 16:48:39 <vaishnav98_[m]> <jkridner "vaishnav98_: I just posted a fol"> jkridner: I was going through your mail
Jul 22 16:49:32 <vaishnav98_[m]> <jkridner "starting with other IIO sensors "> jkridner: sure I'll try it and update you
Jul 22 17:04:09 <pratimugale[m]> abhishek_:  https://github.com/pratimugale/PRUSS-Bindings/tree/wip/examples/firmware_examples/example4-analog-wave-gen -> This is the code for single channel, in case its up now
Jul 22 17:20:23 <mdp> jkridner[m]: SPI has no concept of irq in hw
Jul 22 17:24:47 <vaishnav98_[m]> mdp : hi , I tried to bring in device tree based support for greybus as you suggested, however I am stuck at the part where I need to the pass the platform details to the corresponding device driver, I can do this if i know the corresponding device platform_data struct , but how can this be extended in a generic way where the platform data struct of the device is not exactly known?
Jul 22 17:33:56 <mdp> vaishnav98_[m]: unfortunately the answer is complex...some of the drivers you want to work with..let's take fbtft, for example, do things unconventionally or what I'll call "the wrong way". that's why fbtft is in staging. the method I suggests works if you have a properly defined device with a DT binding. that device will always be described with the spi/i2c/gpio/irq resources it uses either in your base DTB or an overlay.
Jul 22 17:37:52 <mdp> a good example of something where this works is e.g. the adxl372 accelerometer. it's a device with a proper dt binding that defines a irq that is typically implemented from a gpio and a transport bus that either i2c or spi. and all the information you need would be in the DT fragment.
Jul 22 17:56:43 <vaishnav98_[m]> mdp : Thanks a lot, I'll look into it
Jul 22 21:00:37 <embden_new[m]> julieng:  have you meant to use dt_debug option?
Jul 22 21:01:57 <embden_new[m]> can you remind me how to trun on the option?
Jul 22 21:06:36 <jkridner> vaishnav98_[m]: can't tell if I'm reconnected
Jul 22 21:06:49 <jkridner> ah, yes, just needed to scroll.
Jul 22 21:07:11 <jkridner> vaishnav98_[m]: let me know if you are still up (or, more likely, up early)
Jul 22 21:13:35 <embden_new[m]> julieng:  found it
**** ENDING LOGGING AT Tue Jul 23 02:59:57 2019