Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1062178ybp; Wed, 9 Oct 2019 08:18:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqx9KUmtLX4COU2jPKDhftRxTR75Ht+vuA55eVlqblrcoCvVhAJ7oCsryXRVrlpIcH/jptaK X-Received: by 2002:a17:907:20c5:: with SMTP id qq5mr3338873ejb.96.1570634318312; Wed, 09 Oct 2019 08:18:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570634318; cv=none; d=google.com; s=arc-20160816; b=s1s5KvRcy66qqGBPx+UiT7Ou+qSOl7Rkk4BEZQlOiEAQb4X3dJinnzcxNqse9jNmPb HnZmfHxmVAYaMMsDFYIVST9hSKMIUlOCysG4GW3YhJ5DTKEvLz6pDxyOlNeDNcgGIAwV XI9xfzib1zH69b7HCevtxhye0dzVnwU0Llahf34hXelwE6fQrhtQyL41oyXWTD8/S4Ru fsrkvg26Rp5tBjtFls95oCNDx6kH2OoGJJIOxzHPMN1AvvT4GOdZE5amOoyXEe2WiZWZ PGfPXr7H3tLki23GxSVbOYmmLxZ1fgDej/AnK9EFvSbEA8CPKUqXVmJ6lKCGY4ko9VGv 1tOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=cFVYnSaDwHMRURu9DKV/GpdVXduiDZ/K16NKle6HFe0=; b=MJSZdxjuz8toQLt/6OVCiuHJ1clWHA0uYhLoUjBawDLy78te/lUFic2i59JTrVjQQl ZPCcAlXS1VwujZ+WszLQEshaE3MnYULFXn/16Ehu8I5nFkPnfcS4HMccRp8VnbRbkDQQ SAF6hH8mKM5yyKJRynSddbCbxglZjbePOBvMDSexD3fikIXYfcZJV39YEhfC1R6kUbE6 7iTTbkvfly0pdxAP/M7Xmj3rBN+fbpX4RppMQ67gv4dI/03ij7f963UFXv8MwI8gKtQ3 UTgJoUDGArrbGQ61cWcQQ2trq+xza7lEe+aYMHpyv/nF0s7hXz4p0sw5PcLY/6CqauXE deUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c24si1439841edt.364.2019.10.09.08.18.14; Wed, 09 Oct 2019 08:18:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731145AbfJIPPn (ORCPT + 99 others); Wed, 9 Oct 2019 11:15:43 -0400 Received: from foss.arm.com ([217.140.110.172]:36452 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727920AbfJIPPm (ORCPT ); Wed, 9 Oct 2019 11:15:42 -0400 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 C68C2337; Wed, 9 Oct 2019 08:15:41 -0700 (PDT) Received: from [10.1.197.57] (e110467-lin.cambridge.arm.com [10.1.197.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 870A63F68E; Wed, 9 Oct 2019 08:15:40 -0700 (PDT) Subject: Re: [PATCH] dts: Disable DMA support on the BK4 vf610 device's fsl_lpuart driver To: Lukasz Majewski Cc: linux-kernel@vger.kernel.org, Shawn Guo , Mark Rutland , devicetree@vger.kernel.org, Sascha Hauer , Stefan Agner , Rob Herring , Pengutronix Kernel Team , linux-arm-kernel@lists.infradead.org References: <20191009143032.9261-1-lukma@denx.de> <20191009164442.51f27b9d@jawa> From: Robin Murphy Message-ID: <34d5f652-57e5-168e-0025-38b897e88fff@arm.com> Date: Wed, 9 Oct 2019 16:15:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20191009164442.51f27b9d@jawa> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/10/2019 15:44, Lukasz Majewski wrote: > Hi Robin, > >> On 09/10/2019 15:30, Lukasz Majewski wrote: >>> This change disables the DMA support (RX/TX) on the NXP's fsl_lpuart >>> driver - the PIO mode is used instead. This change is necessary for >>> better robustness of BK4's device use cases with many potentially >>> interrupted short serial transfers. >>> >>> Without it the driver hangs when some distortion happens on UART >>> lines. >>> >>> Signed-off-by: Lukasz Majewski >>> --- >>> arch/arm/boot/dts/vf610-bk4.dts | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/vf610-bk4.dts >>> b/arch/arm/boot/dts/vf610-bk4.dts index 0f3870d3b099..ad20f3442d40 >>> 100644 --- a/arch/arm/boot/dts/vf610-bk4.dts >>> +++ b/arch/arm/boot/dts/vf610-bk4.dts >>> @@ -259,24 +259,28 @@ >>> &uart0 { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&pinctrl_uart0>; >>> + dma-names = "",""; >> >> This looks like a horrible hack - is there any reason not to just >> strip things at compile-time, i.e. "/delete-property/ dmas;"? > > I don't want to strip the dma-names property globally. I just want to > adjust this particular driver mode from DMA to PIO. What do you mean by "globally"? The /delete-property/ operator just removes a previously-defined property from the node in which it appears. > For my use cases - as written in the commit message - the PIO mode is > more suitable (and reliable). Right, and having invalid "dma-names" properties for this board is what happens to trick Linux into not using DMA mode via of_dma_request_slave_channel() failing, yes? What I'm saying is that if the underlying justification is that it's not worth using DMA mode at all on this board, then suppressing the actual "dmas" property it its DTS such that there's no dependency on a particular driver behaviour is a lot more robust. Robin. >>> status = "okay"; >>> }; >>> >>> &uart1 { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&pinctrl_uart1>; >>> + dma-names = "",""; >>> status = "okay"; >>> }; >>> >>> &uart2 { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&pinctrl_uart2>; >>> + dma-names = "",""; >>> status = "okay"; >>> }; >>> >>> &uart3 { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&pinctrl_uart3>; >>> + dma-names = "",""; >>> status = "okay"; >>> }; >>> >>> > > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de >