On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swarren@nvidia.com wrote:
Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
What about the peripheral resets which are also handled by CAR? Peripheral clock nodes also offer assert and deassert methods for the reset signal associated with them. Those methods are used when powergating domains for example. Should we model this in the same binding?
In most cases, I think the resets are handled purely within clock enable and disable, so there's no need to explicitly manage them or represent them in the device tree. Do you agree here?
clk_enable could force a deasserted reset, but clk_disable cannot imply asserting reset. The clocks need to be turned off for power management without resetting the registers.
I recall that you mentioned some power-management code might need to manage reset separately though. Can you explain why a module would be reset separately from disabling the clocks though?
The TRM lists a very specific sequence of clocks, resets, clamps, and power for power domain gating. Other than that, I think the only use for directly calling reset that ended up in the Android Tegra2 tree was for error recovery on HW blocks that could get locked up, probably I2C.
If we do need this, I think we can just add a property to the node of each device that needs such explicit management. Something like:
tegra_car: clock@60006000 { compatible = "nvidia,tegra20-car"; .... };
foo@70007000 { compatible = "nvidia,tegra20-foo"; regs = <...>; nvidia,car-reset-id = <&tegra_car 30>; };
And the driver for "foo" can ignore cell 0, and extract the cell 1 and pass the value to tegra_periph_reset_assert().
I'd expect to put the CAR phandle into the property in case we ever get a more generalized reset subsystem, and need more general code to interpret the property. I did the same for the Tegra APB DMA controller client binding where clients need to know the "DMA select" value.
Does that all seem reasonable?
-- nvpublic