Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-28 Thread gh78731 
I think the primary use for the eQEP is to decode shaft encoders that are 
being used to replace analog controls for volume control, tuning, tone 
controls, etc.

In other words, knobs for applications suited for them, but you don't 
digitize the analog knob output, you go directly into the digital domain 
inside the shaft encoder.

There are also some industrial applications for measuring speed (and 
position) of motors, belts, etc.

The shaft encoder has two switches that open and close in a quadrature 
"gray code" pattern so you get rotation and un-ambiguous direction of 
rotation.

The problem is that they usually come in applications greater than two.

We use them for radio controls, but our application uses 12.

So, rather than deal with the vagaries of a real time process running 
underneath an OS, we just programmed a PIC to watch all 12 simultaneously, 
and the Linux OS can ask the PIC the status of any or all of the knobs when 
it gets around to it.

So using the eQEP inside the BBB is fine for learning how shaft encoders 
work, but I don't see using it for real world applications with more than 
one or two knobs.

--- Graham

==

On Tuesday, February 28, 2017 at 6:02:17 PM UTC-6, William Hermans wrote:
>
>
>
> On Tue, Feb 28, 2017 at 3:41 PM, Drew Fustini  > wrote:
>
>>
>> eCAP is interesting as there seems to be two modes: capture input, and 
>> PWM output.  The use of eCAP as PWM output is already supported in mainline 
>> as part of epwmss.
>>
>> However, the eCAP input driver written Matt Porter is still out-of-tree 
>> and carried as a patch by Robert.  At least this my understanding after 
>> chatting with Robert Nelson and Michael Welling last week. 
>>
>> eCAP input seems to be another candidate to upstream.  Question is which 
>> subsystem fits best.
>>
>>  
> You know I'm not really sure. I've never used the ecap module before, but 
> my impressions form what I've read that the ecap is similar to a high speed 
> ADC, except instead of "capturing" voltage levels. ecap captures logic 
> level transitions. High's, to low, low to highs..
>
> Again I'm not sure for this specific application, in terms of speed, but 
> imagine a car with a high RPM engine at the drag strip. Where one could 
> monitor the rotation speed of the engine's cam, and adjust engine timing 
> based on engine RPM. I've discussed this a few times in the past with a 
> person talking about maximizing an engines performance curve. But with an 
> engine operating at let's say 30,000 RPMs, an ADC would need an insane 
> amount of sample per second. I think at one time we calculated this out to 
> somewhere around 2-3Msps minimum. With pulse counting however, which is all 
> you'd really need an ADC for with this application. I think "samples per 
> second" could be mitigated some.
>
> Of course with this application mentioned above. One would probably have 
> to use the PRU's, but I'm also not sure in this case if the ecap module, 
> the PRU's or the beaglebone board in general would be up to the task. 
> Because not only would one need to count RPM pulses, but one for this 
> application would have to act on those pulses. The X15 most definitely 
> could handle this.
>
> Anyway, I'm not sure if that really helps with the question in general. 
> It's just a thought I've had once in a while for several years now. I have 
> had other ideas similar to this one where I *think* pulse counting could in 
> fact be used instead of ADCs. For various other projects I've considered in 
> the past. *shrug*.
>

-- 
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/2bb63ba3-e2cd-4b15-a6b9-92e199f3538b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-28 Thread William Hermans 
On Tue, Feb 28, 2017 at 3:41 PM, Drew Fustini  wrote:

>
> eCAP is interesting as there seems to be two modes: capture input, and PWM
> output.  The use of eCAP as PWM output is already supported in mainline as
> part of epwmss.
>
> However, the eCAP input driver written Matt Porter is still out-of-tree
> and carried as a patch by Robert.  At least this my understanding after
> chatting with Robert Nelson and Michael Welling last week.
>
> eCAP input seems to be another candidate to upstream.  Question is which
> subsystem fits best.
>
>
You know I'm not really sure. I've never used the ecap module before, but
my impressions form what I've read that the ecap is similar to a high speed
ADC, except instead of "capturing" voltage levels. ecap captures logic
level transitions. High's, to low, low to highs..

Again I'm not sure for this specific application, in terms of speed, but
imagine a car with a high RPM engine at the drag strip. Where one could
monitor the rotation speed of the engine's cam, and adjust engine timing
based on engine RPM. I've discussed this a few times in the past with a
person talking about maximizing an engines performance curve. But with an
engine operating at let's say 30,000 RPMs, an ADC would need an insane
amount of sample per second. I think at one time we calculated this out to
somewhere around 2-3Msps minimum. With pulse counting however, which is all
you'd really need an ADC for with this application. I think "samples per
second" could be mitigated some.

Of course with this application mentioned above. One would probably have to
use the PRU's, but I'm also not sure in this case if the ecap module, the
PRU's or the beaglebone board in general would be up to the task. Because
not only would one need to count RPM pulses, but one for this application
would have to act on those pulses. The X15 most definitely could handle
this.

Anyway, I'm not sure if that really helps with the question in general.
It's just a thought I've had once in a while for several years now. I have
had other ideas similar to this one where I *think* pulse counting could in
fact be used instead of ADCs. For various other projects I've considered in
the past. *shrug*.

-- 
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/CALHSORp7Tf8jHOqeHGKNwG%2BLV9NmdQeA%3D27cUgm2jQ2ze403Gg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-28 Thread Drew Fustini 
On Feb 25, 2017 5:35 PM, "William Hermans"  wrote:
> Why do you think a new driver needs to be written ?

My desire is to get support for eQEP upstream in the mainline Linux
kernel.  I don't believe it is easy to get new misc drivers merged.  IIO
seems to be the only subsystem that is suitable but I'd be interested know
of other subsystems that would be appropriate.

> But if you're intent on having something IIO, and new driver . . . the
ecap modules probably fits into that category better. The ecap module now,
I could find all kinds of "out of the ordinary" uses

eCAP is interesting as there seems to be two modes: capture input, and PWM
output.  The use of eCAP as PWM output is already supported in mainline as
part of epwmss.

However, the eCAP input driver written Matt Porter is still out-of-tree and
carried as a patch by Robert.  At least this my understanding after
chatting with Robert Nelson and Michael Welling last week.

eCAP input seems to be another candidate to upstream.  Question is which
subsystem fits best.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAEf4M_DSpTrnon70OXXPDYn5gadKzJ%3DaZeow%3DzbHyE3gOS03nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-25 Thread William Hermans 
On Sat, Feb 25, 2017 at 11:23 AM, Drew Fustini  wrote:

> Thanks for following up.
>
> I've been using the tieqep module to read absolute position count of a
> rotary encoder knob.  I'm curious what other use cases people have for eQEP?
>

I'm not sure I would have an out of the ordinary use for eqep personally.

>
> The reason I ask is I think a new driver needs to be written and it would
> be good to know which features of the eQEP peripheral should be implemented.
>

Why do you think a new driver needs to be written ?

>
> The existing tieqep driver is out of tree and seems unlikely to be
> included in the mainline Linux kernel.  We are able to use it on BeagleBone
> because Robert includes it as a patch in his kernel builds.
>
> The IIO subsystem now has infrastructure for encoders.  I am thinking that
> an IIO driver should be written for eQEP with the goal of being merged into
> the mainline kernel.
>
> Thoughts?
>

Thoughts . . .So personally, I really do not like anything IIO. I do not
like the driver, I do not like the IIO "community support", and I think
it's unnecessary for the ADC as it is. However, for simple ADC use cases,
it's what we have, so I put up with it.

But if you're intent on having something IIO, and new driver . . . the ecap
modules probably fits into that category better. The ecap module now, I
could find all kinds of "out of the ordinary" uses for.

-- 
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/CALHSORrU1FLO820Vs739dUQidOoR7OYqGbkpbSCZXnB_EiR_zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-25 Thread Drew Fustini 
Thanks for following up.

I've been using the tieqep module to read absolute position count of a
rotary encoder knob.  I'm curious what other use cases people have for eQEP?

The reason I ask is I think a new driver needs to be written and it would
be good to know which features of the eQEP peripheral should be implemented.

The existing tieqep driver is out of tree and seems unlikely to be included
in the mainline Linux kernel.  We are able to use it on BeagleBone because
Robert includes it as a patch in his kernel builds.

The IIO subsystem now has infrastructure for encoders.  I am thinking that
an IIO driver should be written for eQEP with the goal of being merged into
the mainline kernel.

Thoughts?

-Drew

On Feb 24, 2017 3:39 AM, "Hugh Frater"  wrote:

I was getting weird values - it turns out I didn't correctly understand how
to use pin-config & the universal overlay. When I configured the pins
correctly, everything works.

On Friday, 3 February 2017 21:18:35 UTC, Drew Fustini wrote:

> On Fri, Feb 3, 2017 at 6:02 AM, Hugh Frater  wrote:
> > Did you ever get any further with this? I'm struggling with eQEP on
> 4.4.36 -
> > but for different reasons
>
> Are you getting an error?
>
> I am able to use eQEP ok with a rotary encoder on 4.4 kernel:
>
> # uname -a
> Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52
>
> # config-pin p8.11 qep
> # config-pin p8.12 qep
>
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
> -2
> 
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
> 18
>
> Here are results with 4.1, 4.4 and 4.9:
> https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673
>
>
> -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+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/beagleboard/1276f9da-9966-4171-a03c-4915d94e8e6b%40googlegroups.com

.

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/CAEf4M_ALLyTM18zH_wkB6gYH0k7XL%2Bw_amzLMsCjYTvaws6kPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-24 Thread Hugh Frater 
I was getting weird values - it turns out I didn't correctly understand how 
to use pin-config & the universal overlay. When I configured the pins 
correctly, everything works.

On Friday, 3 February 2017 21:18:35 UTC, Drew Fustini wrote:
>
> On Fri, Feb 3, 2017 at 6:02 AM, Hugh Frater  > wrote: 
> > Did you ever get any further with this? I'm struggling with eQEP on 
> 4.4.36 - 
> > but for different reasons 
>
> Are you getting an error? 
>
> I am able to use eQEP ok with a rotary encoder on 4.4 kernel: 
>
> # uname -a 
> Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52 
>
> # config-pin p8.11 qep 
> # config-pin p8.12 qep 
>
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position 
> -2 
>  
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position 
> 18 
>
> Here are results with 4.1, 4.4 and 4.9: 
> https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673 
>
>
> -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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1276f9da-9966-4171-a03c-4915d94e8e6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-03 Thread woody.lois via BeagleBoard 


On Fri, 2/3/17, Drew Fustini <pdp7p...@gmail.com> wrote:

 Subject: Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41
 To: "Beagle Board" <beagleboard@googlegroups.com>
 Date: Friday, February 3, 2017, 11:18 PM
 
 On Fri, Feb 3, 2017 at
 6:02 AM, Hugh Frater <hugh.fra...@gmail.com>
 wrote:
 > Did you ever get any further
 with this? I'm struggling with eQEP on 4.4.36 -
 > but for different reasons
 
 Are you getting an error?
 
 I am able to use eQEP ok with
 a rotary encoder on 4.4 kernel:
 
 # uname -a
 Linux beaglebone
 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52
 
 # config-pin p8.11 qep
 #
 config-pin p8.12 qep
 
 # cat
 /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
 -2
 
 # cat
 /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
 18
 
 Here are
 results with 4.1, 4.4 and 4.9:
 https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673
 
 
 -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+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 
https://groups.google.com/d/msgid/beagleboard/CAEf4M_CgQ-B0qmtLa1XtNSLcnyvY0ewK47vC%3DCt%2Bejndna91sQ%40mail.gmail.com.
 For
 more options, visit https://groups.google.com/d/optout.
 i in celelaltare provincii romanesti aflate sub opresiunea straina au avut   
mari adunari plebiscitare. La 20 mai 1848  la Cernauti  in prezenta unor 
prezentanti de frunte ai clerului  boierimii  si fruntasilor taranimii  dupa 
izbateri sustinute  au fost adoptate 12 dorinte  intre care  la loc de frunte  
se Iau separarea Bucovinei de Galitia  conservarea nationalitatii romane si 
earea de scoli nationale  autonomia provinciala  defiintarea clacii si a dijmei 
 isfacerea de Mitropolia Ortodoxa de la Karlowitz si alegerea episcopului de 
atre un Congres bisericesc alcatuit din clerici si mireni. La 15 27 iunie 1848  
la jgoj  in Banat  sub presedintia lui Eftimie Murgu  o Adunare de 12 000 de 
ameni a decretat  intre altele  respectarea nationalitatii romanesti  
oficializarea nbii romane  inarmarea poporului dupa putinta in rastimp de 6 
zile cu sfensive  iar dupa ce se va arma de catre stat  atunci sa paseasca 
ofensive .

-- 
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/1511214478.641889.1486162999635%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2017-02-03 Thread Drew Fustini 
On Fri, Feb 3, 2017 at 6:02 AM, Hugh Frater  wrote:
> Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 -
> but for different reasons

Are you getting an error?

I am able to use eQEP ok with a rotary encoder on 4.4 kernel:

# uname -a
Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52

# config-pin p8.11 qep
# config-pin p8.12 qep

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-2

# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
18

Here are results with 4.1, 4.4 and 4.9:
https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673


-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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAEf4M_CgQ-B0qmtLa1XtNSLcnyvY0ewK47vC%3DCt%2Bejndna91sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-19 Thread William Hermans 
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,  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(>dev, "fck");
>
> if (IS_ERR(clk)) {
>
> dev_err(>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 
>>> 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@44c0/scm@21000
 0/pinmux@800/pinctrl_eqep2_pins
 /sys/firmware/devicetree/base/ocp/epwmss@4830/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
 30/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 
 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

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-18 Thread bkuschak 
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(>dev, "fck");

if (IS_ERR(clk)) {

dev_err(>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  
>> 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@44c0/scm@21/pinmux@800/pinctrl_eqep2_pins
>>> /sys/firmware/devicetree/base/ocp/epwmss@4830/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@4830/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  
>>> 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  
 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 . I'm not 
> however sure if one would encounter this error when loading overlays when 
> using the standard "traditional"

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-15 Thread Mark A. Yoder 
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  > 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@44c0/scm@21/pinmux@800/pinctrl_eqep2_pins
>> /sys/firmware/devicetree/base/ocp/epwmss@4830/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@4830/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 > > 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 >> > 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 . 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  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.75] bone_capemgr bone_capemgr: slot #9: override
>> [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data 
>> at slot 9
>> [  +0.46] 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

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-14 Thread William Hermans 
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  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@44c0/scm@21/pinmux@800
> /pinctrl_eqep2_pins
> /sys/firmware/devicetree/base/ocp/epwmss@4830/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@
> 4830/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 
> 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 
>> 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 . 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 
>>> 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.75] bone_capemgr bone_capemgr: slot #9: override
> [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 9
> [  +0.46] 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.
>

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-14 Thread William Hermans 
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@44c0/scm@21/pinmux@800
/pinctrl_eqep2_pins
/sys/firmware/devicetree/base/ocp/epwmss@4830/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@4830
/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  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 
> 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 . 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 
>> 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.75] bone_capemgr bone_capemgr: slot #9: override
 [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data at
 slot 9
 [  +0.46] 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/beagleboard/e476efbe-ffa1-4356-8200-e6f0e32bc3c7%40googlegroups.com
>>>

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-14 Thread William Hermans 
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  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 . 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 
> 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.75] bone_capemgr bone_capemgr: slot #9: override
>>> [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data at
>>> slot 9
>>> [  +0.46] 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/e476efbe-ffa1-4356-8200-e6f0e32bc3c7%40googlegroups.com
>> 
>> .
>>
>> 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/CALHSORrm0U9hSgU7-BtYxk5WND-2MHHK9-rsR7dzcjZO3Svt2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

2016-09-14 Thread William Hermans 
>
> *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 . 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 
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.75] bone_capemgr bone_capemgr: slot #9: override
>> [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data at
>> slot 9
>> [  +0.46] 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/e476efbe-ffa1-4356-8200-e6f0e32bc3c7%40googlegroups.com
> 
> .
>
> 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/CALHSORqMfR8XwpYL_GcSdOyB%2B0XKoQNdvkQgFcEWZ5e7RcoG%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.