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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 C6D46C33C9E for ; Thu, 30 Jan 2020 07:53:43 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.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 921A52082E for ; Thu, 30 Jan 2020 07:53:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 921A52082E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 7827F88395; Thu, 30 Jan 2020 07:53:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjVXQK+HfdSV; Thu, 30 Jan 2020 07:53:41 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id 45F9088338; Thu, 30 Jan 2020 07:53:41 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2853BC0881; Thu, 30 Jan 2020 07:53:41 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id DC647C0171 for ; Thu, 30 Jan 2020 07:53:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id CD9B022699 for ; Thu, 30 Jan 2020 07:53:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvoI-X1L8AEv for ; Thu, 30 Jan 2020 07:53:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by silver.osuosl.org (Postfix) with ESMTPS id 3F9FE2268C for ; Thu, 30 Jan 2020 07:53:37 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 57B3C68B05; Thu, 30 Jan 2020 08:53:32 +0100 (CET) Date: Thu, 30 Jan 2020 08:53:32 +0100 From: Christoph Hellwig To: Peter Ujfalusi Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130075332.GA30735@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: robh@kernel.org, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , hch@lst.de, linux-arm-kernel@lists.infradead.org, rogerq@ti.com X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" [skipping the DT bits, as I'm everything but an expert on that..] On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > I agree on the phys_to_dma(). It should fail for addresses which does > not fall into any of the ranges. > It is just a that we in Linux don't have the concept atm for ranges, we > have only _one_ range which applies to every memory address. what does atm here mean? We have needed multi-range support for quite a while, as common broadcom SOCs do need it. So patches for that are welcome at least from the DMA layer perspective (kinda similar to your pseudo code earlier) > > Nobody's disputing that the current dma_direct_supported() > > implementation is broken for the case where ZONE_DMA itself is offset > > from PA 0; the more pressing question is why Christoph's diff, which was > > trying to take that into account, still didn't work. > > I understand that this is a bit more complex than I interpret it, but > the k2g is broken and currently the simplest way to make it work is to > use the arm dma_ops in case the pfn_offset is not 0. > It will be easy to test dma-direct changes trying to address the issue > in hand, but will allow k2g to be usable at the same time. Well, using the legacy arm dma ops means we can't use swiotlb if there is an offset, which is also wrong for lots of common cases, including the Rpi 4. I'm still curious why my patch didn't work, as I thought it should. We'll need to find the minimum change to make it work for now without switching ops, even if it isn't the correct one, and then work from there. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_DBL_ABUSE_MALW,USER_AGENT_SANE_1 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 76266C33C9E for ; Thu, 30 Jan 2020 07:53:48 +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 3FB1B20702 for ; Thu, 30 Jan 2020 07:53:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZuRqW75Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FB1B20702 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Gag2ATcCoArrS5/L+0nWVNmcW+IQyyA/rSmVdHEgBRs=; b=ZuRqW75Q3+I5n8 MMBlNylw5L0zZoJntNC+TXw0xDAUzORMFOSauEhFrjT+75l7JO4yyof11CMoliNNkB0ECqS1mT33R J7N99ypEBFQnP2oS1OqZkgZgxw3GsRQUgnKCJICmI4bjL+LblCHg+pkpm2O5N5mLoLhe65OcVPtWh SSNTUd1OQzZ/RRUE/5Z4VFQLcEHoZfs/yJwKh158DZhmxO6gYopTpdZr1U3j+hJ0sNLysToTfaxSf pa3Dq7MjjcBnD6t4f4+MtHKOQAYQ82FklHijiDHx0u+f+OOTurXDHuRruXYmM3YvH41lXZjyCmk+0 dKIkUn76famHqmKO4Cnw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ix4dy-0001bc-GR; Thu, 30 Jan 2020 07:53:42 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ix4dv-0001ax-AO for linux-arm-kernel@lists.infradead.org; Thu, 30 Jan 2020 07:53:41 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 57B3C68B05; Thu, 30 Jan 2020 08:53:32 +0100 (CET) Date: Thu, 30 Jan 2020 08:53:32 +0100 From: Christoph Hellwig To: Peter Ujfalusi Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130075332.GA30735@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200129_235339_508876_DB040E62 X-CRM114-Status: GOOD ( 16.52 ) 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: robh@kernel.org, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Robin Murphy , hch@lst.de, linux-arm-kernel@lists.infradead.org, rogerq@ti.com 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 [skipping the DT bits, as I'm everything but an expert on that..] On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > I agree on the phys_to_dma(). It should fail for addresses which does > not fall into any of the ranges. > It is just a that we in Linux don't have the concept atm for ranges, we > have only _one_ range which applies to every memory address. what does atm here mean? We have needed multi-range support for quite a while, as common broadcom SOCs do need it. So patches for that are welcome at least from the DMA layer perspective (kinda similar to your pseudo code earlier) > > Nobody's disputing that the current dma_direct_supported() > > implementation is broken for the case where ZONE_DMA itself is offset > > from PA 0; the more pressing question is why Christoph's diff, which was > > trying to take that into account, still didn't work. > > I understand that this is a bit more complex than I interpret it, but > the k2g is broken and currently the simplest way to make it work is to > use the arm dma_ops in case the pfn_offset is not 0. > It will be easy to test dma-direct changes trying to address the issue > in hand, but will allow k2g to be usable at the same time. Well, using the legacy arm dma ops means we can't use swiotlb if there is an offset, which is also wrong for lots of common cases, including the Rpi 4. I'm still curious why my patch didn't work, as I thought it should. We'll need to find the minimum change to make it work for now without switching ops, even if it isn't the correct one, and then work from there. _______________________________________________ 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 40649C33C9E for ; Thu, 30 Jan 2020 07:53:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 178C420702 for ; Thu, 30 Jan 2020 07:53:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726893AbgA3Hxg (ORCPT ); Thu, 30 Jan 2020 02:53:36 -0500 Received: from verein.lst.de ([213.95.11.211]:39306 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726464AbgA3Hxf (ORCPT ); Thu, 30 Jan 2020 02:53:35 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 57B3C68B05; Thu, 30 Jan 2020 08:53:32 +0100 (CET) Date: Thu, 30 Jan 2020 08:53:32 +0100 From: Christoph Hellwig To: Peter Ujfalusi Cc: Robin Murphy , hch@lst.de, vigneshr@ti.com, konrad.wilk@oracle.com, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, rogerq@ti.com, robh@kernel.org Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Message-ID: <20200130075332.GA30735@lst.de> References: <8eb68140-97b2-62ce-3e06-3761984aa5b1@ti.com> <20200114164332.3164-1-peter.ujfalusi@ti.com> <28ee3395-baed-8d59-8546-ab7765829cc8@ti.com> <4f0e307f-29a9-44cd-eeaa-3b999e03871c@arm.com> <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [skipping the DT bits, as I'm everything but an expert on that..] On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote: > I agree on the phys_to_dma(). It should fail for addresses which does > not fall into any of the ranges. > It is just a that we in Linux don't have the concept atm for ranges, we > have only _one_ range which applies to every memory address. what does atm here mean? We have needed multi-range support for quite a while, as common broadcom SOCs do need it. So patches for that are welcome at least from the DMA layer perspective (kinda similar to your pseudo code earlier) > > Nobody's disputing that the current dma_direct_supported() > > implementation is broken for the case where ZONE_DMA itself is offset > > from PA 0; the more pressing question is why Christoph's diff, which was > > trying to take that into account, still didn't work. > > I understand that this is a bit more complex than I interpret it, but > the k2g is broken and currently the simplest way to make it work is to > use the arm dma_ops in case the pfn_offset is not 0. > It will be easy to test dma-direct changes trying to address the issue > in hand, but will allow k2g to be usable at the same time. Well, using the legacy arm dma ops means we can't use swiotlb if there is an offset, which is also wrong for lots of common cases, including the Rpi 4. I'm still curious why my patch didn't work, as I thought it should. We'll need to find the minimum change to make it work for now without switching ops, even if it isn't the correct one, and then work from there.