--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/eVgyVduT288/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c67b75be-155c-4985-8052-6071688740c8%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 a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/eVgyVduT288/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYguQyz6xk-9RxEfeSArm8ObK_0kwnRtEi9%2B_9M1cMbZNw%40mail.gmail.com.
Sooo is this a "not going to happen" or if I comment stuff out from this pwm-tiehrpwm.c and and rebuild the kernel a thousand times, I may find that clock somehow? Or is the scope of "somewhere" the whole kernel? :) (I really want that eHRPWM start from PRU...)
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/eVgyVduT288/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhCfiLc6d-9iTOSDhbegoTk9CiC1wmK5xLLnxMukedU0A%40mail.gmail.com.
I've been trying to set up the eHRPWMx outputs on my BeagleBone Black (started out with eHRPWM1 -> P9_14) using only the PRU (no intervention/help from the Linux side, just setting registers on PRU code).
&epwmss0 { ti,no-idle; }; &epwmss1 { ti,no-idle; }; &epwmss2 { ti,no-idle; };
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c @@ -482,7 +482,7 @@ struct omap_hwmod am33xx_epwmss0_hwmod = { .name = "epwmss0", .class = &am33xx_epwmss_hwmod_class, .clkdm_name = "l4ls_clkdm", - .main_clk = "l4ls_gclk", + .main_clk = "ehrpwm0_tbclk", .prcm = { .omap4 = { .modulemode = MODULEMODE_SWCTRL, @@ -495,7 +495,7 @@ struct omap_hwmod am33xx_epwmss1_hwmod = { .name = "epwmss1", .class = &am33xx_epwmss_hwmod_class, .clkdm_name = "l4ls_clkdm", - .main_clk = "l4ls_gclk", + .main_clk = "ehrpwm1_tbclk", .prcm = { .omap4 = { .modulemode = MODULEMODE_SWCTRL, @@ -508,7 +508,7 @@ struct omap_hwmod am33xx_epwmss2_hwmod = { .name = "epwmss2", .class = &am33xx_epwmss_hwmod_class, .clkdm_name = "l4ls_clkdm", - .main_clk = "l4ls_gclk", + .main_clk = "ehrpwm2_tbclk", .prcm = { .omap4 = { .modulemode = MODULEMODE_SWCTRL,
&ehrpwm0_tbclk { ti,set-bit-to-disable; }; &ehrpwm1_tbclk { ti,set-bit-to-disable; }; &ehrpwm2_tbclk { ti,set-bit-to-disable; };
I got a bus error while calling prussdrv_open() in host code. Seeing this I tried going back (deleted the lines I added) but couldn't get rid of the bus error.
Possibly those device tree sources were not recent enough?
I see two solutions:Regards
- Either switch back to kernel 3.8. where everything works as it should.
- Or, if you want to stay with a 4.x kernel, follow this guide in order to make the PWMSS accessible by the PRUSS.
Would be cool if TJF could confirm this -> I think if I had the somewhat "correct" dt's inside /opt/source/dtb-4.9-ti/src/arm, changing the "am33xx-clocks.dtsi" would have done virtually the same thing?
** Matthijs you've mentioned this "synchronization of the ehrpwm clocks" via tbclken bits and mentioned that it's worse than useless right now with the kernel I'm using. You've said this since the kernel literally can't set the whole register to 0x7 or 0x0, thus enabling or disabling all 3 of the ehrpwm clocks simultaneously (at the same clock edge), right? The TRM also explicitly states this intended use case so I guess if the kernel somehow treated this register as a whole and not the separate bits as three clock nodes (and thus could set the whole register to 0x7, 0x0 etc.), using this feature would be possible right? (not that I know if this is possible with the kernel or not, just curious)
** TJF, I'm using the eCAP PWM right now as a busy-on-wait timer. I use that to generate fixed-time tasks (like interrupt service routines on MCUs triggered by a dedicated timer etc.). I guess it's not possible to truly *interrupt* the PRUs from an event generated by a timer outside the PRUSS or something, right? Haven't read the DMTIMERx's yet on the TRM though. By the way, I mean interrupt in the following sense -> the PRU is running its main loop doing stuff, and the ISR kicks in, stops the PRU main loop, does the ISR job, PRU continues from where it left off on the main loop before the interrupt happened.
Hi TJF,I mixed it up in hurry, you're right, the one I mentioned was the PRU local eCAP. The PWMSS0 and PWMSS2 eCAP's are available on pins for external PWM tasks I guess.
I used the local eCAP to not run into that non-deterministic latency due to OCP master access, it's pretty neat but I didn't know about the IEP, will check that out, thanks! The PRU local eCAP's are not routed to any pins either though right? So even if I switch to IEP for the busy-on-wait timer, I don't gain a PWM output (from the local PRU eCAP)?
Maybe there's still a better way I'm overlooking, so I'll keep thinking.
How about configure it as an optional clock named "tbclk" for themodule with ti-sysc driver in the dts and then tag it withSYSC_QUIRK_OPT_CLKS_NEEDED (ti,opt-clocks-needed maybe) andti,no-idle-on-init?Unfortunately those parts are not yet implemented in the ti-syscdriver.. I need to get rid of the hwmod platform data first withoutregressions so I'm still relying on platform data to verify dtsdata and use platform data callbacks for now for reset and idle.For other alternatives, if you have a proper device driver as achild of the module, tbclk could be it's "fck".Or if you don't want Linux to do anything with it, enable the clockin bootloader and tag the module with status = "disabled".BTW, we do now have patches posted for first ever hwmod freeti-sysc dts using driver for MCAN :) See thread:[PATCH v3 0/6] Add MCAN Support for dra76xThat device is super simple though so no idle quirks yet.
** Matthijs you've mentioned this "synchronization of the ehrpwm clocks" via tbclken bits and mentioned that it's worse than useless right now with the kernel I'm using. You've said this since the kernel literally can't set the whole register to 0x7 or 0x0, thus enabling or disabling all 3 of the ehrpwm clocks simultaneously (at the same clock edge), right? The TRM also explicitly states this intended use case so I guess if the kernel somehow treated this register as a whole and not the separate bits as three clock nodes (and thus could set the whole register to 0x7, 0x0 etc.), using this feature would be possible right? (not that I know if this is possible with the kernel or not, just curious)
Am Samstag, 30. Juni 2018 23:00:02 UTC+2 schrieb buraks...@gmail.com:Would be cool if TJF could confirm this -> I think if I had the somewhat "correct" dt's inside /opt/source/dtb-4.9-ti/src/arm, changing the "am33xx-clocks.dtsi" would have done virtually the same thing?Yes, changing the "am33xx-clocks.dtsi" should do the same thing. I wonder why it doesn't work for you.
Enabling tbclk in u-boot and not touching it in the kernel at all would have been by far the best option if it had been done in the first place, but unfortunately it's a bit invasive to implement now.
tbclk is enabled at CPU start-up. Not touching it at all would have been by far the best option.
As long as kernel 4.x is still experimental, kernel 3.8 will never go out of scope.