From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1D3EC0044D for ; Mon, 16 Mar 2020 12:45:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A389A205ED for ; Mon, 16 Mar 2020 12:45:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="jODpM2Vl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731029AbgCPMpP (ORCPT ); Mon, 16 Mar 2020 08:45:15 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:35916 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730970AbgCPMpP (ORCPT ); Mon, 16 Mar 2020 08:45:15 -0400 Received: from pendragon.ideasonboard.com (81-175-216-236.bb.dnainternet.fi [81.175.216.236]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id F2078A3B; Mon, 16 Mar 2020 13:45:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1584362713; bh=Oqj74XhRMFDpmMsINduuBAeTxeEZ78NWD6ITCjIM+H4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jODpM2VlCT9q+Rzhe7maIfkG4FiXs6Hr41WS7d7rPKB0vbdCeud4xkt7Ffi20Rapq emSmbuXHjMeaM7MUVYhWc6zM/dJJwlehdM+kCcHRKuicyBaCZIRGG4/CDiVggIdEK2 hZTZPD7/rs0HLjIF1VjLQJQjNt3uuWMriAY7QVKg= Date: Mon, 16 Mar 2020 14:45:07 +0200 From: Laurent Pinchart To: Tomi Valkeinen Cc: linux-media@vger.kernel.org, Benoit Parrot , Mauro Carvalho Chehab Subject: Re: [PATCH 15/16] media: ti-vpe: cal: improve wait for stop-state Message-ID: <20200316124507.GH4732@pendragon.ideasonboard.com> References: <20200313114121.32182-1-tomi.valkeinen@ti.com> <20200313114121.32182-15-tomi.valkeinen@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200313114121.32182-15-tomi.valkeinen@ti.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Tomi, Thank you for the patch. On Fri, Mar 13, 2020 at 01:41:20PM +0200, Tomi Valkeinen wrote: > Sometimes waiting for stop-state timeouts. Testing shows that sometimes > we need to wait more than what the current code does. It is not clear > how long this wait can be, but it is based on how quickly the sensor > provides a valid clock, and how quickly CAL syncs to it. > > Change the code to make it more obvious how long we'll wait, and set a > wider range for usleep_range. Increase the timeout to 750ms. > > Signed-off-by: Tomi Valkeinen > --- > drivers/media/platform/ti-vpe/cal.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c > index 929f9b3ca4f9..df5a4281838b 100644 > --- a/drivers/media/platform/ti-vpe/cal.c > +++ b/drivers/media/platform/ti-vpe/cal.c > @@ -849,19 +849,19 @@ static void csi2_wait_complexio_reset(struct cal_ctx *ctx) > > static void csi2_wait_stop_state(struct cal_ctx *ctx) > { > - int i; > + unsigned long timeout; > > - for (i = 0; i < 10; i++) { > + timeout = jiffies + msecs_to_jiffies(750); > + while (time_before(jiffies, timeout)) { > if (reg_read_field(ctx->dev, > CAL_CSI2_TIMING(ctx->csi2_port), > CAL_CSI2_TIMING_FORCE_RX_MODE_IO1_MASK) == 0) > break; > - usleep_range(1000, 1100); > + usleep_range(500, 5000); > } Same here, readx_poll_timeout() ? > - ctx_dbg(3, ctx, "CAL_CSI2_TIMING(%d) = 0x%08x Stop State Reached %s\n", > + ctx_dbg(3, ctx, "CAL_CSI2_TIMING(%d) = 0x%08x Stop State Reached\n", > ctx->csi2_port, > - reg_read(ctx->dev, CAL_CSI2_TIMING(ctx->csi2_port)), > - (i >= 10) ? "(timeout)" : ""); > + reg_read(ctx->dev, CAL_CSI2_TIMING(ctx->csi2_port))); That's not correct anymore, if the condition is false then the stop state hasn't been reached. Is this debug statement really useful ? > > if (reg_read_field(ctx->dev, CAL_CSI2_TIMING(ctx->csi2_port), > CAL_CSI2_TIMING_FORCE_RX_MODE_IO1_MASK) != 0) -- Regards, Laurent Pinchart