From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 433A8372063 for ; Wed, 1 Jul 2026 17:41:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782927709; cv=none; b=G8C+wzhP8oUywPxf7nWFhrL71Rtyci/gf2JDVhLo6EPV4G8LgzmEL9lBIGAB2XMZTpx+eBDaHKtK8+oA9faf8WhqYgPBD/7Fx9HQdOhg8ToAr72mQ2247sdkLZjskAhxuKO8zginRGhHFjmsGYY767cztVZSiSxsx3aKxz8BObc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782927709; c=relaxed/simple; bh=/sFIIMwv1cwP6QuFYC8Bi6QyLRzPPMzGLuRnacUwDUk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=u2D3gWSz2PDYEOWvxs8za1RBHCzo0DPQqCiaVkve7E1xiVLE223R81/miHdcx+fXy3Mtmm5n2yhC0+j1O9sighVChZEPQULfL0xqLMgSZZ+w8G6SlP0qk9gz8PF0Je+/n1PdDOsPschfgKxGxNPS5Ky0OuxiYkpkNN6oKMvuQ44= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MIRmANSp; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MIRmANSp" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-47640541585so592005f8f.1 for ; Wed, 01 Jul 2026 10:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782927707; x=1783532507; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=RgZ+RRPPPNkUcHKx4yOh/np63o+QAr4UfMkPtju0y+0=; b=MIRmANSpMmXXlyoF5YflIczMsBt1rwp26MWE8ORGPcoc6hMrvrpv8f3rGrkcHvEJxM jMHL+k9J+YC45TcB3vlle8NMHNlnPm5E1PsnzFbsJguqmURB8M2bNZE8usNSc1q4c1rD DQv9g1vp5m3rPnd5+KNaOunbvWsiHfsXu2ZTStIANeerPwi7Q0dG46uXHfA0hZOuvFyU byazA+VJu9Ak9AuPrE7xVsfIl0J1p1NIn0L1IY+MYMOM6ul5wtG7VQhVA8uu9MI0D/03 ZDyTkbQt1krLbS+Z+1YvWg5wIlaydqOxp9dqzngEaSXNfVhkfzHZWm5Vvww3uj8QumhG kb6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782927707; x=1783532507; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RgZ+RRPPPNkUcHKx4yOh/np63o+QAr4UfMkPtju0y+0=; b=lqC4d4X7R2vIB5AnPK8gYKu/9AXFX35f6sW3cF5rKFn991X7Lk2S88s56AOcd3zaOk FjO2QMJibh1rJ7Oxd17rk/Lz39rSmgPN0Lrkup0NL6gPA5kpkQKEO8SHAVRmknk3EbGv op/s5ZqPh7J++NMSrAbUyfJ/E0bpo7DO3WYvtbhLFUNSuy6AAJFa1Yuq4FFMnL1YhSHK qvcAIm/CyJTOdqWDWmUjWZ7Tm3nbC4GCaE63aESQc2qPzkAda4vNBP/EPmFLqxn/+0hL j5aagHmpk6guZPQoRyji5veaXJ903UYUJA6TyPNoZr4W180DplUNkk39uG8HmGxoC6BD NIBg== X-Forwarded-Encrypted: i=1; AHgh+RopRwyO3HeOp0WCZj72RLaNMhGx6Oc3OPAReQr2NOfb8VAH3ZGcZavIYgY0pvV2+WzXwbLt1/GGcN2FySQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyuE1WVC85tHm8zneDHww64CgEqJMbmpsso9uGzb6HOHfdihpYR bhAkG2hVLeD7oO3zGRkp4j0nkmVGNhhwhsXZrAva2nWypLrNi18xibAgsImD0GTf X-Gm-Gg: AfdE7cl0Wnjm6TuV4/vOaw/uY3JI0P4HRpGOPguYhcrTqV3Gt9rce7X8D+2r0bisAZZ oIi6CwUROdlfAbKvBfedeXoZhqHWXhfSOElBZIguXsIWlg+9s273v64rULthnOCDTqNrz6sfhjG 0iluH3WjaLtceZ+dslOAtLPqzIK9ahr1uAlzfY83ydQFF38/g6ROJhAc3f48G8QXLUZVSDkgcB3 wg7eoPuXJkmfiZ+7rYpd33uuKviCwbxwUy6KoyPePK/qbBZO6Us89ff3/aJqhlmZtptiXp4S78r B0DTH0sUvCbtXiqCwIB64DQZzKjju0PPNnFMPuqrgFs4c7sW3eR+bcyDZNmBAOR8OYtHkfOWuW8 3ThJZaSeK82A8dapYLkKIPbPGRYtI9EGC0dkWdepMCF/q+OA+F6iWtc4rp2nAo2HJqsLp9j9d07 KTytIvsz98hxn1l8iLZ7VNFmULbDZZViVtVBPuYj/MAEukZg== X-Received: by 2002:a05:6000:2893:b0:46f:f12b:e444 with SMTP id ffacd0b85a97d-47759098164mr4140611f8f.29.1782927706618; Wed, 01 Jul 2026 10:41:46 -0700 (PDT) Received: from pumpkin (host-92-21-50-228.as13285.net. [92.21.50.228]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-477ddf0fb15sm1250276f8f.29.2026.07.01.10.41.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 10:41:46 -0700 (PDT) Date: Wed, 1 Jul 2026 18:41:44 +0100 From: David Laight To: Paul Mbewe Cc: , , , , , , , Subject: Re: [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns Message-ID: <20260701184144.62bac61e@pumpkin> In-Reply-To: <20260701164056.951230-1-paultyson.mbewe@ziehl-abegg.de> References: <418f9ae5-8827-475c-b465-1271a784fbf1.bc56e27e-ecd8-43ae-bb87-75bfd472a28d.88efbd1d-67dc-430a-adbe-b90700d161bb@emailsignatures365.codetwo.com> <20260701164056.951230-1-paultyson.mbewe@ziehl-abegg.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 1 Jul 2026 18:40:56 +0200 Paul Mbewe wrote: > Hi David, Maarten, >=20 > I rechecked this with ftrace, and I think the right explanation is > narrower than my v1 commit message. >=20 > The underrun trace shows the SC16IS7xx refill path running with the > hardware TX FIFO already empty while the tty xmit FIFO still had data > queued, for example: >=20 > =C2=A0 sc16is7xx delayed refill: line=3D0 txlvl=3D64 pending=3D172 >=20 > So the conclusions for me are: >=20 > =C2=A0 - The driver can catch up if the FIFO is only partially drained wh= en > =C2=A0=C2=A0=C2=A0 the THRI path runs. TXLVL will report more than the no= minal trigger > =C2=A0=C2=A0=C2=A0 amount and the driver can write more bytes. >=20 > =C2=A0 - Once TXLVL is 64, the FIFO has already emptied and the TX gap has > =C2=A0=C2=A0=C2=A0 already occurred. Right, but there must be something happening after the previous time the fifo was filled that makes this one happen too late. Either the hardware ISR was very late or it didn't schedule the thread. Thinks..... Maybe you are getting a fifo empty interrupt (rather than the fifo threshol= d) interrupt, with the threshold one getting lost. So what happens if the threshold is reached while the threaded ISR is still running? When that happens the ISR needs to loop, either in software or by re-enabli= ng a level-sensitive interrupt so that another hardware interrupt happens immediately. I'm not at all sure how that works with threaded ISR on the SPI interface. Especially since you really don't want to read any more SPI registers than absolutely necessary (you need to avoid PCIe reads as well!). For a 'normal' ethernet driver rx path it is important to check the next rx ring entry a second time after enabling the hardware interrupt. Otherwise you miss a wakeup. I think you are getting (effectively) the same problem. You might need to use (say) ktime_get_ns() to work out how many bytes were transmitted between the fifo space being read and the end of the fifo writes to see if you need to do a second refill. (Or, rather, to detect that you definitely don't need to do one.) With the threshold set to 32 it is much less likely that it will be hit during the fifo writes, so you are much less likely to lose an interrupt. But scheduling delays could still make it happen.=20 David >=20 > =C2=A0 - The v1 explanation was wrong to describe a 32-free-space trigger= as > =C2=A0=C2=A0=C2=A0 increasing the per-interrupt refill window. It does no= t. With the > =C2=A0=C2=A0=C2=A0 default trigger, the FIFO has about 56 character times= left when THRI > =C2=A0=C2=A0=C2=A0 fires; with a 32-free-space trigger, it has about 32 c= haracter times > =C2=A0=C2=A0=C2=A0 left. >=20 > =C2=A0 - As Maarten pointed out, the benefit is the other side of the > =C2=A0=C2=A0=C2=A0 trade-off: the refill event rate is reduced by 4x, fro= m roughly > =C2=A0=C2=A0=C2=A0 1 refill per 8 transmitted bytes to 1 refill per 32 tr= ansmitted bytes. > =C2=A0=C2=A0=C2=A0 > =C2=A0 - On the tested SPI-backed system, that lower refill rate reduces = the > =C2=A0=C2=A0=C2=A0 IRQ/SPI load enough to avoid the observed underruns. >=20 > The change is limited to SPI-attached parts so the I2C case is > unaffected. >=20 > For v2 I will: >=20 > =C2=A0 - rework the commit message around Maarten's trade-off calculation: > =C2=A0=C2=A0=C2=A0 4x fewer TX refill events, at the cost of reducing the= time-to-empty > =C2=A0=C2=A0=C2=A0 margin from 56 to 32 character times; > =C2=A0 - limit the TX trigger change to SPI-backed SC16IS7xx devices; > =C2=A0 - leave the RX trigger level unchanged. >=20 > If maintainers would prefer this to be board-configurable instead, I can > look at a follow-up DT binding/property, but I would prefer to keep v2 > focused on the TX/SPI case. >=20 > Thanks, > Paul >=20 > _______________________________________=C2=A0 >=20 > ZIEHL-ABEGG=C2=A0 >=20 > Executive Board: Joachim Ley (Chairman), Marco Altherr, Wolfgang Mayer > Supervisory Board: Dennis Ziehl (Chairman)=C2=A0 >=20 > Court of Registry: District Court Stuttgart HRB 746188 > Company Seat: K=C3=BCnzelsau, Germany=C2=A0 >=20 > Der Inhalt dieser E-Mail und/oder jegliche Anh=C3=A4nge k=C3=B6nnen vertr= auliche Mitteilungen enthalten und sind ausschlie=C3=9Flich f=C3=BCr den be= zeichneten Adressaten bestimmt. > Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertret= er sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, V= er=C3=B6ffentlichung, > Vervielf=C3=A4ltigung oder Weitergabe des Inhalts dieser E-Mail einschlie= =C3=9Flich Anh=C3=A4ngen unzul=C3=A4ssig ist. > Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbin= dung zu setzen.=C2=A0 >=20 > The content of this e-mail and/or attachments may contain confidential in= formation and is intended solely for the named recipient. > If you are not the intended recipient of this e-mail or on its distributi= on list, please note that any type of disclosure, publication, > copying or distribution of the content of this e-mail including attachmen= ts is strictly forbidden. > In this case, we would kindly ask you to notify the sender of the e-mail.