discrepancy while save and restore of debounce registers
Hebbar, Gururaja
gururaja.hebbar at ti.com
Fri Nov 2 05:44:26 EDT 2012
On Thu, Oct 18, 2012 at 21:44:56, Hunter, Jon wrote:
> Hi Gururaja,
>
> On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote:
> > Jon,
> >
> > On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
>
> [snip]
>
> >>> My doubt/questions are
> >>> 1. Why should debounce registers be updated only when it's accessed previously?
> >>
> >> If debounce is not being used by any of the gpios, then there is no need
> >> to restore them as there are no bits set. So this makes sense and saves
> >> a couple register writes.
> >
> > What I want to know is that other than saving register writes, is there any
> > other important stuff that specifies this requirement.
>
> From a HW perspective, none that I can see.
>
> From a SW perspective, yes, as I mentioned if you restore these
> registers without first initialising the context variables where these
> registers are stored, then you may be restoring unknown values to the
> registers and that is bad.
>
> >>> 2. What is the relation between updating debounce registers and crash seen on
> >>> others registers?
> >>
> >> This I am not sure about. I gave this a quick try on my omap3430 beagle
> >> board, but I did not see any side-effects from doing this. However, if
> >> you are always restoring the debounce context regardless of whether
> >> debounce is being used, then you could be writing bad values to the
> >> debounce registers as the context variables bank->context.debouce and
> >> bank->context.debouce_en may not initialised. So that is bad. However,
> >> that said I am still not sure how this could cause a crash.
> >>
> >> Can you share more details on ...
> >
> > Sorry for missing below details in first post.
> >
> >> 1. The OMAP platform you are using?
> >
> > I was trying this on TI AM335x platform (repo below). On AM335x EVM board
> >
> > http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog;
> > h=refs/heads/v3.2-staging
> >
> >> 2. What linux distro/environment you are using?
> >
> > Arago AM335x PSP release (linux 3.2 + am335x patch-set)
> >
> >> 3. If there are any specific steps to reproduce this 100% of the time?
> >
> > On top of this tree, try suspend/resume using "echo mem > /syspower/state"
>
> I have a beagle-bone but unfortunately, suspend does not appear to be
> supported in the mainline kernel yet so I am unable to test this on the
> am335x on the mainline.
You can try the suspend/resume on BB from Arago tree which I mentioned above
>
> Have you compared the gpio driver from your v3.2 branch with the current
> mainline to see how different this code is? Ideally, it would be good to
> test on the mainline kernel for another data point to see if this is
> local to your branch.
The mainline kernel omap GPIO driver has changed a lot from current arago
tree (which is at v3.2). Upon comparing is when I found out about the
register access check done before restoring.
>
> Cheers
> Jon
>
>
>
Regards,
Gururaja
More information about the linux-arm-kernel
mailing list