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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 1656EC3F2D2 for ; Fri, 28 Feb 2020 21:50:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DEB8C20637 for ; Fri, 28 Feb 2020 21:50:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=walle.cc header.i=@walle.cc header.b="utAc0NN1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726688AbgB1Vu4 (ORCPT ); Fri, 28 Feb 2020 16:50:56 -0500 Received: from ssl.serverraum.org ([176.9.125.105]:50665 "EHLO ssl.serverraum.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726077AbgB1Vuz (ORCPT ); Fri, 28 Feb 2020 16:50:55 -0500 Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id D735D23E29; Fri, 28 Feb 2020 22:50:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1582926652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oYF0XupHCNrJePiMiwuR1qNRjdHRjVb4x1LouSfF1I4=; b=utAc0NN1aDLhRtpGKBeNvJSNKQa5PluFyiMyy9TK6sRiqMm7D5mU0tUS4DM/gz9cLsFpTT HBKXqrPcpfqKmgF8uRHUwNAThWGigvVWE1ytVCFRRzoyUCcACkjNPcuERohmfkfNObruwS Y+XzZUVQUA6Q7xCDddtK8wJy4sWoYiQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Feb 2020 22:50:51 +0100 From: Michael Walle To: Rob Herring Cc: Li Yang , "open list:SERIAL DRIVERS" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-kernel@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Greg Kroah-Hartman , Mark Rutland , Shawn Guo , Jiri Slaby , Peng Fan , Vabhav Sharma Subject: Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE_DEFER for DMA In-Reply-To: <639a1df72fbeda77436b282a99f17995@walle.cc> References: <20200221174754.5295-1-michael@walle.cc> <20200221174754.5295-4-michael@walle.cc> <639a1df72fbeda77436b282a99f17995@walle.cc> Message-ID: <24b9a657a65f75a4f4f10baa17561451@walle.cc> X-Sender: michael@walle.cc User-Agent: Roundcube Webmail/1.3.10 X-Spamd-Bar: + X-Rspamd-Server: web X-Rspamd-Queue-Id: D735D23E29 X-Spamd-Result: default: False [1.40 / 15.00]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[dt]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[]; RCPT_COUNT_TWELVE(0.00)[12]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2020-02-28 12:46, schrieb Michael Walle: > Hi Rob, Hi Leo, > > Am 2020-02-28 00:03, schrieb Rob Herring: >> On Thu, Feb 27, 2020 at 4:49 PM Li Yang wrote: >>> >>> On Thu, Feb 27, 2020 at 4:35 PM Rob Herring >>> wrote: >>> > >>> > On Fri, Feb 21, 2020 at 11:48 AM Michael Walle wrote: >>> > > >>> > > The DMA channel might not be available at the first probe time. This is >>> > > esp. the case if the DMA controller has an IOMMU mapping. >>> > > >>> > > Use the new dma_request_chan() API and handle EPROBE_DEFER errors. Also >>> > > reorder the code a bit, so that we don't prepare the whole UART just to >>> > > determine that the DMA channel is not ready yet and we have to undo all >>> > > the stuff. Try to map the DMA channels earlier. >>> > >>> > Changing this means you never probe successfully if you boot a kernel >>> > with the DMA driver disabled (or it's IOMMU disabled). Some other >>> > drivers request DMA in open() and can work either way. > > Oh, I see. > >>> We got this exact issue previously with another driver. When the > > What driver is it? I've been working on the i2c-mxs.c driver which has whoops, i2c-imx.c, not i2c-mxs.c -michael > the same problem. Ie. its not working with DMA when the IOMMU is > enabled. > Now that I've learned that dma_request_chan() will return EPROBE_DEFER > if the actual DMA driver is not available, I don't think there is any > trick like this there. There is no function which would be called late > except you'd do something like on the first master_xfer() try to > request > the DMA channels. But I don't think that would be the way to go. > > -michael > >>> required DMA driver is disabled, the DMA framework cannot figure out >>> this situation and keeps returning EPROBE_DEFER. I'm wondering if we >>> should update the DMA framework to use your deferred probe timeout >>> mechanism. Is it still only used for debug purpose? >> >> It's undergoing some rework ATM to not just be for debug. However, >> it's not really going to help you if you care about the console >> because waiting for the timeout will be too late to register the >> console.