All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: qianfan <qianfanguijin@163.com>
Cc: linux-omap@vger.kernel.org,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Kevin Hilman <khilman@kernel.org>
Subject: Re: OMAP GPIO ready too later
Date: Wed, 16 Feb 2022 13:56:46 +0200	[thread overview]
Message-ID: <Ygzmfh+F3J8Zt9vl@atomide.com> (raw)
In-Reply-To: <379b9e75-933c-902c-0f6e-807be9acebc5@163.com>

* qianfan <qianfanguijin@163.com> [220216 04:05]:
> 在 2022/2/14 15:50, Tony Lindgren 写道:
> > Well seems like the boottime of 1.25 seconds to having the gpio probed should
> > be way longer than your bootloader configured watchdog timeout :) What do you
> > have the bootloader set the watchdog timeout?
> I had sniffer the gpio data by using logic analysis, when the linux gpio-wdt
> driver toggle watchdog pin, it passed about 5 seconds after the u-boot done.
> And the gpio watchdog's deadline is 1.6s.

Well on my beaglebone black looks like gpios are initialized around 1.7s,
but pinctrl is initialized around 0.25s. You could create some driver that
in it's init sets the related gpio pin to PIN_OUTPUT_PULLUP | SAFE_MODE
to kick the gpio watchdog, and then exits releasing the pinmux so the
gpio based driver can take over. Or maybe your gpio watchdog driver could
do pin configuration in init, then do what it currently does in probe.

Of course booting things faster would be the best solution, but that can
easily get delayed with kernel updates with deferred probe for example.

Regards,

Tony

      reply	other threads:[~2022-02-16 11:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19  8:20 OMAP GPIO ready too later qianfan
2022-02-03  9:07 ` Tony Lindgren
2022-02-12  2:18   ` qianfan
2022-02-14  7:50     ` Tony Lindgren
2022-02-16  4:06       ` qianfan
2022-02-16 11:56         ` Tony Lindgren [this message]

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=Ygzmfh+F3J8Zt9vl@atomide.com \
    --to=tony@atomide.com \
    --cc=grygorii.strashko@ti.com \
    --cc=khilman@kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=qianfanguijin@163.com \
    --cc=ssantosh@kernel.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.