From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751719AbbEEAHe (ORCPT ); Mon, 4 May 2015 20:07:34 -0400 Received: from gabe.freedesktop.org ([131.252.210.177]:57986 "EHLO gabe.freedesktop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887AbbEEAH0 (ORCPT ); Mon, 4 May 2015 20:07:26 -0400 From: Eric Anholt To: Noralf =?utf-8?Q?Tr=C3=B8nnes?= , linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, linux-rpi-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM. In-Reply-To: <5547D5BA.5070407@tronnes.org> References: <1430768034-12734-1-git-send-email-eric@anholt.net> <5547D5BA.5070407@tronnes.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 04 May 2015 17:07:22 -0700 Message-ID: <878ud3q43p.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noralf Tr=C3=B8nnes writes: > Den 04.05.2015 21:33, skrev Eric Anholt: >> There exists a tiny MMU, configurable only by the VC (running the >> closed firmware), which maps from the ARM's physical addresses to bus >> addresses. These bus addresses determine the caching behavior in the >> VC's L1/L2 (note: separate from the ARM's L1/L2) according to the top >> 2 bits. The bits in the bus address mean: >> >> From the VideoCore processor: >> 0x0... L1 and L2 cache allocating and coherent >> 0x4... L1 non-allocating, but coherent. L2 allocating and coherent >> 0x8... L1 non-allocating, but coherent. L2 non-allocating, but coherent >> 0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or cohere= nt >> >> From the GPU peripherals (note: all peripherals bypass the L1 >> cache. The ARM will see this view once through the VC MMU): >> 0x0... Do not use >> 0x4... L1 non-allocating, and incoherent. L2 allocating and coherent. >> 0x8... L1 non-allocating, and incoherent. L2 non-allocating, but coherent >> 0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or cohere= nt >> >> The 2835 firmware always configures the MMU to turn ARM physical >> addresses with 0x0 top bits to 0x4, meaning present in L2 but >> incoherent with L1. However, any bus addresses we were generating in >> the kernel to be passed to a device had 0x0 bits. That would be a >> reserved (possibly totally incoherent) value if sent to a GPU >> peripheral like USB, or L1 allocating if sent to the VC (like a >> firmware property request). By setting dma-ranges, all of the devices >> below it get a dev->dma_pfn_offset, so that dma_alloc_coherent() and >> friends return addresses with 0x4 bits and avoid cache incoherency. >> >> This matches the behavior in the downstream 2708 kernel (see >> BUS_OFFSET in arch/arm/mach-bcm2708/include/mach/memory.h). >> >> Signed-off-by: Eric Anholt >> Cc: popcornmix@gmail.com >> --- >> arch/arm/boot/dts/bcm2835.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.= dtsi >> index 5734650..2df1b5c 100644 >> --- a/arch/arm/boot/dts/bcm2835.dtsi >> +++ b/arch/arm/boot/dts/bcm2835.dtsi >> @@ -15,6 +15,7 @@ >> #address-cells =3D <1>; >> #size-cells =3D <1>; >> ranges =3D <0x7e000000 0x20000000 0x02000000>; >> + dma-ranges =3D <0x40000000 0x00000000 0x1f000000>; >>=20=20=20 >> timer@7e003000 { >> compatible =3D "brcm,bcm2835-system-timer"; > > This was quite a coincidence. I discovered the need for 'dma-ranges' > yesterday while trying to get the downstream bcm2708_fb driver to > work with ARCH_BCM2835. The driver is using the mailbox to get info > about the framebuffer from the firmware. When it failed I discovered > that the bus address was wrong. > > What I don't understand, is that mmc and spi works fine with a "wrong" > bus address. It's only the framebuffer driver and the vchiq driver > when using mailbox that fails. > > Tested-by: Noralf Tr=C3=B8nnes Yeah, it was the mailbox driver I've been trying to merge, on pi2, that made me get this patch together. I'm suspicious that 0x0 works the same as 0x4 for GPU peripherals (mmc, spi, vc4) on pi1, though I've had occasional instability (something like 3 events per ~5000 tests) that I sure hope is due to this. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJVSAm6AAoJELXWKTbR/J7opTYP+gPfawBgzvNXVNqvzBW63UbH R4Ww9jio3iI1QMDppRez1GTCq6QvBzchUggWKbJmcfJxVpF+ikMA+qin1OQWFggI oNEVHolzKtg116mHxuPRA0ZBdDASeexMO2r9rhCHoGSxGwjz0OPn+se9H5MbkHcF GBFC9pMQ2UI947jSVI0HxZZxQsjiqtf/BQF89uOL3AzJ+cWsJ8IfOGfHr2+XR9MA FyjyoRm1fbrGtxgygf5SK0I+uHeSWpmnTaepw/HmlTHQquUZrUvb0fcS2EYvIFR+ g+Z/4gSVIQsRZFL3w1sSlfmuld/tnxahugVSegY9gpXm3u91fkqhXS6EmY+qsyDw C3iW57r2+dyYfS6srjABYBmmQI2+e8BuclCLVCjuIL+swyx/sK4au/NFpWOB4x8x rAoMcuAAXp+Y21BwzU+yB0be5yTheh3Muwl+J7lUY6RkJ8qKjABfF9cySuUMIutj XNecWsRE4I1nHbUy8MQAHpkgF/I1XeWmjVCVUfwtAXxgDeQDEl4R3e7LR1hfrBIS C4dkOj93JN0cY0uNNTqWQSYPtg+fBu1s4fOTE3xSfv/KbQdepw/gWZz/Wz1tAVot 2VV5OuENcpMVwRPJHdLak3Y9W3iEkTRrLQMsOaoJACg5fQi5j1rlIoHXe/yKTMoI j4E1QSCpbxuiA8Y/91x7 =iSZZ -----END PGP SIGNATURE----- --=-=-=--