**** BEGIN LOGGING AT Fri Mar 18 02:59:58 2016
**** BEGIN LOGGING AT Fri Mar 18 04:53:32 2016
Mar 18 05:23:36 <nerdboy> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_5:_RPMsg_Communication_between_ARM_and_PRU
Mar 18 05:23:48 <nerdboy> kernel sample drivers even
Mar 18 05:27:05 <nerdboy> pretty sure there's a native cgt package to install on bbb
Mar 18 05:27:31 <nerdboy> otherwise the above has cross-compile examples using ti/linaro toolchains
Mar 18 15:06:33 <pmezydlo> bradfa: what do you think about my application?
Mar 18 15:08:16 <bradfa> pmezydlo: I did a quick read through this morning, overall I think it looks pretty good!
Mar 18 15:08:27 <bradfa> pmezydlo: I think you should remove the hardware parts
Mar 18 15:09:09 <bradfa> pmezydlo: I think you should expand upon the last bit where you point to some existing people asking about SPI slave implementation, to better cover actual Linux code proposals and what their shortcomings are
Mar 18 15:10:41 <pmezydlo> bradfa: I think it's a good idea
Mar 18 15:12:25 <pmezydlo> bradfa: well I will try to remove the things of hardware
Mar 18 15:13:14 <pmezydlo> bradfa: In monday will send a second proposal
Mar 18 15:20:31 <bradfa> pmezydlo: ok, good! :)
Mar 18 15:21:06 <bradfa> pmezydlo: I believe students are being encouraged to start putting their draft proposals into the official google system, as students can continue to modify their proposals up until the submission date
Mar 18 15:23:21 <alexhiam> anyone seen carpediem in here recently?
Mar 18 15:28:03 <alexhiam> I was looking forward to their proposal, and now they seem to have completely disappeared :|
Mar 18 16:06:29 <cdesai_> Hi, I would like to apply for GSoC
Mar 18 16:06:29 <cdesai_> I'm interested in the idea "FlightGear remote Cockpit on BBB"
Mar 18 16:07:56 <cdesai_> While I don't have any UI experience, I'm an avid aviation fan, and have played a lot of flightgear (and other sims).
Mar 18 16:07:56 <cdesai_> I do have some general programming experience as well, mainly with android (firmware development)
Mar 18 16:11:43 <Zephman> Hi
Mar 18 16:33:04 <kiran4399> alexhiam: I am little confused about the kernel part..
Mar 18 16:34:04 <kiran4399> alexhiam: There is only mpu9250 kernel driver and pru servo kernel driver which have to be developed.. right??
Mar 18 16:34:17 <kiran4399> alexhiam: every other driver is already present..
Mar 18 17:45:02 <kiran4399> jkridner: ping :)
Mar 18 18:02:43 <alexhiam> kiran4399: I'm not sure. Have you looked for drivers for the other parts?
Mar 18 18:03:10 <kiran4399> alexhiam: yeah..
Mar 18 18:03:15 <kiran4399> all of them seem to be inplace..
Mar 18 18:03:44 <ds2> develop MPU9250 driver?!
Mar 18 18:04:12 <ds2> something wrong with the existing drivers?
Mar 18 18:04:14 <kiran4399> ds2: mpu9250 and pru servo drivers are the only things which need to be developed..
Mar 18 18:04:23 <ds2> why?
Mar 18 18:04:38 <kiran4399> ds2: well, all the others are already present..
Mar 18 18:04:42 <ds2> what kind of servos is the PRU hooking up to?
Mar 18 18:04:56 <ds2> kiran4399: there should be a driver for the mpu9250 already
Mar 18 18:05:14 <kiran4399> ds2: not in the kernel..
Mar 18 18:05:19 <kiran4399> it is not yet present..
Mar 18 18:05:29 <alexhiam> kiran4399: cool. Also be sure to look into the current state of the invensense driver, I saw some invensense code recently in android I think that looked like it might actually fully support the 9250
Mar 18 18:05:35 <nerdboy> which version/branch?  was that in linux-next queue?
Mar 18 18:05:37 <ds2> kiran4399: i see emails for fixes to it
Mar 18 18:05:49 <alexhiam> I think it might just be an older version that's currently in mainline
Mar 18 18:05:52 <ds2> so either it is fixing non existant drivers or....
Mar 18 18:06:07 <ds2> kiran4399: are you looking for MPU 9250 explicitly?
Mar 18 18:06:16 <alexhiam> ds2: that's what's on the beaglebone blue
Mar 18 18:06:35 <kiran4399> https://github.com/beagleboard/linux/tree/4.1/drivers/iio/imu
Mar 18 18:06:58 <nerdboy> you should look at 4.4
Mar 18 18:07:00 <ds2> alexhiam: the driver might not be under that explicit name
Mar 18 18:07:01 <alexhiam> we want to make sure it's fully supported in beagleboard/linux, which may just mean grabbing a patch from mainline or android
Mar 18 18:07:06 <ds2> let me look for the datasheet
Mar 18 18:07:35 <nerdboy> latest patches are in robert's queue i think
Mar 18 18:07:43 <alexhiam> ds2: yeah, I think there's a general invensense driver in android that supports all of them through some config values
Mar 18 18:07:56 <nerdboy> then they go to denys/ti-staging
Mar 18 18:08:38 <ds2> kiran4399, alexhiam: please read the product page and search for other names - http://www.invensense.com/products/motion-tracking/9-axis/mpu-9250/
Mar 18 18:08:40 <ds2> sigh
Mar 18 18:09:39 <nerdboy> students looking at pru/kernel stuffs should really be going through the ti examples
Mar 18 18:09:47 <ds2> and as for the servos...
Mar 18 18:09:51 <nerdboy> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_5:_RPMsg_Communication_between_ARM_and_PRU
Mar 18 18:10:38 <alexhiam> ds2: lol, is that a sigh of it's right there on the product page?
Mar 18 18:11:00 <ds2> alexhiam: that page should have been the starting point that tells you what to look for
Mar 18 18:11:11 <nerdboy> if you think it's too easy try it with am33x-v4.5 (Stable) kernel
Mar 18 18:11:17 <ds2> a driver specifically for the MPU9250 makes no sense if that page has been seen
Mar 18 18:12:02 <ds2> and if you check mailing list archives, there have been drivers posted on various ML's for quite a while
Mar 18 18:13:12 <alexhiam> cool, well then kiran4399, that's just a matter of making sure the right patches get to beagleboard/linux
Mar 18 18:13:12 <nerdboy> maybe look at their sdk even
Mar 18 18:14:20 <nerdboy> meh, need to make an account just to see their developer stuff
Mar 18 18:22:33 <nerdboy> "Embedded MotionDriver 6.12 is our first ever 9-axis solution not locked to a specific MCU.Version 6.1.2 is an update to 6.1 that includes bug fixes and new libraries. This release is supported across all ARM Mx core architectures and supports the InvenSense MPU-6000, 6050, 6500, 9150, and 9250"
Mar 18 18:23:24 <alexhiam> what's the license on that?
Mar 18 18:23:58 <chanakya_vc> Hey alexhiam I have written the hello world driver.Please have a look https://github.com/chanakya-vc/BBB-Gsoctry/tree/master/Drivers
Mar 18 18:24:54 <alexhiam> chanakya_vc: cool, and you've compiled and loaded it?
Mar 18 18:25:28 <kiran4399> alexhiam: I think we need not even write the pru_servo driver..
Mar 18 18:25:31 <chanakya_vc> Yes.I did
Mar 18 18:25:37 <kiran4399> alexhiam: it's already there..
Mar 18 18:25:41 <kiran4399> alexhiam: did you see?
Mar 18 18:25:54 <alexhiam> kiran4399: in the ardupilot stuff?
Mar 18 18:26:12 <kiran4399> alexhiam: yeah... the other day m_w showed.
Mar 18 18:26:12 <chanakya_vc> In fact I have provided the instructions to compile and the makefile there.
Mar 18 18:26:13 <kiran4399> remember?
Mar 18 18:26:27 <ds2> isn't a pull require part of it?
Mar 18 18:26:48 <alexhiam> kiran4399: I remember there was some pru firmware. I didn't look to see if there was a kernel driver as well
Mar 18 18:26:57 <kiran4399> let me give you the link
Mar 18 18:28:24 <kiran4399> alexhiam: https://github.com/diydrones/ardupilot/tree/master/Tools/Linux_HAL_Essentials/pru/aiopru..
Mar 18 18:28:33 <kiran4399> is'nt this a driver?
Mar 18 18:28:47 <alexhiam> yuck, mmap!
Mar 18 18:29:08 <alexhiam> nope, that's a userspace program
Mar 18 18:29:10 <ds2> unless you are doing file access or getting fresh memory....
Mar 18 18:29:21 <alexhiam> a good example of what we don't want happening
Mar 18 18:29:54 <alexhiam> ds2: yeah, 'yuck mmap instead of kernel' driver is what I mean
Mar 18 18:30:11 <ds2> *nod*
Mar 18 18:30:25 <nerdboy> the intarweb is over-full of examples of how not to do it...
Mar 18 18:30:57 <nerdboy> some are pretty hilarious even
Mar 18 18:31:18 * alexhiam has a detailed blog post about how to use it the wrong way on the beaglebone ;)
Mar 18 18:31:35 <ds2> it is hilarious til you get asked to fix it :D
Mar 18 18:32:29 <chanakya_vc> alexhiam, What should I so next regarding the driver?
Mar 18 18:33:30 <alexhiam> ¯\_(ツ)_/¯
Mar 18 18:33:31 <gcl-bot> UnicodeEncodeError: 'ascii' codec can't encode character u'\xaf' in position 0: ordinal not in range(128) (file "/home/ahiam/.sopel/modules/gitter_bridge.py", line 52, in ircToGitter)
Mar 18 18:33:52 <alexhiam> whoa... sorry there gcl-bot
Mar 18 18:34:13 <ds2> Hmmmm do I see an exploit somewhere? ;)
Mar 18 18:34:16 <alexhiam> I guess my gitter bridge doesn't like unicode...
Mar 18 18:34:18 * nerdboy fixes that kind of crap almost every day...
Mar 18 18:35:09 * alexhiam is blindly trusting some random python irc bot framework on one of his servers....
Mar 18 18:35:12 <nerdboy> that bug crops up a lot of places
Mar 18 18:37:11 <nerdboy> trac git interface for example...
Mar 18 18:37:16 <alexhiam> lol, really python2.7? you don't support unicode in your string.format() method?!
Mar 18 18:38:12 <nerdboy> ds2: don't look at perl configure if you want to stay sane...
Mar 18 18:39:01 <nerdboy> it's even nice enough to silently fail and replace libc functions with broken crap and then try to build anyway
Mar 18 18:39:43 <alexhiam> I would kinda prefer my irc bot silently failing over directing stderr to the irc channel...
Mar 18 18:40:27 <alexhiam> ok, let's try that again...
Mar 18 18:40:28 <alexhiam> ¯\_(ツ)_/¯
Mar 18 18:40:36 <alexhiam> much better
Mar 18 18:40:49 <alexhiam> gcl-bot: .weather
Mar 18 18:40:49 <gcl-bot> Yahoo! Weather - Brattleboro, VT: Partly Cloudy, 7°C (44°F), Humidity: 57%, Gentle breeze 4.5m/s (↓)
Mar 18 18:41:21 <nerdboy> that is not a gentle breeze...
Mar 18 18:41:59 <alexhiam> it also looks perfectly still out...
Mar 18 18:43:41 <nerdboy> sort of maybe...
Mar 18 18:44:29 <ds2> miles per second?
Mar 18 18:45:42 <nerdboy> hopefully it's meters...
Mar 18 18:46:01 <alexhiam> I think I'd have noticed if it was miles
Mar 18 18:47:22 <nerdboy> you'd also be on saturn...
Mar 18 18:47:49 <ds2> if you got a decent basement...
Mar 18 18:50:06 <nerdboy> so, something tells me their not-so-open license on 6.x driver package is not what's in the kernel...
Mar 18 18:51:06 * nerdboy fetches recent kernel commits
Mar 18 18:51:08 <alexhiam> there's this https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-fr2/drivers/staging/iio/imu/inv_mpu/README
Mar 18 18:52:06 <nerdboy> i don't think you want a fork that old...
Mar 18 18:52:34 <alexhiam> nope, but clearly it's been around for a while
Mar 18 18:52:54 <alexhiam> I haven't looked to see if that's in mainline
Mar 18 18:53:07 <nerdboy> can't really infer that much from backported vendor fork
Mar 18 18:53:44 <nerdboy> brittle pieces of crap mostly...
Mar 18 18:54:21 <ds2> okay food time
Mar 18 18:54:31 <nerdboy> mostly they suck horribly at upstreaming
Mar 18 18:54:58 <nerdboy> so they patch until things explode if you make one tiny config change...
Mar 18 18:55:18 <nerdboy> <cough> chromeos <cough>
Mar 18 18:56:42 * nerdboy waiting patiently for git kernel fetch
Mar 18 18:58:05 <kiran4399> alexhiam: when the kernel driver is enabled for let us say an imu device which is onboard... how does the processor know where the device is?? I mean the address of the onboard device..
Mar 18 18:58:15 <kiran4399> will it be mentioned in the overlay file?
Mar 18 18:58:16 <nerdboy> remotes/origin/linux-4.5.y <= checkiing here first
Mar 18 18:58:52 <kiran4399> alexhiam: and will it be interfaced via some kind of protocol like i2c or uart or spi?
Mar 18 18:59:01 <nerdboy> probably depends on the driver/module parameters
Mar 18 18:59:12 <kiran4399> alexhiam: I am sorry for this naive question... :-P
Mar 18 18:59:53 <nerdboy> kiran4399: some drivers are both 12c/spi, sometimes they're separate
Mar 18 19:00:14 <alexhiam> that depends on the device of course
Mar 18 19:00:28 <alexhiam> the mpu-9250 has both i2c and spi I believe
Mar 18 19:01:43 <chanakya_vc> alexhiam, What would should I do regarding the device driver next?I have given the complete instructions for compiling it in the readme file for the hello world driver.
Mar 18 19:01:52 <chanakya_vc> *should
Mar 18 19:02:46 <chanakya_vc> I mean what should I try to code next?
Mar 18 19:02:52 <alexhiam> chanakya_vc: have you gotten feedback on your proposal yet? Have you got some pru code working and on github?
Mar 18 19:03:26 <chanakya_vc> ds2 asked me a couple of questions on the ml.I am still working on that.
Mar 18 19:03:29 <nerdboy> Your branch is behind 'origin/master' by 56623 commits, and can be fast-forwarded.
Mar 18 19:04:00 <chanakya_vc> alexhiam, No I haven't.Should I work on that next?
Mar 18 19:04:54 <alexhiam> chanakya_vc: I'd say any proposal updates are a higher priority, then some pru code would be good
Mar 18 19:07:13 <nerdboy> okay, in linux-4.5.y i got:
Mar 18 19:07:19 <nerdboy> drivers/iio/imu/inv_mpu6050
Mar 18 19:07:25 <nerdboy> drivers/input/misc/mpu3050.c
Mar 18 19:07:30 <nerdboy> that's it
Mar 18 19:07:48 <alexhiam> sounds the same as 4.1
Mar 18 19:07:56 <alexhiam> or beagleboard/linux 4.1 at least
Mar 18 19:11:05 <chanakya_vc> alexhiam,Just wanted to ask that when you were talking about implementing a circular buffer to give communication between the driver and shared mem,would data and parameters both be written to a such a circular buffer?
Mar 18 19:11:39 <alexhiam> they could be
Mar 18 19:11:43 <chanakya_vc> In case of SPI,where we require a shift register,wouldn't a linear buffer be better?
Mar 18 19:11:44 <nerdboy> i guess "we" should look at their new driver license
Mar 18 19:12:10 <nerdboy> it does say "distribute" but with weird restrictions
Mar 18 19:12:40 <alexhiam> chanakya_vc: getting the data from the arm to the pru is different than shifting out the bytes
Mar 18 19:12:41 <nerdboy> could be okay for bb stuff, but IANAL...
Mar 18 19:13:18 <nerdboy> it's not a coincidence that acronym has "anal" in it...
Mar 18 19:13:50 <alexhiam> you certainly wouldn't be shifting the data out of shared memory a bit at a time, so a 'shift register' type abstraction there doesn't really make sense
Mar 18 19:14:10 <alexhiam> lol
Mar 18 19:14:30 <nerdboy> streaming data would be a little better...
Mar 18 19:18:01 <nerdboy> the driver has chip name as parameter
Mar 18 19:18:42 <nerdboy> maybe it does take the new one
Mar 18 19:19:47 <chanakya_vc> alexhiam,Okay. So as I understand it I could write the parameters and data into two such buffers and then perhaps the PRU's would read from these buffers right?
Mar 18 19:20:02 <chanakya_vc> Would you prefer this or using rpmsg?
Mar 18 19:20:42 <alexhiam> no idea, that depends on which is better suited for the use case, which would require some looking into and testing
Mar 18 19:20:58 <alexhiam> but any config stuff could also just be sent in downcalls
Mar 18 19:23:11 <nerdboy> hang on a sec, lemme look at another kernel fork
Mar 18 19:24:01 <chanakya_vc> alexhiam,Okay. So if in my proposal if I were to write that I would be using circular buffers and at a later stage the me and mentors would feel that rpmsg would be better,you would not expect me to deviate from anything written in the proposal
Mar 18 19:24:30 <chanakya_vc> alexhiam, Given the time constraints for the proposal?
Mar 18 19:25:43 <alexhiam> not sure what you mean... obviously you can't predict everything, it would be fine to mention a couple possible ways to do it and how you might do some performance testing to see what's better
Mar 18 19:25:55 <alexhiam> and speculate as to why one might be better than the other
Mar 18 19:26:23 <hpfmn> could somebody tell me about PRU and access to main memory? is it possible to load off work to a PRU and have it operating on the main memory (a buffer between the A8 and PRU)?
Mar 18 19:27:13 <alexhiam> hpfmn: yeah, you can have shared memory between the arm and the pru
Mar 18 19:27:44 <nerdboy> hpfmn: seen the ti stuff?
Mar 18 19:27:59 <nerdboy> er, pru docs
Mar 18 19:28:12 <hpfmn> nerdboy: which document do you refer to?
Mar 18 19:28:44 <chanakya_vc> alexhiam, I was just asking whether I would have to make the choice between rpmsg or the circular buffer before I submit my proposal and will that choice be binding or not :)
Mar 18 19:29:37 <nerdboy> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_5:_RPMsg_Communication_between_ARM_and_PRU
Mar 18 19:29:44 <nerdboy> that stuff
Mar 18 19:30:00 <nerdboy> and the example kernel drivers
Mar 18 19:30:00 <alexhiam> ok, then the answer is no, but it would be good to see some pros and cons of each in your proposal
Mar 18 19:30:02 <hpfmn> thx nerdboy
Mar 18 19:30:54 <nerdboy> enable sample code under kernel hacking i think...
Mar 18 19:31:28 <nerdboy> *pru sample code
Mar 18 19:33:38 <nerdboy> chanakya_vc: if you haven't looked at pru sample driver code in the kernel yet, then you should do that now
Mar 18 19:34:17 <chanakya_vc> nerdboy,the link that you gave above?
Mar 18 19:35:54 <nerdboy> the actual source in the kernel
Mar 18 19:36:10 <nerdboy> but also the TI stuff if you haven't looked yet
Mar 18 19:37:56 <chanakya_vc> nerdboy,Could you please give me the links to it?I am unable to follow the sample driver you are referring to.
Mar 18 19:38:16 <nerdboy> it's in that ti doc
Mar 18 19:38:37 <nerdboy> but you can look at your local kernel source
Mar 18 19:38:46 <nerdboy> make menuconifg
Mar 18 19:38:53 <nerdboy> menuconfig even
Mar 18 19:40:18 <nerdboy> Kernel hacking  ---> Sample kernel code  ---->  Build rpmsg client sample -- loadable modules only
Mar 18 19:40:34 <alexhiam> that's in 4.1?
Mar 18 19:41:08 <nerdboy> should be
Mar 18 19:41:20 <alexhiam> cool
Mar 18 19:41:23 <nerdboy> linux-4.4.x is what i'm looking at
Mar 18 19:41:30 <nerdboy> but it's in the TI docs
Mar 18 19:42:11 <nerdboy> other examples too
Mar 18 19:43:03 <nerdboy> hopefully that answers/forestalls repeated questions...
Mar 18 19:43:54 <chanakya_vc> nerdboy,this link? http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
Mar 18 19:44:16 <chanakya_vc> All the examples seemed to mentioned here only.
Mar 18 19:45:20 <nerdboy> ti is kinda the best place to look for ti developer stuff
Mar 18 19:45:54 <nerdboy> best/first/obvious/whatever
Mar 18 19:47:19 <nerdboy> drivers/rpmsg/virtio_rpmsg_bus.c =>
Mar 18 19:47:22 <nerdboy>  * This structure stores the rpmsg state of a given virtio remote processor
Mar 18 19:47:22 <nerdboy>  * device (there might be several virtio proc devices for each physical
Mar 18 19:47:23 <nerdboy>  * remote processor).
Mar 18 19:47:44 <nerdboy> use the source, luke...
Mar 18 19:48:55 <nerdboy> Copyright (C) 2011, so yeah, probably been there for a while
Mar 18 19:49:03 <nerdboy> just well hidden...
Mar 18 19:59:15 <chanakya_vc> nerdboy,I think remoteproc is the driver in linux that supports the basic I/o operations for PRU along with the rpmsg Linux driver?
Mar 18 19:59:43 <chanakya_vc> You would be referring to both of these only right?
Mar 18 20:00:08 <nerdboy> s/only//
Mar 18 20:00:42 <nerdboy> i mainly hack stuff at the packaging/OS level
Mar 18 20:01:23 <chanakya_vc> nerdboy,Okay.
Mar 18 20:01:27 <nerdboy> the ti docs, beagle wiki, hands on labs should make things clear mostly
Mar 18 20:02:02 <nerdboy> you have an existing virtio rpmsg interface
Mar 18 20:02:31 <chanakya_vc> nerdboy, Yes.So you would suggest using that only?
Mar 18 20:03:02 <nerdboy> i would suggest following that same model
Mar 18 20:03:03 <chanakya_vc> For ARM to PRU communications?
Mar 18 20:03:36 <nerdboy> looks to me like you need to code an interface for that virtio driver
Mar 18 20:04:11 <nerdboy> so you can talk to the virtio_rpmsg_bus
Mar 18 20:04:27 <nerdboy> go back to the last lab
Mar 18 20:04:52 <nerdboy> didn't you build a pru/led blinky example?
Mar 18 20:05:01 <chanakya_vc> Yes will do that.I need to research a bit more about this rpmsg.
Mar 18 20:05:13 <chanakya_vc> I did that using PRUspeak
Mar 18 20:05:20 <nerdboy> just follow the lab, then research
Mar 18 20:05:30 <nerdboy> do the virtio one
Mar 18 20:05:57 <chanakya_vc> Okay.Will do that.
Mar 18 20:06:09 <chanakya_vc> And perhaps upload to github
Mar 18 20:06:19 <chanakya_vc> with certain modifiactions and changes
Mar 18 20:07:08 <chanakya_vc> modifications.If that's allowed?If TI allows that.
Mar 18 20:10:26 <chanakya_vc> alexhiam, Just wanted to ask you that after the data is written into the circular buffer in the shared mem,we would transfer it to data rams of the two PRU's right?
Mar 18 20:10:57 <chanakya_vc> for the bitbanging operation to take place right?
Mar 18 20:11:05 <alexhiam> yeah
Mar 18 20:14:23 <chanakya_vc> For that we would have to read the buffer element by element.So wouldn't that result in a bit by bit transfer?Like you said before that would be extremely slower right?
Mar 18 20:14:23 <nerdboy> the rpmsg sample driver is only in bb/ti/rcn kernels
Mar 18 20:14:56 <chanakya_vc> alexhiam, No other way of doing it I suppose.
Mar 18 20:15:08 <alexhiam> chanakya_vc: reads from the shared mem are not 1 bit
Mar 18 20:15:59 <chanakya_vc> Okay.I guess I need to read up on this.
Mar 18 20:17:54 <chanakya_vc> nerdboy, Thanks for the mail :)
Mar 18 21:36:44 <nerdboy> hopefully everyone is busy building firmware and kernel examples...
Mar 19 00:08:30 <nerdboy> so i guess drivers/input/misc/mpu3050.c is the "old" style mpu gyro interface
Mar 19 00:08:53 <nerdboy> based on a completely different chip driver
Mar 19 00:09:19 <nerdboy> bma023.c whatever that is...
Mar 19 00:10:00 <nerdboy> current drivers for bma180 and bma150
Mar 19 00:10:49 <nerdboy> 150 is also input/misc but 180 is iio interface
Mar 19 00:11:07 <nerdboy> so, examples abound...
**** ENDING LOGGING AT Sat Mar 19 02:59:58 2016