Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
From: Paul Walmsley <paul@pwsan.com>
Date: 2016-02-18 17:21:33
Also in:
linux-arm-kernel, linux-clk, linux-omap, linux-pwm, lkml
Hi Franklin, On Thu, 18 Feb 2016, Franklin S Cooper Jr. wrote:
On 02/18/2016 12:58 AM, Paul Walmsley wrote:quoted
OK I'm not sure I understand what's going on, particularly the part about locking and unlocking. Are you saying that the pwm_bl driver calls into the pwm_tiecap module to write to the PWMSS_CLKCONFIG registers to ungate the ECAP clock, and then the hardware silently ignores the write? If that's the case, shouldn't we be seeing some warning messages from a failure to ungate the clock from a subsequent PWMSS_CLKSTATUS poll? Or am I misunderstanding what's going on here?Pwm-tipwmss.c exports a function pwmss_submodule_state_change which interacts with PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. Both pwm-tiehrpwm.c and pwm-tiecap.c calls this exported function to unlock the gate at probe time and lock the gate when the driver is removed. So when the gate fails to be unlocked after it previously is locked there isn't a way to know this via the PWMSS_CLKSTATUS registers.
OK I understand now. Sounds like the gating -> ungating transition is effectively a one-time operation, and once the ungating -> gating transition is done, there's no way to reverse it. Please correct me if I've got it wrong.
So the driver "believes" that the gate is unlocked and when pwm_bl runs it calls the set_polarity function. Set_polarity in the case of AM437x gp evm maps to the ecap's ecap_pwm_set_polarity function call. This call then attempts to write to the ecap registers which results in the external abort since the clock to the ecap is still gated. When the ecap and tihrpwm driver request to unlock the clock gate it already checks the XXX_CLK_EN_ACK bitfields within CLKSTATUS and it shows that the clocks "should" be unlocked. So there is an issue with the IP.
OK
Yes, I plan on addressing the change Vignesh acknowledged regarding changing RESETSTATUS to SOFTRESET. For your other comments I believe he already explained why it has to be set in that particular way. If there is anything that I missed or something that isn't clear please let me know.
Perfect, thanks for the good description and the followup. - Paul