Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220608161150.58919-1-linux@fw-web.de> <20220608161150.58919-2-linux@fw-web.de>
 <5611d1c5-44db-4144-3c46-256323d39fe3@arm.com>
In-Reply-To: <5611d1c5-44db-4144-3c46-256323d39fe3@arm.com>
From:   Peter Geis <pgwipeout@gmail.com>
Date:   Fri, 8 Jul 2022 14:41:35 -0400
Message-ID: <CAMdYzYo=Wft93OEKapVFx-oxe8ocU7OuhU+MOdqUw8-QjqzDGg@mail.gmail.com>
Subject: Re: [PATCH 1/2] rtc: hym8563: try multiple times to init device
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Frank Wunderlich <linux@fw-web.de>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        Frank Wunderlich <frank-w@public-files.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Heiko Stuebner <heiko@sntech.de>,
        Alessandro Zummo <a.zummo@towertech.it>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        devicetree <devicetree@vger.kernel.org>,
        arm-mail-list <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-rtc@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jul 8, 2022 at 12:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2022-06-08 17:11, Frank Wunderlich wrote:
> > From: Peter Geis <pgwipeout@gmail.com>
> >
> > RTC sometimes does not respond the first time in init.
> > Try multiple times to get a response.
>
> 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?

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.

>
> Robin.
>
> > Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> > Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> > ---
> >   drivers/rtc/rtc-hym8563.c | 11 +++++++++--
> >   1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c
> > index 90e602e99d03..9adcedaa4613 100644
> > --- a/drivers/rtc/rtc-hym8563.c
> > +++ b/drivers/rtc/rtc-hym8563.c
> > @@ -13,6 +13,7 @@
> >   #include <linux/clk-provider.h>
> >   #include <linux/i2c.h>
> >   #include <linux/bcd.h>
> > +#include <linux/delay.h>
> >   #include <linux/rtc.h>
> >
> >   #define HYM8563_CTL1                0x00
> > @@ -438,10 +439,16 @@ static irqreturn_t hym8563_irq(int irq, void *dev_id)
> >
> >   static int hym8563_init_device(struct i2c_client *client)
> >   {
> > -     int ret;
> > +     int ret, i;
> >
> >       /* Clear stop flag if present */
> > -     ret = i2c_smbus_write_byte_data(client, HYM8563_CTL1, 0);
> > +     for (i = 0; i < 3; i++) {
> > +             ret = i2c_smbus_write_byte_data(client, HYM8563_CTL1, 0);
> > +             if (ret == 0)
> > +                     break;
> > +             msleep(20);
> > +     }
> > +
> >       if (ret < 0)
> >               return ret;
> >