Hi Javier,
在 2016年01月12日 00:02, Javier Martinez Canillas 写道:
Hello Heiko,
On 01/08/2016 11:42 PM, Heiko Stuebner wrote:
Am Freitag, 8. Januar 2016, 09:22:31 schrieb Javier Martinez Canillas:
For example:
we need enable wifi module power to via the WL_REG_ON
pin, we need enable it as the regulator if this pin is connected to
the gpio of cpu.
This part confuses me, so does your chip have an actual regulator that
needs to be enabled or is just a fake regulator whose gpio property is
used not to enable the regulator but to toggle the WL_REG_ON pin of
the WiFi chip?
another option would be to use the reset-gpio-handles. rk3288-veyron and I
think some Exynos as well use it that way.
Yes I know, my point was that the reset-gpios property should be used
instead of a fake regulator if what's needed is to toggle a chip pin.
Maybe, someone will say that can pull up/down from dts.
Unfortunately some SoCs can't support pinctrl pull up/down in
internal.
Can you please elaborate on this? AFAIU this limitation is the reason
why you went with the regulator approach so I think it deserve a more
deep explanation.
On the rk3036 each pin has an individual unchangable pull direction. So it's
either no bias or pulling in the predefined direction (the pin_default bias
option).
I think each change has to be justified on its own so I would say that
having a regulator enabled as a part of a SDIO chip's power sequencing
is something needed for many platforms, and that this provider should
be extended to support that (something like commit msg in patch 05/12).
And then in the kylin DTS change (patch 08/12), I would explain why a
chained regulators approach is used/needed instead of the reset-gpios
due any platform limitations.
Okay,
I 'm agreed with your points in here.
The reset-gpios/pwrsq can meet the demand of some wlan chips trigger
condition.
No matter whatever is the BT_EN or WL_EN triggers pin.
Heiko
Best regards,
--
Thanks,
Caesar
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
