**** BEGIN LOGGING AT Thu Jun 16 02:59:58 2016 Jun 16 03:05:14 well, at least it loads... Jun 16 03:05:50 https://bpaste.net/show/f16f5a397bb7 <= alexhiam Jun 16 06:23:20 Nerdboy, need device tree binding for the magnetometer I think... (note the exact binding is likely to change) Jun 16 06:26:46 Interesting. Keystone dropped mailboxes which I guess is why the change for pru support in general... Jun 16 06:30:43 Plus if people want devicetree bindings for firmware then talk to ti guys. Probably on their list! Jun 16 06:40:58 you mean ak part is not in the iio beagle branch? Jun 16 06:41:40 gpio/i2c sounds better and better... Jun 16 07:06:54 nerdboy, (sorry was cycling to work) Jun 16 07:07:02 Anyhow, ak part has been supported a long time. Jun 16 07:07:25 Trick is that it is wired up to the externally visible i2c master in the invensens parts. Jun 16 07:07:42 It's in the package, but as far as software is concerned that doesn't matter. Jun 16 07:07:51 So you need to tell it that it is there like any other i2c device. Jun 16 07:08:28 which reg in particular? Jun 16 07:08:45 https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt?h=experimental-beaglefun Jun 16 07:08:49 First example. Jun 16 07:08:50 the main part needs a pwrmgt wake-up Jun 16 07:09:10 ? Jun 16 07:09:24 Not following - in addition to driver load? Jun 16 07:10:06 the 6xxx part starts in sleep mode Jun 16 07:10:25 hmm, should wake when you do a read I think.... Jun 16 07:11:30 https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c?h=experimental-beaglefun Jun 16 07:11:37 All the calls to set_power_itg in there. Jun 16 07:11:50 If not then that's a bug :( Jun 16 07:13:06 The mux stuff should then handle firing up the mpu side to allow access to the ak chip. Jun 16 07:14:24 so which mode applies to which? Jun 16 07:14:26 actually I think that device tree binding for the ak is just setting it up as muxed - so it'll turn up as a separate device. Jun 16 07:14:47 The hmc one is doing the magic to get data into the mpu fifos. Jun 16 07:15:00 needs to be master mode to get slave data automatically? Jun 16 07:15:13 Kind of more messy than that. Jun 16 07:15:30 mpu is always the master really. Jun 16 07:15:43 Has 5 (IIRC) i2c slaves supported. Jun 16 07:15:57 Last one actually forwards a limited subset of i2c type commands. Jun 16 07:16:16 Hence that one was supported for a while as an i2c mux. Jun 16 07:16:23 The ak part can be accessed through that. Jun 16 07:16:33 looks like external-sensors are slaves Jun 16 07:16:36 The automatic capture stuff is on the first 4 of those supported slaves. Jun 16 07:16:49 Yup, they are indeed Jun 16 07:17:03 But those first 4 slaves are dumb. Jun 16 07:17:21 They just support 'here is an address and a number of bytes to read' Jun 16 07:17:32 So you can't do any configuration etc (which is what the last bus is really meant for). Jun 16 07:18:27 Now the fun bit comes in that these chips are often on spi buses. Hence there is some debate over whether the last child i2c bus (general purpose one) should always be a true i2c master, or whether for i2c connections to the mpu it should be a mux. Jun 16 07:18:34 so what's the answer then? Jun 16 07:19:00 Depends if you want to configure that ak part at all, or if the defaults are fine. Jun 16 07:19:14 If you are happy with it's settings then: Jun 16 07:19:25 whatever it is should work with i2c/spi either way Jun 16 07:19:42 yeah, but i2c mux is quicker as there is much less overhead in just pushign stuff on. Jun 16 07:19:58 Anyhow, doesn't really matter as I guess you want the automated fifo capture of data anyway? Jun 16 07:20:09 i mean the part can be wired either way Jun 16 07:20:20 with or without int pin Jun 16 07:20:37 yeah, the int pin is also an issue right now unfortunately.... Jun 16 07:20:41 on grove breakout it's only 4 i2c pins Jun 16 07:20:48 Can do polled reads just fine, but needed to do fast fifo stuff. Jun 16 07:21:07 Stupid decision on grove connectors (always thought that). Jun 16 07:21:31 We did have some patches to take a nasty route around the lack of interrupt. Jun 16 07:21:36 so spi with interrupt is pretty much required for full mag control Jun 16 07:21:59 The right way is to run a thread that checks from time to time (before the fifo can have filled) for how much new data. Jun 16 07:22:16 but "easy" if you're okay with factory calibration? Jun 16 07:22:26 Nah, i2c is fine, just a question of what exactly the device tree bindings look like. Jun 16 07:22:34 (and what is going on locking wise etc) Jun 16 07:22:43 Easyish. Jun 16 07:22:59 Iritatingly that example doesn't cover that case. Can probably figure it out though - give me a sec. Jun 16 07:23:14 (or we can pin Leonard and ask him what it should be as I know he's been testing with that part) Jun 16 07:23:22 or a 9150 anyway. Jun 16 07:23:22 i just want "working" for this project Jun 16 07:23:37 sure, Jun 16 07:23:45 last year needed mag data so he did spi on a breadboard i think Jun 16 07:23:58 *ie not a grove board Jun 16 07:25:07 this year just needs all slave firing on all cylinders so we get a decent compass reading, pressure, and temp/humidity Jun 16 07:27:45 http://pastebin.com/fsDeLqAq Jun 16 07:27:52 i think i need a simple python i2c interface (and without any fancy kalman filtering) Jun 16 07:27:55 Should give data via the fifos. Jun 16 07:28:29 Actually thinking again - to get the simple result you want, might be easier to just use the first example in that doc and have it Jun 16 07:28:34 as a mux. Jun 16 07:29:42 cynical question, does the grove board pin out the interrupt? Maybe a loop wire across to a gpio could be added? Jun 16 07:29:57 what is hmc5833l ? Jun 16 07:30:10 shucks, missed a bit. Jun 16 07:30:14 make that the ak part number... Jun 16 07:30:23 (it's another mag I was cutting and pasting from) Jun 16 07:30:49 i don't think so, i'll need daylight and magnification to check Jun 16 07:31:30 http://pastebin.com/S57VUHJY Jun 16 07:31:36 hmm. is it he seed one? Jun 16 07:31:43 yup Jun 16 07:31:50 http://www.seeedstudio.com/wiki/Grove_-_IMU_9DOF_v2.0 Jun 16 07:31:51 ? Jun 16 07:32:02 pin is there on that picture. Jun 16 07:32:53 http://www.seeedstudio.com/wiki/Grove_-_IMU_10DOF Jun 16 07:32:54 hehe, they've actually pinned out the spi on an extra connector as well + the master i2c bus. Jun 16 07:33:01 nice try ;) Jun 16 07:33:29 pinned out as well on that one ;) Jun 16 07:34:28 i see int thing Jun 16 07:34:42 we'd need to solder a pin in there? Jun 16 07:35:59 is there even a hole there? Jun 16 07:38:34 Looks like in the picture... Jun 16 07:39:06 You'll get better throughput if you do, but for now just lie and pick a plausible interrupt to get the driver to load. Then you can do some testing at least. Jun 16 07:41:09 i have python test code for everything except the magnetometer Jun 16 07:41:43 cool. First option for those bindings should get you up and running with that as well. Jun 16 18:26:23 bradfa, There? Jun 16 18:29:11 alexhiam: what's your licensing criteria for pybbio libraries? Jun 16 18:35:59 and robert just bushed this into bb.org kernel => https://github.com/beagleboard/linux/tree/4.4/drivers/iio/imu/inv_mpu6050 Jun 16 18:36:18 "backports: iio: from: linux.git" Jun 16 21:00:26 bradfa, Working on ioremap.Will push code soon.I will email you the details and some doubts Jun 16 21:33:28 nerdboy: pybbio is under the MIT license, so that's the easiest, but anything compatible Jun 16 22:10:12 hey alexhiam ,Just wanted to ask you about ioremap.Read that it is a derivative of vmalloc. Jun 16 22:10:41 I don't understand why we can't kmalloc? Jun 16 22:10:44 use Jun 16 22:11:19 Because it does not return memory from the address that we want? Jun 16 22:11:44 * chanakya_vc read in ldd3 that it is bad practice to use vmalloc Jun 16 22:13:28 chanakya_vc: right, kmalloc just grabs a contiguous block of memory from wherever it can Jun 16 22:14:21 you want to map a particular block of from the physical memory into your virtual memory Jun 16 22:14:32 Okay alexhiam .But even vmalloc also returns contiguous block of memory Jun 16 22:14:46 I don't get the difference with kmalloc Jun 16 22:15:09 "vmalloc... allocates memory that is only virtually contiguous and not necessarily physically contiguous" Jun 16 22:16:01 with both you get a contiguous block in your virtual memory, but only kmalloc guarantees that it's physically contiguous Jun 16 22:16:24 alexhiam, Okay so both return virtual memory.That userland or kernal device drivers can use Jun 16 22:16:24 * alexhiam is just reading the docs right now and doesn't actually know too much about the particulars of Linux kernel memory... Jun 16 22:16:25 Ohkay got it Jun 16 22:16:36 not return, but allocate Jun 16 22:17:23 alexhiam, IRC client just dropped me without any reason Jun 16 22:17:43 Anyway, ioremap is also based on vmalloc Jun 16 22:18:23 So if the physical memory is not continuous then how come can we be sure that all the data is being stored in the shared mem? Jun 16 22:18:25 alexhiam, ^^ Jun 16 22:20:01 "Like vmalloc, ioremap builds new page tables; unlike vmalloc, however, it doesn't actually allocate any memory. The return value of ioremap is a special virtual address that can be used to access the specified physical address range" Jun 16 22:20:29 it just creates a virtual address that maps to a physical address Jun 16 22:21:16 the page tables being where the virtual->physical address mappings are stored Jun 16 22:21:59 Okay alexhiam .So this is basically completely opposite to DMA right?I mean there there was no concept of virtual addresses? Jun 16 22:23:14 not opposite, just totally different. All this memory access is going through the CPU. DMA is its own subsystem with its own clock that can move chunks of data around independent of the CPU Jun 16 22:24:39 alexhiam, Okay so it would be much faster than all these methods right?Since it is independent of the CPU? Jun 16 22:25:21 depends. You still need to set it up, so it could be much slower if your just moving around 1 byte at a time Jun 16 22:25:57 Yes I would be moving only one byte at one time alexhiam Jun 16 22:26:06 So ioremap is the way to go. Jun 16 22:26:53 no clue, depends on SPI transfer sizes I guess Jun 16 22:27:18 I'd probably start with it Jun 16 22:28:20 Okay alexhiam . Just one more question,if you'd look here: http://www.makelinux.net/ldd3/chp-9-sect-4, the functions are mentioned here. Jun 16 22:29:02 I am unable to understand how to pass the address returned by the request mem function to the write function Jun 16 22:31:44 iowrite function alexhiam. addr is the parameter. So I write addr=struct resource*request_mem() ? Jun 16 22:32:35 chanakya_vc: read the paragraph after check_mem_region Jun 16 22:33:27 Okay I haven't read ch 8 :P alexhiam Jun 16 22:33:38 Will go through it. Jun 17 01:55:27 hmmm quiet day **** ENDING LOGGING AT Fri Jun 17 02:59:58 2016