All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, "Cousson, Benoit" <b-cousson@ti.com>
Subject: Re: 4430sdp nfsroot broken with ff5c9059
Date: Mon, 15 Apr 2013 13:10:19 -0500	[thread overview]
Message-ID: <516C428B.3020805@ti.com> (raw)
In-Reply-To: <516C3179.4070501@ti.com>


On 04/15/2013 11:57 AM, Jon Hunter wrote:
> 
> On 04/13/2013 11:50 AM, Tony Lindgren wrote:
>> * Jon Hunter <jon-hunter@ti.com> [130412 19:22]:
>>>
>>> On 04/12/2013 07:06 PM, Tony Lindgren wrote:
>>>> * Tony Lindgren <tony@atomide.com> [130410 15:32]:
>>>>> * Jon Hunter <jon-hunter@ti.com> [130410 15:30]:
>>>>>>
>>>>>> Are you saying that you want to use the version with that is using the
>>>>>> pre-processor definitions? I was thinking that may be we could do that
>>>>>> as a clean-up for v3.11 and just use the original version I posted
>>>>>> earlier. Seems cleaner to me.
>>>>>
>>>>> No let's do that the preprocessor conversion for v3.11.
>>>>
>>>> Hmm looks like there are few more 3430sdp dt nfsroot exposed
>>>> issues in today's linux next.
>>>
>>> I don't even see any ethernet devices defined in the omap3430-sdp.dts
>>> file. Is this something that you have added on top?
>>
>> Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430.
> 
> Ok makes sense.
> 
>>>> To get nfsroot to behave, I had to have your earlier fix
>>>> from this thread and also revert a2797bea (gpio/omap: force
>>>> restore if context loss is not detectable).
>>>>
>>>> Otherwise nfsroot fails, but not necessarily every time?
>>>
>>> Well this patch is going to force a gpio restore everytime we call
>>> pm_runtime_get() when the use-count is 0. Yes this is not efficient,
>>> however, without this patch you run the risk of context being lost and
>>> you would never know. Per the changelog, long term a better solution is
>>> needed.
>>
>> It seems that this patch kills the ks8851 GPIO interrupt somehow,
>> at least most of the time.
> 
> Hmmm, let me go back and re-test this.

Ok I am seeing the problem. Looks like this patch exposed another
bug in the gpio driver. Seems that we never initialise the gpio
context during the probe and so on the first pm_runtime_get_sync()
during the probe we are restoring crap. Can you try this? If this
works, I will add a changelog and post as a fix.

Jon

>From 56598ba51a75481b050433bb38b7ae31a5ed4ae8 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised

---
 drivers/gpio/gpio-omap.c |   42 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..53bb8d5 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
 	bool is_mpuio;
 	bool dbck_flag;
 	bool loses_context;
+	bool context_setup;
 	int stride;
 	u32 width;
 	int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 }
 
 static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_setup_context(struct gpio_bank *p);
 
 static int omap_gpio_probe(struct platform_device *pdev)
 {
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
 	omap_gpio_chip_init(bank);
 	omap_gpio_show_rev(bank);
 
-	if (bank->loses_context)
+	if (bank->loses_context) {
 		bank->get_context_loss_count = pdata->get_context_loss_count;
+		omap_gpio_setup_context(bank);
+	}
 
 	pm_runtime_put(bank->dev);
 
@@ -1385,8 +1389,43 @@ void omap2_gpio_resume_after_idle(void)
 }
 
 #if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_setup_context(struct gpio_bank *p)
+{
+	struct omap_gpio_reg_offs *regs = p->regs;
+	void __iomem *base = p->base;
+
+	p->context.wake_en = __raw_readl(base + regs->wkup_en);
+	p->context.ctrl = __raw_readl(base + regs->ctrl);
+	p->context.ctrl = __raw_readl(base + regs->ctrl);
+	p->context.leveldetect0 = __raw_readl(base + regs->leveldetect0);
+	p->context.leveldetect1 = __raw_readl(base + regs->leveldetect1);
+	p->context.risingdetect = __raw_readl(base + regs->risingdetect);
+	p->context.fallingdetect = __raw_readl(base + regs->fallingdetect);
+
+	if (regs->set_dataout && p->regs->clr_dataout)
+		p->context.dataout = __raw_readl(base + regs->set_dataout);
+	else
+		p->context.dataout = __raw_readl(base + regs->dataout);
+
+	p->context.oe = __raw_readl(base + regs->direction);
+
+	if (p->dbck_enable_mask) {
+		p->context.debounce = __raw_readl(base + regs->debounce);
+		p->context.debounce_en = __raw_readl(base + regs->debounce_en);
+	}
+
+	p->context.irqenable1 = __raw_readl(base + regs->irqenable);
+	p->context.irqenable2 = __raw_readl(base + regs->irqenable2);
+
+	p->context_setup = true;
+}
+
 static void omap_gpio_restore_context(struct gpio_bank *bank)
 {
+	/* If context has not been initialised yet, return */
+	if (!bank->context_setup)
+		return;
+
 	__raw_writel(bank->context.wake_en,
 				bank->base + bank->regs->wkup_en);
 	__raw_writel(bank->context.ctrl, bank->base + bank->regs->ctrl);
@@ -1422,6 +1461,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
 #else
 #define omap_gpio_runtime_suspend NULL
 #define omap_gpio_runtime_resume NULL
+#define omap_gpio_setup_context NULL
 #endif
 
 static const struct dev_pm_ops gpio_pm_ops = {
-- 
1.7.10.4


  reply	other threads:[~2013-04-15 18:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09 21:23 4430sdp nfsroot broken with ff5c9059 Tony Lindgren
2013-04-10 17:31 ` Jon Hunter
2013-04-10 18:20   ` Tony Lindgren
2013-04-10 20:43     ` Jon Hunter
2013-04-10 20:54       ` Tony Lindgren
2013-04-10 22:25         ` Jon Hunter
2013-04-10 22:27           ` Tony Lindgren
2013-04-13  0:06             ` Tony Lindgren
2013-04-13  2:17               ` Jon Hunter
2013-04-13 16:50                 ` Tony Lindgren
2013-04-15 16:57                   ` Jon Hunter
2013-04-15 18:10                     ` Jon Hunter [this message]
2013-04-15 21:27                       ` Tony Lindgren
2013-04-16 17:14                         ` Jon Hunter
2013-04-16 18:06                           ` Tony Lindgren
2013-04-16 18:40                             ` Jon Hunter
2013-04-17  0:56                               ` Tony Lindgren
2013-04-10 23:58   ` Javier Martinez Canillas
2013-04-11  0:28     ` Jon Hunter
2013-04-11  0:50       ` Javier Martinez Canillas
2013-04-11  9:22     ` Benoit Cousson
2013-04-11  9:58       ` Javier Martinez Canillas
2013-05-08 22:05   ` Tony Lindgren

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=516C428B.3020805@ti.com \
    --to=jon-hunter@ti.com \
    --cc=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    /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.