On 15/11/16 19:38, Tony Lindgren wrote:
* Tony Lindgren <tony@xxxxxxxxxxx> [161115 09:35]:
* Cor Peters <cpeters@xxxxxxxxxxxxxxxxx> [161115 01:00]:
This patch adds the PRM_DEV as a syscon compatible device to
am33xx.dtsi. This is needed for the watchdog bootstatus patch.
We somehow need to see the bootreason for sure.. But we need to
check with Tero on the reset driver work too.
Tero, does setting up of PRM_DEVICE as syscon cause issues for
your reset driver work?
Good question, currently the reset driver is on hold waiting for hwmod /
interconnect work to nudge forward. We could probably try to even re-use
the syscon reset driver for OMAPs (drivers/reset/reset-ti-syscon.c);
reset handling is not performance critical as such, and we only have few
sources for these so...
The nightmare scenario is that we have drivers calling random
syscon areas across various interconnect targets and then we have
zero chance of getting genpd to ever to work properly.
Exporting this specific area exposes a few interesting features, like
performing a system wide reset or tweaking SRAM PM configs (preventing
SRAM LDOs from idling for example.)
Do the reset drivers offer some way of exporting the reset status?
reset_control_status() can be used to read the reset status, this is
however mostly meant for checking if reset line is currently asserted or
not. We could in theory overload this for checking if reset has been
asserted previously or not (checking current status for watchdog reset
doesn't make much sense for example.)
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
