v4.9.x-ti now open for testing...

[Robert Nelson]

Hey Everyone,

Over the weekend, TI imported and tagged there first v4.9.x branch:

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.9.y

I've added our patchset, overlays are broken past the first i2c
address: (havn't tried with a board plugged in)

debian@beaglebone:~$ dmesg | grep bone
[ 2.101727] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 2.101753] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.101796] bone_capemgr bone_capemgr: Failed to add slot #1
[ 2.126911] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 2.126940] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.126971] bone_capemgr bone_capemgr: Failed to add slot #1
[ 2.360973] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 2.361012] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4

cpufreq is broken, this should be fixed pretty soon..

HDMI-Audio: this is new and went mainline in v4.9.x-rc, fingers
crossed, it should work so please test. ;) ( i finally have a lcd
monitor (with audio) that i can finally test with. .;) )

pru: nothing yet..

eqep: needs porting..

Kernel should hit the apt repo in a day or two, i'll reply to this
message when ready...

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --ti-channel --lts-4_9

(no rt yet)

SRC is here:

https://github.com/beagleboard/linux/tree/4.9

https://github.com/beagleboard/linux/commits/4.9

The best way to build it is via yakbuild:

git clone https://github.com/RobertCNelson/yakbuild
cd ./yakbuild/
cp recipe.sh.v4.9.x.sample recipe.sh
./build_kernel.sh

While the dtb's can be built/tested via dtb-rebuilder

#this is one line..
git clone -b 4.9-ti https://github.com/RobertCNelson/dtb-rebuilder/
cd ./dtb-rebuilder/
make

status
v4.4.x-ti - still supported and on-going working
v4.1.x-ti - maintenance-only please upgrade to v4.4.x-ti
v3.14.x-ti - maintenance (really eol)
v3.8.13-bone - maintenance, probably never EOL... (i see another gcc6
patch coming on the horizon). ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

On Tue, Nov 1, 2016 at 5:08 AM, Pantelis Antoniou
<pa...@antoniou-consulting.com> wrote:
> Hi Robert,

>
>
>> On Oct 31, 2016, at 23:46 , Robert Nelson <robert...@gmail.com> wrote:
>>
>> Hey Everyone,
>>
>> Over the weekend, TI imported and tagged there first v4.9.x branch:
>>
>> http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.9.y
>>
>> I've added our patchset, overlays are broken past the first i2c
>> address: (havn't tried with a board plugged in)
>>
>> debian@beaglebone:~$ dmesg | grep bone
>> [ 2.101727] bone_capemgr bone_capemgr: Baseboard:
>> 'A335BNLT,00C0,2516BBBK2626'
>> [ 2.101753] bone_capemgr bone_capemgr:
>> compatible-baseboard=ti,beaglebone-black - #slots=4
>> [ 2.101796] bone_capemgr bone_capemgr: Failed to add slot #1
>> [ 2.126911] bone_capemgr bone_capemgr: Baseboard:
>> 'A335BNLT,00C0,2516BBBK2626'
>> [ 2.126940] bone_capemgr bone_capemgr:
>> compatible-baseboard=ti,beaglebone-black - #slots=4
>> [ 2.126971] bone_capemgr bone_capemgr: Failed to add slot #1
>> [ 2.360973] bone_capemgr bone_capemgr: Baseboard:
>> 'A335BNLT,00C0,2516BBBK2626'
>> [ 2.361012] bone_capemgr bone_capemgr:
>> compatible-baseboard=ti,beaglebone-black - #slots=4

Okay, i've bisected this down too the i2c merge:

https://github.com/torvalds/linux/compare/2ab704a47e0f27df758840a589aec3298dbb98dd...87840a2b7e048018d18d60bdac5c09224de85370

at first glance, this looks interesting...

https://github.com/torvalds/linux/commit/00f0ea70d2b82b7d7afeb1bdedc9169eb8ea6675

ddebian@beaglebone:~$ dmesg | grep bone
[ 5.406775] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 5.414178] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 5.422573] bone_capemgr bone_capemgr: Failed to add slot #1
[ 5.435891] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 5.443266] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 5.451642] bone_capemgr bone_capemgr: Failed to add slot #1
[ 5.886506] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 5.894893] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 5.904095] bone_capemgr bone_capemgr: Failed to add slot #1
[ 5.918062] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 5.926964] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 5.933191] bone_capemgr bone_capemgr: Failed to add slot #1
[ 6.121432] systemd[1]: Set hostname to <beaglebone>.
[ 16.777609] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 16.817049] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 16.859844] bone_capemgr bone_capemgr: Failed to add slot #1
[ 16.929737] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 16.969785] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 16.975687] bone_capemgr bone_capemgr: Failed to add slot #1
[ 17.085904] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 17.118474] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 17.154454] bone_capemgr bone_capemgr: Failed to add slot #1
[ 28.115248] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 28.134653] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 28.151867] bone_capemgr bone_capemgr: Failed to add slot #1
[ 28.697746] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 28.717744] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 28.749783] bone_capemgr bone_capemgr: Failed to add slot #1
[ 29.327858] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 29.348258] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 29.384620] bone_capemgr bone_capemgr: Failed to add slot #1
[ 30.895227] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 30.915409] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 30.945180] bone_capemgr bone_capemgr: Failed to add slot #1
[ 32.262988] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 32.289802] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 32.312861] bone_capemgr bone_capemgr: Failed to add slot #1
[ 35.250962] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 35.258274] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 35.298916] bone_capemgr bone_capemgr: Failed to add slot #1


>> pru: nothing yet..
>>
>
> I should have something for this in the next couple of week or so.
>
> Heavy rework, and I’d probably have to touch base with Beaglelogic
> at all for a new PRU driver (continuation of the old one in 3.8).
>
> If anyone is interested drop me an email but please be patient.
> I’m super busy right now.

I bet John Syn & William Hermans, would be supper interested in seeing that..

[Robert Nelson]

Confirmed, reverting that fixes things:

debian@beaglebone:~$ dmesg | grep bone

[ 5.341046] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 5.348327] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 5.399132] bone_capemgr bone_capemgr: slot #0: No cape found
[ 5.430812] bone_capemgr bone_capemgr: slot #1: No cape found
[ 5.461555] bone_capemgr bone_capemgr: slot #2: No cape found
[ 5.490595] bone_capemgr bone_capemgr: slot #3: No cape found
[ 5.496434] bone_capemgr bone_capemgr: initialized OK.
[ 6.171903] systemd[1]: Set hostname to <beaglebone>.

So, cape support/detection should be as good as v4.8.x-bone/v4.4.x-ti's ;)

[Robert Nelson]

Status:

4.9.0-rc3-ti-r1:

BBB - okay - HDMI video
BBG - okay
BBGW - broken wlan0 - bluetooth okay
BBBW - broken wlan0 - bluetooth okay - HDMI video
BLUE - broken wlan0 - bluetooth okay

v4.9.0-rc3-ti-r2 (staged *1)

BBGW - wlan0 works
BBBW - wlan0 works
BLUE - wlan0 works

1: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/04ee88d2fb71a3e7a3ae9d2d27de3cdb752c973c

[Robert Nelson]

On Tue, Nov 1, 2016 at 4:00 PM, Robert Nelson <robert...@gmail.com> wrote:
> Status:
>
> 4.9.0-rc3-ti-r1:
>
> BBB - okay - HDMI video
> BBG - okay
> BBGW - broken wlan0 - bluetooth okay
> BBBW - broken wlan0 - bluetooth okay - HDMI video
> BLUE - broken wlan0 - bluetooth okay
>
> v4.9.0-rc3-ti-r2 (staged *1)
>
> BBGW - wlan0 works
> BBBW - wlan0 works
> BLUE - wlan0 works
>
> 1: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/04ee88d2fb71a3e7a3ae9d2d27de3cdb752c973c

cpufreq is now staged too for ( v4.9.0-rc3-ti-r2 ) Thatnks to Dave's patchset:

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/c7e2ceeaa302886db538b4e6a521eff6636257c7

While the Black looks good, the Octavo on the Blue is not getting 1Ghz enabled:

[ 2.081446] cpufreq: cpufreq_online: CPU0: Running at unlisted
freq: 1000000 KHz
[ 2.081483] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 1000000000 (-34)
[ 2.092525] cpufreq: cpufreq_online: CPU0: Unlisted initial
frequency changed to: 800000 KHz

debian@beaglebone:~$ dmesg | grep -i am335
[ 0.000000] OF: fdt:Machine model: TI AM335x BeagleBone Blue
[ 0.000000] AM335X ES2.1 (
[ 2.080164] remoteproc0: Booting fw image am335x-pm-firmware.elf,
size 217148

debian@beaglebone:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpu...@vger.kernel.org, please.
analyzing CPU 0:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 300 us.
hardware limits: 300 MHz - 800 MHz
available frequency steps: 300 MHz, 600 MHz, 720 MHz, 800 MHz
available cpufreq governors: powersave, conservative, userspace,
ondemand, performance, schedutil
current policy: frequency should be within 300 MHz and 800 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 300 MHz.
cpufreq stats: 300 MHz:93.27%, 600 MHz:1.09%, 720 MHz:0.00%, 800
MHz:5.64% (56)

debian@beaglebone:~$ sudo omapconf --cpuinfo
OMAPCONF (rev 1.72-nogit built Thu Apr 14 19:49:20 UTC 2016)

HW Platform:
Generic AM33XX (Flattened Device Tree)
AM3358 ES2.1 GP Device (UNKNOWN performance (1.0GHz))
Error: I2C Read failed
Error: I2C Read failed
Error: I2C Read failed
TPS65217C ES1.2
Error: I2C Read failed
UNKNOWN AUDIO IC


Dave: base dts for the blue:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.9.y/patches/soc/ti/blue/0001-ARM-dts-add-am335x-boneblue.dtb.patch

[Robert Nelson]

On Tue, Nov 1, 2016 at 4:00 PM, Robert Nelson <robert...@gmail.com> wrote:
> Status:
>
> 4.9.0-rc3-ti-r1:
>
> BBB - okay - HDMI video
> BBG - okay
> BBGW - broken wlan0 - bluetooth okay
> BBBW - broken wlan0 - bluetooth okay - HDMI video
> BLUE - broken wlan0 - bluetooth okay
>
> v4.9.0-rc3-ti-r2 (staged *1)
>
> BBGW - wlan0 works
> BBBW - wlan0 works
> BLUE - wlan0 works
>
> 1: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/04ee88d2fb71a3e7a3ae9d2d27de3cdb752c973c

I've just added a forward port of the eqep driver.. One of the big
changes, the eqep clock should be enabled/setup via the device-tree,
instead of the driver..

[ 36.292972] eqep 48300180.eqep: ver. 1.0
[ 36.293178] eqep 48300180.eqep: count_mode:0
[ 36.293187] eqep 48300180.eqep: invert_qa:1
[ 36.293195] eqep 48300180.eqep: invert_qb:1
[ 36.293201] eqep 48300180.eqep: invert_qi:0
[ 36.293208] eqep 48300180.eqep: invert_qs:0
[ 36.293215] eqep 48300180.eqep: swap_inputs:0
[ 36.293222] eqep 48300180.eqep: QDECCTL:0x0180
[ 36.293230] eqep 48300180.eqep: QPOSINIT:0x00000000
[ 36.293236] eqep 48300180.eqep: QPOSMAX:0xffffffff
[ 36.293241] eqep 48300180.eqep: QPOSCNT:0x00000000
[ 36.293249] eqep 48300180.eqep: omit_interrupt:0
[ 36.293254] eqep 48300180.eqep: QEINT:0x0800
[ 36.293261] eqep 48300180.eqep: QUPRD:0x05f5e100
[ 36.293267] eqep 48300180.eqep: QEPCTL:0x009e write
[ 36.293273] eqep 48300180.eqep: QEPCTL:0x009e read
[ 36.293296] eqep 48300180.eqep: irq:193, clk_rate:100000000

It would be awesome if someone who had it working in v4.4.x-bone/etc..
Could verify. ;)

It's part of "r2" which is now pushed out, and should be in the apt
repo in a couple hours

Changes from r1 -> r2:

wl18xx: firmware loading fixes
cpufreq: now enabled: (odd bug, where we get 1Ghz on bbb's, but 800Mhz
on Octavo based boards)
eqep: re-enabled

[TJF]

Am Dienstag, 1. November 2016 18:20:02 UTC+1 schrieb RobertCNelson:

On Tue, Nov 1, 2016 at 5:08 AM, Pantelis Antoniou
<pa...@antoniou-consulting.com> wrote:
> Hi Robert,

> ...

> I should have something for this in the next couple of week or so.
>
> Heavy rework, and I’d probably have to touch base with Beaglelogic
> at all for a new PRU driver (continuation of the old one in 3.8).
>
> If anyone is interested drop me an email but please be patient.
> I’m super busy right now.

I'm interested (author of libpruio). Please add me to the email distribution list.

Regards

[William Hermans]

On Tue, Nov 1, 2016 at 10:19 AM, Robert Nelson <robert...@gmail.com> wrote:

On Tue, Nov 1, 2016 at 5:08 AM, Pantelis Antoniou
<pa...@antoniou-consulting.com> wrote:
> Hi Robert,

. . .

>> pru: nothing yet..
>>
>
> I should have something for this in the next couple of week or so.
>
> Heavy rework, and I’d probably have to touch base with Beaglelogic
> at all for a new PRU driver (continuation of the old one in 3.8).
>
> If anyone is interested drop me an email but please be patient.
> I’m super busy right now.

I bet John Syn & William Hermans, would be supper interested in seeing that..

Regards,

--
Robert Nelson
https://rcn-ee.com/

If I was not otherwise busy, maybe. I'm still waiting for rpmsg / remoteproc to exit the experimental stage. I do however have a project that *could* use the PRU's in either configuration. A 1200 baud UART device that *may* need to be bit banged, if I can't get uart4 sending 2-3 bytes per stop / start bit sets. With that said I have no experience with the uarts on that level, and reading the TRM it *seems* the FIFO's on the UARTs should be up to 64 bytes each . . . still reading / learning.

[Robert Nelson]

I'd say about a month or two, to fully transition for all devices..

I've been testing v4.9.x-rcX's on a good number of boards on my test
farm. Just starting to see uptime's that mirror v4.4.x for
stability..

Regards,

On Thu, Dec 8, 2016 at 10:17 PM, Baozhu Zuo <zuob...@gmail.com> wrote:
> What's the kernel 4.9 plan? will we switch to kernel 4.9 ?
>
> 在 2016年11月3日星期四 UTC+8上午12:24:27，robert nelson写道：

> --
> You received this message because you are subscribed to the Google Groups
> "Beagle Alpha" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagle-alpha...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[roboknight]

I read through this thread and noted that the PRU isn't working yet?  I ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,

and was able to get the PRU working with the old UIO driver.  I was hoping at some point to switch to the new remoteproc driver, but

reading through this thread, it seems as its not ready?  I know this thread is about a month old now, but is my understanding accurate?  

Or have things progressed to a working state?  If my understanding is accurate, how much more work does the remoteproc driver require?  

I've even tested the old driver with my code and without any changes, it was performing like a champ.  My only problem now is I haven't been

able to get the USB gadget interface to work.  Everything seems to go fine up until I attempt:

ls /sys/class/udc > UDC  # enable my gadget

At this point, I get a crash around line 620 in f_hid.c in usb/gadget/function .  At least the crash is in alloc_ep_req.  It says, if I'm reading it right, that the in_ep is NULL, which I don't think it is supposed to be or can't be.  So I'm not sure what I'm doing wrong that I'm getting a NULL endpoint, but I thought maybe I hadn't configured the kernel quite right for USB.  So now that TI has a more "official" 4.9 release, maybe things work there?

At any rate, I needed both the USB gadget interface and the PRU to work and eventually am hoping to migrate my code toward remoteproc so I don't have the current issues (I needed various components that didn't seem to be all in one place until 4.9).

[Robert Nelson]

On Fri, Dec 16, 2016 at 3:38 PM, roboknight <robok...@gmail.com> wrote:
> I read through this thread and noted that the PRU isn't working yet? I
> ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
> and was able to get the PRU working with the old UIO driver. I was hoping
> at some point to switch to the new remoteproc driver, but
> reading through this thread, it seems as its not ready? I know this thread
> is about a month old now, but is my understanding accurate?
> Or have things progressed to a working state? If my understanding is
> accurate, how much more work does the remoteproc driver require?

Correct only, uio_pruss as it's mostly upstream, and with a quick hack
we have a version that is compatible with 3.8.13 kernel's..

The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti
and port it to v4.9.x-ti when they feel like it. ;)

>
> I've even tested the old driver with my code and without any changes, it was
> performing like a champ. My only problem now is I haven't been
> able to get the USB gadget interface to work. Everything seems to go fine
> up until I attempt:
>
> ls /sys/class/udc > UDC # enable my gadget
>
> At this point, I get a crash around line 620 in f_hid.c in
> usb/gadget/function . At least the crash is in alloc_ep_req. It says, if
> I'm reading it right, that the in_ep is NULL, which I don't think it is
> supposed to be or can't be. So I'm not sure what I'm doing wrong that I'm
> getting a NULL endpoint, but I thought maybe I hadn't configured the kernel
> quite right for USB. So now that TI has a more "official" 4.9 release,
> maybe things work there?

Double check with v4.9.0, i've been also messing around with the usb
gadget configfs interface:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/omap3_beagle.sh#L44-L90

hopefully we drop the old g_multi version that we use on the bone..

>
> At any rate, I needed both the USB gadget interface and the PRU to work and
> eventually am hoping to migrate my code toward remoteproc so I don't have
> the current issues (I needed various components that didn't seem to be all
> in one place until 4.9).

[roboknight]

On Friday, December 16, 2016 at 4:44:33 PM UTC-5, RobertCNelson wrote:

On Fri, Dec 16, 2016 at 3:38 PM, roboknight <robok...@gmail.com> wrote:
> I read through this thread and noted that the PRU isn't working yet?  I
> ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
> and was able to get the PRU working with the old UIO driver.  I was hoping
> at some point to switch to the new remoteproc driver, but
> reading through this thread, it seems as its not ready?  I know this thread
> is about a month old now, but is my understanding accurate?
> Or have things progressed to a working state?  If my understanding is
> accurate, how much more work does the remoteproc driver require?

Correct only, uio_pruss as it's mostly upstream, and with a quick hack
we have a version that is compatible with 3.8.13 kernel's..

I take it that's why my uio_pruss works in 4.9... At least I haven't had any problems... yet.

 

The remoteproc driver isn't upstream, TI will rebase it from v4.4.x-ti
and port it to v4.9.x-ti when they feel like it. ;)

>
> I've even tested the old driver with my code and without any changes, it was
> performing like a champ.  My only problem now is I haven't been
> able to get the USB gadget interface to work.  Everything seems to go fine
> up until I attempt:
>
> ls /sys/class/udc > UDC  # enable my gadget
>
> At this point, I get a crash around line 620 in f_hid.c in
> usb/gadget/function .  At least the crash is in alloc_ep_req.  It says, if
> I'm reading it right, that the in_ep is NULL, which I don't think it is
> supposed to be or can't be.  So I'm not sure what I'm doing wrong that I'm
> getting a NULL endpoint, but I thought maybe I hadn't configured the kernel
> quite right for USB.  So now that TI has a more "official" 4.9 release,
> maybe things work there?

Double check with v4.9.0, i've been also messing around with the usb
gadget configfs interface:

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/omap3_beagle.sh#L44-L90

hopefully we drop the old g_multi version that we use on the bone..

I am not sure what's going on here, but I'll check this out.  Either I'm not doing something with configfs properly, or I've screwed up the kernel config.

I did note that when I look at my dmesg, I see musb-hdrc.1.auto showing up as a "host" driver and musb-hdrc.0.auto showing up under /sys/class/udc.

I didn't know if the musb-hdrc.0.auto under /sys/class/udc means that its an "available" udc, or if it is the "device" udc, or if things are screwing up altogether.

Thanks for the script pointer. 

[Robert Nelson]

On Fri, Dec 16, 2016 at 4:07 PM, roboknight <robok...@gmail.com> wrote:
>
>
> On Friday, December 16, 2016 at 4:44:33 PM UTC-5, RobertCNelson wrote:
>>
>> On Fri, Dec 16, 2016 at 3:38 PM, roboknight <robok...@gmail.com> wrote:
>> > I read through this thread and noted that the PRU isn't working yet? I
>> > ended up compiling a 4.9.0-rc6 kernel, although not the ti variant,
>> > and was able to get the PRU working with the old UIO driver. I was
>> > hoping
>> > at some point to switch to the new remoteproc driver, but
>> > reading through this thread, it seems as its not ready? I know this
>> > thread
>> > is about a month old now, but is my understanding accurate?
>> > Or have things progressed to a working state? If my understanding is
>> > accurate, how much more work does the remoteproc driver require?
>>
>> Correct only, uio_pruss as it's mostly upstream, and with a quick hack
>> we have a version that is compatible with 3.8.13 kernel's..
>
>
> I take it that's why my uio_pruss works in 4.9... At least I haven't had any
> problems... yet.

Yeah you shouldn't have any problems, the one nice thing about uio, it
let's you handle everything. ;)

On the beagle xM, we just have one musb port, thus "musb-hdrc.0.auto"..

On the BeagleBone,

usb0 = peripheral
usb1 = host

So use "musb-hdrc.0.auto"

[roboknight]

I checked the script you posted to me.  That's pretty much what I'm doing, except I'm trying to create a

HID function device with:

mkdir g1/function/hid.0

Which does "create" the device.  I then have to provide some kind of HID report descriptor, which I do

based on one that has worked for me before, but somehow, when I perform the final step, I get a crash

when libcomposite tries to call the f_hid.c (the function file which I believe is contained in usb_f_hid driver).

Following the crash, it appears that it isn't getting an endpoint back from usb_ep_autoconfig ... and I don't

know at this point, why that would be the case.

The other drivers, I believe, do seem to work, or at least I was able to originally (before I needed to use the

OTG port as a device port) connect to the beaglebone black (that's the board I'm using, btw) over the regular

USB-IP interface.  So when I wasn't able to configure the HID interface properly, I became confused.

I had a script that looked like this:

-----------------------------------------------

modprobe libcomposite
cd /sys/kernel/config/usb_gadget


mkdir g1


cd g1


echo 0x1234 > idVendor
echo 0x5678 > idProduct


echo 0x0100 > bcdDevice
echo 0x0200 > bcdUSB


mkdir -p strings/0x409


echo "0123456789" > strings/0x409/serialnumber
echo "Manufacturer Inc." > strings/0x409/manufacturer
echo "My HID Dev" > strings/0x409/product


mkdir -p functions/hid.0


echo "Config 1: MY HID Cfg" > configs/c.1/strings/0x409/configuration
echo 250 > configs/c.1/MaxPower


echo 1 > functions/hid.0/protocol
echo 1 > functions/hid.0/subclass
echo 9 > functions/hid.0/report_length


cat ~/my_hid_desc.bin > functions/hid.0/report_desc


ln -s functions/hid.0 configs/c.1


ls /sys/class/udc > UDC

----------------------------------------

At the last, it fails:

udc musb-hdrc.0.auto: registering UDC driver [g1]

configfs-gadget gadget: adding 'hid'/dc77eb7c to config 'c'/dc7298a8

Unable to handle kernel NULL pointer dereference at virtual address 00000002

pgd = dab90000

[00000002] *pgd=9ab55831, *pte=00000000, *ppte=00000000

Internal error: Oops: 17 [#1] PREEMPT THUMB2

Modules linked in: usb_f_hid libcomposite gadgetfs musb_dsps musb_hdrc phy_am335x udc_core phy_am335x_control phy_generic ... other drivers ...

CPU: 0 PID: 1247 Comm: ls Not tainted 4.9.0-rc6-armv7-devel-r62 #5

Hardware name: Generic AM33XX (Flattened Device Tree)

task: da82b900 task.stack: dc6a6000

PC is at alloc_ep_req_0x1b/0x58 [libcomposite]

LR is at 0x0

And the stack dump continues.

On Monday, October 31, 2016 at 5:47:06 PM UTC-4, RobertCNelson wrote:

[Robert Nelson]

no change: 4.9.0-bone3

I'm still figuring out usb configfs, so no pointers yet. ;)

[ 23.696925] Unable to handle kernel NULL pointer dereference at
virtual address 00000002
[ 23.705155] pgd = da914000
[ 23.707872] [00000002] *pgd=9c60b831, *pte=00000000, *ppte=00000000
[ 23.714215] Internal error: Oops: 17 [#1] THUMB2
[ 23.718851] Modules linked in: usb_f_hid libcomposite
cpufreq_powersave cpufreq_conservative cpufreq_ondemand
cpufreq_userspace snd_soc_hdmi_codec nls_ascii nls_cp437
snd_soc_simple_card snd_soc_simple_card_utils omap_sham omap_aes
crypto_engine snd_soc_davinci_mcasp snd_soc_omap snd_soc_edma omap_rng
snd_soc_core rng_core tilcdc snd_pcm_dmaengine tps65217_charger
snd_pcm evdev snd_seq snd_seq_device snd_timer snd tda998x soundcore
omap_wdt uio_pdrv_genirq uio leds_gpio cpufreq_dt
[ 23.761803] CPU: 0 PID: 1159 Comm: ls Not tainted 4.9.0-bone3 #1
[ 23.767831] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 23.773947] task: db4440c0 task.stack: db70e000
[ 23.778583] PC is at alloc_ep_req+0x1b/0x58 [libcomposite]
[ 23.784088] LR is at 0x0
[ 23.786629] pc : [<bf94027c>] lr : [<00000000>] psr: 60000033
[ 23.786629] sp : db70fde0 ip : 00000000 fp : db70ab1c
[ 23.798154] r10: db70aac4 r9 : db70aac4 r8 : db09d7d4
[ 23.803396] r7 : db70aaa8 r6 : dc31c488 r5 : 00000009 r4 : da907800
[ 23.809948] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : da907800
[ 23.816501] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb
Segment none
[ 23.823838] Control: 50c5387d Table: 9a914019 DAC: 00000051
[ 23.829605] Process ls (pid: 1159, stack limit = 0xdb70e210)
[ 23.835285] Stack: (0xdb70fde0 to 0xdb710000)
[ 23.839662] fde0: db09d77c bf950188 00000000 bf94f5e5 db70ab24
db70aaa8 dc5b8f00 00000001
[ 23.847876] fe00: db09d77c db70aaa8 bf94f579 bf941ad8 db09d7d4
bf93ce23 00000000 db70aaa8
[ 23.856089] fe20: db010e8c db010de0 db70aaa8 db010e8c db010de0
db010c00 db09d7d4 bf93fca9
[ 23.864302] fe40: 00000055 db010e54 00000000 dc31d1b8 024000c0
db557000 db010de0 00000000
[ 23.872515] fe60: c0eabee4 dc5b8900 c0eabed8 db480f00 dc5b8ed8
c05a933d db010de0 db557000
[ 23.880728] fe80: 00000000 c05a9499 00000000 db010c00 00000011
dc5b8900 db010d90 fffffff0
[ 23.888941] fea0: 00000051 bf93ff9d 00000011 00000000 00000011
db70ff80 00000011 dc5b8ec0
[ 23.897154] fec0: dc603000 c024e419 db70ff80 db480f00 00000011
db70ff80 c024e381 00000000
[ 23.905367] fee0: 00000000 00000000 000222f8 c01fdfe9 b6fc8000
db70ffb0 c0e09664 50c5387d
[ 23.913581] ff00: be8193e4 00000000 000222e0 c01011e5 00000073
c01e40f1 000b6fc8 c01feeb1
[ 23.921794] ff20: 00004df6 00000007 db480f00 db70ff64 00000000
c01feeb1 00000011 db480f00
[ 23.930007] ff40: 00000011 b6fc8000 db70ff80 00000000 00000000
c01feedf 000b6fc8 db70ff64
[ 23.938220] ff60: 00000001 db480f00 db480f00 00000011 b6fc8000
00000000 00000000 c01ff12d
[ 23.946433] ff80: 00000000 00000000 00000022 b6f415e0 00000011
b6fc8000 00000004 c0106824
[ 23.954646] ffa0: db70e000 c0106641 b6f415e0 00000011 00000001
b6fc8000 00000011 00000000
[ 23.962860] ffc0: b6f415e0 00000011 b6fc8000 00000004 b6fc9528
00562e20 00562e50 000222f8
[ 23.971073] ffe0: 00000011 be81b700 b6eaf905 b6ee906c 40000010
00000001 00000000 00000000
[ 23.979362] [<bf94027c>] (alloc_ep_req [libcomposite]) from
[<bf94f5e5>] (hidg_bind+0x6c/0x1bc [usb_f_hid])
[ 23.989178] [<bf94f5e5>] (hidg_bind [usb_f_hid]) from [<bf93ce23>]
(usb_add_function+0x4a/0x118 [libcomposite])
[ 23.999356] [<bf93ce23>] (usb_add_function [libcomposite]) from
[<bf93fca9>] (configfs_composite_bind+0x19c/0x250 [libcomposite])
[ 24.011091] [<bf93fca9>] (configfs_composite_bind [libcomposite])
from [<c05a933d>] (udc_bind_to_driver+0x29/0xa8)
[ 24.021489] [<c05a933d>] (udc_bind_to_driver) from [<c05a9499>]
(usb_gadget_probe_driver+0xa1/0xd0)
[ 24.030598] [<c05a9499>] (usb_gadget_probe_driver) from
[<bf93ff9d>] (gadget_dev_desc_UDC_store+0x84/0x94 [libcomposite])
[ 24.041629] [<bf93ff9d>] (gadget_dev_desc_UDC_store [libcomposite])
from [<c024e419>] (configfs_write_file+0x99/0xf0)
[ 24.052290] [<c024e419>] (configfs_write_file) from [<c01fdfe9>]
(__vfs_write+0x1d/0xbc)
[ 24.060418] [<c01fdfe9>] (__vfs_write) from [<c01feedf>]
(vfs_write+0x83/0x134)
[ 24.067759] [<c01feedf>] (vfs_write) from [<c01ff12d>] (SyS_write+0x39/0x68)
[ 24.074846] [<c01ff12d>] (SyS_write) from [<c0106641>]
(ret_fast_syscall+0x1/0x4e)
[ 24.082453] Code: d545 4604 b1b0 6a73 (f993) 2002
[ 24.087360] ---[ end trace c208dc44a507be5c ]---

[roboknight]

I had another look at this.  I don't think it is creating any interfaces for some reason.  I am unsure why not.

If I check the configfs part of the filesystem, there doesn't seem to be anywhere where the "interface" values

show up (things like bInterfaceProtocol or bInterfaceSubClass).  I thought they were supposed to be part of the

configuration or something like that.  Maybe I'm missing something. 

[roboknight]

Well, still no dice as far as usb_f_hid goes.  I tried to change a few config items.  I ended up, I think, with a better kernel build (less kruft),

but nothing working.  I guess its either bisect the kernel and see what broke (que mission impossible theme), or dig into the kernel further

and see what is going wrong (que mission impossible theme reprise).  I have not seen ANYWHERE, regular docs included, that anything 

I've done should lead to this, but maybe something is misconfigured in the kernel, or its just "broke".  I SUPPOSE I could try the OTHER

types of hid interface (I compile out hiddev and the other hid interface just in case), or heaven forbid, g_hid.ko (que Kirk yelling "Kahn" from

Star Trek II, replacing it with "g_hid").

[roboknight]

Oh, this does remind me, I meant to ask, since I have *NOT* bisected the kernel before, any pointers on where to start

looking for good info on effective bisection?  I figured I would mark the 3.13 kernel as working (i had things working there), unless you know or have

tried some kind of hid device in a later kernel and it worked.  

On Monday, October 31, 2016 at 5:47:06 PM UTC-4, RobertCNelson wrote:

[Drew Fustini]

On Wed, Nov 2, 2016 at 11:23 AM,
Robert Nelson <robert...@gmail.com> wrote:
> I've just added a forward port of the eqep driver.. One of the big
> changes, the eqep clock should be enabled/setup via the device-tree,
> instead of the driver..
>
> [ 36.292972] eqep 48300180.eqep: ver. 1.0
> [ 36.293178] eqep 48300180.eqep: count_mode:0
> [ 36.293187] eqep 48300180.eqep: invert_qa:1
> [ 36.293195] eqep 48300180.eqep: invert_qb:1
> [ 36.293201] eqep 48300180.eqep: invert_qi:0
> [ 36.293208] eqep 48300180.eqep: invert_qs:0
> [ 36.293215] eqep 48300180.eqep: swap_inputs:0
> [ 36.293222] eqep 48300180.eqep: QDECCTL:0x0180
> [ 36.293230] eqep 48300180.eqep: QPOSINIT:0x00000000
> [ 36.293236] eqep 48300180.eqep: QPOSMAX:0xffffffff
> [ 36.293241] eqep 48300180.eqep: QPOSCNT:0x00000000
> [ 36.293249] eqep 48300180.eqep: omit_interrupt:0
> [ 36.293254] eqep 48300180.eqep: QEINT:0x0800
> [ 36.293261] eqep 48300180.eqep: QUPRD:0x05f5e100
> [ 36.293267] eqep 48300180.eqep: QEPCTL:0x009e write
> [ 36.293273] eqep 48300180.eqep: QEPCTL:0x009e read
> [ 36.293296] eqep 48300180.eqep: irq:193, clk_rate:100000000
>
> It would be awesome if someone who had it working in v4.4.x-bone/etc..
> Could verify. ;)

eqep was working for me in 4.4.x but I get a segmentation fault when I
read the sysfs position file:
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position

It seems to happen at this call to readl() in eqep_get_position():
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

I got some good hints from Google+:
https://plus.google.com/u/0/+DrewFustini/posts/MYfYUyQvv7W

Michael Welling wrote:
> This external abort fault is probably caused by the clock being dynamically
> disabled by runtime suspend. pm_runtime_get_sync is missing somewhere.

Felipe Balbi wrote:
> 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

I'm now reading about pm_runtime_get_sync() in
Documentation/power/runtime_pm.txt. I'll update if I make any
progress.

Thanks,
Drew

[Drew Fustini]

On Sun, Jan 29, 2017 at 3:13 AM, Drew Fustini <pdp7...@gmail.com> wrote:
> eqep was working for me in 4.4.x but I get a segmentation fault when I
> read the sysfs position file:
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position

> [ 1858.108446] Unhandled fault: external abort on non-linefetch
> (0x1028) at 0xfa304184
>

> I'm now reading about pm_runtime_get_sync() in
> Documentation/power/runtime_pm.txt. I'll update if I make any
> progress.

I'm still investigating but I did notice that the original tieqep
driver had this code to enable the clock to the eQEP unit:
https://github.com/Teknoman117/beaglebot/blob/master/encoders/patches/0001-tieqep-driver.patch#L721

// Enable the clock to the eQEP unit
status = pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EQEPCLK_EN);

// If we failed to enable the clocks, fail out
if (!(status & PWMSS_EQEPCLK_EN_ACK))
{
dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
ret = -EINVAL;
goto pwmss_clk_failure;
}

The function pwmss_submodule_state_change() appears to have been
removed by this commit:

commit cc37655e6bbf83ded1e4d1d7ffd977786a845a67
Author: Cooper Jr., Franklin <fco...@ti.com>
Date: Mon Mar 7 13:33:56 2016 -0600

pwm: pwm-ti*: Remove support for local clock gating

The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.

Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.


-Drew

[Drew Fustini]

On Mon, Jan 30, 2017 at 10:56 AM, Franklin S Cooper Jr <fco...@ti.com> wrote:
> So one thing I noticed is that the eqep node isn't adding any clocks
> compared to EHRPWM and ECAP. So I would be curious if adding the
> following entries to the eqep node may solve. I don't really remember
> how we came up with this
>
> clocks = <&l4_root_clk_div>;
> clock-names = "fck";
>
> From what I remember for ECAP and PWM that the PWMSS clock gate wouldn't
> allow a clock to be ungated once you tell it to gate it. However, the
> patch you mentioned shouldn't change anything because by default (on
> reset) PWMSS ungates the PWM, ECAP and EQEP clocks.
>
> You mind sharing a boot log showing this failure? Also can you share the
> patch your using now for the eqep driver along with dts changes?

Thanks for the assistance, Franklin. Here is the patch that is applied:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep

The boot log is in this gist and also attached:
https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7/


Thanks!
Drew

[Franklin S Cooper Jr]

So one thing I noticed is that the eqep node isn't adding any clocks
compared to EHRPWM and ECAP. So I would be curious if adding the
following entries to the eqep node may solve. I don't really remember
how we came up with this

clocks = <&l4_root_clk_div>;
clock-names = "fck";

From what I remember for ECAP and PWM that the PWMSS clock gate wouldn't
allow a clock to be ungated once you tell it to gate it. However, the
patch you mentioned shouldn't change anything because by default (on
reset) PWMSS ungates the PWM, ECAP and EQEP clocks.

You mind sharing a boot log showing this failure? Also can you share the
patch your using now for the eqep driver along with dts changes?

[Drew Fustini]

On Mon, Jan 30, 2017 at 1:02 PM, Drew Fustini <dr...@beagleboard.org> wrote:
> Thanks for the assistance, Franklin. Here is the patch that is applied:
> https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep
>
> The boot log is in this gist and also attached:
> https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7/

I just found that I can avoid the abort by setting runtime power
control to "on" instead of "auto" through sysfs.

# uname -r
4.9.6-ti-r17
# config-pin p8.11 qep
# config-pin p8.12 qep

# echo on > /sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/power/control
# echo on > /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/control
# echo on > /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control

# cat /sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/power/runtime_status
active
# cat /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/runtime_status
active
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/runtime_status
active

# cat /sys/devices/platform/ocp/48300000.epwmss/48300180.eqep/position
0
# cat /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/position
0
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-1

I'm guessing this is probably not a real solution, but it seems
promising to finally avoid that unhandled fault ("external abort on
non-linefetch") upon reading position.

-Drew

[Robert Nelson]

Nice find Drew!

Once you enable the power control, it's it acting the same as v4.4.x was?

[Drew Fustini]

On Mon, Jan 30, 2017 at 8:40 PM, Robert Nelson <robert...@gmail.com> wrote:
> Once you enable the power control, it's it acting the same as v4.4.x was?

Yes, it does read position ok.

# uname -r
4.9.6-ti-r17

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
auto
# echo on > /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
on
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/runtime_status
active

# 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
46


thanks,
drew

[William Hermans]

Drew, do you have a complete gist on how you set this all up ? Mark Yoder was interested in the wqep module a while back, but I do not thnk he was able to figure it out completely. Also, from a personal project / somethign to tpy with. I'm very interested in the eqep module as well. Or hmm maybe ecap is more of what I'm interested in ?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAPgEAj6P6Zsh%2BfRPtzfA9i%2Bm3O7bTUHq9cNwQYZdbo0GzdX6wA%40mail.gmail.com.

[Drew Fustini]

On Tue, Jan 31, 2017 at 9:28 PM, William Hermans <yyr...@gmail.com> wrote:
> Drew, do you have a complete gist on how you set this all up ? Mark Yoder
> was interested in the wqep module a while back, but I do not thnk he was
> able to figure it out completely. Also, from a personal project / somethign
> to tpy with. I'm very interested in the eqep module as well. Or hmm maybe
> ecap is more of what I'm interested in ?

Here is a gist that I've been keeping notes in:
https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7

Here is repeating the steps on 4.1, 4.4 and 4.9:
https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673

For 4.9, I am forcing the eQEP peripheral that I'm using to never
suspend by changing its power/control file in sysfs to "on" instead of
"auto". I still need to figure out the real solution so that the
tieqep handles suspend and resume properly.

-drew

[William Hermans]

Thanks Drew.

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAEf4M_A%2BD-09JaDaAwTmA7PmEWvFsvmEE-Z2V_1N3-Ztc9dWng%40mail.gmail.com.

[Drew Fustini]

On Tue, Jan 31, 2017 at 5:47 AM, Drew Fustini <dr...@beagleboard.org> wrote:
> On Mon, Jan 30, 2017 at 8:40 PM, Robert Nelson <robert...@gmail.com> wrote:
>> Once you enable the power control, it's it acting the same as v4.4.x was?
>
> Yes, it does read position ok.

I've created this patch which seems to have done the trick without
messing with sysfs. It adds pm_runtime_get_sync() before read or
write to eQEP memory mapped registers:
patches/drivers/ti/eqep/0002-Avoid-unhandled-fault-when-reading-eQEP-registers.patch

Here is the gist of the patch (also attached):
https://gist.github.com/pdp7/5fddaab028630dd06ace8e5012cf6798

Here's the results (no need to mess with files in sysfs anymore):

root@beaglebone:~# uname -r
4.9.6-ti-r18
root@beaglebone:~# config-pin p8.11 qep && config-pin p8.12 qep
root@beaglebone:~# cat
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
0
<turn the rotary encoder>
root@beaglebone:~# cat
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
66


thanks,
drew

[Drew Fustini]

On Thursday, February 2, 2017 at 4:16:24 AM UTC-6, Drew Fustini wrote:

I've created this patch which seems to have done the trick without 
messing with sysfs.  It adds pm_runtime_get_sync() before read or 
write to eQEP memory mapped registers: 

 

Robert - I've raised a pull request with the patch on the ti-linux-4.9.y branch of your ti-linux-kernel-dev repo:

https://github.com/RobertCNelson/ti-linux-kernel-dev/pull/10

thanks,

drew