**** BEGIN LOGGING AT Tue Jul 23 02:59:57 2019 Jul 23 03:00:09 jkridner: sorry, I wasn't up yesterday at that time, Jul 23 03:02:05 jkridner: where should the proposed Greybus iio protocol driver look for the resources (interrupts,reset..etc) parse it from the manifest or from the device tree? Jul 23 03:09:25 on the host side, I think it can be hard coded. on the gbsim side, I think there can be some generic device tree (one for each mikroBus port) Jul 23 03:14:01 jkridner: okay , looking at some of the iio based clicks like mpu9dof and waveform generator click , I see that they require more than interrupts/resets in the platform data , how can we deal with it? Jul 23 03:29:25 what else? Jul 23 03:33:31 jkridner: mpu9dof click has a i2c mux device , the magnetometer ak8975 , so it requires those corresponding parameters also during instantiation, similarly the function generator click has a digital pot to control the amplitude of output **** BEGIN LOGGING AT Tue Jul 23 06:46:23 2019 Jul 23 09:19:47 pratimugale: nice report. Jul 23 09:20:22 About increasing buffer size. You can't do that in a simple way. Jul 23 09:21:07 The rpmsg driver has set that limit. To override it, you'll have to change it in the driver. Recompile it, and then use it. Jul 23 09:21:47 Which would be a hack-y approach. Jul 23 09:22:28 About sending more data in single "kick" : so, the ultimate limit is that which is set by driver. Jul 23 09:24:37 So, if you want to send more data, which is less than 512, but that which you accumulate over time, then it can be done. Jul 23 09:26:59 pratimugale: look into this : https://github.com/ZeekHuge/BeagleScope/blob/master/firmware/main_pru0.c#L93 Jul 23 09:27:58 zeekhuge: So is it recommended to send multiple messages after the limit? Or changing the driver? Jul 23 09:28:27 zeekhuge: Thanks, going through your code Jul 23 09:29:52 pratimugale: this is the kernel limit : https://github.com/beagleboard/linux/blob/4.4/drivers/rpmsg/rpmsg_pru.c#L31 Jul 23 10:06:26 I think I understood, will try to implement it, I'm trying to send more data (less than 512) from the ARM to PRU, and will need to modify the daemon function, as it currently sends only one 4-byte integer at a time. Jul 23 10:16:04 pratimugale: Feel free to ask if their is any query. Jul 23 10:36:27 jkridner: julieng cwicks Hello, I won't be able to participate in a meeting tomorrow. I have an appointment to the doctor at that time. Jul 23 11:36:43 julieng: I found out that I forgor to include "compatible" property into crossbar node for dom0. But after including it, the dom0 still doesn't call the crossbar driver Jul 23 11:38:11 embden_new[m]: How do you create the node? Jul 23 11:40:23 julieng: https://github.com/embeddedden/xen/blob/e6f28381b9790dd3adc554e0dfae88f744ce3813/xen/arch/arm/domain_build.c#L967 Jul 23 11:41:45 I can see the message when it steps into the function and no error messages Jul 23 11:43:27 Which message in which function? Jul 23 11:44:08 "Create crossbar node" in the make_crossbar_node Jul 23 11:44:19 ^ Jul 23 11:46:24 embden_new[m]: Hmmm, I don't see anything obviously wrong in this function. The best would be to debug on the linux side. Jul 23 11:50:55 embden_new[m]: Actually, I think you are missing the property "interrupt-controller" Jul 23 11:51:05 So Linux does not detect it is not interrupt controller Jul 23 11:51:50 https://github.com/embeddedden/xen/blob/e6f28381b9790dd3adc554e0dfae88f744ce3813/xen/arch/arm/domain_build.c#L1039 Jul 23 12:03:50 julieng: ^ Jul 23 12:07:14 embden_new[m]: Oh, I missed that one. Then I don't know what's the problem here. Jul 23 12:07:51 ok, I will look from the kernel's perspective Jul 23 12:07:52 The function looking for interrupt-controller in Linux is called of_irq_init Jul 23 12:08:18 You can add some debug in the function to see what's going on. Jul 23 12:08:22 julieng: thank you Jul 23 12:55:15 julieng: it seems that though Linux can see three interrupt controllers it can't find their order (who is a parent for who) Jul 23 12:57:17 my assumption might be is that wugen node which is also in interrupt controller (has the proprty) it is probably not processed right in xen Jul 23 14:22:01 julieng: I can see that for some reason gic intc has the crossbar as a parent Jul 23 14:22:12 but it should be parent for itself Jul 23 14:22:29 probably, something in xen should be changed Jul 23 16:00:29 Won't be able to attend today's meeting, pratimugale if you have any open questions, leave me a @ mention, I will respond when I am able to. Jul 23 16:04:23 abhishek_: Meeting's tomorrow, right? Jul 23 16:04:44 Ouch I thought it was Wednesday today :) Jul 23 16:06:07 :) Jul 24 02:46:19 abhishek_ zeekhuge Just wanted to clear it out; while sending large amount of raw data, writing a block of data to the rpmsg file is better than looping over and sending them individually, right? Block => https://gist.github.com/pratimugale/875def7870a9d170d0980091a864289c#file-userspace-py-L26 Loop(send individually) => Jul 24 02:46:20 https://github.com/pratimugale/PRUSS-Bindings/blob/4e25b3f9dbf5128383cc67e7061ef5fdc1c85e8c/examples/firmware_examples/example4-analog-wave-gen/userspace.cpp#L31 Jul 24 02:51:12 pratimugale: morning. The reason why I had created that hack-y function was that, if I was sending large amount of data, in short write-and-kick cycles, the ARM was getting stuck because of so many interrupts. So, that hack-y function reduces the number of kicks for the same amount of data, hence increasing the max data transfer speed. Jul 24 02:52:00 So, yes. In general its better to write more and kick less But what should actually be done depends on the use case. Jul 24 02:52:39 Yes, I realized that it would depend on the application Jul 24 02:52:43 If high data transfer speed is not required, then simple writing is fine. Jul 24 02:53:26 got it, thanks Jul 24 02:59:47 pratimugale: also, in my use case, the ARM did not require data immediately as it was being produced on PRU side. So, the data transfer could have waited (hence first write lots of data and then inform-kick the arm) **** ENDING LOGGING AT Wed Jul 24 02:59:57 2019