Originally shared by Drew Fustini (pdp7) ``` Any kernel folks have advice on how

Electronics
, ,
1

Originally shared by Drew Fustini (pdp7)

<b>Any kernel folks have advice on how to troubleshoot this?</b>

The @Texas_Instruments  Sitara AM3358 SoC in the BeagleBone has a quaduture encoded pulse decoder peripheral named eQEP.  @Nathaniel_Lewis  wrote a kernel driver for it:
https://github.com/Teknoman117/beaglebot/blob/master/encoders/patches/0001-tieqep-driver.patch

@Robert_Nelson  has been including the patch in the BeagleBone kernel and it is working with 4.4:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.4.y/patches/beaglebone/eqep

I'm attempting to use the eQEP driver with the 4.9.5-ti-r16:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep

I get a Segmentation Fault in eqep_get_position() when I read the sysfs position file:
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position

This readl() runs OK in eqep_probe() from drivers/misc/tieqep.c:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep#L401

Line 697: dev_info(&pdev->dev, "QPOSCNT:0x%08x\n", readl(eqep->mmio_base + QPOSCNT));

The output is seen ok in dmesg:
[   50.589737] eqep 48304180.eqep: eqep->mmio_base:fa304180
[   50.590080] eqep 48304180.eqep: QPOSCNT:0x00000000

However, the same readl() causes a seg fault in eqep_get_position():
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep#L401

Line 401: position = readl(eqep->mmio_base + QPOSCNT);

from dmesg:
[ 1858.085381] DEBUG: tieqep.c: eqep_get_position: QPOSCNT=0
[ 1858.102133] DEBUG: tieqep.c: eqep_get_position: eqep->mmio_base=fa304180
[ 1858.108446] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa304184

These are the eqep enteries in /proc/iomem:
48300180-483001ff : /ocp/epwmss@48300000/eqep@0x48300180
48302180-483021ff : /ocp/epwmss@48302000/eqep@0x48302180
48304180-483041ff : /ocp/epwmss@48304000/eqep@0x48304180

<b>I'm not sure what the difference is. Maybe the io memory mapping changed in between the probe and reading the sysfs file?</b>

More details:
https://gist.github.com/pdp7/fe07082d23f2bfbc362c733a7b0aea72
2

This external abort fault is probably caused by the clock being dynamically disabled by runtime suspend. pm_runtime_get_sync is missing somewhere.

3

Looking at the diff, it works on 4.4 out of sheer luck. There’s nothing guaranteeing clock won’t be gated. Enable pm runtime and call pm runtime get sync as @Michael_Welling said

4

Thanks for the insights @Michael_Welling ​ and @Felipe_Balbi ​!

5

Thanks @Michael_Welling and @Felipe_Balbi ! That did do the trick and @Robert_Nelson has merged the fix :slight_smile:

tieqep: add patch to fix unhandled fault on 4.9 kernel
https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/f89418b8f79dea8a843dab279b7c47c5a4b79ef9

BTW, I think it would good to get eQEP support upstream. Do you have any suggestions as to what subsystem is appropriate?

This driver by @Nathaniel_Lewis currently gets applied to drivers/misc. eCAP is in drivers/pwm, but drivers/iio seems to be a popular place to add new drivers these days.

6

Maybe IIO? I don’t think it currently supports quadrature encoders, but it seems like a fitting API

7

@Felipe_Balbi thanks

8

@Drew_Fustini_pdp7 There is a rotary encoder driver in drivers/input/misc. Not sure this is the best place but it is there.
http://lxr.free-electrons.com/source/drivers/input/misc/rotary_encoder.c

9

Oh and I think you are suppose to have error checking on pm_runtime_get_sync so they may ask for that when mainlining the driver.

10

@Michael_Welling thanks, i’ll check it out

11

Interesting, looks like there is now a driver for a quadrature encoder in IIO for ACCES 104-QUAD-8 by William Breathitt Gray:
drivers/iio/counter/104-quad-8.c
https://lwn.net/Articles/700690/