On 08/13/13 12:03, Thierry Reding wrote:
On Tue, Aug 13, 2013 at 10:30:30AM +0200, Thomas Petazzoni wrote:
Dear Thierry Reding,
On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote:
+- reset-gpios: optional gpio to PERST#
+- reset-delay-ms: delay in ms to wait after reset de-assertion
I remember some recent discussion about this, and we now have this reset
framework, so perhaps it makes more sense to use the reset binding for
this? Cc'ing Stephen (as part of the device tree bindings maintainers
team) who was involved in that recent reset bindings discussion.
I also thought about this, but the reset framework seems to be designed
for "reset controller" IPs, i.e special IPs that are controlling reset
signals. Looking at Documentation/devicetree/bindings/reset/reset.txt,
I'm not sure to see how this would apply to GPIO-controlled reset
signals.
See:
http://www.mail-archive.com/devicetree-discuss@xxxxxxxxxxxxxxxx/msg36900.html
which seems to have carried over to this at some point:
http://www.spinics.net/lists/devicetree/msg00521.html
Some of the messages in between I can't find in any archive, sorry.
Thierry, Sascha,
thanks for the input. Flipping through the above discussion, I guess
using "reset-gpios" and "reset-delay-us" should be fine?
I can also remove the delay property for now, as I cannot find a final
conclusion about the configurable delay.
In the driver, I will stick to bare gpiolib and wait for gpio-reset
driver to become available. Currently, we don't have sophisticated
reset handling in pci-mvebu anyway.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
