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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 738ADC432C2 for ; Wed, 25 Sep 2019 16:17:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4AEFB21D7E for ; Wed, 25 Sep 2019 16:17:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569428220; bh=kWvQDMnhvqyvgI/cRcXoMhpMrwTzw21yx7s7QxCURME=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=n2FyI0oHH9GP3+BC4uP/GSxjw1jHv65H7A/D79YUIx25S8T6PhwzbbCcW+HIgMqx+ hdE8pXRrbYI+5JxTUCxbGd531TkW1D+8+5188vQ2a031PqTst+wZjFQZDh4HBPu5Fp y1SlFnpk1aivvVyMD4uNM+m44RtfN1PJlH1xFZSg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2501965AbfIYQRA (ORCPT ); Wed, 25 Sep 2019 12:17:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:60562 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2501933AbfIYQQ7 (ORCPT ); Wed, 25 Sep 2019 12:16:59 -0400 Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.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 EA50A222BF; Wed, 25 Sep 2019 16:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569428218; bh=kWvQDMnhvqyvgI/cRcXoMhpMrwTzw21yx7s7QxCURME=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0yN231Pbtuv+A35lsN4TVWWkAO/Ao1z+ejWEW70agRAiztlbt/DXeoxut4H8u0lni g2Sc0yzW9dahjD5GhfnpP7r4r+vF2NS+Ad9wA3nPzCfNIZpt3Zn8SW5rmnhGN60Wta Vjtu3J1zixjw+Pddib6E0BK6QMuLIg46YmwdgczY= Received: by mail-qk1-f181.google.com with SMTP id y144so5748849qkb.7; Wed, 25 Sep 2019 09:16:57 -0700 (PDT) X-Gm-Message-State: APjAAAVoBWZ/+FrIqF+S5vnX1RPonBpCj+G1lFaarvhio6lj+loH1zkH xExU6ZHAmERboX1YwypC4/JZA3UXrLyTXaT6Kw== X-Google-Smtp-Source: APXvYqyTl1XVuWTp/35jWle4Kbs2xpDG3Z/T5fV7UMzbxRk+doCiTCUGQILqDsprUV9H9iwgwr82s3aYudHesNV1NR4= X-Received: by 2002:a37:be87:: with SMTP id o129mr4499696qkf.254.1569428216961; Wed, 25 Sep 2019 09:16:56 -0700 (PDT) MIME-Version: 1.0 References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> In-Reply-To: <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> From: Rob Herring Date: Wed, 25 Sep 2019 11:16:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters To: Nicolas Saenz Julienne Cc: Robin Murphy , devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , freedreno , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Type: text/plain; charset="UTF-8" Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org 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. > > 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. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters Date: Wed, 25 Sep 2019 11:16:45 -0500 Message-ID: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> Sender: linux-kernel-owner@vger.kernel.org To: Nicolas Saenz Julienne Cc: Robin Murphy , devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , freedreno , Frank Rowand , moderated list:ARM/FREESCALE IMX / MXC ARM List-Id: linux-tegra@vger.kernel.org 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. > > 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. Rob 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 BDBF3C432C2 for ; Wed, 25 Sep 2019 16:19:55 +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 8FF202146E for ; Wed, 25 Sep 2019 16:19:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eJCRi4E9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0yN231Pb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FF202146E 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=+soDYanrGv5dPQIM/XvkcKubyWvtUce2IqgnMh5NSiY=; b=eJCRi4E9ueavI/ xqEBMTxTx50DO6+uNvMI45IK+8WZiiRna15b481xEP9A5s1CuHGk3xS91F6APAVt4Oh2+WuBY5PNJ zGw2emESuvM4718q0AhIrauTNQpm0R5EtFgKkodYUsCi+zhRnOkiEqx2gd8ltBY04u0cgK4sqqsFN BYrq1sJpWoG0c0v3gllotnWDXvwtbJzBK6LwkgSYikHfs9Gl7FOKgfL8IFzky1pCPi9z3PwgqR6pp WvrU6RHRkQ82tg9+pMm1807ssyMNpVIa1uwg8WFTaC+lpd6P6xQFtBC+ivo7fzuE7gMjRR7VMzPui ickBj1Zwh93lUWih9r9g==; 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 1iDA16-0000jo-02; Wed, 25 Sep 2019 16:19:48 +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 1iD9yM-00074C-AT for linux-arm-kernel@lists.infradead.org; Wed, 25 Sep 2019 16:17:00 +0000 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (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 D2F3B21D79 for ; Wed, 25 Sep 2019 16:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569428218; bh=kWvQDMnhvqyvgI/cRcXoMhpMrwTzw21yx7s7QxCURME=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0yN231Pbtuv+A35lsN4TVWWkAO/Ao1z+ejWEW70agRAiztlbt/DXeoxut4H8u0lni g2Sc0yzW9dahjD5GhfnpP7r4r+vF2NS+Ad9wA3nPzCfNIZpt3Zn8SW5rmnhGN60Wta Vjtu3J1zixjw+Pddib6E0BK6QMuLIg46YmwdgczY= Received: by mail-qk1-f176.google.com with SMTP id u186so5773925qkc.5 for ; Wed, 25 Sep 2019 09:16:57 -0700 (PDT) X-Gm-Message-State: APjAAAVAFkdBowoEXbrsNck5vIv56Avx/I8BATFqtTyLGrMNM5cP98DT VakIulrSFm1CRPNfeoLiJFDNPz9Ve/fhjHOMjg== X-Google-Smtp-Source: APXvYqyTl1XVuWTp/35jWle4Kbs2xpDG3Z/T5fV7UMzbxRk+doCiTCUGQILqDsprUV9H9iwgwr82s3aYudHesNV1NR4= X-Received: by 2002:a37:be87:: with SMTP id o129mr4499696qkf.254.1569428216961; Wed, 25 Sep 2019 09:16:56 -0700 (PDT) MIME-Version: 1.0 References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> In-Reply-To: <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> From: Rob Herring Date: Wed, 25 Sep 2019 11:16:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters To: Nicolas Saenz Julienne X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190925_091658_544131_17B7AD84 X-CRM114-Status: GOOD ( 31.03 ) 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: 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 , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , 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 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. > > 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. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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_INVALID,DKIM_SIGNED, 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 74B7CC432C2 for ; Wed, 25 Sep 2019 16:17:11 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 4243521D7C for ; Wed, 25 Sep 2019 16:17:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0yN231Pb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4243521D7C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iD9yO-0006Wb-N8; Wed, 25 Sep 2019 16:17:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iD9yN-0006WO-B4 for xen-devel@lists.xenproject.org; Wed, 25 Sep 2019 16:16:59 +0000 X-Inumbo-ID: e60955d6-dfaf-11e9-9638-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by localhost (Halon) with ESMTPS id e60955d6-dfaf-11e9-9638-12813bfff9fa; Wed, 25 Sep 2019 16:16:58 +0000 (UTC) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 E034F21D80 for ; Wed, 25 Sep 2019 16:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569428218; bh=kWvQDMnhvqyvgI/cRcXoMhpMrwTzw21yx7s7QxCURME=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0yN231Pbtuv+A35lsN4TVWWkAO/Ao1z+ejWEW70agRAiztlbt/DXeoxut4H8u0lni g2Sc0yzW9dahjD5GhfnpP7r4r+vF2NS+Ad9wA3nPzCfNIZpt3Zn8SW5rmnhGN60Wta Vjtu3J1zixjw+Pddib6E0BK6QMuLIg46YmwdgczY= Received: by mail-qk1-f182.google.com with SMTP id z67so5733872qkb.12 for ; Wed, 25 Sep 2019 09:16:57 -0700 (PDT) X-Gm-Message-State: APjAAAUE3veYtxbU6ChawJxwoWqkO7nv8osIkrtz8vLAp1sWJzEmxukK QnnMcRwFHU8F6Z7KcfJ7Dg9PFL97a1LB2buluw== X-Google-Smtp-Source: APXvYqyTl1XVuWTp/35jWle4Kbs2xpDG3Z/T5fV7UMzbxRk+doCiTCUGQILqDsprUV9H9iwgwr82s3aYudHesNV1NR4= X-Received: by 2002:a37:be87:: with SMTP id o129mr4499696qkf.254.1569428216961; Wed, 25 Sep 2019 09:16:56 -0700 (PDT) MIME-Version: 1.0 References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> In-Reply-To: <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> From: Rob Herring Date: Wed, 25 Sep 2019 11:16:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Nicolas Saenz Julienne Subject: Re: [Xen-devel] [PATCH 00/11] of: Fix DMA configuration for non-DT masters X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 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 , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gV2VkLCBTZXAgMjUsIDIwMTkgYXQgMTA6MzAgQU0gTmljb2xhcyBTYWVueiBKdWxpZW5uZQo8 bnNhZW56anVsaWVubmVAc3VzZS5kZT4gd3JvdGU6Cj4KPiBPbiBXZWQsIDIwMTktMDktMjUgYXQg MTY6MDkgKzAxMDAsIFJvYmluIE11cnBoeSB3cm90ZToKPiA+IE9uIDI1LzA5LzIwMTkgMTU6NTIs IE5pY29sYXMgU2FlbnogSnVsaWVubmUgd3JvdGU6Cj4gPiA+IE9uIFR1ZSwgMjAxOS0wOS0yNCBh dCAxNjo1OSAtMDUwMCwgUm9iIEhlcnJpbmcgd3JvdGU6Cj4gPiA+ID4gT24gVHVlLCBTZXAgMjQs IDIwMTkgYXQgMToxMiBQTSBOaWNvbGFzIFNhZW56IEp1bGllbm5lCj4gPiA+ID4gPG5zYWVuemp1 bGllbm5lQHN1c2UuZGU+IHdyb3RlOgo+ID4gPiA+ID4gSGkgQWxsLAo+ID4gPiA+ID4gdGhpcyBz ZXJpZXMgdHJpZXMgdG8gYWRkcmVzcyBvbmUgb2YgdGhlIGlzc3VlcyBibG9ja2luZyB1cyBmcm9t Cj4gPiA+ID4gPiB1cHN0cmVhbWluZyBCcm9hZGNvbSdzIFNUQiBQQ0llIGNvbnRyb2xsZXJbMV0u IE5hbWVseSwgdGhlIGZhY3QgdGhhdAo+ID4gPiA+ID4gZGV2aWNlcyBub3QgcmVwcmVzZW50ZWQg aW4gRFQgd2hpY2ggc2l0IGJlaGluZCBhIFBDSSBidXMgZmFpbCB0byBnZXQgdGhlCj4gPiA+ID4g PiBidXMnIERNQSBhZGRyZXNzaW5nIGNvbnN0cmFpbnRzLgo+ID4gPiA+ID4KPiA+ID4gPiA+IFRo aXMgaXMgZHVlIHRvIHRoZSBmYWN0IHRoYXQgb2ZfZG1hX2NvbmZpZ3VyZSgpIGFzc3VtZXMgaXQn cyByZWNlaXZpbmcgYQo+ID4gPiA+ID4gRFQgbm9kZSByZXByZXNlbnRpbmcgdGhlIGRldmljZSBi ZWluZyBjb25maWd1cmVkLCBhcyBvcHBvc2VkIHRvIHRoZSBQQ0llCj4gPiA+ID4gPiBicmlkZ2Ug bm9kZSB3ZSBjdXJyZW50bHkgcGFzcy4gVGhpcyBjYXVzZXMgdGhlIGNvZGUgdG8gZGlyZWN0bHkg anVtcAo+ID4gPiA+ID4gaW50byBQQ0kncyBwYXJlbnQgbm9kZSB3aGVuIGNoZWNraW5nIGZvciAn ZG1hLXJhbmdlcycgYW5kIG1pc3Nlcwo+ID4gPiA+ID4gd2hhdGV2ZXIgd2FzIHNldCB0aGVyZS4K PiA+ID4gPiA+Cj4gPiA+ID4gPiBUbyBhZGRyZXNzIHRoaXMgSSBjcmVhdGUgYSBuZXcgQVBJIGlu IE9GIC0gaW5zcGlyZWQgZnJvbSBSb2JpbiBNdXJwaHlzCj4gPiA+ID4gPiBvcmlnaW5hbCBwcm9w b3NhbFsyXSAtIHdoaWNoIGFjY2VwdHMgYSBidXMgRFQgbm9kZSBhcyBpdCdzIGlucHV0IGluCj4g PiA+ID4gPiBvcmRlciB0byBjb25maWd1cmUgYSBkZXZpY2UncyBETUEgY29uc3RyYWludHMuIFRo ZSBjaGFuZ2VzIGdvIGRlZXAgaW50bwo+ID4gPiA+ID4gb2YvYWRkcmVzcy5jJ3MgaW1wbGVtZW50 YXRpb24sIGFzIGEgZGV2aWNlIGJlaW5nIGhhdmluZyBhIERUIG5vZGUKPiA+ID4gPiA+IGFzc3Vt cHRpb24gd2FzIHByZXR0eSBzdHJvbmcuCj4gPiA+ID4gPgo+ID4gPiA+ID4gT24gdG9wIG9mIHRo aXMgd29yaywgSSBhbHNvIGNsZWFuZWQgdXAgb2ZfZG1hX2NvbmZpZ3VyZSgpIHJlbW92aW5nIGl0 cwo+ID4gPiA+ID4gcmVkdW5kYW50IGFyZ3VtZW50cyBhbmQgY3JlYXRpbmcgYW4gYWx0ZXJuYXRp dmUgZnVuY3Rpb24gZm9yIHRoZSBzcGVjaWFsCj4gPiA+ID4gPiBjYXNlcwo+ID4gPiA+ID4gbm90 IGFwcGxpY2FibGUgdG8gZWl0aGVyIHRoZSBhYm92ZSBjYXNlIG9yIHRoZSBkZWZhdWx0IHVzYWdl Lgo+ID4gPiA+ID4KPiA+ID4gPiA+IElNTyB0aGUgcmVzdWx0aW5nIGZ1bmN0aW9ucyBhcmUgbW9y ZSBleHBsaWNpdC4gVGhleSB3aWxsIHByb2JhYmx5Cj4gPiA+ID4gPiBzdXJmYWNlIHNvbWUgaGFj a3kgdXNhZ2VzIHRoYXQgY2FuIGJlIHByb3Blcmx5IGZpeGVkIGFzIEkgc2hvdyB3aXRoIHRoZQo+ ID4gPiA+ID4gRFQgZml4ZXMgb24gdGhlIExheWVyc2NhcGUgcGxhdGZvcm0uCj4gPiA+ID4gPgo+ ID4gPiA+ID4gVGhpcyB3YXMgYWxzbyB0ZXN0ZWQgb24gYSBSYXNwYmVycnkgUGkgNCB3aXRoIGEg Y3VzdG9tIFBDSWUgZHJpdmVyIGFuZAo+ID4gPiA+ID4gb24gYSBTZWF0dGxlIEFNRCBib2FyZC4K PiA+ID4gPgo+ID4gPiA+IEh1bW0sIEkndmUgYmVlbiB3b3JraW5nIG9uIHRoaXMgaXNzdWUgdG9v LiBMb29rcyBzaW1pbGFyIHRob3VnaCB5b3Vycwo+ID4gPiA+IGhhcyBhIGxvdCBtb3JlIGNodXJu IGFuZCB0aGVyZSdzIHNvbWUgb3RoZXIgYnVncyBJJ3ZlIGZvdW5kLgo+ID4gPgo+ID4gPiBUaGF0 J3MgZ29vZCBuZXdzLCBhbmQgeWVzIG5vdyB0aGF0IEkgc2VlIGl0LCBzb21lIHN0dWZmIG9uIG15 IHNlcmllcyBpcwo+ID4gPiBvdmVybHkKPiA+ID4gY29tcGxpY2F0ZWQuIFNwZWNpYWxseSBhcm91 bmQgb2ZfdHJhbnNsYXRlXyooKS4KPiA+ID4KPiA+ID4gT24gdG9wIG9mIHRoYXQsIHlvdSByZW1v dmVkIGluIG9mX2RtYV9nZXRfcmFuZ2UoKToKPiA+ID4KPiA+ID4gLSAgIC8qCj4gPiA+IC0gICAg KiBBdCBsZWFzdCBlbXB0eSByYW5nZXMgaGFzIHRvIGJlIGRlZmluZWQgZm9yIHBhcmVudCBub2Rl IGlmCj4gPiA+IC0gICAgKiBETUEgaXMgc3VwcG9ydGVkCj4gPiA+IC0gICAgKi8KPiA+ID4gLSAg IGlmICghcmFuZ2VzKQo+ID4gPiAtICAgICAgICAgICBicmVhazsKPiA+ID4KPiA+ID4gV2hpY2gg SSBhc3N1bWVkIHdhcyBib3VuZCB0byB0aGUgc3RhbmRhcmQgYW5kIG1ha2VzIHRoaW5ncyBlYXNp ZXIuCj4gPiA+Cj4gPiA+ID4gQ2FuIHlvdSB0ZXN0IG91dCB0aGlzIGJyYW5jaFsxXS4gSSBkb24n dCBoYXZlIGFueSBoL3cgbmVlZGluZyB0aGlzLAo+ID4gPiA+IGJ1dCB3cm90ZSBhIHVuaXR0ZXN0 IGFuZCB0ZXN0ZWQgd2l0aCBtb2RpZmllZCBRRU1VLgo+ID4gPgo+ID4gPiBJIHJldmlld2VkIGV2 ZXJ5dGhpbmcsIEkgZGlkIGZpbmQgYSBtaW5vciBpc3N1ZSwgc2VlIHRoZSBwYXRjaCBhdHRhY2hl ZC4KPiA+Cj4gPiBXUlQgdGhhdCBwYXRjaCwgdGhlIG9yaWdpbmFsIGludGVudCBvZiAiZm9yY2Vf ZG1hIiB3YXMgcHVyZWx5IHRvCj4gPiBjb25zaWRlciBhIGRldmljZSBETUEtY2FwYWJsZSByZWdh cmRsZXNzIG9mIHRoZSBwcmVzZW5jZSBvZgo+ID4gImRtYS1yYW5nZXMiLiBFeHBlY3Rpbmcgb2Zf ZG1hX2NvbmZpZ3VyZSgpIHRvIGRvIGFueXRoaW5nIGZvciBhIG5vbi1PRgo+ID4gZGV2aWNlIGhh cyBhbHdheXMgYmVlbiBib2d1cyAtIG1hZ2ljIHBhcmF2aXJ0IGRldmljZXMgd2hpY2ggYXBwZWFy IG91dAo+ID4gb2Ygbm93aGVyZSBhbmQgZXhwZWN0IHRvIGJlIHRyZWF0ZWQgYXMgZ2VudWluZSBE TUEgbWFzdGVycyBhcmUgYQo+ID4gc2VwYXJhdGUgcHJvYmxlbSB0aGF0IHdlIGhhdmVuJ3QgcmVh bGx5IGFwcHJvYWNoZWQgeWV0Lgo+Cj4gSSBhZ3JlZSBpdCdzIGNsZWFybHkgYWJ1c2luZyB0aGUg ZnVuY3Rpb24uIEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggdGhlIGJlaGF2aW91cgo+IGNoYW5nZSBp ZiBpdCdzIE9LIHdpdGggeW91Lgo+Cj4gUm9iaW4sIGhhdmUgeW91IGxvb2tlZCBpbnRvIHN1cHBv cnRpbmcgbXVsdGlwbGUgZG1hLXJhbmdlcz8gSXQncyB0aGUgbmV4dCB0aGluZwo+IHdlIG5lZWQg Zm9yIEJDTSBTVEIncyBQQ0llLiBJJ2xsIGhhdmUgYSBnbyBhdCBpdCBteXNlbGYgaWYgbm90aGlu ZyBpcyBpbiB0aGUKPiB3b3JrcyBhbHJlYWR5LgoKTXVsdGlwbGUgZG1hLXJhbmdlcyBhcyBmYXIg YXMgY29uZmlndXJpbmcgaW5ib3VuZCB3aW5kb3dzIHNob3VsZCB3b3JrCmFscmVhZHkgb3RoZXIg dGhhbiB0aGUgYnVnIHdoZW4gdGhlcmUncyBhbnkgcGFyZW50IHRyYW5zbGF0aW9uLiBCdXQgaWYK eW91IG1lYW4gc3VwcG9ydGluZyBtdWx0aXBsZSBETUEgb2Zmc2V0cyBhbmQgbWFza3MgcGVyIGRl dmljZSBpbiB0aGUKRE1BIEFQSSwgdGhlcmUncyBub3RoaW5nIGluIHRoZSB3b3JrcyB5ZXQuCgpS b2IKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnCmh0dHBzOi8v bGlzdHMueGVucHJvamVjdC5vcmcvbWFpbG1hbi9saXN0aW5mby94ZW4tZGV2ZWw=