From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754337AbbEMRlz (ORCPT ); Wed, 13 May 2015 13:41:55 -0400 Received: from gabe.freedesktop.org ([131.252.210.177]:43418 "EHLO gabe.freedesktop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751648AbbEMRly (ORCPT ); Wed, 13 May 2015 13:41:54 -0400 From: Eric Anholt To: Lee Jones Cc: Stephen Warren , linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, popcornmix@gmail.com Subject: Re: [PATCH] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM. In-Reply-To: <20150513085119.GD3394@x1> References: <1430768034-12734-1-git-send-email-eric@anholt.net> <55491A12.3070608@wwwdotorg.org> <87wq0mol7e.fsf@eliezer.anholt.net> <20150513085119.GD3394@x1> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 13 May 2015 10:41:50 -0700 Message-ID: <87zj584boh.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 Content-Transfer-Encoding: quoted-printable Lee Jones writes: > On Tue, 05 May 2015, Eric Anholt wrote: > >> Stephen Warren writes: >>=20 >> > On 05/04/2015 01:33 PM, Eric Anholt wrote: >> >> 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 cohere= nt >> >> 0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coh= erent >> >> >> >> 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 cohe= rent >> >> 0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coh= erent >> >> >> >> 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). >> > >> >> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm28= 35.dtsi >> > >> >> #address-cells =3D <1>; >> >> #size-cells =3D <1>; >> >> ranges =3D <0x7e000000 0x20000000 0x02000000>; >> >> + dma-ranges =3D <0x40000000 0x00000000 0x1f000000>; >> > >> > Oh well that's a nice and simple patch; I had been avoiding looking in= to=20 >> > fixing the kernel for this since I was worried it'd be rather complex! >> > >> > I'm puzzled why the length cell of ranges and dma-ranges differs thoug= h?=20 >> > Assuming there's a good explanation for that, >>=20 >> Nope, you're right, it should be 0x20000000. '0x1f' came from going >> back from the '0x3f' on the pi2, but pi2 just has a chunk lost to the >> bus mapping. > > So are you going to fix this and send another patch? I see it having hit the list: http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-May/001699.html but I'm missing both versions in my inbox, so I'm not sure what happened. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJVU4zeAAoJELXWKTbR/J7oqgoP/jmmlvp8K326xAeWyXqZH6rO qu5OhR4IIp1dMTYlSWW00kHW6U7SPHAiopZYaMQPTs62KSrh7mJuYDrhBpHgyn6F Ng4KL7jXcIUzIPrjGX5s4+I2AfiF4qmo6cSOLeFkKpDxi/YdHvNVu+ufLB+k+Lyt +WnExdCAYfVGp0f0eQsI6MkrpYPVeX9IOnqfGQDsqxb4IqhXfQEMBBIsHeSuBdsm YpoSrGCEYevE6pf95Lpz6bW7TG7yO28D8hJKr1nFNsILoW2A3bmMOR2JH1wc/kaY Ik0jFsScoQ7/bwE1tJvUrV2ziDOG09uvSHWwcpTl9izEVcPjebIV/RRFKAEt5JIF RN8jD7fo4sTAVUthuHKC+s3I24vEZAUxUcnNuS7B+hSUD/sFzpTLM9Ad8biQi6c5 FFzxbnTlE6AG6WPYMcKmu7qI98Flz/X9PWbrXgQuQuo3LGDsxFgrqYKagFp+G1Ia Gdw25jjZPfi1NN0UX7uVGBDeEMrLKUApbwnqTxjukCbIgasYrgLc9Nnvs/AdAoPl ZGBMl7jfbxM1I0M0bWQWEGSghOUHMKm4TvYpTNbpp1SyCv8Q2qc2n3nKRkqYFoXJ sHJ5LUf3T8TxXYQxzsBsJOtrto5RScr6k3co39p7Bmx5KSGwSJYMdGj9kf1dXAZT qXxjB5syE8lulfU5xsn9 =xmZL -----END PGP SIGNATURE----- --=-=-=--