Hello, On 25/08/2022 15:19:02+0100, Robin Murphy wrote: > On 2022-08-21 13:26, Frank Wunderlich wrote: > > From: Peter Geis <pgwipeout@xxxxxxxxx> > > > > RTC sometimes does not respond the first time in init. > > Try multiple times to get a response. > > > > Signed-off-by: Peter Geis <pgwipeout@xxxxxxxxx> > > Signed-off-by: Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx> > > --- > > discussion from v1 > > https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@xxxxxxxxx/ > > > > On Fri, Jul 8, 2022 at 12:18 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > > FWIW, given that HYM8563 is fairly common on RK3288 boards - I can't say > > > I've ever noticed an issue with mine, for instance - it seems dubious > > > that this would be a general issue of the chip itself. Are you sure it's > > > not a SoC or board-level issue with the I2C bus being in a funny initial > > > state, timings being marginal, or suchlike? > > > > Peter Geis <pgwipeout@xxxxxxxxx>: > > I don't think this is an SoC issue since this is the first instance > > I've encountered it. Mind you we don't have the reset lines hooked up > > at all for the Rockchip i2c driver, so it's possible that's the case, > > but I'd imagine it would be observed more broadly if that was the > > case. I've tried pushing the timings out pretty far as well as bumping > > up the drive strength to no change. It seems to occur only with the > > hym rtc used on this board. I suspect it's a new variant of the hym > > that has slightly different behavior. > > Sure, if it's documented somewhere that Hayou (or if the BPI-R2 Pro > schematic is to be believed, AnalogTek) decided to innovate a new "sometimes > doesn't work" feature for a chip that's been in production for a decade or > more, and that 2 retries at 20ms intervals is what's recommended, then I'm > open to believing that this isn't a complete hack. Or at least if someone > can say they've scoped the pins and confirmed that nothing looks suspect at > the protocol level when this happens that could explain it. > Just to be clear, this is also my opinion and I'm not going to apply that, especially since the IP of the RTC is not just a decade old, it is actually from 1999. It doesn't suddenly stop working. > Otherwise, I'll remain unconvinced that it isn't a coincidence that this has > shown up while bringing up a new board with a new SoC, and hacking a mature > common driver to bodge around an issue that isn't fully understood, and > could very conceivably lie elsewhere, is not the right answer. Especially > when it involves a board vendor... let's say, whose reputation proceeds > them. > > Since I'm not above wasting 20 minutes of my time to prove a point, for > starters the schematic seems to imply that it's using a variant of RK809 > where LDO4, used as the I/O supply for i2c3, is off by default, so on the > face of it it could be something as stupidly simple as the RTC probe racing > with the PMIC or I/O domain probe. Sure, the DT claims it's already on at > boot, but *is* it? Maybe that was true with some downstream bootloader, but > do we know that's what you're using to boot mainline? Maybe this something > so obvious that you've already confirmed and taken it for granted, but the > patch as presented doesn't give me the confidence to rule *anything* out. > Thanks for your input! -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
