From: He YunLei <heyunlei@huawei.com>
To: Tony Lindgren <tony@atomide.com>
Cc: <linux-kernel@vger.kernel.org>, <grant.likely@linaro.org>,
<robh+dt@kernel.org>, <wangbintian@huawei.com>,
<liguozhu@hisilicon.com>, <kong.kongxinwei@hisilicon.com>
Subject: Re: [RFC PATCH] pinctrl: pinctrl-single.c: init pinctrl single at arch_initcall time
Date: Sat, 11 Oct 2014 17:01:42 +0800 [thread overview]
Message-ID: <5438F1F6.4080300@huawei.com> (raw)
In-Reply-To: <20141008181027.GE10014@atomide.com>
On 2014/10/9 2:10, Tony Lindgren wrote:
> * He YunLei <heyunlei@huawei.com> [141007 18:43]:
>>
>> Thanks for your review and I am really appreciated it, but in our arm
>> platform, we haven't custom initcall levels for other drivers. Although
>> deferred probe helps other drivers to register well, we are also confused
>> for the issues of lots of pin request errors debug output while booting the
>> kernel. Besides, if the number is bigger than the limited number, whether
>> deferred probe can solve this problem.
>
> OK. Care to provide some examples where this happens on your
> platform?
>
> Note that we already have pinctrl very early in drivers/Makefile.
> What are the early users for pinctrl-single in your setup?
>
> Regards,
>
> Tony
>
> .
>
In our platform we use subsys_initcall in I2C, and fs_initcall in PMIC,
Both of them are early than pinctrl-single. Although they register well
with the aid of deferred probe, it's really confused us that pins
request deferred. Why can't we setup pinctrl-single earlier to reduce
these messages.
Regards
YunLei
next prev parent reply other threads:[~2014-10-11 9:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 10:31 [RFC PATCH] pinctrl: pinctrl-single.c: init pinctrl single at arch_initcall time He YunLei
2014-09-29 17:54 ` Tony Lindgren
2014-10-08 1:42 ` He YunLei
2014-10-08 18:10 ` Tony Lindgren
2014-10-11 9:01 ` He YunLei [this message]
2014-10-13 15:42 ` 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=5438F1F6.4080300@huawei.com \
--to=heyunlei@huawei.com \
--cc=grant.likely@linaro.org \
--cc=kong.kongxinwei@hisilicon.com \
--cc=liguozhu@hisilicon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.com \
--cc=wangbintian@huawei.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.