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=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 07FE9C4338F for ; Wed, 25 Aug 2021 04:42:15 +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 C0DC1611C8 for ; Wed, 25 Aug 2021 04:42:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C0DC1611C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=TlaxTfqXTPw7THAY+BmyAHAZVnFKF8iao4IsJYXT8F4=; b=rysMe4wq5uiM9t t6wXugdejQ34lryUlY2qat5tPNjnW4xGd2Bj/oePUfldXUjzI655eEIT2aIhWlzr9bz2UPANbQ95Q DuvebB6uznAp1xtwt2yRP79EJgs5nSB0YosyX/mLWksIXrazP8oTHY7OkG1nhzn9+4Y02YX26XwA9 ylVmQdSw8Mh4ExI5+fYNMZrAsSgPtZ4IzixaMH8jb/oD335oWjxSbVeFS5VyzafnHpVE8hmr61s1V fz4EvDGGnYyfVUQPXh7rmeH7MreTtExQ6ypggTKoMMsnEVjUGhJG1UKjrf/prJ85NJ8iHqyj3pzwR RzEv6E+eFmhCO0/hCOgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIkgx-005Tq0-4v; Wed, 25 Aug 2021 04:39:11 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIkgt-005Tp1-78 for linux-arm-kernel@lists.infradead.org; Wed, 25 Aug 2021 04:39:08 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9564761246; Wed, 25 Aug 2021 04:39:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629866346; bh=DyJlqtTO+nFr0UnDA22UPSMLbTJ+DzvuMl9//OXkwzE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qPEay1hYiUr55ZMZUrxsSndXmclPRr9OIYk4pCIV24HBrV0SgRNe8QBlZ6yKyfnyN L5dT0c9rHRIEHLS29zCHtSti+dzEcrBncirZiitQofLip9UDhzN8tDcrL1KzJ7T4P0 EW9FkMJr44oatqBJJ8QrDEOxAcAvB1hdmGMt2Yx3mKMD6xCvG/zK1AKBkzqPRjwca0 XuTj4wwcckO5axQG9XVj0Ftv5H+hwMQVTy/+KdZ095uuGf5UE5m+tbh0uAjglMPIY+ vgnCloEWZX1T2HJKlhGcZ2Gx/G5EUPvEZ7O1dGgeUemqWQtLbjlP0FSI48ArNgoyz+ D4AihaLgGRUnA== Date: Wed, 25 Aug 2021 07:39:00 +0300 From: Mike Rapoport To: Alex Bee Cc: Catalin Marinas , Will Deacon , Andrew Morton , Anshuman Khandual , Linux Kernel Mailing List , linux-mm@kvack.org, Linux ARM , Robin Murphy Subject: Re: [BUG 5.14] arm64/mm: dma memory mapping fails (in some cases) Message-ID: References: <20210824173741.GC623@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210824_213907_338522_2F8A9B55 X-CRM114-Status: GOOD ( 40.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 24, 2021 at 10:14:01PM +0200, Alex Bee wrote: > Hi Mike, > = > thanks for your reply > = > Am 24.08.21 um 20:28 schrieb Mike Rapoport: > > On Tue, Aug 24, 2021 at 06:37:41PM +0100, Catalin Marinas wrote: > > > Hi Alex, > > > = > > > Thanks for the report. > > > = > > > On Tue, Aug 24, 2021 at 03:40:47PM +0200, Alex Bee wrote: > > > > it seems there is a regression in arm64 memory mapping in 5.14, sin= ce it > > > > fails on Rockchip RK3328 when the pl330 dmac tries to map with: > > > > = > > > > [=A0=A0=A0 8.921909] ------------[ cut here ]------------ > > > > [=A0=A0=A0 8.921940] WARNING: CPU: 2 PID: 373 at kernel/dma/mapping= .c:235 dma_map_resource+0x68/0xc0 > > > > [=A0=A0=A0 8.921973] Modules linked in: spi_rockchip(+) fuse > > > > [=A0=A0=A0 8.921996] CPU: 2 PID: 373 Comm: systemd-udevd Not tainte= d 5.14.0-rc7 #1 > > > > [=A0=A0=A0 8.922004] Hardware name: Pine64 Rock64 (DT) > > > > [=A0=A0=A0 8.922011] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTY= PE=3D--) > > > > [=A0=A0=A0 8.922018] pc : dma_map_resource+0x68/0xc0 > > > > [=A0=A0=A0 8.922026] lr : pl330_prep_slave_fifo+0x78/0xd0 > > > > [=A0=A0=A0 8.922040] sp : ffff800012102ae0 > > > > [=A0=A0=A0 8.922043] x29: ffff800012102ae0 x28: ffff000005c94800 x2= 7: 0000000000000000 > > > > [=A0=A0=A0 8.922056] x26: ffff000000566bd0 x25: 0000000000000001 x2= 4: 0000000000000001 > > > > [=A0=A0=A0 8.922067] x23: 0000000000000002 x22: ffff000000628c00 x2= 1: 0000000000000001 > > > > [=A0=A0=A0 8.922078] x20: ffff000000566bd0 x19: 0000000000000001 x1= 8: 0000000000000000 > > > > [=A0=A0=A0 8.922089] x17: 0000000000000000 x16: 0000000000000000 x1= 5: 0000000000000000 > > > > [=A0=A0=A0 8.922100] x14: 0000000000000277 x13: 0000000000000001 x1= 2: 0000000000000000 > > > > [=A0=A0=A0 8.922111] x11: 0000000000000001 x10: 00000000000008e0 x9= : ffff800012102a80 > > > > [=A0=A0=A0 8.922123] x8 : ffff000000d14b80 x7 : ffff0000fe7b12f0 x6= : ffff0000fe7b1100 > > > > [=A0=A0=A0 8.922134] x5 : fffffc000000000f x4 : 0000000000000000 x3= : 0000000000000001 > > > > [=A0=A0=A0 8.922145] x2 : 0000000000000001 x1 : 00000000ff190800 x0= : ffff000000628c00 > > > > [=A0=A0=A0 8.922158] Call trace: > > > > [=A0=A0=A0 8.922163]=A0 dma_map_resource+0x68/0xc0 > > > > [=A0=A0=A0 8.922173]=A0 pl330_prep_slave_sg+0x58/0x220 > > > > [=A0=A0=A0 8.922181]=A0 rockchip_spi_prepare_dma+0xd8/0x2c0 [spi_ro= ckchip] > > > > [=A0=A0=A0 8.922208]=A0 rockchip_spi_transfer_one+0x294/0x3d8 [spi_= rockchip] > > > [...] > > > > Note: This does not relate to the spi driver - when disabling this = device in > > > > the device tree it fails for any other (i2s, for instance) which us= es dma. > > > > Commenting out the failing check at [1], however, helps and the map= ping > > > > works again. > > > Do you know which address dma_map_resource() is trying to map (maybe > > > add some printk())? It's not supposed to map RAM, hence the warning. > > > Random guess, the address is 0xff190800 (based on the x1 above but the > > > regs might as well be mangled). > > 0xff190800 will cause this warning for sure. It has a memory map, but i= t is > > not RAM so old version of pfn_valid() would return 0 and the new one > > returns 1. > > > > I tried to follow the recent changes for arm64 mm which could relat= e to the > > > > check failing at [1] and reverting > > > > =A0 commit 16c9afc77660 ("arm64/mm: drop HAVE_ARCH_PFN_VALID") > > > > helps and makes it work again, but I'm 100% uncertain if that commi= t is > > > > really the culprit. > > > > = > > > > Note, that the firmware (legacy u-boot) injects memory configuratio= n in the > > > > device tree as follows: > > > > = > > > > /memreserve/=A0=A0=A0 0x00000000fcefc000 0x000000000000d000; > > > > / { > > > > .. > > > > =A0=A0=A0 compatible =3D "pine64,rock64\0rockchip,rk3328"; > > > > .. > > > > =A0=A0=A0 memory { > > > > =A0=A0=A0 =A0=A0=A0 reg =3D <0x00 0x200000 0x00 0xfee00000 0x00 0x= 00 0x00 0x00>; > > > > =A0=A0=A0 =A0=A0=A0 device_type =3D "memory"; > > > > =A0=A0=A0 }; > > > > = > > > > .. > > > > } > > > Either pfn_valid() gets confused in 5.14 or something is wrong with t= he > > > DT. I have a suspicion it's the former since reverting the above comm= it > > > makes it disappear. > > I think pfn_valid() actually behaves as expected but the caller is wrong > > because pfn_valid !=3D RAM (this applies btw to !arm64 as well). > > = > > /* Don't allow RAM to be mapped */ > > if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) > > return DMA_MAPPING_ERROR; > > = > > Alex, can you please try this patch: > > = > > diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c > > index 2b06a809d0b9..4715e9641a29 100644 > > --- a/kernel/dma/mapping.c > > +++ b/kernel/dma/mapping.c > > @@ -232,7 +232,7 @@ dma_addr_t dma_map_resource(struct device *dev, phy= s_addr_t phys_addr, > > return DMA_MAPPING_ERROR; > > /* Don't allow RAM to be mapped */ > > - if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr)))) > > + if (WARN_ON_ONCE(!memblock_is_memory(phys_addr))) > > return DMA_MAPPING_ERROR; > > if (dma_map_direct(dev, ops)) > = > Nope, doesn't help: > = > [=A0=A0=A0 8.353879] dma_map_resource Failed to map address 0xff190800 > [=A0=A0=A0 8.353886] dma_map_resource pfn_valid(PHYS_PFN(0xff190800)): 1 > [=A0=A0=A0 8.353892] dma_map_resource memblock_is_memory(0xff190800): 0 > = > If understand the comment for that check correct, that we _don't_ want RAM > to be mapped - shoudn't that be: > = > + if (WARN_ON_ONCE(memblock_is_memory(phys_addr))) > = > ? Right, we don't want RAM to be mapped, the negation was wrong and it should be = if (WARN_ON_ONCE(memblock_is_memory(phys_addr))) = -- = Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel