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?

-- 
nvpublic