Linux/DRA71: PWM reset at kernel starting

Christian N

Part Number: DRA71

Tool/software: Linux

Team

We are configuring the PWMSS3 in IPU1.

It works fine running IPU1 firmware and A15 U-Boot, but when A15 jumps from U-Boot to Kernel (Starting kernel message before any log displaying) PWM shows a glitch after that it works fine again.

Our DTS related bindings

&ehrpwm2 {
   ti,late-attach;
   ti,no-idle-on-init;
   ti,no-reset-on-init;
   ti,no-idle;
};

&ehrpwm2_tbclk {
    /delete-property/ clocks; /* It avoids the omap_hwmod to try to initialize it and stop it. This tbclk is already up and running from the ipu1*/
}; /*With or without it, glitch happens*/

&epwmss2{
   ti,late-attach;
   ti,no-idle-on-init;
   ti,no-reset-on-init;
   ti,no-idle;
};

Reading PWM registers from IPU1 side to analyze this issue, it likes as pwm is suffering a sudden reset, and then keeps counting.

Our platform based on Android SDK 6AO.1.0 (A15) and ti-processor-sdk-rtos-automotive-dra7xx-evm-04.00.00.04 (IPU1)

Could you provide any hints

Regards

over 7 years ago

0 Vishal Mahaveer over 7 years ago

TI__Mastermind 33390 points

Hi Christian,

Is PWM completely controlled by IPU1 or shared between IPU1 and A15?

Regards,
Vishal

0 Christian N over 7 years ago in reply to Vishal Mahaveer

Expert 1285 points

Hi Vishal

(I hope everything is fine out there)

PWM is controlled and configured by IPU1. A15 made pinmux in U-Boot only

Regards

0 Vishal Mahaveer over 7 years ago in reply to Christian N

TI__Mastermind 33390 points

All well, thanks for asking.

Few things to try.

-1-
In that case could you try disabling the drivers in kernel config or making status="disabled" for these nodes.
(CONFIG_PWM_TIECAP, CONFIG_PWM_TIEHRPWM, CONFIG_PWM_TIPWMSS)

-2-
Add the same no-idle, no-reset properties to ecap node as well

Note: the ti,lateattach flag is only understood by remoteproc driver and applies to remote core nodes and associated timers and mmu nodes.

Regards,
Vishal

0 Christian N over 7 years ago in reply to Vishal Mahaveer

Expert 1285 points

Hi Vishal

Proposed things didn't work

We have to make the following work around

/* l4_per2 */

static struct omap_hwmod dra7xx_l4_per2_hwmod = {

    .name       = "l4_per2",

    .class      = &dra7xx_l4_hwmod_class,

    .clkdm_name = "l4per2_clkdm",

    .flags = HWMOD_NO_IDLE, /*FLAG ADDED*/

    .prcm = {

        .omap4 = {

            .clkctrl_offs = DRA7XX_CM_L4PER2_L4_PER2_CLKCTRL_OFFSET,

            .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,

        },

    },

};

As far we know pwm_ss3 is not taken in account device tree noreset, noidle, bindings and set 0x4a00970c register in idle

We don't know if our work around could have "collateral demage", related clocks

Could you give us any hint ?

Regards

0 Vishal Mahaveer over 7 years ago in reply to Christian N

TI__Mastermind 33390 points

Hi Christian,

The flags "ti,no-idle-on-init", "ti,no-reset-on-init", etc.. are read by hwmod driver (arch/arm/mach-omap2/omap_hwmod.c)
I would not recommend changing the flags of whole l4_per2 domain.

Could you try below change and see if it makes a difference?

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 38c42a163510..830c8a756439 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -4744,7 +4744,6 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
        &dra7xx_l4_wkup__wd_timer2,
        &dra7xx_l4_per2__epwmss0,
        &dra7xx_l4_per2__epwmss1,
-       &dra7xx_l4_per2__epwmss2,
        NULL,
 };

Regards,
Vishal

0 Christian N over 7 years ago in reply to Vishal Mahaveer

Expert 1285 points

Hi Vishal

It doesn't wok :-(

Regards

0 Vishal Mahaveer over 7 years ago in reply to Christian N

TI__Mastermind 33390 points

Ideally, the flags in dts should have been enough to instruct hwmod driver to not reset/idle the module.
I have to check and get back on this behavior.

0 Vishal Mahaveer over 7 years ago in reply to Vishal Mahaveer

TI__Mastermind 33390 points

Hi Christian,

Could you share the full dts node of epwmss2?
It would be better if you could convert the finally built dtb to dts and share the epwmss part of the dts.

Regards,
Vishal

0 Christian N over 7 years ago in reply to Vishal Mahaveer

Expert 1285 points

Good Morning Vishal

Please take in account that we did the test with status= ok and disabled with the same behaviour

		epwmss@48442000 {
			compatible = "ti,dra746-pwmss", "ti,am33xx-pwmss";
			reg = <0x48442000 0x30>;
			ti,hwmods = "epwmss2";
			#address-cells = <0x1>;
			#size-cells = <0x1>;
			status = "disabled";
			ranges;
			ti,late-attach;
			ti,no-idle-on-init;
			ti,no-reset-on-init;
			ti,no-idle;

			pwm@48442200 {
				compatible = "ti,dra746-ehrpwm", "ti,am3352-ehrpwm", "ti,am33xx-ehrpwm";
				#pwm-cells = <0x3>;
				reg = <0x48442200 0x80>;
				clocks = <0x118 0xc>;
				clock-names = "tbclk", "fck";
				status = "disabled";
				ti,late-attach;
				ti,no-idle-on-init;
				ti,no-reset-on-init;
				ti,no-idle;
			};

			ecap@48442100 {
				compatible = "ti,dra746-ecap", "ti,am3352-ecap", "ti,am33xx-ecap";
				#pwm-cells = <0x3>;
				reg = <0x48442100 0x80>;
				clocks = <0xc>;
				clock-names = "fck";
				status = "disabled";
			};
		};

Regards

0 Vishal Mahaveer over 7 years ago in reply to Christian N

TI__Mastermind 33390 points

You did try adding the "ti,no*" properties to ecap node as well right?

0 Christian N over 6 years ago in reply to Vishal Mahaveer

Expert 1285 points

We re-test with ti,no... in all subnodes members with no results

0 Vishal Mahaveer over 6 years ago in reply to Christian N

TI__Mastermind 33390 points

Ideally, the properties in dts node should have been enough.
The strange thing is even after removing the pwmss from hwmod file, you are seeing the glitch.

We are discussing it internally, will get back to you when I have more information.

0 Vishal Mahaveer over 6 years ago in reply to Vishal Mahaveer

TI__Mastermind 33390 points

Hi Christian,

We think what happens here is that kernel doesn't have any visible users for l4per2, so it is idled, temporarily cutting clocks from pwmss2 also.
Your previous change of touching the master (in this case l4per2) is the solution.

Instead of adding HWMOD_NO_IDLE, could you try adding HWMOD_INIT_NO_IDLE in l4per2 flag?

0 Christian N over 6 years ago in reply to Vishal Mahaveer

Expert 1285 points

Hi Vishal

With HWMOD_INIT_NO_IDLE, no glitch is present, also.
We'll test a couple of features related to verify that no regressions are present.

Thanks

Processors

Processors forum

Linux/DRA71: PWM reset at kernel starting