* Tero Kristo <t-kristo@xxxxxx> [161115 11:18]: > 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.) OK in that case I'd prefer that we get the status from a reset driver. I think a minimal reset driver could be already done as a regular device driver that works also as a loadable module. It probably still needs some callback functions passed to it in platform_data via pdata-quirks.c though. Regards, Tony -- 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
