Question about fixed regulator DT properties

[Vladimir Zapolskiy]

Hello Mark,

On 18.11.2014 17:00, Vladimir Zapolskiy wrote:
> Hello,
> 
> I need to set a GPIO (active high) output high on boot, which enables a
> power rail supplying some external devices.
> 
> I have a question regarding "regulator-boot-on" and "enable-active-high"
> fixed regulator device tree properties (actually AFAIU it applies to
> gpio regulator as well, by the way, which one is proper to use in my
> situation?)
> 
> Here is what we have from the code:
> 
>   [...]
>   constraints->boot_on = of_property_read_bool(np, "regulator-boot-on");
>   [...]
>   if (init_data->constraints.boot_on)
>           config->enabled_at_boot = true;
>   [...]
>   config->enable_high = of_property_read_bool(np, "enable-active-high");
>   [...]
>   cfg.ena_gpio_invert = !config->enable_high;
>   if (config->enabled_at_boot) {
>           if (config->enable_high)
>                   cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
>           else
>                   cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
>   } else {
>           if (config->enable_high)
>                   cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
>           else
>                  cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
>   }
>   [...]
>   ret = gpio_request_one(config->ena_gpio,
>                          GPIOF_DIR_OUT | config->ena_gpio_flags,
>                          rdev_get_name(rdev));
>   [...]
>   /* Enable GPIO at initial use */
>   if (pin->enable_count == 0)
>           gpiod_set_value_cansleep(pin->gpiod,
>                                   !pin->ena_gpio_invert);
>   [...]
> 
> 
> If we simplify the matter by assuming GPIOF_OUT_INIT_LOW is inverted
> GPIOF_OUT_INIT_HIGH and vice versa, then it is easy to compute by
> running over the variants that GPIO output value is set HIGH (regardless
> of GPIO active low status) if and only if "regulator-boot-on" is
> provided and "enable-active-high" has no effect at all.
> 
> This fact confuses me, because from the general regulator and fixed
> regulator device tree bindings documentation I get:
> 
>   [...]
>   - regulator-boot-on: bootloader/firmware enabled regulator
>   [...]
>   - enable-active-high: Polarity of GPIO is Active high
>   If this property is missing, the default assumed is Active low.
>   [...]
> 
> According to the documentation I'd assume that "regulator-boot-on" does
> not touch gpio output value setting (so, if it is controlled by
> bootloader or firmware, then it might be out of Linux kernel control).
> Also my impression of "enable-active-high" property is that is should
> have some effect on the GPIO output value (but it is not, see above),
> and actually I don't quite understand why this property exists - there
> is a high chance that "enable-active-high" and the real GPIO polarity do
> not coincide, it should be more reliable to get GPIO flags of a
> particular GPIO right in the regulator driver/framework.
> 
> Let's consider two possible configurations:
> 
> | regulator-boot-on | enable-active-high | GPIO polarity | GPIO output |
> +-------------------+--------------------+---------------+-------------+
> |        no         |         yes        |  active high  |    low      |
> |        no         |          no        |  active low   |   high      |
> 
> I'd rather think that both resulting GPIO outputs are incorrect or
> better to say do not correspond to my perception of "regulator-boot-on"
> and "enable-active-high" DTS properties described in the documentation,
> however above "enable-active-high" and actual GPIO polarity are the same
> (when they are not, it is another open topic for discussion).
> 
> Do I miss something or have a mistake? Is there a problem in the
> implemented logic?
> 
> Should documentation be updated to reflect "regulator-boot-on" role that
> a regulator is re-enabled by the kernel?
> 
> Should "enable-active-high" be replaced by getting GPIO flags directly?
> 
> Thank you in advance.
> 

sorry for non-informative original subject, I would appreciate to get
any comments from you on the topic, if there is a problem, it may caused
by your commit 25a53dfbfbf.

If there is an actual problem, please let me know, I'm always willing to
improve the kernel.

--
With best wishes,
Vladimir
--
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/