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?
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?
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?