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

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. :wink: ( i finally have a lcd
monitor (with audio) that i can finally test with. .:wink: )

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). :wink:

Regards,

Hi Robert,

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..

Regards,

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 :wink:

Regards,

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

Regards,

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 cpufreq@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

Regards,

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. :wink:

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

Regards,

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

Regards

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.

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,

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).

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. :wink:

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).

Regards,

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. :wink:

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.

> 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. :wink:

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. :wink:

>
> 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.

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"

Regards,

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:

no change: 4.9.0-bone3

I'm still figuring out usb configfs, so no pointers yet. :wink:

[ 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 ]---

Regards,

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.

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”).

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.

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. :wink:

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

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 <fcooper@ti.com>

    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