From: Steven Saunderson <[email protected]> Sent: Thursday, 26 February 2015, 21:57 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth On Friday, February 27, 2015 at 1:36:43 AM UTC+11, Al Thomas wrote: Why do you use mmap to access the GPIOs and not write to the sysfs files from within the C program? mmap seems good because it avoids the indirection (and interface differences across kernel releases) imposed by the drivers. I can understand that many people might not like this kind of access.
I didn't know the way of referencing GPIO pins had changed for later kernels. Looking at your https://github.com/phelum/CT_Bluetooth/blob/master/usr/local/bin/bt.init I understand now. I was only thinking that at some point using /proc/device-tree/ (or whatever interface this should be if this turns in to a kernel driver) to read the pins could be useful in the general sense. There was some discussion last year about placing those details as a sub-node of the UART in the DTS file:http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/248765.htmlhttp://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/247985.htmlThe Marvell Bluetooth driver has some DTS documentation:https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/btmrvl.txt Do the 3.4 kernel and standard Broadcom program work together without the restart program? If so then maybe the restart program should just be for new kernels with DTS support. Thanks for the insight into what you did with mmap. Al -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
