On Wed, May 14, 2014 at 4:59 AM, Teknoman117 <linux.robotd...@gmail.com>wrote:
> I don't believe that actually will change the I/O configuration. For the > pin ctrl entry to be adopted, it needs to be used by some driver. Turns > out there is a "pinmux helper" device. Check out this blog post: > http://hipstercircuits.com/enable-serialuarttty-on-beaglebone-black/. > More specifically, this section: > > fragment@2 { > target = <&ocp>; > __overlay__ { > test_helper: helper { > compatible = "bone-pinmux-helper"; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_uart5>; > status = "okay"; > }; > }; > }; > > > - Nathaniel > With cape-universal, I believe our new path is to include stuff like this in https://github.com/cdsteinkuehler/beaglebone-universal-io. In that case, you could simply do something like: root@beaglebone:~# config-pin P8.16 qep root@beaglebone:~# config-pin -q P8.16 P8_16 Mode: qep root@beaglebone:~# cat /sys/devices/ocp.3/P8_16_pinmux.24/state qep However, with HDMI enabled, I'm not able to find a valid set of pins to put together an entire eQEP. Further, the entries for an eqep don't seem to be in cape-universal. There has been some discussion if they are necessary, but I haven't been able to expose an eqep as of yet. I'll disable HDMI and reboot next, but can those with experience comment on if something like this is necessary: https://github.com/jadonk/beaglebone-universal-io/commit/5394b3e3813913e2b05253a1f06dbdb9f09341b5 diff --git a/cape-universal-00A0.dts b/cape-universal-00A0.dts index ad5b388..bc6c005 100755 --- a/cape-universal-00A0.dts +++ b/cape-universal-00A0.dts @@ -602,7 +602,7 @@ P9_27_gpio_pd_pin: pinmux_P9_27_gpio_pd_pin { pinctrl-single,pins = <0x1a4 0x27>; }; /* Mode 7, Pull-Down, RxActive */ P9_27_qep_pin: pinmux_P9_27_qep_pin { - pinctrl-single,pins = <0x1a4 0x21>; }; /* Mode 1, Pull-Down, RxActive */ + pinctrl-single,pins = <0x1a4 0x31>; }; /* Mode 1, Pull-Up, RxActive */ P9_27_pruout_pin: pinmux_P9_27_pruout_pin { pinctrl-single,pins = <0x1a4 0x25>; }; /* Mode 5, Pull-Down, RxActive */ P9_27_pruin_pin: pinmux_P9_27_pruin_pin { @@ -752,7 +752,7 @@ P9_92_gpio_pd_pin: pinmux_P9_92_gpio_pd_pin { pinctrl-single,pins = <0x1a0 0x27>; }; /* Mode 7, Pull-Down, RxActive */ P9_92_qep_pin: pinmux_P9_92_qep_pin { - pinctrl-single,pins = <0x1a0 0x21>; }; /* Mode 1, Pull-Down, RxActive */ + pinctrl-single,pins = <0x1a0 0x31>; }; /* Mode 1, Pull-Up, RxActive */ P9_92_pruout_pin: pinmux_P9_92_pruout_pin { pinctrl-single,pins = <0x1a0 0x25>; }; /* Mode 5, Pull-Down, RxActive */ P9_92_pruin_pin: pinmux_P9_92_pruin_pin { @@ -1727,4 +1727,24 @@ }; }; + + /************************/ + /* eQEP */ + /************************/ + + fragment@41 { + target = <&eqep0>; + __overlay__ { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <>; + + count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase offset cha & chb. 1 - Direction mode. cha input = clock, chb input = direction */ + swap_inputs = <0>; /* Are channel A and channel B swapped? (0 - no, 1 - yes) */ + invert_qa = <1>; /* Should we invert the channel A input? */ + invert_qb = <1>; /* Should we invert the channel B input? I invert these because my encoder outputs drive transistors that pull down the pins */ + invert_qi = <0>; /* Should we invert the index input? */ + invert_qs = <0>; /* Should we invert the strobe input? */ + }; + }; }; > > > On Tuesday, May 13, 2014 1:55:00 AM UTC-7, Strawson wrote: >> >> Actually, let me be more specific. I use the pinmux lines and enable the >> PWM Subsystem as follows >> >> fragment@0 { >> target = <&am33xx_pinmux>; >> __overlay__ { >> pinctrl_eqep0: pinctrl_eqep0_pins { >> pinctrl-single,pins = < >> 0x1A8 0x21 /* P9_41 = GPIO3_20 = EQEP0_index, MODE1 >> */ >> 0x1AC 0x21 /* P9_25 = GPIO3_21 = EQEP0_strobe, >> MODE1 */ >> 0x1A0 0x31 /* P9_42 = GPIO3_18 = EQEP0A_in, MODE1 */ >> 0x1A4 0x31 /* P9_27 = GPIO3_19 = EQEP0B_in, MODE1 */ >> >; >> }; >> }; >> }; >> >> fragment@1 { >> target = <&epwmss0>; >> __overlay__ { >> status = "okay"; >> }; >> }; >> >> >> I am not using the following fragment passing parameters to the kernel >> driver >> >> fragment@2 { >> target = <&eqep0>; >> __overlay__ { >> pinctrl-names = "default"; >> pinctrl-0 = <&pinctrl_eqep0>; >> >> count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase >> offset cha & chb. 1 - Direction mode. cha input = clock, chb input = >> direction */ >> swap_inputs = <0>; /* Are channel A and channel B swapped? (0 - >> no, 1 - yes) */ >> invert_qa = <1>; /* Should we invert the channel A input? */ >> invert_qb = <1>; /* Should we invert the channel B input? I >> invert these because my encoder outputs drive transistors that pull down the >> pins */ >> invert_qi = <0>; /* Should we invert the index input? */ >> invert_qs = <0>; /* Should we invert the strobe input? */ >> >> status = "okay"; >> }; >> }; >> >> >> This is for two reasons. Firstly, I don't see how this would change the >> behavior of the hardware if I'm setting the registers anyway. Secondly, it >> fails to load because eqep is not a part of the >> default am335x-boneblack.dtb located in /boot/uboot/dtbo in debian >> >> When trying to load this, dmesg returns >> >> [ 523.086537] bone-capemgr bone_capemgr.9: slot #10: dtbo >> 'bone_eqep0-00A0.dtbo' loaded; converting to live tree >> [ 523.090030] of_resolve: Could not find symbol 'eqep0' >> [ 523.095581] bone-capemgr bone_capemgr.9: slot #10: Failed to resolve >> tree >> >> >> >> In Angstrom, this file was located in /boot/am335x-boneblack.dtb. >> Attached is a modified version of this that was provided by TI and results >> in the eqep dts loading correctly in angstrom. This file has since changed >> in the Debian release and the fix no longer works. As stated in the first >> post in this thread, it would be nice if the correct eqep entries and your >> driver were included in the public image so that this functionality can be >> used out of the box like pwm. >> >> >> On Monday, May 12, 2014 11:53:08 PM UTC-7, Strawson wrote: >>> >>> Hi Nathaniel. The correct device tree fragments are loaded, pins are >>> multiplexed correctly, and all 3 eqep channels work perfectly with your >>> driver. The supplied mmap code from my last post also works perfectly, but >>> only if I insmod the compiled .ko kernel module first. Strange, I know. >>> >>> On Monday, May 12, 2014 11:41:14 PM UTC-7, Teknoman117 wrote: >>>> >>>> I'll certainly take a look at this next week. Currently in the middle >>>> of finals and Maker Faire is this weekend. And in all honesty, once i >>>> figure out whats going on with the driver, its still a good idea to use the >>>> kernel based implementation, mainly because you can take advantage of >>>> hardware interrupts and not have to busy wait. I know there are sleep >>>> methods, but unless something like Xenomai is being used, you're at the >>>> mercy of the scheduler... >>>> >>>> Although, just to rule it out - are you still applying a device tree >>>> overlay? The supplied DTS files do more than just initialize the driver, >>>> they setup the IO configuration, as the default board config doesn't bring >>>> out the eQEP lines. >>>> >>>> - Nathaniel Lewis >>>> >>>> On Saturday, May 10, 2014 12:25:14 AM UTC-7, Strawson wrote: >>>>> >>>>> I believe it is enabled. From my last post: the PWMSS clock config >>>>> returns >>>>> CLKCONFIG 0x111 = 000100010001 >>>>> >>>>> According to pg 1492 of the reference manual, PWMSS_EQEP_EN is bit 4 >>>>> in this register which appears to be true. Furthermore the interrupt >>>>> timer register QUTMR >>>>> is incrementing away just fine. Good idea, but no dice. >>>>> >>>>> For good measure I will write this bit anyway, but with |= instead of >>>>> = since some bits are not writable and I wouldn't want to erase the enable >>>>> bits for pwm and ecap. >>>>> >>>>> >>>>> On Friday, May 9, 2014 11:33:23 PM UTC-7, James Zapico wrote: >>>>>> >>>>>> Strawson, >>>>>> >>>>>> It looks like you're not turning the PWM EQEP clock on. There should >>>>>> be something to accomplish what this line from the kernel driver does: >>>>>> >>>>>> // Enable the clock to the eQEP unit >>>>>> status = pwmss_submodule_state_change(pdev->dev.parent,PWMSS_EQEPCLK_EN >>>>>> ); >>>>>> >>>>>> I haven't tried this out, but it should be something like >>>>>> *(unsigned long*)(pwm_map_base[0]+PWMSS_CLKCONFIG) =PWMSS_EQEPCLK_EN >>>>>> ; >>>>>> >>>>>> - >>>>>> James >>>>>> >>>>>> On Friday, May 9, 2014 9:25:33 PM UTC-5, Strawson wrote: >>>>>>> >>>>>>> it seems my excitement was short-lived. While reading the position >>>>>>> with the previous (and attached) code does work, it only does so when >>>>>>> Teknoman's eqep driver is loaded. I've added writes to set up the PWMSS >>>>>>> and >>>>>>> eQEP configuration registers and have confirmed by reading them back >>>>>>> that >>>>>>> they are set up the same as the driver does. Any ideas on what I'm >>>>>>> missing? >>>>>>> >>>>>>> // Write the decoder control settings >>>>>>> *(unsigned short*)(pwm_map_base[0]+EQEP_OFFSET+QDECCTL) = 0; >>>>>>> // set maximum position to two's compliment of -1, aka UINT_MAX >>>>>>> *(unsigned long*)(pwm_map_base[0]+EQEP_OFFSET+QPOSMAX)=-1; >>>>>>> // Enable interrupt >>>>>>> *(uint16_t*)(pwm_map_base[0]+EQEP_OFFSET+QEINT) = UTOF; >>>>>>> // set unit period register >>>>>>> *(unsigned long*)(pwm_map_base[0]+EQEP_OFFSET+QUPRD)=0x5F5E100; >>>>>>> // enable counter in control register >>>>>>> *(unsigned short*)(pwm_map_base[0]+EQEP_OFFSET+QEPCTL) = >>>>>>> PHEN|IEL0|SWI|UTE|QCLM; >>>>>>> >>>>>>> SYSCONFIG 0xC >>>>>>> CLKCONFIG 0x111 >>>>>>> QEPCTL0 0x9E >>>>>>> QDECCTL0 0x0 >>>>>>> QEINT0 0x800 >>>>>>> QUPRD0 0x5F5E100 >>>>>>> QPOSMAX0 0xFFFFFFFF >>>>>>> QEPSTS0 0xA0 >>>>>>> eqep0: -174 eqep1: 544 e^Cp2: 0 >>>>>>> >>>>>>> >>>>>>> -- > 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 beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
