Messages in this thread | | | Date | Fri, 20 Apr 2012 17:59:42 +0530 | Subject | Re: [PATCH] regulator: Provide a check for dummy regulator | From | Jassi Brar <> |
| |
On 20 April 2012 17:16, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Fri, Apr 20, 2012 at 01:02:06PM +0530, Jassi Brar wrote: > >> Say, an audio CODEC chip has a simple PLL1 run by main voltage >> domain(Vmain). PLL1 can only support 11025x sample rates. >> Another PLL2 on the chip, powered by optional supply Vaux, could >> provide 8000x sample rates. Obviously low-end platforms could choose >> to not provide Vaux. > >> The platform has some other drivers that need to have dummy regulator >> support enabled. > >> How is the CODEC driver supposed to know if 'vaux' is actually present? >> Because if it isn't present, the driver wouldn't declare support for >> 8000x rates. >> regulator_get() would always succeed, and regulator_is_enabled() would >> always return 1, even if the vaux is not supplied. > > This is just one of those cases that won't ever work well with dummy > regulators > That's what I have been trying to fix. My example might be fictitious but I have a real scenario with omap_hsmmc (I was avoiding getting into that).
The dummy not just provide a place holder data structure for missing definition of an available supply, but it also masks the fact that there might indeed be no supply at all on the given machine.
As I said, atm the only option for a consumer is to know it via PD/DT.
We can avoid requiring this 'oob' info by simply letting the consumer driver know that "The platform didn't provide the supply, but here is a dummy one in case you don't strictly require your supplies be completely defined by all platforms". Which can be achieved by simply adding that regulator_is_dummy() call.
The benefit is magnified by the fact that, for a given circuit, at least theoretically, there is no limit to the number/combination of supplies that could be controlled by inserting a regulator. And that could lead to a very noisy PD/DT.
Thanks, -Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |