About [PATCH 1/2] regulator: core: Provide a dummy regulator with full constraints
Hi, Mark
In the latest regulator framework, it default to provide dummy regulators with full constraints by your patch "regulator: core: Provide a dummy regulator with full constraints".
I tried to use regulator_get() on lm90.c. If not set vcc-supply property in the dts file to assume the regulator is physically present and enabled, but it still can't get dummy regulator, just return -ENODEV. I traced it, the regulator_dev_lookup() will return -ENODEV, and at that time the has_full_constraints is still false, didn't be initialized in regulator_init_complete() yet, so it will not return dummy regulator, and will not return -EPROBE_DEFER either. This will cause the lm90_probe() failed.
Could you take a look ?
Thanks.
Wei.
Quoted 13 lines · Wei Ni
In the latest regulator framework, it default to provide dummy regulators with full constraints by your patch "regulator: core: Provide a dummy regulator with full constraints".
I tried to use
regulator_get()onlm90.c. If not set vcc-supply property in the dts file to assume the regulator is physically present and enabled, but it still can't get dummy regulator, just return-ENODEV. I traced it, theregulator_dev_lookup()will return-ENODEV, and at that time thehas_full_constraintsis still false, didn't be initialized inregulator_init_complete()yet, so it will not return dummy regulator, and will not return -EPROBE_DEFER either. This will cause thelm90_probe()failed.
Quoted 1 line
Could you take a look ?
Could you take a look at why we're getting -ENODEV please - this indicates a problem with the device tree code since it should be what's requesting probe deferral when it sees a link is present.
Quoted 17 lines · Mark Brown
* PGP Signed by an unknown key
Quoted 12 lines · Wei Ni
In the latest regulator framework, it default to provide dummy regulators with full constraints by your patch "regulator: core: Provide a dummy regulator with full constraints".
I tried to use
regulator_get()onlm90.c. If not set vcc-supply property in the dts file to assume the regulator is physically present and enabled, but it still can't get dummy regulator, just return-ENODEV. I traced it, theregulator_dev_lookup()will return-ENODEV, and at that time thehas_full_constraintsis still false, didn't be initialized inregulator_init_complete()yet, so it will not return dummy regulator, and will not return -EPROBE_DEFER either. This will cause thelm90_probe()failed.
Quoted 5 lines
Quoted 1 line
Could you take a look ?
Could you take a look at why we're getting
-ENODEVplease - this indicates a problem with the device tree code since it should be what's requesting probe deferral when it sees a link is present.
In the regulator_dev_lookup(), it will try to read the "xx-supply" to get the regnode, but I didn't set the vcc-supply in dts file for lm90, so the of_get_regulator() will return NULL, then the regulator_dev_lookup() will set the ret to -ENODEV, and return the rdev as NULL.
Thanks.
Wei.
Quoted 4 lines
* Unknown Key
*0x7EA229BD
Quoted 5 lines · Wei Ni
In the
regulator_dev_lookup(), it will try to read the "xx-supply" to get the regnode, but I didn't set the vcc-supply in dts file for lm90, so theof_get_regulator()will return NULL, then theregulator_dev_lookup()will set the ret to-ENODEV, and return the rdev as NULL.
OK, I think the device tree board code just needs to set full constraints during machine initialisation. We can't have multiple initcalls in the regulator code and doing it there is really a bit of a workaround anyway.
Quoted 4 lines · Mark Brown
* PGP Signed by an unknown key
On Tue, Oct 08, 2013 at 05:46:49PM +0800, Wei Ni wrote:
Quoted 8 lines
Quoted 5 lines
In the
regulator_dev_lookup(), it will try to read the "xx-supply" to get the regnode, but I didn't set the vcc-supply in dts file for lm90, so theof_get_regulator()will return NULL, then theregulator_dev_lookup()will set the ret to-ENODEV, and return the rdev as NULL.OK, I think the device tree board code just needs to set full constraints during machine initialisation. We can't have multiple
Hi, Mark, do you mean we can call regulator_has_full_constraints(), but some platforms doesn't have board file now, they only have dts file, how to call this functions?
Wei.
Quoted 6 lines
initcalls in the regulator code and doing it there is really a bit of a workaround anyway.
* Unknown Key
*0x7EA229BD
Quoted 8 lines · Wei Ni
Quoted 2 lines · Mark Brown
OK, I think the device tree board code just needs to set full constraints during machine initialisation. We can't have multiple
Hi, Mark, do you mean we can call
regulator_has_full_constraints(), but some platforms doesn't have board file now, they only have dts file, how to call this functions?
There is still a board file for DT machines, it's just shared between all machines - it should be doing the call instead of the regulator framework trying to retrofit it.
Quoted 8 lines · Mark Brown
* PGP Signed by an unknown key
Quoted 4 lines · Wei Ni
Quoted 2 lines · Mark Brown
OK, I think the device tree board code just needs to set full constraints during machine initialisation. We can't have multiple
Quoted 7 lines
Quoted 3 lines
Hi, Mark, do you mean we can call
regulator_has_full_constraints(), but some platforms doesn't have board file now, they only have dts file, how to call this functions?There is still a board file for DT machines, it's just shared between all machines - it should be doing the call instead of the regulator framework trying to retrofit it.
So do you mean it should call the regulator_has_full_constraints() in the .init_machine for all machines? If so, this will affect all boards, for example, in arch/arm/mach-tegra, if we set full constraints in the shared board file tegra.c, all tegra boards will be set, is it right?
Thanks.
Wei.
Quoted 4 lines
* Unknown Key
*0x7EA229BD
Quoted 4 lines · Wei Ni
So do you mean it should call the
regulator_has_full_constraints()in the .init_machine for all machines? If so, this will affect all boards, for example, inarch/arm/mach-tegra, if we set full constraints in the shared board filetegra.c, all tegra boards will be set, is it right?
Yes, but this is currently the case anyway for every system using DT - all we'd be doing is moving this call earlier in init.
Quoted 11 lines · Mark Brown
* PGP Signed by an unknown key
Quoted 4 lines · Wei Ni
So do you mean it should call the
regulator_has_full_constraints()in the .init_machine for all machines? If so, this will affect all boards, for example, inarch/arm/mach-tegra, if we set full constraints in the shared board filetegra.c, all tegra boards will be set, is it right?Yes, but this is currently the case anyway for every system using DT - all we'd be doing is moving this call earlier in init.
Ok, I will send out patches for Tegra series.
Quoted 4 lines
* Unknown Key
*0x7EA229BD