**** BEGIN LOGGING AT Tue Jul 19 02:59:58 2016 Jul 19 05:46:57 * Abhishek_ checks in Jul 19 15:49:47 Wormo, Are you there? Jul 19 15:50:28 mdp ^^? Jul 19 16:07:49 hi chanakya_vc Jul 19 16:08:31 hi mdp , I sent a mail to you. Did you get a chance to read it? Jul 19 16:09:35 Actually mdp, I am working on the driver using the spi-subsytem. I am not able comprehend the concept of platform bus Jul 19 16:10:24 As far I have understood it, it is a virtual bus and is for devices that are non-discoverable. Jul 19 16:11:53 But essentially a bus is a means to transfer data, so I understand that it would be required in case of an external hardware controller. but in my case the processor Jul 19 16:12:02 has direct access to the shared mem Jul 19 16:12:08 So why do I need it mdp? Jul 19 16:21:36 I mean do I need to use it? Jul 19 16:37:34 let me switch to a real keyboard..just a sec Jul 19 16:41:49 chanakya_vc: so perhaps it's best to explain here where I can clarify things quickly rather than email? or should I just respond there? Jul 19 16:43:08 let's start here...so the Linux kernel has what we call a "driver model". in this driver model we have an abstraction of the hardware world that represents a relationship between buses, devices, and also drivers that associates with those devices. Jul 19 16:43:59 the bus model started because that's the real world for most things. PCI, USB, etc. Jul 19 16:44:09 and those buses inherently often have a hierarchy Jul 19 16:45:12 now once you had this model and the need for each device to be represented in the kernel as existing on some bus..now you needed a type of virtual bus to contain all the devices representing things that don't necessarily exist under a hierarchical bus Jul 19 16:45:15 that's the platform bus Jul 19 16:45:46 so in typical use the kernel platform bus contains all the devices that are memory mapped in physical address space. Jul 19 16:46:03 now, let's go back and talk about "devices" and "drivers".. Jul 19 16:46:30 regardless of where a device lives..that is, on which bus it is on...it must be paired with a driver in order to do anything useful. Jul 19 16:47:02 so we fundamentally have a representation of every h/w device in a system in the struct device data structure Jul 19 16:47:20 and so there's an instantiation of that for each device Jul 19 16:48:06 now, in order for you to execute code that does something with your h/w you need to pair your device driver code with a device Jul 19 16:48:52 there is bus-specific code that does a process called "matching" where a driver is matched with the instantiated device representation. Jul 19 16:49:54 once a device is matched with a driver, it is probed..that's the entry point to your driver at runtime. if the probe returns successfully, then the driver is then _bound_ to the device abstraction. Jul 19 16:50:09 so backing up to why platform bus is necessary.... Jul 19 16:51:01 so backing up to why platform bus is necessary....like PCI or USB that a device actually lives on..then you typically register the device as a platform bus Jul 19 16:51:36 once you register it then it inherits the matching characteristics of a platform bus device which means it matches with a driver based on a simple string. Jul 19 16:52:20 hmmm Jul 19 16:52:43 so this is why you need to register as a platform bus driver...and you must somehow instantiate a platform device...in order to get your driver to probe. both must exist. Jul 19 16:53:11 now, in full remoteproc with virtio support, you shouldn't need this. Jul 19 16:53:27 as the devices should be instantiated from the PCI-like header of virtio Jul 19 16:53:36 you should be doing a virtio driver. Jul 19 16:54:12 tbh, I need to see what the pru virtio stuff ended up as..I never looked at the capabilities of the current implementation. Jul 19 16:55:03 hmmm Jul 19 16:55:14 the way virtio works is your remoteproc firmware exposes the PCI-like headers..and advertises functionality...that instantiates virtio devices...and drivers are bound to those devices when the remoteproc starts. Jul 19 16:55:35 unfortunately, I have to run to lunch quickly..but will watch from the phone. Jul 19 16:55:48 I'll take a look at the current implementation when I'm back in an hour Jul 19 17:36:26 Visaoni: you're smashing your stack Jul 19 17:37:08 a lot of your head-pounding problems will go away when you stop doing that Jul 19 17:39:10 The changing buffer size gets a new memory layout, sometimes critically bad and sometimes not Jul 19 17:39:25 but moving that receive buffer out into global was the real fix Jul 19 17:40:30 grep STACK gen/*.map Jul 19 17:40:41 abs 00000100 __TI_STACK_SIZE Jul 19 17:42:46 see the Makefile for where it gets set Jul 19 17:43:28 it would need to more than double to safely hold the receive buffer Jul 19 17:44:00 the lab example does *not* put the receive buffer on the stack Jul 19 17:46:24 I think you threw yourself off the trail because you'd been fighting with it too long, commit saying "nope buf location doesn't matter" turned out to be the wrong one, maybe you ran a stale output file at that point Jul 19 17:53:38 Okay mdp, This has made it very clear. Thanks a lot. Jul 19 17:55:13 So basically in order to get the device to match up with the driver, the device must be registered on a bus,only then it will inherit the matching characters of that bus. Jul 19 17:58:29 mdp, Please do look at virtio and let me know. I will also search on this. Jul 19 17:59:14 bradfa,mdp Should I abandon my current approach with the platform bus? And focus on the virtio thing? Jul 19 18:00:50 And I am not sure how to instantiate the PRU as a platform device. bradfa mdp Jul 19 18:03:25 chanakya_vc: I'm not sure I understand the background of your question Jul 19 18:04:42 same here..not full context to understand if you are instantiating the pru device or a virtual device created by running pru firmware. there is a distinct difference. Jul 19 18:05:32 Okay let me put it this way mdp, bradfa Jul 19 18:06:10 https://lwn.net/Articles/448499/ Jul 19 18:06:27 the PRU should be instantiated already Jul 19 18:06:31 or you can't load firmware Jul 19 18:06:44 Here the device is declared by the resources table and filling up the struct platform_device Jul 19 18:06:50 Ohh ds2, Jul 19 18:07:37 you can create the other devices (for the SPI/UART/etc) stuff by - doing virtio magic, hacking the UIO/remote proc driver to create a child device; or just hack the remoteproc/uio drivers to call your init function to register the tty (UART)/spi master/i2c master devices Jul 19 18:07:55 the first is likely the preferred one... the last is likely the quickest path to something Jul 19 18:08:06 * ds2 wants for the tomatos to come flying his way Jul 19 18:08:07 :D Jul 19 18:08:14 So what do I write for resource table? That's my basic doubt. Jul 19 18:08:16 Ohh ds2 Jul 19 18:08:29 think of it this way - Jul 19 18:09:21 the SoC (aka chip) has a block called the PRUSS Jul 19 18:09:42 mdp I guess I meant instantiating of the virtual device. Jul 19 18:09:46 Okay ds2 Jul 19 18:09:55 the underlying code creates the platform device for the PRUSS; the UIO/remote proc stuff is a driver that matches the PRUSS device Jul 19 18:10:02 that is all there is at this point Jul 19 18:10:25 to create your SPI/I2C/UART stuff, you need to load firmware; afterall it is purely a figment of the firmware on the PRUSS that is doing it Jul 19 18:10:40 this is where the virtio and other hacks I mentioned come in Jul 19 18:10:54 you need to tell the system, you have a device that can do UART/I2C/SPI Jul 19 18:11:02 then you attach a driver to that name Jul 19 18:11:09 doe this help? Jul 19 18:11:12 does Jul 19 18:11:49 Okay ds2, I got that the firmware is creating a virtual device that can do SPI/I2C. And then I somehow hack the remoteproc to match the driver to this device Jul 19 18:12:04 chanakya_vc: no! Jul 19 18:12:31 chanakya_vc:the firmware implements a SPI/I2C/UART device Jul 19 18:12:47 at that point, you have various options to tell Linux about the existance of that device Jul 19 18:13:22 Option 1 - get the virtio stuff working (probally the ideal path... might take time to figure out) Jul 19 18:14:20 Option 2 - cheat and tell the remoteproc driver that it has firmware that does only those functions and have it create a child device. This means the remoteproc driver is specifc to your thing. not ideal, but more bits are reuseable for converting to option 1 Jul 19 18:14:22 chanakya_vc: see what I said about the virtio bus...and all the generic driver model description. all of that fundamentally applies here Jul 19 18:15:15 if you implement a compliant virtio device, the subsystem will handle instantiation of the device for you. Jul 19 18:15:16 Option 3 - completely and totally cheat - modify the remote proc driver's probe function to call your driver's init/probe function. Complete hack but allows for very very quick way of getting something.code is less reuseable Jul 19 18:15:41 to repeat what mdp has said earlier in different words - Jul 19 18:15:57 there are 2 parts to getting HW working on Linux under the platform device model: Jul 19 18:16:29 Part 1 - Something has to tell Linux it has a device (be it real physical or a virtual thing). This creates a name and populates a database Jul 19 18:16:48 Part 2 - A driver registers with Linux saying it can control a device with a given name. Jul 19 18:17:15 Once the 2 parts are there, the kernel "magic" will match the names and start up drivers as needed. (start up == calling the driver's probe function) Jul 19 18:18:46 mdp: do stop me if I am muddying things Jul 19 18:18:47 to interject, although option 1 is ideal, I think chanakya_vc may need to resort to option 2 or 3 atm to meet his GSoC goals. Jul 19 18:19:39 ds2 mdp , Okay I get what you are trying to say. When you say virtio compliant device, this is something that the driver that I write has to do right. Because even in case of platform drivers, it is when we populate the struct platform_device in our driver is when the kernel gets to know about the device right? Jul 19 18:19:51 ds2, please continue ;) Jul 19 18:20:01 Or am I wrong in this assumption of mine? Jul 19 18:20:07 chanakya_vc: terminology is critical Jul 19 18:20:36 virtio is dependent on the firmware you write conforming to the virtio spec. Jul 19 18:21:16 chanakya_vc: conceptually yes. the names choosen might be off Jul 19 18:22:05 there is a corresponding device driver for the kernel which will only match to your firmware if it implements the virtio header Jul 19 18:22:22 Okay so my firmware has to conform to the virtio spec in order for the device being implemented by the firmware to be virtio compliant device right? Jul 19 18:22:32 correct Jul 19 18:23:16 you see, there's a virtio subsystem that will look for a well defined header that describes the functionality your firmware exposes Jul 19 18:23:27 chanakya_vc: keep in mind - GSoC's end is not far off. and you should allocate time to docs, debugging, and testing Jul 19 18:23:37 it also defines the resources (number of virtqueues) that it provides Jul 19 18:24:41 ds2, I think we are aligned. so chanakya_vc, were recommending you make it work via option 2 or 3 rather than the ideal option 1 that will take too long. Jul 19 18:25:45 Okay mdp, I will go for whatever you say. Jul 19 18:26:33 mdp: are you one of the offical mentors for chanakya_vc? Jul 19 18:28:21 Yes mdp is one of my official mentors ds2. Jul 19 18:29:02 chanakya_vc: 'k cool... just wanted to make sure things are good with the people that are doing the evals :D Jul 19 18:35:01 mdp, So just so that I am clear with everything you and ds2 have said so far:1) My firmware has to be virtio compliant. Then the firmware has to tell the virtio subsystem about the functionality that it has. Jul 19 18:35:25 2) Then when the remote-proc starts up it bounds the driver to the firmware right? Jul 19 18:36:08 no, we are saying you should not be virtio compliant in the interest of GSoC schedule Jul 19 18:36:34 Yeah that is if we go for option 3 right? Jul 19 18:37:15 chanakya_vc: option 2 doesn't involve virtio Jul 19 18:37:16 you can hack the remoteproc loading driver and just instantiate a device for your spi/i2c for now Jul 19 18:38:07 option 2 or 3 Jul 19 18:38:55 option 3 also doesn't involve virtio Jul 19 18:39:26 * mdp has to go Jul 19 18:39:48 Okay I think I got it. mdp, I will mail you incase of further doubts Jul 19 18:40:26 chanakya_vc: I am here on and off... feel free to shout out questions here (or you can email me if that is easier) Jul 19 18:40:46 ds2, Yup I guess I will have a lot of doubts :P Jul 19 18:41:06 Let me try to understand everything that you have told me today Jul 19 20:24:25 Wormo: hm, that makes sense and I think that's probably it. although I have no clue how I thought it didn't work... I only use that deploy script, which starts with make clean Jul 19 21:22:03 Visaoni: did you try your "real" code yet with buffer pulled out of the stack? Jul 19 21:39:41 Wormo: yep... still not getting anything through the char device Jul 19 21:50:12 Visaoni: did you push the current attempt? Jul 19 21:54:06 Wormo_: done Jul 19 21:58:40 Wormo_: fixed... braindead error on my part Jul 19 21:59:37 so fake data flows and you go on to real data? Jul 19 22:07:52 just about. going to make sure I'm properly getting that data out the other end first (just did a simple test with cat to confirm it works) **** ENDING LOGGING AT Wed Jul 20 02:59:58 2016