On 11/05/2013 12:18 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Mon, Nov 04, 2013 at 01:59:33PM +0800, Wei Ni wrote:
>
>> I didn't find the generic DT init code, do you mean to add it in the
>> customize_machine() in arch/arm/kernel/setup.c ? But it isn't only for
>> DT systems.
>
> We can do it as part of parsing the DT or deciding to parse the DT.
I checked the kernel codes, it seems the different arch uses different
way to parse DT, and I think these codes are related with DT, it's not
better to add such regulator full constraints codes.
>
>> How about to add it in the regulator subsystem? I mean we can add
>> following codes in the regulator_init() routine in driver/regulator/core.c:
>> +#ifdef CONFIG_OF
>> +regulator_has_full_constraints();
>> +#endif
>
> No, that's not good - we can have DT enabled but boot on a non-DT board.
I found in regulator_init_complete(void), there has following codes:
"
/*
* Since DT doesn't provide an idiomatic mechanism for
* enabling full constraints and since it's much more natural
* with DT to provide them just assume that a DT enabled
* system has full constraints.
*/
if (of_have_populated_dt())
has_full_constraints = true;
"
According to the comment, this is what we want. Since this routine is
called by late_initcall, it's later than some device probing, so it will
cause the device can't get the dummy regulator.
I think we can move them to the regulator_init() routine, then we can
fix this issue.
Thanks.
Wei.
>
> * Unknown Key
> * 0x7EA229BD
>
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
