On Tue, Feb 23, 2021 at 02:26:57AM +0100, Sebastian Reichel wrote: > Hi, > > On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote: > > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > > > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > > > the clock is disabled and all i.MX6 functionality depending on > > > > the 32 KHz clock has undefined behaviour. On systems using hardware > > > > watchdog it seems to likely trigger a lot earlier than configured. > > > > > > > > The proper solution would be to describe this dependency in DT, > > > > but that will result in a deadlock. The kernel will see, that > > > > i.MX6 system clock needs the RTC clock and do probe deferral. > > > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > > > CKIL clock and thus the RTC's clock will not be probed. So from > > > > the kernel's perspective this is a chicken-and-egg problem. > > > > > > > > > > Reading the previous paragraph, I was going to suggest describing the > > > dependency and wondering whether this would cause a circular dependency. > > > I guess this will keep being an issue for clocks on an I2C or SPI bus... > > Yes, it is a circular dependency on this particular system on > module. It only works because the RTC enables the clock by > default. The i.MX6 CKIL is expected to be always enabled. I think you should describe the circular clocking and then provide a way to break the dependency. It's a somewhat common issue. Rob
