Hi Peter, Sorry to bother you with this, but you said some time ago you would write something about reset.
On 10/2/18 4:24 PM, Damien Hedde wrote: > There is also the problem of initialization which is very much like the > migration. Currently, in the zynq example, clocks outputs are initialized in > the clock controller device_reset. According to Peter, outputs should not be > set in device_reset, so we need a better way. To illustrate the problem, lets take an example with the zynq case in the patchset. We have a 2-stage clock tree: +--------+ +----------------+ +------+ | Machine|>>base_clk>>|Clock controller|>>uart_clock>>| UART | +--------+ +----------------+ +------+ At the end of the tree, the uart uses the clock to setup the backend baudrate. The problem is that we need the whole clock path initialized before having the right final frequency. I've had some thought about it and I see several solutions 1. Set clock outputs in device_reset. But It can trigger side effects in yet-non-reseted devices. 2. Have some kind of global 2nd stage reset to do all the output propagation. 3. Try to propagate init values at platform building when doing the clock connection. 4. (1) and (2) mixed. Have a per device 2nd stage reset "clock_reset" (or any better name) method called when device_reset has been called and all clock inputs have been initialized (by other device "clock_reset"). At the end of reset phase everything should have been propagated. (1) being not-an-option and also (2) I think. (3) seems complicated at best due to the unknown clock connection order. And I'm not sure clock connection is the right moment to do this. In the general case, a clock init value can depend on on some user-set/config properties which will be applied later on I suppose (But I don't have a clue at which point this operation -- the "realize" thing -- cab be done in the platform startup sequence) Do you think (4) is sensible ? It means any device requiring clock input value will need to implement this new method. Basically this "clock_reset" is just a part of the actual device_reset being delayed. Obviously if there is a clock loop, the method will never be called. -- Damien
