eQEP on 4.4.19-ti-r41

GoogleGroups
1

Hi:
I’m running BeagleBoard.org Debian Image 2016-08-28 which is running the 4.4.19-ti-r41 kernel. I’ve disabled the HDMI (audio and video) and want to use the eQEPs.

ls /lib/firmware/ | grep -i eqep
bone_eqep0-00A0.dtbo
bone_eqep1-00A0.dtbo
bone_eqep2-00A0.dtbo
bone_eqep2b-00A0.dtbo
PyBBIO-eqep0-00A0.dtbo
PyBBIO-eqep1-00A0.dtbo
PyBBIO-eqep2-00A0.dtbo
PyBBIO-eqep2b-00A0.dtbo

shows I have several options. However none seem to work.

echo bone_eqep1 > $SLOTS
-bash: echo: write error: File exists

dmesg

[Sep14 16:15] bone_capemgr bone_capemgr: part_number ‘bone_eqep1’, version ‘N/A’
[ +0.000075] bone_capemgr bone_capemgr: slot #9: override
[ +0.000045] bone_capemgr bone_capemgr: Using override eeprom data at slot 9
[ +0.000046] bone_capemgr bone_capemgr: slot #9: ‘Override Board Name,00A0,Override Manuf,bone_eqep1’
[ +0.012094] bone_capemgr bone_capemgr: slot #9: bone_eqep1 conflict P8.35 (#4:univ-emmc)
[ +0.008573] bone_capemgr bone_capemgr: slot #9: Failed verification

So it looking like the emmc overlay is controlling the pin.

What’s the correct way to get emmc overlay to let me use the pin?

Do I have to get dtb-4.4-ti and edit am335x-boneblack-emmc-overlay.dtb? If so, what do I edit?

I’m looking for a general approach that I can apply to other pins I want to control.

Thanks…

–Mark

2

Well, I found half my answer. A simple:

config-pin -a P8_11 qep
config-pin -a P8_12 qep

gets the eQEP pin muxes set, but once set how do I export them?

cd /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep
ls
driver_override modalias of_node power subsystem uevent

There are no period, or position files to read.

–Mark

3

echo bone_eqep1 > $SLOTS

-bash: echo: write error: File exists

Yeah, you’re going to get this error whenever you load a device tree file that attempts to mux pins that have already been muxed in a different overlay. At minimum, when using config-pin overlay . I’m not however sure if one would encounter this error when loading overlays when using the standard “traditional” method.

Are the eQEP modules related to the pwm modules ? I do not remember, but if they are, they’ll be listed in /sys/class/pwm . I’ve never used them . . .

4

OK so hopedully this helps you Mark.

debian@beaglebone:~$ ls /sys/devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm
pwmchip5

debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5
device export npwm power subsystem uevent unexport

debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5
device export npwm power subsystem uevent unexport

debian@beaglebone:~$ sudo sh -c “echo ‘0’ > /sys/class/pwm/pwmchip5/export”
debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5
device export npwm power pwm0 subsystem uevent unexport

debian@beaglebone:~$ ls /sys/class/pwm/pwmchip5/pwm0/
duty_cycle enable period polarity power uevent

5

Yeah that probably wont work. It’s probably configuring the eQEP module as a PWM. I don’t know Mark, it seems broken to me.

Nothing of use here:

debian@beaglebone:~$ sudo find / -type d -name ‘qep’
/sys/bus/platform/drivers/eqep
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep
/sys/firmware/devicetree/base/ocp/l4_wkup@44c00000/scm@210000/pinmux@800/pinctrl_eqep2_pins
/sys/firmware/devicetree/base/ocp/epwmss@48300000/eqep@0x48300180
/sys/firmware/devicetree/base/ocp/epwmss@48302000/eqep@0x48302180
/sys/firmware/devicetree/base/ocp/epwmss@48304000/eqep@0x48304180
/sys/firmware/devicetree/base/local_fixups/ocp/epwmss@48300000/eqep@0x48300180
/sys/firmware/devicetree/base/local_fixups/ocp/epwmss@48302000/eqep@0x48302180
/sys/firmware/devicetree/base/local_fixups/ocp/epwmss@48304000/eqep@0x48304180
/sys/module/tieqep

6

Mark, let us know if you figure anything out. I spent a couple hours on trying to figure this out myself - with no joy.

Something seems very broken, but I did recall that the PWM modules exhibit the same behavior, if you do not load the epwmss modules prior to loading the actual pwmx module in a device tree overlay. But I checked the source file for the eqep2b overlay, and all that seems to be in place.

7

William:
Thanks for looking into it. It looks like you got about as far as I did. There is something missing that should make the eQEPs appear.

–Mark

8

Mark,

Did you have any luck solving this? I’m running into the same problem on 4.4.9-ti-r25 and Debian Jessie.

Disabled cape_universal=enable in /boot/uEnv.txt

Set cape_enable=bone_capemgr.enable_partno=bone_eqep1
and also tried various other things. Can’t get config-pin -l to recognize that P8_31, etc are allowed to be eqep.
The ‘fragment’ definitions are in the dts files, but config-pin doesn’t see them.

$ cat /sys/devices/platform/bone_capemgr/slots

0: PF---- -1

1: PF---- -1

2: PF---- -1

3: PF---- -1

6: P-O-L- 0 Override Board Name,00A0,Override Manuf,bone_eqep2

7: P-O-L- 1 Override Board Name,00A0,Override Manuf,bone_eqep1

$ config-pin -l P8_31

default gpio gpio_pu gpio_pd uart

This error looks bad:

[ 456.118649] bone_capemgr bone_capemgr: part_number ‘bone_eqep1’, version ‘N/A’

[ 456.118721] bone_capemgr bone_capemgr: slot #7: override

[ 456.118762] bone_capemgr bone_capemgr: Using override eeprom data at slot 7

[ 456.118809] bone_capemgr bone_capemgr: slot #7: ‘Override Board Name,00A0,Override Manuf,bone_eqep1’

[ 456.134771] platform 48302180.eqep: Cannot lookup hwmod ‘eqep1’

[ 456.156907] eqep 48302180.eqep: ver. 1.0

[ 456.157294] eqep 48302180.eqep: failed to get clock

[ 456.177397] eqep**: probe of 48302180.eqep failed with error -2**

[ 456.177984] bone_capemgr bone_capemgr: slot #7: dtbo ‘bone_eqep1-00A0.dtbo’ loaded; overlay id #1

$ lsmod |grep eqep

tieqep 8758 0

Looks like the driver is failing here

// Get a handle to the system clock object

clk = devm_clk_get(&pdev->dev, “fck”);

if (IS_ERR(clk)) {

dev_err(&pdev->dev, “failed to get clock\n”);

return PTR_ERR(clk);

}

This patch looks interesting. Maybe the same issue?

https://patchwork.kernel.org/patch/9005611/

Brian

9

Mark,

I wonder if loading a slightly older “bone” kernel would do the trick ? I did however read somewhere( possibly on this group ) no long ago that some board file overlays work for some peripherals, and not for others.

10

Did you ever get any further with this? I’m struggling with eQEP on 4.4.36 - but for different reasons

Hugh

11

Are you getting an error?

I am able to use eQEP ok with a rotary encoder on 4.4 kernel:

# uname -a
Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52

# config-pin p8.11 qep
# config-pin p8.12 qep

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-2
<turn the rotary encoder>
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
18

Here are results with 4.1, 4.4 and 4.9:
https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673

-drew

12

I was getting weird values - it turns out I didn’t correctly understand how to use pin-config & the universal overlay. When I configured the pins correctly, everything works.

13

Thanks for following up.

I’ve been using the tieqep module to read absolute position count of a rotary encoder knob. I’m curious what other use cases people have for eQEP?

The reason I ask is I think a new driver needs to be written and it would be good to know which features of the eQEP peripheral should be implemented.

The existing tieqep driver is out of tree and seems unlikely to be included in the mainline Linux kernel. We are able to use it on BeagleBone because Robert includes it as a patch in his kernel builds.

The IIO subsystem now has infrastructure for encoders. I am thinking that an IIO driver should be written for eQEP with the goal of being merged into the mainline kernel.

Thoughts?

-Drew

14

Thanks for following up.

I've been using the tieqep module to read absolute position count of a
rotary encoder knob. I'm curious what other use cases people have for eQEP?

I'm not sure I would have an out of the ordinary use for eqep personally.

The reason I ask is I think a new driver needs to be written and it would
be good to know which features of the eQEP peripheral should be implemented.

Why do you think a new driver needs to be written ?

The existing tieqep driver is out of tree and seems unlikely to be
included in the mainline Linux kernel. We are able to use it on BeagleBone
because Robert includes it as a patch in his kernel builds.

The IIO subsystem now has infrastructure for encoders. I am thinking that
an IIO driver should be written for eQEP with the goal of being merged into
the mainline kernel.

Thoughts?

Thoughts . . .So personally, I really do not like anything IIO. I do not
like the driver, I do not like the IIO "community support", and I think
it's unnecessary for the ADC as it is. However, for simple ADC use cases,
it's what we have, so I put up with it.

But if you're intent on having something IIO, and new driver . . . the ecap
modules probably fits into that category better. The ecap module now, I
could find all kinds of "out of the ordinary" uses for.

15

Why do you think a new driver needs to be written ?

My desire is to get support for eQEP upstream in the mainline Linux kernel. I don’t believe it is easy to get new misc drivers merged. IIO seems to be the only subsystem that is suitable but I’d be interested know of other subsystems that would be appropriate.

But if you’re intent on having something IIO, and new driver . . . the ecap modules probably fits into that category better. The ecap module now, I could find all kinds of “out of the ordinary” uses

eCAP is interesting as there seems to be two modes: capture input, and PWM output. The use of eCAP as PWM output is already supported in mainline as part of epwmss.

However, the eCAP input driver written Matt Porter is still out-of-tree and carried as a patch by Robert. At least this my understanding after chatting with Robert Nelson and Michael Welling last week.

eCAP input seems to be another candidate to upstream. Question is which subsystem fits best.

Thanks
Drew

16

You know I'm not really sure. I've never used the ecap module before, but
my impressions form what I've read that the ecap is similar to a high speed
ADC, except instead of "capturing" voltage levels. ecap captures logic
level transitions. High's, to low, low to highs..

Again I'm not sure for this specific application, in terms of speed, but
imagine a car with a high RPM engine at the drag strip. Where one could
monitor the rotation speed of the engine's cam, and adjust engine timing
based on engine RPM. I've discussed this a few times in the past with a
person talking about maximizing an engines performance curve. But with an
engine operating at let's say 30,000 RPMs, an ADC would need an insane
amount of sample per second. I think at one time we calculated this out to
somewhere around 2-3Msps minimum. With pulse counting however, which is all
you'd really need an ADC for with this application. I think "samples per
second" could be mitigated some.

Of course with this application mentioned above. One would probably have to
use the PRU's, but I'm also not sure in this case if the ecap module, the
PRU's or the beaglebone board in general would be up to the task. Because
not only would one need to count RPM pulses, but one for this application
would have to act on those pulses. The X15 most definitely could handle
this.

Anyway, I'm not sure if that really helps with the question in general.
It's just a thought I've had once in a while for several years now. I have
had other ideas similar to this one where I *think* pulse counting could in
fact be used instead of ADCs. For various other projects I've considered in
the past. *shrug*.

17

I think the primary use for the eQEP is to decode shaft encoders that are being used to replace analog controls for volume control, tuning, tone controls, etc.

In other words, knobs for applications suited for them, but you don’t digitize the analog knob output, you go directly into the digital domain inside the shaft encoder.

There are also some industrial applications for measuring speed (and position) of motors, belts, etc.

The shaft encoder has two switches that open and close in a quadrature “gray code” pattern so you get rotation and un-ambiguous direction of rotation.

The problem is that they usually come in applications greater than two.

We use them for radio controls, but our application uses 12.

So, rather than deal with the vagaries of a real time process running underneath an OS, we just programmed a PIC to watch all 12 simultaneously, and the Linux OS can ask the PIC the status of any or all of the knobs when it gets around to it.

So using the eQEP inside the BBB is fine for learning how shaft encoders work, but I don’t see using it for real world applications with more than one or two knobs.

— Graham