* Tony Lindgren <tony@xxxxxxxxxxx> [230526 05:09]: > * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [230525 08:34]: > > > Am 25.05.2023 um 06:53 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: > > > You could also check some driver registers for > > > context lost status in the driver as the context lost registers are outside > > > the driver IO range. And after that, using reset framework for context lost > > > status could be done, maybe by adding support to drivers/soc/ti/omap_prm.c. > > > > Ok. I'll look into that. > > So reset_control_status() could maybe return -EIO error if context was lost. > Or maybe something like reset_control_context_lost() could be implemented. > Needs to be discussed on the related mailing lists of course. Then omap_prm.c > just needs the context lost registers mapped, and consumer drivers can check > context lost status from the reset framework. Oh looking at the dts files, we're not passing the register offset to the prm reset controller instance. So the binding #reset-cells = <2> would be needed where the first one is reset controller offset and second one is the bit in the context register. Seems doable though if we want to make reset framework support hardware triggered reset status. Regards, Tony
