Re: [PATCH V2 2/2] ARM: tegra: add ams AS3722 device to Venice2 DT

[Laxman Dewangan]

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.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/