On 15:53 Sat 10 Apr , Philippe Mathieu-Daudé wrote: > Hi Luc, > > On 4/10/21 3:19 PM, Luc Michel wrote: > > On 08:23 Fri 09 Apr , Philippe Mathieu-Daudé wrote: > >> I've been debugging some odd issue with the clocks: > >> a clock created in the machine (IOW, not a qdev clock) isn't > >> always resetted, thus propagating its value. > >> "not always" is the odd part. In the MPS2 board, the machine > >> clock is propagated. Apparently because the peripherals are > >> created directly in the machine_init() handler. When moving > >> them out in a SoC QOM container, the clock isn't... I'm still > >> having hard time to understand what is going on. > > > > I think there is a misunderstanding on how the clock API works. If I > > understand correctly your issue, you expect the callback of an input > > clock connected to your constant "main oscillator" clock to be called on > > machine reset. > > > > If I'm not mistaken this is not the way the API has been designed. The > > callback is called only when the clock period changes. A constant clock > > does not change on reset, so the callback of child clocks should not be > > called. > > They why the children of a clock tree fed with constant clock stay with > a clock of 0? Who is responsible of setting their clock to the constant > value?
I think we expect the child to be set when we call clock_set_source. In this function the child period is set to the parent one. Maybe you have a case where clock_set_source is called before clock_set on the parent? -- Luc
