Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp691581rwe; Thu, 25 Aug 2022 07:38:44 -0700 (PDT) X-Google-Smtp-Source: AA6agR6A8sLWXMnJc3wIbuvggMuDZmpjopzF5XQx+2XyDyEX8RcPfZM4wExIEamdse78AMxxoM6T X-Received: by 2002:a05:6a00:1410:b0:528:5a5a:d846 with SMTP id l16-20020a056a00141000b005285a5ad846mr4652885pfu.9.1661438324205; Thu, 25 Aug 2022 07:38:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661438324; cv=none; d=google.com; s=arc-20160816; b=FTyCaqrkyTJf0e64jRc4haMksOpLRcuFLPmFNOKBypcVqyZvrhLDysWrFZWhBkIFwZ YVx2bjKyTa3xNbUTluI5f4RRj12PSbI/fa4BDOkJFCFPfb+yt+md+m0wGlDr94Fp4Xjc rPrRrQj8UZVXqSrOJkXuuqqQK/3Nus71GHoosgQhTfuKukdr4RwTBNwV7amEedv+3+Rm B+ipX/GksVNwEZmRe3UlWQ2xit9P0yoHPdC87iK4FlLpu/4abez9yjeLoH+E5ibQtvcJ peuqNJCq2mQDCLlTQlL7oBhplDNf68QPZZCjyXWRK9UL0+MeT61GWfvHa/sb7WIPZ1QW pTcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=d8MKuvUoNtvFE6VhtzEB0wBgbo6tmNZbiMFoQdO1fFg=; b=E1t0jB49ZpyIR//5RaiLWEl1WAwSRhy3gWqWpqcL4HedP/9s3EYGu9eUPhSZ/nOAzs wVmvuOvwK6grBUZp9dyu3F/NWh8PVwmX14oBz+CUZ760cIQfjVp5+4bb5LNS+xOXJYe7 5PdsAY6yJrxDuoRZepqOQY+iTNDthjMKDqNoLDm9nTJ2ZbZJfO8mIez01AiWiiin3w9S iQ03o3X5iFL96pm9tI7lk6ENBV9PM6SRvdC/nO9WBbQUxSr2NJvgZ7lmvHuIqy0Rjs3U RKJtk2UZjvHLgrrhHn1BJ8IAIPLla+vR/1JziwuBpn2U2Ct1bWmk+fjTbce1IE/plszf /hqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q9-20020a170902dac900b00172eb2fac96si11395555plx.148.2022.08.25.07.38.32; Thu, 25 Aug 2022 07:38:44 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241215AbiHYOUS (ORCPT + 99 others); Thu, 25 Aug 2022 10:20:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239604AbiHYOTK (ORCPT ); Thu, 25 Aug 2022 10:19:10 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 49547B2DAC; Thu, 25 Aug 2022 07:19:09 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 954A4D6E; Thu, 25 Aug 2022 07:19:13 -0700 (PDT) Received: from [10.57.16.12] (unknown [10.57.16.12]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CEFB73F67D; Thu, 25 Aug 2022 07:19:07 -0700 (PDT) Message-ID: <5fd3f684-1d20-c646-04a4-09f32d765f8d@arm.com> Date: Thu, 25 Aug 2022 15:19:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [RESEND] rtc: hym8563: try multiple times to init device Content-Language: en-GB To: Frank Wunderlich Cc: Peter Geis , Alessandro Zummo , Alexandre Belloni , linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Wunderlich References: <20220821122613.245026-1-linux@fw-web.de> From: Robin Murphy In-Reply-To: <20220821122613.245026-1-linux@fw-web.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-08-21 13:26, Frank Wunderlich wrote: > From: Peter Geis > > RTC sometimes does not respond the first time in init. > Try multiple times to get a response. > > Signed-off-by: Peter Geis > Signed-off-by: Frank Wunderlich > --- > discussion from v1 > https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@fw-web.de/ > > On Fri, Jul 8, 2022 at 12:18 PM Robin Murphy 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 : > 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. 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, Robin. > --- > 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 cc710d682121..d9d0b6615a07 100644 > --- a/drivers/rtc/rtc-hym8563.c > +++ b/drivers/rtc/rtc-hym8563.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > > #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; >