All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Doug Anderson <dianders@chromium.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Olof Johansson <olof@lixom.net>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thomas Abraham <thomas.abraham@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Prathyush K <prathyush.k@samsung.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] pinctrl: samsung: fix suspend/resume functionality
Date: Fri, 17 May 2013 00:56:41 +0200	[thread overview]
Message-ID: <1475116.qtX3b3bLWZ@flatron> (raw)
In-Reply-To: <201305170030.39266.heiko@sntech.de>

On Friday 17 of May 2013 00:30:38 Heiko Stübner wrote:
> Am Freitag, 17. Mai 2013, 00:08:34 schrieb Tomasz Figa:
> > On Thursday 16 of May 2013 14:51:53 Doug Anderson wrote:
> > > Tomasz,
> > > 
> > > On Thu, May 16, 2013 at 2:27 PM, Tomasz Figa <tomasz.figa@gmail.com>
> > 
> > wrote:
> > > > OK. I will be fine to go with your patches, after addressing the
> > > > comments. In the end it's good that you posted them, as reviewing
> > > > them allowed me to find even better ways of doing some things than
> > > > I
> > > > had in mine ;) .
> > > 
> > > Yes.  I often find that the best way to review code is to think
> > > about
> > > how I would implement it myself.  Certainly I think we've ended up
> > > with something better / less buggy this way.  ;)
> > > 
> > > > How all of this works is basically a good question. I couldn't
> > > > find
> > > > any
> > > > mention about pins switching from power down to normal mode in the
> > > > documentation, but maybe there is a small side note somewhere,
> > > > which I
> > > > could miss.
> > > > 
> > > > On S3C6410, for example, there are two modes. State is switched to
> > > > power down mode automatically, but can be switched out either
> > > > automatically on wake-up (exact timing is unknown to me) or by
> > > > clearing a special bit, depending on value of other special bit.
> > > > 
> > > > IMHO this is rather important, so we should find out how it work
> > > > on
> > > > other SoCs and make the code account for it.
> > > 
> > > Agreed that it's important.  ...but it's also good not to have tons
> > > of
> > > complexity when it's not needed.  It sounds like S3C6410 could be
> > > handled OK by just using the special bits and waiting to take things
> > > out of power down mode.
> > > 
> > > ...thinking about it, all SoCs that have power down modes (which you
> > > _must_ have if your pinctrl state is lost across a low power) would
> > > be
> > > slightly broken if they didn't have a bit to switch out of power
> > > down
> > > mode.  Otherwise you're asking for at least some type of glitch
> > > because you'll end up in the default state of pins for a little
> > > while
> > > during resume.
> > > 
> > > That's not to say that there aren't broken SoCs out there and it's
> > > entirely possible that people even designed systems around them
> > > (knowing that the default state of each pin after wakeup is not
> > > harmful to whatever is connected to that pin).  If there are any
> > > cases
> > > like this then they would need the special code like my V1 patch
> > > had.
> > > Do you know of any SoCs like this that we need to support on kernel
> > > 3.10 and higher?
> > 
> > Hmm, I just checked documentation of S3C2440 and S3C2416 they seem to
> > retain GPIO settings completely in sleep mode. This would mean that
> > they don't require any suspend/resume support in pinctrl driver.
> > Heiko, can you confirm this?
> 
> Hmm, my system does not have a working suspend right now, but looking at
> the legacy code (mach-s3c24xx/pm.c, etc) tells me that the gpio banks
> were never saved during suspend.
> 
> And as there were (and still are) systems with working suspend around,
> I'd assume that you're correct that the pins retain their state.
> 
> Is the same true for the s3c64xx, as I didn't find any gpio suspend
> handling for it either.

Seems like I need some sleep, as I'm already starting to overlook large 
blobs of code. 

Originally, GPIO suspend/resume handlers have been configured in 
drivers/gpio/gpio-samsung.c, by setting pm field of samsung_gpio_chip 
struct to point to appropriate samsung_gpio_pm struct, which contains 
pointers to save and resume callbacks.

In result, samsung_gpio_pm_2bit_* or samsung_gpio_pm_4bit_* have been 
used, depending on bank type, on all SoCs.

Now since the documentation states that wake-up reset doesn't reset GPIO 
registers (at least on S3C2440 and S3C2416), I wonder what is the correct 
way of handling them.

Best regards,
Tomasz


  reply	other threads:[~2013-05-16 22:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16 17:12 [PATCH 0/2] Fix suspend/resume issues created by pinmux on exynos Doug Anderson
2013-05-16 17:12 ` [PATCH 1/2] pinctrl: samsung: fix suspend/resume functionality Doug Anderson
2013-05-16 19:19   ` Tomasz Figa
2013-05-16 20:32     ` Doug Anderson
2013-05-16 21:27       ` Tomasz Figa
2013-05-16 21:51         ` Doug Anderson
2013-05-16 22:08           ` Tomasz Figa
2013-05-16 22:30             ` Heiko Stübner
2013-05-16 22:56               ` Tomasz Figa [this message]
2013-05-16 23:10                 ` Doug Anderson
2013-05-16 23:55                   ` Doug Anderson
2013-05-16 21:19     ` Heiko Stübner
2013-05-16 17:12 ` [PATCH 2/2] pinctrl: exynos: fix eint wakeup by using irq_set_wake() Doug Anderson
2013-05-16 19:26   ` Tomasz Figa
2013-05-16 22:25     ` Doug Anderson
2013-05-16 22:37       ` Tomasz Figa
2013-05-16 23:49         ` Doug Anderson
2013-05-16 23:19 ` [PATCH v2] pinctrl: samsung: fix suspend/resume functionality Doug Anderson
2013-05-17  4:33   ` [PATCH v3] " Doug Anderson
2013-05-17 14:38     ` Tomasz Figa
2013-05-20 11:47     ` Linus Walleij
2013-05-20 14:59       ` Doug Anderson
2013-05-20 16:16         ` Kukjin Kim
2013-05-21  6:26         ` Olof Johansson
2013-05-21 11:21     ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1475116.qtX3b3bLWZ@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=kgene.kim@samsung.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=prathyush.k@samsung.com \
    --cc=swarren@wwwdotorg.org \
    --cc=thomas.abraham@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.