Ah ok, I do actually mean to use P8.26 which I think is GPIO1_29. I am using a 3.8 kernel, any way to check at all if it is fixed or not as well?
On 29 January 2014 at 19:19:00, [email protected] ([email protected]) wrote: On 28/01/14 15:18, [email protected] wrote: > I have what I think is a working DTS as the UART is working fine but I cannot > get the system to read the PPS from a GPS unit I have connected. > > Below is my DTS and the UART 4 is working fine and I have the GPS's PPS > connected to P8-26 and so I'm hoping my DTS puts it into Mode7 on that pin. > > PPS support is inside my kernel > > Any ideas at all? I haven't specifically tried PPS through devicetree yet, however.. gps_pps_pins: pinmux_gps_pps_pins { pinctrl-single,pins = <0x7c 0x27 /* P8.26 gpio1_29 */ > >; and pps { compatible = "pps-gpio"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&gps_pps_pins>; gpios = <&gpio2 7 0 >; assert-rising-edge; }; are using two different gpio pins. You're setting the pinmux for gpio1_29 then telling pps-gpio to use gpio2_7 Also you should be aware that this will depend on which kernel version you're using. Some kernels have the &gpio2 reference off-by-one which means that: 0x7c 0x27 /* P8.26 gpio1_29 */ would be referred to as &gpio2 29 as someone ignored the docs which use gpio0,gpio1,gpio2,gpio3 and called them 1-4 instead.. That's fixed in other kernels, but it does mean that your overlay needs to be different for each kernel. Similar off-by-one problems exist elsewhere in the BBB dts, so it's sometimes wise to use dtc to decompile the main dtb and backtrace the references to see if it's really referring to what you think it is! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" 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/groups/opt_out.
