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.
On Sun, Sep 18, 2016 at 10:03 PM, <bkusc...@gmail.com> wrote:
> 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@21000
>>>> 0/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@48
>>>> 300000/eqep@0x48300180
>>>> /sys/firmware/devicetree/base/__local_fixups__/ocp/epwmss@48
>>>> 302000/eqep@0x48302180
>>>> /sys/firmware/devicetree/base/__local_fixups__/ocp/epwmss@48
>>>> 304000/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/4830
>>>>> 4000.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
> <https://groups.google.com/d/msgid/beagleboard/711a3486-9ec0-431d-9a0a-4d3915937a8e%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/CALHSORqcRi-qJe4KYqALPTv%3DeRMuoGh2xMW18trQHLzevxo_Pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
