Damn, now that its in the kernel i'm going to have to maintain backwards compatibility =P.
As far as eQEP goes, I think you can enable eQEP 0 without any conflictions. (P9.42 = eQEP0A_in, P9.27 = eQEP0B_in, P9.25 = eQEP0_strobe, and P9.41 = eQEP0_index -> all at mode 1). I read above someone wanted to see the eQEP hardware in the angstrom device tree - here's a patch just for the device tree file. - Nathaniel Lewis On Thu, May 22, 2014 at 4:11 AM, Jason Kridner <[email protected] > wrote: > On Wed, May 14, 2014 at 4:59 AM, Teknoman117 <[email protected]>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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
From 02dadd6f29d364a47e37f0080046e0a671d69c5c Mon Sep 17 00:00:00 2001 From: Nathaniel Lewis <[email protected]> Date: Wed, 14 May 2014 22:11:12 -0700 Subject: [PATCH] Patch am33xx.dtsi to include device tree nodes for the eQEP units in the SoC --- arch/arm/boot/dts/am33xx.dtsi | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index c1a13a4..bc8502e 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -547,6 +547,16 @@ ti,hwmods = "ehrpwm0"; status = "disabled"; }; + + eqep0: eqep@0x48300180 { + compatible = "ti,am33xx-eqep"; + reg = <0x48300180 0x80>; + interrupt-parent = <&intc>; + interrupts = <79>; + ti,hwmods = "eqep0"; + index = <0>; + status = "disabled"; + }; }; epwmss1: epwmss@48302000 { @@ -575,6 +585,16 @@ ti,hwmods = "ehrpwm1"; status = "disabled"; }; + + eqep1: eqep@0x48302180 { + compatible = "ti,am33xx-eqep"; + reg = <0x48302180 0x80>; + interrupt-parent = <&intc>; + interrupts = <88>; + ti,hwmods = "eqep1"; + index = <1>; + status = "disabled"; + }; }; epwmss2: epwmss@48304000 { @@ -603,6 +623,16 @@ ti,hwmods = "ehrpwm2"; status = "disabled"; }; + + eqep2: eqep@0x48304180 { + compatible = "ti,am33xx-eqep"; + reg = <0x48304180 0x80>; + interrupt-parent = <&intc>; + interrupts = <89>; + ti,hwmods = "eqep2"; + index = <2>; + status = "disabled"; + }; }; sham: sham@53100000 { -- 1.8.4.5
