**** BEGIN LOGGING AT Mon Jul 08 02:59:58 2019
Jul 08 05:21:54 <vaishnav98_[m]> <vaishnav98_[m] "jkridner ravikp7 : I got reply f"> jkridner: can you provide some tips on how to proceed with a implementation which can support new clicks without modifying the gbsim sources each time a new click is added
Jul 08 05:22:35 <jkridner[m]> I really don't know based on Greg's answer.... I think we need to better explain to him what we are trying to do.
Jul 08 05:23:03 <jkridner[m]> wish I could be more helpful, but I'm up to my eyeballs in work right now....
Jul 08 05:23:09 <jkridner[m]> ravikp7: do you have any thoughts?
Jul 08 05:24:39 <vaishnav98_[m]> jkridner ravikp7 : I have been working on Makecode integration of click board support through greybus , and I could get it working(4 clicks) , I'll provide a demonstration video soon , I have not been able to do much on adding new clicks as I couldn't find a consistent way to add new click support
Jul 08 05:26:43 <jkridner[m]> I'd thought that manifest files were complete, but it seems they lack key info. I'm really unsure how that is supposed to work in the Unipro case. Given that Clicks will always put INT, RST, etc. on the same signals, maybe these things can be added to gbsim?
Jul 08 05:27:08 <jkridner[m]> but, it breaks the general GPIO cases. :-(
Jul 08 05:28:33 <jkridner[m]> mdp: can you give us some hints how we should follow-up with Greg to better understand how to keep gbsim generic for all of these Click boards?
Jul 08 05:29:06 <jkridner[m]> how does greybus get the necessary platform data for these extra sideband signals anyway?
Jul 08 05:35:53 <vaishnav98_[m]> <jkridner[m] "I really don't know based on Gre"> jkridner: I'll send him a reply mail describing exactly what we are trying to achieve
Jul 08 05:38:47 <vaishnav98_[m]> <jkridner[m] "wish I could be more helpful, bu"> jkridner: you have been helping a lot :) .. I'll send one more mail to greybus dev list describing the full details of the project
Jul 08 13:10:16 <pratimugale[m]> abhishek_: I started working on waveform generation today. I haven't understood how to make these examples (starting with pwm) multi-channel without disturbing the other channels in assembly also. Could you  please help me with this?
Jul 08 13:10:40 <pratimugale[m]> I have ordered a stepper motor and driver which should arrive by tommorrow evening.
Jul 08 13:30:55 <mdp> jkridner[m]: vaishnav98_[m]: I recall either gregkh or robh talking about adding DT support to the manifest...but at the time it wasn't needed for the Ara requirements. I think any blessed solution would likely revolve around attaching a dt fragment. of course, this gets complicated as those have to be known against a base DT..and they are decidedly not cport specific (you can create conflicts in the remote uC). to my
Jul 08 13:30:55 <mdp> knowledge, nobody has really thought through this problem at the most complex level of use cases like this (using greybus generically, that is)
Jul 08 13:35:00 <mdp> jkridner[m]: keep in mind that the extra platform data was to be hardcoded into the particular Ara module you added..in the original conception. so your module firmware handles that..and there was no provision at all for communicating that flexibly via the manifest.
Jul 08 13:35:45 <mdp> should be straightforward to define an extension and add something to make some generic sideband info (which them starts looking like DT stuff)
Jul 08 13:38:00 <jkridner[m]> <mdp "should be straightforward to def"> other formats can be fine, but it needs to be flexible on the Linux host side and we can come up with a specification on the device side to be generic to all Clicks.
Jul 08 13:38:33 <jkridner[m]> It seems odd to me that manifests aren’t flexible enough to encode this information.
Jul 08 13:39:42 <mdp> it's not that manifests aren't flexible, it's that defining a schema was not done
Jul 08 13:39:55 <mdp> as it wasn't necessary on Ara
Jul 08 13:41:03 <mdp> the use case was enabling some simple userspace drivers in Android. So imagine a phone loaded with the equivalent of cape universal ;) then a module is identified as some widget..and that userspace driver knows what gpios to talk to
Jul 08 13:41:34 <mdp> all the effort was put into the basic plumbing, the bridged/tunneled i/o protocols..not on the sideband data.
Jul 08 13:50:28 <jkridner[m]> as long as there is a way to provide the sideband/platform data without changing the kernel or adding new drivers.
Jul 08 13:50:29 <jkridner[m]> how does gbsim provide this data to the kernel?
Jul 08 13:52:08 <vaishnav98_[m]> <mdp "should be straightforward to def"> mdp jkridner: Thanks a lot for the inputs, so should the support for clickboards implementation be something something similar to the w25q256 spi-nor flash device emulation here https://github.com/projectara/gbsim/blob/master/spi.c , I am not sure how to implement something like that for  a device like a clickboard, could you please provide some more information on how to do
Jul 08 13:52:09 <vaishnav98_[m]> it , excuse my ignorance
Jul 08 14:10:08 <coolgames[m]> Has anyone found or written code for the GHI Game Pup cape for Pocket Beagle that uses the display ?
Jul 08 14:11:18 <Abhishek_1> pratimugale: You probably need to reorganize your code to do multichannel PWM.
Jul 08 14:15:46 <Abhishek_1> Take a few channels, say 4, with arbitrary duty cycles and work out on paper first how you would generate the waveforms.
Jul 08 14:16:45 <Abhishek_1> Or you can also search for "software PWM channels on microcontrollers" and reuse some of the code from there.
Jul 08 14:18:11 <pratimugale[m]> abhishek_: ok, thanks
Jul 08 14:21:12 <Abhishek_1> pranav_kumar: What are you working on right now?
Jul 08 14:46:25 <julieng> embden[m]: How do you get on with the crossbar?
Jul 08 14:48:16 <embden[m]> julieng:  I am trying to understand the GIC make_gic_node function, haven't understood yet how it works
Jul 08 14:56:02 <mdp> vaishnav98_[m]: all the spi.c implementation is the raw spi master device simulation. you'd have to specify a manifest with cports for i2c/spi/gpio etc. for a clickboard afaik.
Jul 08 14:56:22 <julieng> embden[m]: Let me try to explain. Dom0 will be using most of the host devices except a few that are virtualized (such as the GIC). For simplicity all the devices are mapped at the same place in Dom0 (i.e host physical address == guest physical address).
Jul 08 15:00:07 <julieng> While the vGIC is exposed exactly at the same place as the host GIC, we want to strip some informations that are used by Xen.
Jul 08 15:00:35 <julieng> For instance, in the case of the GICv2, we want to remove the virtual interface and hypervisor interface.
Jul 08 15:02:06 <julieng> The function make_gic_node will be re-generating the GIC node
Jul 08 15:02:44 <pranav_kumar[m]> <Abhishek_1 "pranav_kumar: What are you worki"> As suggested by @hendersa testing the enable pin and latch facility and making a cod eon enabling async communication between two beaglebone
Jul 08 15:03:15 <pranav_kumar[m]> *makining code to enable
Jul 08 15:03:43 <embden[m]> julieng:  right now I am trying to understand what are the available classes of devices (DEVICE_GIC) and whether I should add DEVICE_CROSSBAR and how the function device_get_class works
Jul 08 15:05:07 <julieng> embden[m]: I don't think a class DEVICE_CROSSBAR is necessary as you will only have one compatible.
Jul 08 15:06:50 <julieng> We introduced a class DEVICE_GIC because we either support GICv3 and GICv2. Between the two, there are a few compatibles to check. This would make the code quite hard to read.
Jul 08 15:17:03 <jkridner[m]> <mdp "vaishnav98_: all the spi.c imple"> How do I learn what a cport is and how to define one?
Jul 08 15:28:35 <mdp> jkridner[m]: afaik, the only docs are the kernel and manifesto code...but gregkh gave a talk at kernel/embedded recipes about greybus that has an overview of the concepts
Jul 08 15:31:00 <mdp> https://kernel-recipes.org/en/2015/talks/an-introduction-to-greybus/
Jul 08 15:33:04 <mdp> but basically, imagine a cport containing one function..whether that's a gpio, i2c, or spi controller. and then you can group a set of cports into a bundle. a manifest describes those cports and bundles. at a high level you'd describe a particular clickboard using a bundle.
Jul 08 15:54:59 <vaishnav98_[m]> <mdp "vaishnav98_: all the spi.c imple"> mdp : currently for some of the clicks with simple spi/i2c interfaces, I am specifying a manifest with a single cport (spi/i2c)- single bundle with the corresponding protocol id, then device instantiation is done from userspace (echo > i2c_new_device) , how exactly can the device instantiation be done in a better manner (for example when there are interrupts or muxed I2C
Jul 08 15:54:59 <vaishnav98_[m]> requirements with the click this doesn't work)
Jul 08 17:16:05 <mdp> vaishnav98_[m]: you probably want to implement support for describing greybus nodes (and thus non-discoverable subnodes) in DT. This is how non-discoverable i2c devices are supported via DT on PCI devices. you can then provide clickboard support with a fragment specifying those spi/i2c devices under a greybus node. I recommend looking at how this is implemented for PCI.
Jul 08 19:59:45 <embden[m]> julieng:  could you explain this bit of code:https://pastebin.com/5jgx5QbD
Jul 08 20:00:39 <embden[m]> in "xen/include/xen/device_tree.h"
Jul 08 20:01:17 <embden[m]> does it really return bool? I can't find the realization of the function (is it in .S file)
Jul 08 20:02:30 <vaishnav98_[m]> <mdp "vaishnav98_: you probably want t"> mdp: Thanks a lot , will look into how it's implemented for PCI
Jul 08 20:03:35 <julieng> embden[m]: The function is implemented in xen/common/device_tree.c
Jul 08 20:03:46 <julieng> hmmm I think the description is wrong.
Jul 08 20:04:11 <julieng> It returns NULL if not match was found or the match if found
Jul 08 20:06:00 <julieng> This allows the driver to store configuration if the driver needs to handle differently a device depending on the compatible.
Jul 08 20:06:22 <julieng> For instance, we use it in the SMMUv2 driver as some of the version requires quirks.
Jul 08 20:06:30 <embden[m]> ok, I can see the function now
Jul 08 20:08:41 <embden[m]> julieng:  I am just wondering whether I should use it
Jul 08 20:09:51 <embden[m]> I mean to add it to "xen/arch/arm/domain_build.c":1382
Jul 08 20:10:31 <julieng> embden[m]: dt_match_node will do what you want in domain_build.c
Jul 08 20:10:53 <julieng> embden[m]: I mean, dt_match_node() will allows you to compare a node against a match.
Jul 08 20:11:22 <julieng> As an aside note, if you need to find a node matching a compatible, then you will need to use dt_find_compatible_node.
Jul 08 20:12:27 <embden[m]> julieng:  I mean there are two possibilities to make a make_gic_node like function and to handle it somehow in handle_device
Jul 08 20:12:46 <embden[m]> as I can see it, should I use the first approach?
Jul 08 20:13:10 <embden[m]> It just doesn't look right for me
Jul 08 20:13:13 <julieng> embden[m]: What is the second possibility?
Jul 08 20:14:12 <embden[m]> to handle it somehow in handle_device
Jul 08 20:16:21 <julieng> embden[m]: a make_gic_node function would be preferable.
Jul 08 20:17:26 <julieng> embden[m]: Because I want to keep handle_device generic.
Jul 08 20:19:22 <embden[m]> julieng:  for example, there is code like this: https://pastebin.com/emBQpsyf
Jul 08 20:19:23 <embden[m]> So, I can add the third condition (to match against the crossbar) but I think it is not the right step, isn't it?
Jul 08 20:19:30 <embden[m]> julieng:  for example, there is code like this: https://pastebin.com/emBQpsyf
Jul 08 20:19:31 <embden[m]> So, I can add the third condition (to match against the crossbar) but I think it is not the right step, isn't it?
Jul 08 20:21:55 <julieng> embden[m]: We will probably want to make that platform specific (by introducing a new callback). For now, this is the correct way to go.
Jul 08 20:23:27 <embden[m]> julieng:  ok, so, is it ok that it will look like this in the beginning? https://pastebin.com/n1qyDCGJ
Jul 08 20:24:35 <julieng> embden[m]: Sounds good to me. You can clean it up once you have the crossbar fully working.
Jul 08 20:27:32 <embden[m]> ok
Jul 08 20:30:06 <julieng> embden[m]: FAOD, I am happy with some hacks in the code for now as you can focus on what matters (the implementation of the crossbar).
Jul 08 20:56:15 <embden[m]> Got it
**** ENDING LOGGING AT Tue Jul 09 02:59:57 2019