I don't believe that actually will change the I/O configuration. For the
pin ctrl entry to be adopted, it needs to be used by some driver. Turns
out there is a "pinmux helper" device. Check out this blog
post: http://hipstercircuits.com/enable-serialuarttty-on-beaglebone-black/.
More specifically, this section:
fragment@2 {
target = <&ocp>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart5>;
status = "okay";
};
};
};
- Nathaniel
On Tuesday, May 13, 2014 1:55:00 AM UTC-7, Strawson wrote:
>
> Actually, let me be more specific. I use the pinmux lines and enable the
> PWM Subsystem as follows
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_eqep0: pinctrl_eqep0_pins {
> pinctrl-single,pins = <
> 0x1A8 0x21 /* P9_41 = GPIO3_20 = EQEP0_index, MODE1
> */
> 0x1AC 0x21 /* P9_25 = GPIO3_21 = EQEP0_strobe, MODE1
> */
> 0x1A0 0x31 /* P9_42 = GPIO3_18 = EQEP0A_in, MODE1 */
>
> 0x1A4 0x31 /* P9_27 = GPIO3_19 = EQEP0B_in, MODE1 */
>
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&epwmss0>;
> __overlay__ {
> status = "okay";
> };
> };
>
>
> I am not using the following fragment passing parameters to the kernel
> driver
>
> fragment@2 {
> target = <&eqep0>;
> __overlay__ {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_eqep0>;
>
> count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase offset
> cha & chb. 1 - Direction mode. cha input = clock, chb input = direction */
> swap_inputs = <0>; /* Are channel A and channel B swapped? (0 -
> no, 1 - yes) */
> invert_qa = <1>; /* Should we invert the channel A input? */
> invert_qb = <1>; /* Should we invert the channel B input? I
> invert these because my encoder outputs drive transistors that pull down the
> pins */
> invert_qi = <0>; /* Should we invert the index input? */
> invert_qs = <0>; /* Should we invert the strobe input? */
>
> status = "okay";
> };
> };
>
>
> This is for two reasons. Firstly, I don't see how this would change the
> behavior of the hardware if I'm setting the registers anyway. Secondly, it
> fails to load because eqep is not a part of the
> default am335x-boneblack.dtb located in /boot/uboot/dtbo in debian
>
> When trying to load this, dmesg returns
>
> [ 523.086537] bone-capemgr bone_capemgr.9: slot #10: dtbo
> 'bone_eqep0-00A0.dtbo' loaded; converting to live tree
> [ 523.090030] of_resolve: Could not find symbol 'eqep0'
> [ 523.095581] bone-capemgr bone_capemgr.9: slot #10: Failed to resolve
> tree
>
>
>
> In Angstrom, this file was located in /boot/am335x-boneblack.dtb. Attached
> is a modified version of this that was provided by TI and results in the
> eqep dts loading correctly in angstrom. This file has since changed in the
> Debian release and the fix no longer works. As stated in the first post in
> this thread, it would be nice if the correct eqep entries and your driver
> were included in the public image so that this functionality can be used
> out of the box like pwm.
>
>
> On Monday, May 12, 2014 11:53:08 PM UTC-7, Strawson wrote:
>>
>> Hi Nathaniel. The correct device tree fragments are loaded, pins are
>> multiplexed correctly, and all 3 eqep channels work perfectly with your
>> driver. The supplied mmap code from my last post also works perfectly, but
>> only if I insmod the compiled .ko kernel module first. Strange, I know.
>>
>> On Monday, May 12, 2014 11:41:14 PM UTC-7, Teknoman117 wrote:
>>>
>>> I'll certainly take a look at this next week. Currently in the middle
>>> of finals and Maker Faire is this weekend. And in all honesty, once i
>>> figure out whats going on with the driver, its still a good idea to use the
>>> kernel based implementation, mainly because you can take advantage of
>>> hardware interrupts and not have to busy wait. I know there are sleep
>>> methods, but unless something like Xenomai is being used, you're at the
>>> mercy of the scheduler...
>>>
>>> Although, just to rule it out - are you still applying a device tree
>>> overlay? The supplied DTS files do more than just initialize the driver,
>>> they setup the IO configuration, as the default board config doesn't bring
>>> out the eQEP lines.
>>>
>>> - Nathaniel Lewis
>>>
>>> On Saturday, May 10, 2014 12:25:14 AM UTC-7, Strawson wrote:
>>>>
>>>> I believe it is enabled. From my last post: the PWMSS clock config
>>>> returns
>>>> CLKCONFIG 0x111 = 000100010001
>>>>
>>>> According to pg 1492 of the reference manual, PWMSS_EQEP_EN is bit 4
>>>> in this register which appears to be true. Furthermore the interrupt
>>>> timer register QUTMR
>>>> is incrementing away just fine. Good idea, but no dice.
>>>>
>>>> For good measure I will write this bit anyway, but with |= instead of =
>>>> since some bits are not writable and I wouldn't want to erase the enable
>>>> bits for pwm and ecap.
>>>>
>>>>
>>>> On Friday, May 9, 2014 11:33:23 PM UTC-7, James Zapico wrote:
>>>>>
>>>>> Strawson,
>>>>>
>>>>> It looks like you're not turning the PWM EQEP clock on. There should
>>>>> be something to accomplish what this line from the kernel driver does:
>>>>>
>>>>> // Enable the clock to the eQEP unit
>>>>> status = pwmss_submodule_state_change(pdev->dev.parent,PWMSS_EQEPCLK_EN
>>>>> );
>>>>>
>>>>> I haven't tried this out, but it should be something like
>>>>> *(unsigned long*)(pwm_map_base[0]+PWMSS_CLKCONFIG) = PWMSS_EQEPCLK_EN
>>>>> ;
>>>>>
>>>>> -
>>>>> James
>>>>>
>>>>> On Friday, May 9, 2014 9:25:33 PM UTC-5, Strawson wrote:
>>>>>>
>>>>>> it seems my excitement was short-lived. While reading the position
>>>>>> with the previous (and attached) code does work, it only does so when
>>>>>> Teknoman's eqep driver is loaded. I've added writes to set up the PWMSS
>>>>>> and
>>>>>> eQEP configuration registers and have confirmed by reading them back
>>>>>> that
>>>>>> they are set up the same as the driver does. Any ideas on what I'm
>>>>>> missing?
>>>>>>
>>>>>> // Write the decoder control settings
>>>>>> *(unsigned short*)(pwm_map_base[0]+EQEP_OFFSET+QDECCTL) = 0;
>>>>>> // set maximum position to two's compliment of -1, aka UINT_MAX
>>>>>> *(unsigned long*)(pwm_map_base[0]+EQEP_OFFSET+QPOSMAX)=-1;
>>>>>> // Enable interrupt
>>>>>> *(uint16_t*)(pwm_map_base[0]+EQEP_OFFSET+QEINT) = UTOF;
>>>>>> // set unit period register
>>>>>> *(unsigned long*)(pwm_map_base[0]+EQEP_OFFSET+QUPRD)=0x5F5E100;
>>>>>> // enable counter in control register
>>>>>> *(unsigned short*)(pwm_map_base[0]+EQEP_OFFSET+QEPCTL) =
>>>>>> PHEN|IEL0|SWI|UTE|QCLM;
>>>>>>
>>>>>> SYSCONFIG 0xC
>>>>>> CLKCONFIG 0x111
>>>>>> QEPCTL0 0x9E
>>>>>> QDECCTL0 0x0
>>>>>> QEINT0 0x800
>>>>>> QUPRD0 0x5F5E100
>>>>>> QPOSMAX0 0xFFFFFFFF
>>>>>> QEPSTS0 0xA0
>>>>>> eqep0: -174 eqep1: 544 e^Cp2: 0
>>>>>>
>>>>>>
>>>>>>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
