From: ldewangan@nvidia.com (Laxman Dewangan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/2] ARM: tegra: add ams AS3722 device to Venice2 DT
Date: Thu, 19 Dec 2013 12:58:29 +0530 [thread overview]
Message-ID: <52B2A01D.2000207@nvidia.com> (raw)
In-Reply-To: <52B20BB4.50506@wwwdotorg.org>
On Thursday 19 December 2013 02:25 AM, Stephen Warren wrote:
> On 12/18/2013 05:52 AM, Laxman Dewangan wrote:
>> Add ams AS3722 entry for gpio/pincontrol and regulators
>> to venice2 DT.
> This patch still causes:
>
>> [ 0.726545] as3722-pinctrl as3722-pinctrl: pin gpio0 already requested by as3722-pinctrl; cannot claim for as3722-regulator
>> [ 0.737681] as3722-pinctrl as3722-pinctrl: pin-0 (as3722-regulator) status -22
>> [ 0.744895] as3722-pinctrl as3722-pinctrl: could not request pin 0 (gpio0) from group gpio0 on device as3722-pinctrl
>> [ 0.755500] as3722-regulator as3722-regulator: Error applying setting, reverse things back
This error is nothing related to the ams dt or driver. This came from
the framework from the driver/base for adding pinmux call before calling
any diver's probe.
Here is my finding:
Frameworks calls the pinctrl_bind_pins() before calls the driver's probe
(drivers/base/dd.c) and pinctrl_bind_pins() calls the pinmux mapping and
try to set the default (drvers/base/pinctrl.c).
AMS AS3722 DT is flat type on which all sub devices of AS3722 have the
property on parent node only, there is no subnode for each sub driver
like palmas. In this case all sub drivers of_node is initialized as
parent->of_node in mfd-core.c (mfd_add_devices).
mfd-core.c: mfd_add_device()
if (!pdev->dev.of_node)
pdev->dev.of_node = parent->of_node;
So all sub devices of AS3722 has the parent node.
This node has the default pinmux configuration and so it tries to set
the default pinmux before sud-driver's probe get called.
The first one (for pinmux driver) it is success but for regulator and
rtc, it is failed as pins are owned by the pinmux drivers.
This does not have any side impact as currently, pinctrl_bind_pins()
only return the success or ERPOBE_DEFER
I was testing the patch with linux-next-common of your branch and
chrome-os/kernel-next with linux-next's pinctrl/regulator/mfd and not
able to repro this because driver/base changes was not there.
next prev parent reply other threads:[~2013-12-19 7:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 12:52 [PATCH 1/2] ARM: tegra: fix missing pincontrol configuration for Venice2 Laxman Dewangan
2013-12-18 12:52 ` [PATCH V2 2/2] ARM: tegra: add ams AS3722 device to Venice2 DT Laxman Dewangan
2013-12-18 20:55 ` Stephen Warren
2013-12-19 7:28 ` Laxman Dewangan [this message]
2013-12-19 17:24 ` Stephen Warren
2013-12-19 18:23 ` Stephen Warren
2013-12-20 6:32 ` Laxman Dewangan
2013-12-18 20:56 ` [PATCH 1/2] ARM: tegra: fix missing pincontrol configuration for Venice2 Stephen Warren
2013-12-19 7:14 ` Laxman Dewangan
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=52B2A01D.2000207@nvidia.com \
--to=ldewangan@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).