Hi Peter,
DTS is supposed to look as follows:
/ { ak4458_reset: gpio-reset { compatible = "gpio-reset"; reset-gpios = <&pca6416 4 GPIO_ACTIVE_LOW>; #reset-cells = <0>; initially-in-reset;
I can not find anything resembling to this in next-20201119. Where is the implementation and documentation for this gpio-reset?
The board schematics is not publicly available; some info may be seen in DTS files below: https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dt... https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dt... https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dt...
In examples above the GPIO is handled by machine driver - wrong approach given that it requires machine driver being probed before codec driver.
- ak4458->reset_gpiod = devm_gpiod_get_optional(ak4458->dev,
"reset",
GPIOD_OUT_LOW);- if (IS_ERR(ak4458->reset_gpiod))
return PTR_ERR(ak4458->reset_gpiod);
- ak4458->reset = devm_reset_control_get_optional_shared(ak4458-
dev, NULL);
- if (IS_ERR(ak4458->reset))
return PTR_ERR(ak4458->reset);The binding documentation must be updated and you must support the gpio way as well.
Sure, make sense.
When I had this discussion around using the reset framework for shared enable and/or reset pins it was suggested that _if_ such a driver makes sense then it should internally handle (by using magic strings) the fallback and work with pre-reset binding.
Thanks, would appreciate if you point me to the discussion you had.
Viorel