Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 27 Jan 2015, Felipe Balbi wrote:

> On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote:
> > On Tue, Jan 27, 2015 at 05:12:05PM +0000, Paul Walmsley wrote:
> > > On Tue, 27 Jan 2015, Felipe Balbi wrote:
> > > 
> > > > On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote:
> > > > > On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote:
> > > > >
> > > > > > hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?
> > > > > 
> > > > > gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always
> > > > > read as 0x 12510f00 which would translate into:
> > > > > 
> > > > > - module disabled
> > > > > - all opt clocks are on
> > > > > - module is transitioning
> > > > > - module in standby
> > > > > - clkA as TPIU and STM trace clock
> > > > > - all dividers set to 2
> > > > 
> > > > just fyi, checking with HW folks, this might be a new bug, unless
> > > > debugss needs something special.
> > > 
> > > If that happens on DEBUGSS disable, it's probably the same issue as on 
> > > AM33xx:
> > > 
> > > http://www.spinics.net/lists/arm-kernel/msg320801.html
> > > http://www.spinics.net/lists/arm-kernel/msg321930.html
> > > http://www.spinics.net/lists/arm-kernel/msg329151.html
> > > 
> > > Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing?
> > 
> > I'll try it out in a bit...
> 
> nope, same thing.
> 
> [   27.633235] omap_hwmod: debugss: _wait_target_disable failed

OK, looking at the code, this makes sense.  So here's what I'd suggest 
asking the hardware team: is the right approach to:

1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even 
when it's not in use or when entering chip low-power states, or

2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS 
is not in use or when entering chip low-power states, but ignore the 
DEBUGSS CLKCTRL IDLEST register 

We'll need a new hwmod flag either way; the question is whether it should 
be something like HWMOD_CANNOT_DISABLE (case 1), or 
HWMOD_DISABLE_IGNORE_IDLEST (case 2).


- Paul
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux