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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3834C00140 for ; Mon, 8 Aug 2022 08:40:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230127AbiHHIkk (ORCPT ); Mon, 8 Aug 2022 04:40:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234435AbiHHIkj (ORCPT ); Mon, 8 Aug 2022 04:40:39 -0400 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1B87267C; Mon, 8 Aug 2022 01:40:37 -0700 (PDT) Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 2788eRfp093056; Mon, 8 Aug 2022 03:40:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1659948027; bh=ZDN5pWvpFd1ZKont31DiANjrdFZeZQ5xckMN+0lwhKg=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=uE5+3lQKm5llo60P04BRPey0wgXzi27yXKV8hyDG3tsipxu96YmVYdBnKehf2+oTc OjKQ2rHREvvKkcW/gMJTCC4yk74dE+5xe5dGeoCZnerB1EOWJYiFuJDOmVU8IWty7b 9RMtSC9bC/TXWQFM4ln0SCsvUhIXJLqP/9rG1k1U= Received: from DLEE104.ent.ti.com (dlee104.ent.ti.com [157.170.170.34]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 2788eRoq115152 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 8 Aug 2022 03:40:27 -0500 Received: from DLEE100.ent.ti.com (157.170.170.30) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Mon, 8 Aug 2022 03:40:26 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Mon, 8 Aug 2022 03:40:26 -0500 Received: from [10.24.69.12] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 2788eN2k116855; Mon, 8 Aug 2022 03:40:24 -0500 Message-ID: <9a60942c-50ab-a8bf-b398-fd31fc607c1d@ti.com> Date: Mon, 8 Aug 2022 14:10:23 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v3] dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow Content-Language: en-US To: =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , , , CC: , , , , References: <20220802054835.19482-1-vaishnav.a@ti.com> <0fa5fdeb-b633-c543-3e98-1f5e1f064c34@gmail.com> From: Vaishnav Achath In-Reply-To: <0fa5fdeb-b633-c543-3e98-1f5e1f064c34@gmail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 03/08/22 13:38, Péter Ujfalusi wrote: > > > On 02/08/2022 08:48, Vaishnav Achath wrote: >> UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics. >> These registers are 32-bit hardware counters and the driver uses these >> counters to monitor the operational progress status for a channel, when >> transferring more than 4GB of data it was observed that these counters >> overflow and completion calculation of a operation gets affected and the >> transfer hangs indefinitely. >> >> This commit adds changes to decrease the byte count for every complete >> transaction so that these registers never overflow and the proper byte >> count statistics is maintained for ongoing transaction by the RT counters. >> >> Earlier uc->bcnt used to maintain a count of the completed bytes at driver >> side, since the RT counters maintain the statistics of current transaction >> now, the maintenance of uc->bcnt is not necessary. > > Thanks for the updates: > > Acked-by: Peter Ujfalusi > > btw: did you encountered issues with cyclic (audio, ADC) regarding to > wrapping of the counters? S16_LE, stereo, 48KHz should wrap around > 22.369 hours. > It is a bit trickier as we might be running without interrupts, so we > can not rely on the same trick. > We did not see this issue yet with Audio, but will try this longer test case to confirm, this was originally observed during long duration MCSPI transfer tests. >> >> Signed-off-by: Vaishnav Achath >> --- >> V2->V3 : >> * Remove unnecessary checks for uc->tchan and uc->rchan in >> udma_decrement_byte_counters() >> V1->V2 : >> * Update bcnt reset based on uc->desc->dir >> * change order of udma_decrement_byte_counters() to before udma_start() >> * update subsystem tag >> >> drivers/dma/ti/k3-udma.c | 25 +++++++++++++++++-------- >> 1 file changed, 17 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c >> index 2f0d2c68c93c..fcfcde947b30 100644 >> --- a/drivers/dma/ti/k3-udma.c >> +++ b/drivers/dma/ti/k3-udma.c >> @@ -300,8 +300,6 @@ struct udma_chan { >> >> struct udma_tx_drain tx_drain; >> >> - u32 bcnt; /* number of bytes completed since the start of the channel */ >> - >> /* Channel configuration parameters */ >> struct udma_chan_config config; >> >> @@ -757,6 +755,20 @@ static void udma_reset_rings(struct udma_chan *uc) >> } >> } >> >> +static void udma_decrement_byte_counters(struct udma_chan *uc, u32 val) >> +{ >> + if (uc->desc->dir == DMA_DEV_TO_MEM) { >> + udma_rchanrt_write(uc, UDMA_CHAN_RT_BCNT_REG, val); >> + udma_rchanrt_write(uc, UDMA_CHAN_RT_SBCNT_REG, val); >> + udma_rchanrt_write(uc, UDMA_CHAN_RT_PEER_BCNT_REG, val); >> + } else { >> + udma_tchanrt_write(uc, UDMA_CHAN_RT_BCNT_REG, val); >> + udma_tchanrt_write(uc, UDMA_CHAN_RT_SBCNT_REG, val); >> + if (!uc->bchan) >> + udma_tchanrt_write(uc, UDMA_CHAN_RT_PEER_BCNT_REG, val); >> + } >> +} >> + >> static void udma_reset_counters(struct udma_chan *uc) >> { >> u32 val; >> @@ -790,8 +802,6 @@ static void udma_reset_counters(struct udma_chan *uc) >> val = udma_rchanrt_read(uc, UDMA_CHAN_RT_PEER_BCNT_REG); >> udma_rchanrt_write(uc, UDMA_CHAN_RT_PEER_BCNT_REG, val); >> } >> - >> - uc->bcnt = 0; >> } >> >> static int udma_reset_chan(struct udma_chan *uc, bool hard) >> @@ -1115,7 +1125,7 @@ static void udma_check_tx_completion(struct work_struct *work) >> if (uc->desc) { >> struct udma_desc *d = uc->desc; >> >> - uc->bcnt += d->residue; >> + udma_decrement_byte_counters(uc, d->residue); >> udma_start(uc); >> vchan_cookie_complete(&d->vd); >> break; >> @@ -1168,7 +1178,7 @@ static irqreturn_t udma_ring_irq_handler(int irq, void *data) >> vchan_cyclic_callback(&d->vd); >> } else { >> if (udma_is_desc_really_done(uc, d)) { >> - uc->bcnt += d->residue; >> + udma_decrement_byte_counters(uc, d->residue); >> udma_start(uc); >> vchan_cookie_complete(&d->vd); >> } else { >> @@ -1204,7 +1214,7 @@ static irqreturn_t udma_udma_irq_handler(int irq, void *data) >> vchan_cyclic_callback(&d->vd); >> } else { >> /* TODO: figure out the real amount of data */ >> - uc->bcnt += d->residue; >> + udma_decrement_byte_counters(uc, d->residue); >> udma_start(uc); >> vchan_cookie_complete(&d->vd); >> } >> @@ -3809,7 +3819,6 @@ static enum dma_status udma_tx_status(struct dma_chan *chan, >> bcnt = udma_tchanrt_read(uc, UDMA_CHAN_RT_BCNT_REG); >> } >> >> - bcnt -= uc->bcnt; >> if (bcnt && !(bcnt % uc->desc->residue)) >> residue = 0; >> else > -- Thanks and Regards, Vaishnav