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

Laxman Dewangan ldewangan at nvidia.com
Fri Dec 20 01:32:30 EST 2013


On Thursday 19 December 2013 11:53 PM, Stephen Warren wrote:
> On 12/19/2013 12:28 AM, Laxman Dewangan wrote:
>> 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.
> OK, after reverting the problematic MFD commit (which I assume will
> happen upstream too), I see no errors caused by this patch.
>
> As such, I've applied the series to Tegra's for-3.14/dt branch.
Thanks for taking care.

>
> Note that I couldn't verify if the pinctrl setup in patch 1/2 matched
> the ChromeOS kernel, since the node order is different there, and the
> property values don't use named constants there. I'll have to trust you.
> I'll be annoyed if it turns out we need to churn the pinctrl
> configuration in the future...

I referred the configuration from chrome branch. I assume that good 
amount of testing has already been done on this configuration.
I manually check all configuration and run chrome on this change which 
works properly. Did not see any abnormal behavior.
So if something missed then it is just human error which did not catch 
on 2 level of self review.

Again  any change on this configuration can be expected based on new 
testing or bringung new modules.





More information about the linux-arm-kernel mailing list