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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0360BC5479D for ; Wed, 11 Jan 2023 10:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FkpnJBmnPDROgPwOCnmYmgtrKjIm0dr4d3Z6YU/0e28=; b=sJdfaj6zEDoycQ EQ4Zx0v7c4cHmnX7M1CrUmx67i51QkJ4qH6cpA93ZPFeMEwwk/XmRHemDzzCEep9TNSVtmUD7OAKN //Ru7PtMdnmTjiPJ/9fklmQv1s9Admw1xPdhHkY3KgQ8/6zVEINHkbLg07gC3zJWVnnnKwDfGouUv QKcYUhAuBWHPiliRErZlkiGabJ7TsZuoDrXi/IZ8Nh/7hJQZRFTyryGF0EnF15cYZ6EiY5eIF5BZQ Mip/vh5rMtNerSvYo8HNSK6zMSrtYACqbo+YtG+Xd3Q5077zKByiRpBmaohNA5qqpi74ZAsUnB8Hy S8pQEa1F+/cdztg3aStA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFYY2-00Aqt1-JR; Wed, 11 Jan 2023 10:41:34 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pFYXx-00AqrM-J7; Wed, 11 Jan 2023 10:41:32 +0000 Received: from ip5b412258.dynamic.kabel-deutschland.de ([91.65.34.88] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pFYXv-0004Rf-N7; Wed, 11 Jan 2023 11:41:27 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: wens@kernel.org, Peter Geis Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: dts: rockchip: rk356x: Add dma-names to UART device nodes Date: Wed, 11 Jan 2023 11:41:27 +0100 Message-ID: <18284546.sWSEgdgrri@diego> In-Reply-To: References: <20221106161443.4104-1-wens@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230111_024129_695414_964E0512 X-CRM114-Status: GOOD ( 28.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Montag, 7. November 2022, 02:50:43 CET schrieb Peter Geis: > On Sun, Nov 6, 2022 at 8:28 PM Chen-Yu Tsai wrote: > > > > On Mon, Nov 7, 2022 at 8:52 AM Peter Geis wrote: > > > > > > On Sun, Nov 6, 2022 at 11:15 AM Chen-Yu Tsai wrote: > > > > > > > > From: Chen-Yu Tsai > > > > > > > > At least one implementation, Linux, requires "dma-names" properties > > > > be used together with "dmas" to describe DMA resources. These are > > > > currently missing, causing DMA to not be used for UARTs. > > > > > > > > Add "dma-names" to the UART device nodes. > > > > > > > > Fixes: a3adc0b9071d ("arm64: dts: rockchip: add core dtsi for RK3568 SoC") > > > > Signed-off-by: Chen-Yu Tsai > > > > > > Enabling dma globally can cause some interesting issues, have you > > > tested this fully? > > > > It seems to work OK with the Bluetooth controller, though I'm not running > > extensive transfers over it. Scanning both traditional and LE works, and > > does exercise the DMA controller. > > > > If your worried about the DMA controller running out of channels and > > impacting other peripherals, the DMA controller for the UARTs is only > > shared with other UARTs, SPI, and PWM (which the kernel doesn't support > > DMAing to). The UART and SPI drivers can fall back to PIO if DMA isn't > > available. > > Nah, enabling it for bluetooth is fine because you have flow control. > My issues have been on channels without flow control. Without DMA it > simply drops messages or the channel hangs until you close and reopen > it. With DMA, when an overflow locks up the channel it is usually > unavailable until the board is rebooted. > > It's the main reason I've stopped daisy chaining boards to each other, > when the board powers off the pinmux pulls go crazy just long enough > to lock up the other end. It sometimes happens with reboots and large > data bursts as well. > > I'd only enable them on bluetooth channels for the time being because of this. I guess I'll agree with Peter here. So enabling uart dmas should likely happen on a board-level for bluetooth connections. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel