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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 1FBC7C4360D for ; Wed, 25 Sep 2019 21:33:41 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id E82A921D80 for ; Wed, 25 Sep 2019 21:33:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Q/kLJhrY"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="QlI2Sj1D" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E82A921D80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ut/57LJ17sQREZZSN6Fy/b07utHdlNPeGhN0xfiRFjQ=; b=Q/kLJhrYh2JnEw Y4zzw3TIWwOi+eJuvyq6LxTpK6lF9FrYLIs/lnlBKdm/tgDx7qCzzUt0hkkTqmJTcBgBzitjwrTwo zKcCaesJQiKDo5vkUNcd1b2bMsCtez/xkGgEcdM2dt132IeKmjvyhKvVqVP2VMZwEzTtc66ukxN00 BI0e/z2oNLnTv8DEygySLC+deWR9IUAoNuiORh9k5NGYuXXt52VTavjXd7DbnaqRQgY4OsWrzWF0i fpV4Rei7zfY5+DJjwEiJa5mqpFqXM1K6+bHaVL/y/qQNlRqbq21/9dwmZq4RVXJacedQ234vb30by piTFfk2ImUfX7pYp13sQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDEuq-0007Ms-Eh; Wed, 25 Sep 2019 21:33:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iDEum-0007MD-Gz for linux-arm-kernel@lists.infradead.org; Wed, 25 Sep 2019 21:33:38 +0000 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9EB8E222C1 for ; Wed, 25 Sep 2019 21:33:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569447215; bh=TszXw7S5GIEzEo992EEMfz4W0WtzSxu1MBpaBhf4tmw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QlI2Sj1D5LJahPlbpQRPzC/Kfp42A3NwekR29GtyvfIPAZlvPN1zAfycydpBTfcd8 IvT8WVCyptqcO23hrQq7/1AbSsfzPRa68TLRQRP+hrXx+5Qsz/4M4CfEt25gMVn9on EMq0EmayAeKNvnaIFqzE8CzGz5kGoSiMNjw4W64I= Received: by mail-qt1-f181.google.com with SMTP id w14so240145qto.9 for ; Wed, 25 Sep 2019 14:33:35 -0700 (PDT) X-Gm-Message-State: APjAAAW4K6FFJxtU/Yhlo4HTr4csSowFMmKr25bLdMA+b3/YzNUxpQ5u awkDftrAtWK7Ma44gzDFLWx1BZPKeRfsT74YFg== X-Google-Smtp-Source: APXvYqy9YJ9VRUtFzrkZ+iKb5Tx5rlamJJuwaAKBRmCflwCEbYKpuVBbZPPVrEImTOCJgn8Jl5TlEwRQfbhe0HNZXOU= X-Received: by 2002:a0c:8a6d:: with SMTP id 42mr1647258qvu.138.1569447214653; Wed, 25 Sep 2019 14:33:34 -0700 (PDT) MIME-Version: 1.0 References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> In-Reply-To: From: Rob Herring Date: Wed, 25 Sep 2019 16:33:23 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters To: Robin Murphy X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190925_143336_612123_9800F83C X-CRM114-Status: GOOD ( 30.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Matthias Brugger , Frank Rowand , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org, Dan Williams , freedreno , Nicolas Saenz Julienne , Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 25, 2019 at 11:52 AM Robin Murphy wrote: > > On 25/09/2019 17:16, Rob Herring wrote: > > On Wed, Sep 25, 2019 at 10:30 AM Nicolas Saenz Julienne > > wrote: > >> > >> On Wed, 2019-09-25 at 16:09 +0100, Robin Murphy wrote: > >>> On 25/09/2019 15:52, Nicolas Saenz Julienne wrote: > >>>> On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote: > >>>>> On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne > >>>>> wrote: > >>>>>> Hi All, > >>>>>> this series tries to address one of the issues blocking us from > >>>>>> upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that > >>>>>> devices not represented in DT which sit behind a PCI bus fail to get the > >>>>>> bus' DMA addressing constraints. > >>>>>> > >>>>>> This is due to the fact that of_dma_configure() assumes it's receiving a > >>>>>> DT node representing the device being configured, as opposed to the PCIe > >>>>>> bridge node we currently pass. This causes the code to directly jump > >>>>>> into PCI's parent node when checking for 'dma-ranges' and misses > >>>>>> whatever was set there. > >>>>>> > >>>>>> To address this I create a new API in OF - inspired from Robin Murphys > >>>>>> original proposal[2] - which accepts a bus DT node as it's input in > >>>>>> order to configure a device's DMA constraints. The changes go deep into > >>>>>> of/address.c's implementation, as a device being having a DT node > >>>>>> assumption was pretty strong. > >>>>>> > >>>>>> On top of this work, I also cleaned up of_dma_configure() removing its > >>>>>> redundant arguments and creating an alternative function for the special > >>>>>> cases > >>>>>> not applicable to either the above case or the default usage. > >>>>>> > >>>>>> IMO the resulting functions are more explicit. They will probably > >>>>>> surface some hacky usages that can be properly fixed as I show with the > >>>>>> DT fixes on the Layerscape platform. > >>>>>> > >>>>>> This was also tested on a Raspberry Pi 4 with a custom PCIe driver and > >>>>>> on a Seattle AMD board. > >>>>> > >>>>> Humm, I've been working on this issue too. Looks similar though yours > >>>>> has a lot more churn and there's some other bugs I've found. > >>>> > >>>> That's good news, and yes now that I see it, some stuff on my series is > >>>> overly > >>>> complicated. Specially around of_translate_*(). > >>>> > >>>> On top of that, you removed in of_dma_get_range(): > >>>> > >>>> - /* > >>>> - * At least empty ranges has to be defined for parent node if > >>>> - * DMA is supported > >>>> - */ > >>>> - if (!ranges) > >>>> - break; > >>>> > >>>> Which I assumed was bound to the standard and makes things easier. > >>>> > >>>>> Can you test out this branch[1]. I don't have any h/w needing this, > >>>>> but wrote a unittest and tested with modified QEMU. > >>>> > >>>> I reviewed everything, I did find a minor issue, see the patch attached. > >>> > >>> WRT that patch, the original intent of "force_dma" was purely to > >>> consider a device DMA-capable regardless of the presence of > >>> "dma-ranges". Expecting of_dma_configure() to do anything for a non-OF > >>> device has always been bogus - magic paravirt devices which appear out > >>> of nowhere and expect to be treated as genuine DMA masters are a > >>> separate problem that we haven't really approached yet. > >> > >> I agree it's clearly abusing the function. I have no problem with the behaviour > >> change if it's OK with you. > > Thinking about it, you could probably just remove that call from the Xen > DRM driver now anyway - since the dma-direct rework, we lost the ability > to set dma_dummy_ops by default, and NULL ops now represent what it > (presumably) wants. Not xen_dma_ops? In any case, I'll send out a patch for the the Xen folks to comment on. > >> Robin, have you looked into supporting multiple dma-ranges? It's the next thing > >> we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in the > >> works already. > > > > Multiple dma-ranges as far as configuring inbound windows should work > > already other than the bug when there's any parent translation. But if > > you mean supporting multiple DMA offsets and masks per device in the > > DMA API, there's nothing in the works yet. > > There's also the in-between step of making of_dma_get_range() return a > size based on all the dma-ranges entries rather than only the first one > - otherwise, something like [1] can lead to pretty unworkable default > masks. We implemented that when doing acpi_dma_get_range(), it's just > that the OF counterpart never caught up. Right. I suppose we assume any holes in the ranges are addressable by the device but won't get used for other reasons (such as no memory there). However, to be correct, the range of the dma offset plus mask would need to be within the min start and max end addresses. IOW, while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next power of 2, the 'correct' thing to do is round down. Rob > [1] > http://linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=a2814af56b3486c2985a95540a88d8f9fa3a699f _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel