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


On Thursday, September 15, 2016 at 6:45:04 AM UTC-7, Mark A. Yoder wrote:
>
> 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
>
> On Wednesday, September 14, 2016 at 10:51:41 PM UTC-4, William Hermans 
> wrote:
>>
>> 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.
>>
>> On Wed, Sep 14, 2016 at 7:35 PM, William Hermans <yyr...@gmail.com> 
>> wrote:
>>
>>> 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
>>>
>>>
>>> On Wed, Sep 14, 2016 at 6:23 PM, William Hermans <yyr...@gmail.com> 
>>> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Sep 14, 2016 at 5:50 PM, William Hermans <yyr...@gmail.com> 
>>>> wrote:
>>>>
>>>>> *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 <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 . . .
>>>>>
>>>>>
>>>>> On Wed, Sep 14, 2016 at 2:09 PM, Mark A. Yoder <mark.a...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> Well, I found half my answer.  A simple:
>>>>>>
>>>>>> *config-pin -a P8_11 qep*
>>>>>> *config-pin -a P8_12 qe*p
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> On Wednesday, September 14, 2016 at 4:22:06 PM UTC-4, Mark A. Yoder 
>>>>>> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>> -- 
>>>>>> 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...@googlegroups.com.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/beagleboard/e476efbe-ffa1-4356-8200-e6f0e32bc3c7%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/beagleboard/e476efbe-ffa1-4356-8200-e6f0e32bc3c7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/711a3486-9ec0-431d-9a0a-4d3915937a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to