Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1337564

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

From Paul Walmsley <paul@pwsan.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Date 2016-02-18 18:30 +0100
Message-ID <r3AyV-uN-71@gated-at.bofh.it> (permalink)
References (3 earlier) <pMTqs-2pX-65@gated-at.bofh.it> <q3zEZ-3Q6-13@gated-at.bofh.it> <r3hcS-3fe-13@gated-at.bofh.it> <r3qJc-1Fp-1@gated-at.bofh.it> <r3yQq-7CY-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Franklin, 

On Thu, 18 Feb 2016, Franklin S Cooper Jr. wrote:

> On 02/18/2016 12:58 AM, Paul Walmsley wrote:
>
> > 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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS "Franklin S Cooper Jr." <fcooper@ti.com> - 2016-02-17 21:50 +0100
  Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS Paul Walmsley <paul@pwsan.com> - 2016-02-18 08:00 +0100
    Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS "Franklin S Cooper Jr." <fcooper@ti.com> - 2016-02-18 16:40 +0100
      Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS Paul Walmsley <paul@pwsan.com> - 2016-02-18 18:30 +0100

csiph-web