**** BEGIN LOGGING AT Mon Jul 29 03:00:13 2019
Jul 29 03:58:06 <vaishnav98_[m]> jkridner: I tried out instantiating the devices through an external mikrobus module as you suggested, I am able to instantiate most of the supported devices with interrupt and other extra platform requirements on the physical SPI/I2C but when trying it on the greybus virtual SPI/I2C it fails as if the irq wasn't passed, for example the mpu9dof click fails with a message : trigger probe failed, similarly the eth
Jul 29 03:58:06 <vaishnav98_[m]> click on the Greybus virtual SPI fails with enc28j60 chip not found, while both the clicks work well when they're instantiated on the actual physical SPI/I2C bus to which it is connected
Jul 29 04:03:53 <pratimugale[m]> zeekhuge abhishek_ I was able to set different channels to different frequencies, but doing so requires a lot of registers due to which the phase at which the wave starts is unpredictable
Jul 29 04:08:19 <zeekhuge[m]> pratimugale: its not a competition. Its an example. So, implement only as many channels as can be comfortably (and accurately) fit in.
Jul 29 04:08:33 <zeekhuge[m]> pratimugale: what about the kernel panic?
Jul 29 04:08:49 <pratimugale[m]> <zeekhuge[m] "pratimugale: its not a competiti"> ok
Jul 29 04:10:04 <pratimugale[m]> <zeekhuge[m] "pratimugale: what about the kern"> I still have to look into it
Jul 29 06:06:09 <pratimugale[m]> <zeekhuge[m] "pratimugale: its not a competiti"> zeekhuge:abhishek_  I had done the calculation before for 8channels, and just realized what mistake I was making in the code. 8-channels are still possible and  is working. I'll add a video of it and work on the kernel panic after I come back from college(around 5/6PM).
Jul 29 06:10:27 <pratimugale[m]> https://github.com/pratimugale/PRUSS-Bindings/blob/wip/examples/firmware_examples/example9-multichannel-waveform-gen/PRU0/waveform_gen.asm zeekhuge Is it OK to use R0? It hasn't caused any problem yet
Jul 29 06:37:01 <pratimugale[m]> Also R15, although only 1 byte of it is required which can be accomodated in R9
Jul 29 14:41:42 <julieng> embden_new[m]: Dom0 should not touch anything related to device used by Xen. If it is trying then, this should be prevented.
Jul 29 14:43:08 <embden_new[m]> julieng:  I haven't figured out yet how to deal with it
Jul 29 15:30:02 <embden_new[m]> julieng:  ds2  current output of Linux dom0 after disabling uart3: https://pastebin.com/u1wG136w
Jul 29 15:40:40 <embden_new[m]> and afte removing mmc device from DT I still get error
Jul 29 15:40:41 <embden_new[m]> hctosys: unable to open rtc device (rtc0)
Jul 29 15:52:00 <julieng> embden_new[m]: Are you sure Linux is stuck because of the rtc? I mean sometimes the last output does not necessarily this is the reason.
Jul 29 15:52:21 <julieng> embden_new[m]: I can see two ways to debug this
Jul 29 15:52:52 <julieng> 1) You can look at where Linux is stuck. You can dump the registers and look for the pc.
Jul 29 15:53:10 <julieng> 2) You can compare the output with baremetal Linux and see what is the next steps.
Jul 29 15:59:06 <embden_new[m]> julieng:  hm, you are probably right, becuase Linux baremetal get the same output
Jul 29 16:00:20 * embden_new[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/YrePfygzbxtsGAnXvUcdodjg >
Jul 29 16:00:27 <embden_new[m]> (I don't have a valid RAMDISK)
Jul 29 16:19:23 <embden_new[m]> julieng:  how can I find out the place where I stuck?
Jul 29 16:19:43 <julieng> embden_new[m]: CTRL-a three times will give you access to Xen console.
Jul 29 16:19:50 <julieng> if you dump the registers of the domain
Jul 29 16:19:53 <julieng> you should find the pc.
Jul 29 16:20:13 <julieng> you can then use addr2line to find the corresponding line in the code.
Jul 29 16:20:21 <embden_new[m]> julieng:  ctrl+a doesn't work
Jul 29 16:20:35 <julieng> julieng: Oh, I though you had the UART working?
Jul 29 16:20:39 <drhunter[m]> Have you got the emulator up and running? This is good for this type of problem.
Jul 29 16:21:19 <julieng> drhunter[m]: Which emulator? QEMU?
Jul 29 16:21:24 <embden_new[m]> julieng:  it responds before the stuck
Jul 29 16:21:40 <julieng> embden_new[m]: Hmmmm.... I think I know the problem.
Jul 29 16:22:11 <embden_new[m]> julieng:  the debugger
Jul 29 16:22:12 <drhunter[m]> I was meaning a JTAG emulator Julian
Jul 29 16:22:37 <drhunter[m]> Julien *
Jul 29 16:22:50 <embden_new[m]> I mean, yes, the jtag emulator
Jul 29 16:22:51 <julieng> embden_new[m]: Linux will tend to turn off any clocks that are unused from its POV.
Jul 29 16:23:16 <julieng> embden_new[m]: We saw problem in the past where Linux was turning off the UART clock because it was not shared with other devices.
Jul 29 16:23:48 <embden_new[m]> drhunter:  I lost my CCS installation due to failure of my ssd
Jul 29 16:24:28 <embden_new[m]> drhunter:  haven't reinstalled it yet
Jul 29 16:24:42 <julieng> embden_new[m]: The result was the UART unresponsive. Can you try to add "clk_ignore_unused" on your Linux command line?
Jul 29 16:25:05 <julieng> This should tell Linux to keeping on all the clocks even if they are not used.
Jul 29 16:25:17 <embden_new[m]> ok, will try it now
Jul 29 16:25:33 <drhunter[m]> Hopefully Julien's tip works and you can avoid CCS/JTAG. I do find it useful to try and trace through code.
Jul 29 16:27:55 * embden_new[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/usxRGNhvaXfAwhufXrQtQbSb >
Jul 29 16:28:15 <embden_new[m]> But, it doesn't respond to typing
Jul 29 16:28:49 <embden_new[m]> 3 * CTRL+A also doesn't work
Jul 29 16:29:07 <embden_new[m]> julieng:  ^
Jul 29 16:30:02 <embden_new[m]> Probably, it this doesn't works it means that it is a good time to write xen hooks for the crossbar
Jul 29 16:30:15 <embden_new[m]> s/it/if/
Jul 29 16:30:57 <embden_new[m]> "if this doesn't work"
Jul 29 16:37:14 <julieng> embden_new[m]: 3 * CTLR+A should still work whether the crossbar is implemented or not.
Jul 29 16:37:57 <julieng> embden_new[m]: Can you paste the full log (Xen included)?
Jul 29 16:38:10 <embden_new[m]> julieng:  I mean that Linux can change routing in the crossbar and we don't know about it
Jul 29 16:38:28 <embden_new[m]> also, can busybox change the console to listen to?
Jul 29 16:38:29 <embden_new[m]> yes
Jul 29 16:41:13 <julieng> embden_new[m]: Only hvc0 should work.
Jul 29 16:41:42 <julieng> embden_new[m]: If Linux is using a different console, then it may not work.
Jul 29 16:42:03 <julieng> embden_new[m]: Well, I thought the crossbar wasn't mapped to Dom0. So you should receive a trap in that case.
Jul 29 16:43:16 <embden_new[m]> here is the paste: http://pastebin.zone/8yInVAlG (too large for pastebin, with a lot of custom debugging output)
Jul 29 16:45:47 <embden_new[m]> julieng:  the crossbar is not mapped. It is provided in the DT passed to Linux; routes are predefined, all the disabled devices routed to one interrupt, but  there are no traps and I think that Linux can write to the control register
Jul 29 16:50:20 <julieng> embden_new[m]: The control register is an MMIO right? If so it should trap.
Jul 29 16:50:43 <julieng> If it don't trap then it either means Linux is not configuring the crossbar (I doubt it) or it still map.
Jul 29 16:52:29 <embden_new[m]> julieng:  should the region be in specific_mapping?
Jul 29 16:54:13 <embden_new[m]> there is ioremap call for the control register
Jul 29 16:55:16 <embden_new[m]> but probably there is no map_mmio_regions call for the control registers
Jul 29 16:57:16 <julieng> embden_new[m]: It should not be in mapped to Dom0. Otherwise, you will let Dom0 to control the crossbar which we don't want.
Jul 29 16:57:48 <julieng> As you still give the DT bindings to Dom0, then it will trap and you should see a message on the console regarding the trap.
Jul 29 16:58:05 <embden_new[m]> so, probably it is not mapped
Jul 29 16:58:20 <julieng> embden_new[m]: Do you see a message from Xen when accessed?
Jul 29 16:59:57 <embden_new[m]> julieng:  as you can see there are several messages from xen in the log
Jul 29 17:02:26 <julieng> embden_new[m]: I have some doubt whether the crossbar is not mapped.
Jul 29 17:05:40 <julieng> embden_new[m]: Hmmm, it looks like the crossbar is sharing a page with other device :(.
Jul 29 17:05:56 <julieng> embden_new[m]: So the page will still be mapped in Dom0.
Jul 29 17:06:33 <julieng> embden_new[m]: This probably can be confirmed if you have the TRM in hand.
Jul 29 17:08:34 <embden_new[m]> julieng:  how big a page is?
Jul 29 17:10:11 <julieng> embden_new[m]: 4KB
Jul 29 17:11:17 <embden_new[m]> The control register for the crossbar is around 160 words
Jul 29 17:11:37 <embden_new[m]> hm..
Jul 29 17:12:44 <embden_new[m]> I'll look in TRM
Jul 29 17:18:03 <embden_new[m]> for MPU from 0A4C to 0B74
Jul 29 17:20:41 <embden_new[m]> but there also addresses for control crossbar registers for DSP, PRUSS , IPU modules
Jul 29 17:24:12 <embden_new[m]> in summary addresses (offsets) are from 7A0 to B74 and those are only about crossbar. julieng  there are also registers for controlling DMA and some other things
Jul 29 17:41:43 <vaishnav98_[m]> jkridner: passing the irq in spi_board_info or i2c_board_info fails for a greybus spi/i2c while the same method works for instantiating devices on the physical SPI/I2C bus
Jul 29 17:42:02 <embden_new[m]> julieng:  hm, I found out that 3*CTRL+A doesn't work even before dom0 loading if I delete uart3 from DT
Jul 29 17:43:31 <embden_new[m]> probably, I need to delete it only for dom0 then, right? Or what is a better way to deal with the dom0 trying to do something with uart3 which we use in xen?
Jul 29 17:45:48 <embden_new[m]> I think that I should delete the utilized by xen uart from dom0 DT but I think that it should be either already implemented or there should be another approach. julieng
Jul 29 17:50:28 <ds2> few things to think about - can xen make it so any access to a page will trap and then xen can filter out things w/finer granularity? also, you can run Linux's console on a different UART if needed
Jul 29 17:51:05 <ds2> the current UART is somewhat special for the SoC in that it can UART boot from it but if Xen is there, that isn't important
Jul 29 17:51:56 <julieng> ds2: The problem is not the UART but the crossbar. Xen does not have any filtering, but it should be feasible to do it.
Jul 29 17:52:37 <julieng> embden_new[m]: Didn't you test CTRL+A before?
Jul 29 17:52:47 <embden_new[m]> ds2:  but in order to use another uart I need to connect to it somehow. And the only uart I can easily get output from is uart3 (serial debug)
Jul 29 17:54:13 <julieng> embden_new[m]: The UART should already be deleted from Dom0 DT as it is used by Xen.
Jul 29 17:54:27 <embden_new[m]> julieng:  I did but I just recently started to delete uart3 node from DT. And haven't tested yet. And it is clear why it doesn't work (xen can't set up irqs since I deleted the description from DT)
Jul 29 17:55:22 <embden_new[m]> julieng:  but Linux stucks at uart3 which is used by xen when I don't delete it manually
Jul 29 17:56:20 <julieng> embden_new[m]: I am confused. Where do you delete it from? Host DT? Or Dom0 DT?
Jul 29 17:56:52 <julieng> embden_new[m]: Is it stuck also with the clk_ignore_unused?
Jul 29 17:58:14 <julieng> embden_new[m]: Xen should automatically delete the UART node from Dom0 DT thank to the check
Jul 29 17:58:16 <julieng>     if ( dt_device_used_by(node) == DOMID_XEN )
Jul 29 17:58:20 <embden_new[m]> julieng:  I delete it from host dt otherwise Linux is stuck when tries to initiallise it. Yes (clk_ignore_unused)
Jul 29 18:01:14 <embden_new[m]> julieng:  where the device for output is setup?
Jul 29 18:01:29 <julieng> embden_new[m]: xen/drivers/char/omap5.c
Jul 29 18:04:12 <ds2> julieng: yes, I know it is not the UART... I am trying to suggest side stepping the problem rather then addressing it now.
Jul 29 18:04:32 <ds2> embden_new[m]: that's harder to address.
Jul 29 18:09:00 <embden_new[m]> julieng:  I think you meant omap-uart.c. I am truying to find out how xen understand what device node to use as the main uart
Jul 29 18:09:17 <pratimugale[m]> zeekhuge abhishek_ I tried debugging the userspace program to find where the kernel panic happens, it is generally after writing 15 (once I got 14) values to the channel. https://pastebin.com/24gXsKni, https://gist.github.com/pratimugale/d6ac093c7a4aff064457e7f793986b51#file-userspace-cpp-L121.
Jul 29 18:10:08 <julieng> ds2: Do you have multiple UART accessible on the x15? If so, then we could give a different one to Xen. If not, an alternative is to just disable the driver in Linux (assuming it is feasible).
Jul 29 18:10:08 <pratimugale[m]> Sometimes, the kernel panic message isn't shown and it appears that the userspace program writes all the values to the rpmsg channel. But then too the output is incorrect (the first 15 values are skipped) -> https://pastebin.com/9MuWUtBQ. This happens only the first time after booting the BB. The next time the userspace.o is run, all the values are written correctly.
Jul 29 18:10:50 <julieng> embden_new[m]: Look for dt_device_set_used_by(...).
Jul 29 18:10:58 <ds2> julieng: yes/no. it depends on your definition of accessible. It is on a header pin but unless embden has the connectors and maybe a UART/USB cable....
Jul 29 18:11:17 <ds2> for me, I keep those things around my lab so....
Jul 29 18:11:31 <pratimugale[m]> zeekhuge: So I think the problem is while writing to the rpmsg_pru channel which is done from prussd.py
Jul 29 18:11:31 <pratimugale[m]> But I don't understand what it is.
Jul 29 18:12:40 <embden_new[m]> ds2:  my soldering skills are very far from perfect
Jul 29 18:13:55 <embden_new[m]> also, I don't have headers
Jul 29 18:23:47 <embden_new[m]> julieng:  is it a dtuart option that points to the required device node to use as the main uart?
Jul 29 18:26:03 <ds2> headers is the biggest issue....the x15 doesn't use simple ones
Jul 29 18:27:58 <ds2> (please consider it carefully) - you could make the Linux console the ttyACM ports... it does have 2 USB device ports... I have seen it done years ago but if you need early debugging, this isn't going to work well
Jul 29 18:32:48 <julieng> embden_new[m]: Yes it requires an UART node.
Jul 29 18:34:26 <embden_new[m]> julieng:  is it ok that I pass alias instead of a full path?
Jul 29 18:35:37 <julieng> embden_new[m]: Yes you can.
Jul 29 18:55:28 <vaishnav98_[m]> jkridner: I cannot understand why irq passed in spi_board_info for greybus SPI fails while it works well for the physical SPI, I couldn't find anything related to irq under greybus-spi or greybus-spilib , can you help me out with the issue
Jul 29 18:56:00 <jkridner> vaishnav98_[m]: where's the code?
Jul 29 19:01:15 <jkridner> https://github.com/vaishnav98/linux/tree/wip-gbofbus ?
Jul 29 19:01:47 <vaishnav98_[m]> jkridner: this is the module I am using to instantiate the click devices:https://github.com/vaishnav98/mikrobus_device currently the bus numbers correspond to the physical bus which the Mikrobus ports correspond to, and it works with  most(7) clicks, but when I change the bus to a greybus created one(SPI/i2c) clicks without irq gets instantiated correctly but clicks like mpu9dof and eth click fails as if the
Jul 29 19:01:47 <vaishnav98_[m]> interrupt was not provided
Jul 29 19:03:17 <jkridner> can you export a simple greybus gpio using the gpio_helper driver??
Jul 29 19:05:21 <jkridner> where's the probe call?
Jul 29 19:05:48 * jkridner isn't familiar with "X_device_register"
Jul 29 19:07:10 <embden_new[m]> julieng:  hm, don't understand, xen clearly skips the node whose child is uart3 (in domain_build) but Linux tries to do something with uart3...
Jul 29 19:08:05 * jkridner reads https://elixir.bootlin.com/linux/latest/ident/i2c_new_device
Jul 29 19:08:44 <vaishnav98_[m]> <jkridner "can you export a simple greybus "> jkridner: sure I can do that, but currently the number of gpios that can be exported and the actual gpio to which the greybus gpio is linked is hard-coded in gbsim
Jul 29 19:10:13 <vaishnav98_[m]> <jkridner "where's the probe call?"> jkridner: the driver is similar to fbtft_device for instantiating the devices, and takes the click name as module parameter, currently the mikrobus_spi_device and mikrobus_i2c_device modules are used
Jul 29 19:10:39 <jkridner> vaishnav98_[m]: understood. it'll always have to be "fixed" on the gbsim/mcu side to allow translation to occur properly.
Jul 29 19:11:31 <jkridner> vaishnav98_[m]: I might not understand 100%, but I think you still need to allocate the platform driver structure for the probe. it looks like there's a callback as part of the info structure for the probe call as part of the actual driver used.
Jul 29 19:13:06 <vaishnav98_[m]> <jkridner "vaishnav98_: understood. it'll a"> jkridner: okay, after exporting the gpio what shall I do?
Jul 29 19:13:11 <jkridner> that's not part of the i2c driver itself, as per my understanding, so, you'll need to provide the required info in the register_driver call for a callback and that final driver will pull the IRQ info out of whatever structure (info?) to initialize it's platform data.
Jul 29 19:15:02 <jkridner> vaishnav98_[m]: the point of the GPIO driver on it's own is just to understand that you aren't getting hung up on that... it also allows you to test the gpio mapping. further, the ability to have a gpio over greybus along with i2x/spi helps me provide a debug solution as we start adding other transports
Jul 29 19:15:52 <jkridner> vaishnav98_[m]: fyi, I don't really care for that you've made the top-level as i2c or spi... mikrobus should be the top level and just consume all the buses, then use the ones based on the click.
Jul 29 19:16:51 <jkridner> so, if you get a "mikrobus" to show up that consists of each of the gpio/spi/i2c/uart for an interface, you should be able to load the drivers on top of that *1* bus like we had been doing with overlays for the various bus combinations.
Jul 29 19:17:20 <jkridner> that shows that the usage of greybus, at a minimum, covers the port remapping.
Jul 29 19:18:26 <jkridner> feel free to go down either (or both) vector(s)... gpio using gpio_helper or adding a probe callback.
Jul 29 19:19:18 <vaishnav98_[m]> <jkridner "that's not part of the i2c drive"> jkridner: I'll look into this, but I'm still confused why the same instantiation via i2c_new_device fails only with the Greybus i2c
Jul 29 19:19:25 <jkridner> for the i2c device, I'm highly suspicious that the drivers don't load because their probe functions weren't called with the irq and that the callback mechanism likely handles that. I might be far off-base though.
Jul 29 19:19:56 <jkridner> vaishnav98_[m]: ah, interesting. guess I didn't really get that.
Jul 29 19:20:31 <jkridner> so, your code does work in the case of interrupts, but only if the i2c (and gpio) are provided directly?
Jul 29 19:20:39 <jkridner> ie, not through greybus.
Jul 29 19:20:48 <jkridner> I'm missing in your code where you do the gpio allocaiton.
Jul 29 19:21:07 <vaishnav98_[m]> <jkridner "vaishnav98_: the point of the GP"> jkridner: I think I'll go with this one first
Jul 29 19:21:42 <jkridner> I see https://github.com/vaishnav98/mikrobus_device/blob/3851473574ff5bd10b5e6617b91887e4db2c921d/mikrobus_i2c_device.c#L132
Jul 29 19:21:48 <vaishnav98_[m]> <jkridner "I'm missing in your code where y"> jkridner: I have hard-coded the Mikrobus port gpio numbers here https://github.com/vaishnav98/mikrobus_device/blob/master/mikrobus.h
Jul 29 19:21:55 <jkridner> does that succeed? I don't see the test.
Jul 29 19:23:04 <vaishnav98_[m]> <jkridner "so, your code does work in the c"> jkridner: yes, it works with clicks with interrupts (mpu9dof,eth) and additional platform data (oledc,oledb)
Jul 29 19:24:10 <vaishnav98_[m]> <jkridner "does that succeed? I don't see t"> jkridner: I couldn't understand you, what did you mean by 'test'
Jul 29 19:25:08 <jkridner> it looks like you are feeding the result of the gpio_to_int call directly without testing that the result is valid.
Jul 29 19:26:35 <jkridner> my wifi connection is about to die again. it'll be a couple hours before I'm on again.
Jul 29 19:29:37 <vaishnav98_[m]> <jkridner "it looks like you are feeding th"> jkridner: oh :( , sorry I'll fix that, could that be the reason why it fails, but I have debug statements to print out the irq number(in my version, cleaned up before committing) and I was able to confirm that it always printed out 75 for pocketbeagle Mikrobus port 1 interrupt (in both cases when it failed and succeeded)
Jul 29 19:38:08 <embden_new[m]> julieng:  ds2  could you explain why  there is this structure: https://pastebin.com/20iZ1eQ5 ? I mean if xen removes ..../serial@0 there is still a parent node with ti,hwmods="uart3" and other properties.
Jul 29 19:39:12 <embden_new[m]> and is this a sysclock node and Linux is trying to deal with it somehow?
Jul 29 20:29:55 <embden_new[m]> julieng:  So, I added parent of serial@0 to xen domid and now I can load to the same place without removing the whole node
**** BEGIN LOGGING AT Mon Jul 29 22:00:46 2019
Jul 29 22:44:20 <jkridner> vaishnav98_[m]: I'm back online
Jul 29 22:53:58 <jkridner> vaishnav98_[m]: in https://github.com/vaishnav98/mikrobus_device/blob/master/mikrobus.h, why do all of the gpio numbers reflect the hardware gpios rather than they greybus gpios?
Jul 29 22:54:19 <jkridner> wouldn't all of those gpios already be allocated by the target-side of greybus?
Jul 29 22:55:37 <jkridner> in fact, it looks like all of the definitions in the file shouldn't really be on the host side of the greybus.
Jul 29 22:56:06 <jkridner> they should all be handled by gbsim.
Jul 29 22:59:59 <jkridner> as of now, it looks like only the 4 LEDs are grabbed for gbsim gpios: https://github.com/vaishnav98/gbsim/blob/master/gpio.c#L260
Jul 29 23:00:37 <jkridner> when you export the gpios via greybus, are you able to control any except the LEDs?
Jul 29 23:03:14 <jkridner> to be a realistic simulation, I think you might need to have an instance of gbsim per mikrobus header, each given the pointers to the resources used/available for that header.
Jul 29 23:11:19 <cfriedt> jadonk: messaged v, but he's likely either not awake yet or away. will be available via email.
Jul 29 23:12:47 <vaishnav98_[m]> <jkridner "vaishnav98_: in https://github.c"> jkridner: I first tried with hardware gpios+greybus buses but it didn't work, that's why I modified it to hardware gpios and hardware bus, I just now tried a button+led interrupt on greybus gpios as you suggested , but the irq is returning a positive number (121) but the interrupt is not triggered when button is pressed, I have confirmed that the mapping is correct via
Jul 29 23:12:48 <vaishnav98_[m]> sysfs (read/write pins)
Jul 29 23:16:25 <vaishnav98_[m]> <jkridner "when you export the gpios via gr"> jkridner: yes, I was able to control other pins too, but the interrupt fails ,
Jul 29 23:16:42 <jkridner> hi cfriedt!
Jul 29 23:17:14 <vaishnav98_[m]> <cfriedt "jadonk: messaged v, but he's lik"> cfriedt: Hi , sorry I didn't see your message earlier
Jul 29 23:18:39 <jkridner> how did you control other pins?
Jul 29 23:18:48 <jkridner> seems like you are going around greybus to do so.
Jul 29 23:20:46 <vaishnav98_[m]> <jkridner "they should all be handled by gb"> jkridner: yes , I have modified the sources just now to export the Mikrobus port pins
Jul 29 23:21:56 <vaishnav98_[m]> <jkridner "how did you control other pins?"> jkridner: I have modified the exported pin numbers and then can control it via sysfs, echo X > /sys/class/gpio/gpio506/value
Jul 29 23:21:59 <jkridner> which branch?
Jul 29 23:24:03 <jkridner> so, the point is to try to get the abstraction and the dynamic loading, so I hope that it is clear why the mikrobus driver should eventually not have any particular pin references, except as it pertains to within a mikrobus slot.
Jul 29 23:26:38 <vaishnav98_[m]> <jkridner "which branch?"> jkridner: master branch https://github.com/vaishnav98/gbsim/commit/074b64786be7dcb4af8072c0a15b4873fbb1ec40 , sorry for the delay, I thought I had uploaded the commit
Jul 29 23:27:51 <jkridner> guess you removed the LEDs. seems you only added the first 6.
Jul 29 23:29:06 <vaishnav98_[m]> <jkridner "so, the point is to try to get t"> jkridner: I understand that, I was also trying to understand the difference between device instantiation on a hardware SPI/i2c and greybus spi/i2c bus that's why the pin definitions are still there
Jul 29 23:29:26 <jkridner> ok, just making sure.
Jul 29 23:30:09 <jkridner> got something to experiment with? if so, I'll take leave for an hour or so.
Jul 29 23:30:22 <vaishnav98_[m]> <jkridner "guess you removed the LEDs. seem"> jkridner: a Mikrobus port has only 3 gpios which is used for other purposes (reset, interrupts..) , currently I am exporting 6 pins corresponding to 2 Mikrobus ports in Pocketbeagle
Jul 29 23:30:25 <jkridner> just want to make sure you have some useful tasks to learn about how things are working.
Jul 29 23:31:02 <jkridner> cfriedt has been doing some interesting exercises in getting the greybus traffic moving across TCP/IP (based on other folks work).
Jul 29 23:31:25 <jkridner> k
Jul 29 23:35:02 <vaishnav98_[m]> <jkridner "just want to make sure you have "> jkridner: I was trying out the button+led interrupt(on greybus gpio) example via a driver as per your suggestion, I cannot understand why it fails : http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/ , i have been following this example
Jul 29 23:37:56 <jkridner[m]> <vaishnav98_[m] "jkridner: I was trying out the b"> works directly, yes? check the show-pin.pl state of the pin. should be easy to add some print statements to gbsim too.
Jul 29 23:38:44 <vaishnav98_[m]> jkridner: the interrupt request doesn't fail and I can see in /proc/interrupts : and it is attached to greybus_gpio , but it doesn't respond to edge changes/button presses
Jul 29 23:48:18 <vaishnav98_[m]> <jkridner[m] "works directly, yes? check the s"> jkridner: works directly, show-pin.pl is giving some errors (Inline ), trying to fix it , will update you after fixing it
Jul 30 00:01:46 <vaishnav98_[m]> jkridner : this is the output of show-pins https://pastebin.com/YWgZWZsc
Jul 30 00:02:54 <vaishnav98_[m]> <jkridner "cfriedt has been doing some inte"> jkridner: I'll send a mail to cfriedt
**** ENDING LOGGING AT Tue Jul 30 03:01:12 2019