From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757266AbdJPUQA (ORCPT ); Mon, 16 Oct 2017 16:16:00 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:38346 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757231AbdJPUPv (ORCPT ); Mon, 16 Oct 2017 16:15:51 -0400 Date: Mon, 16 Oct 2017 22:15:47 +0200 From: Maxime Ripard To: Chen-Yu Tsai Cc: David Airlie , dri-devel , linux-kernel , linux-sunxi Subject: Re: [linux-sunxi] Re: [PATCH 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address Message-ID: <20171016201547.xx3r4mibhzchu2fk@flea.home> References: <20171014040252.9621-1-wens@csie.org> <20171014040252.9621-6-wens@csie.org> <20171016080043.xqpcxj7xfckcxdem@flea.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cilqbw6aznkc5cuo" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171013 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cilqbw6aznkc5cuo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 16, 2017 at 04:20:32PM +0800, Chen-Yu Tsai wrote: > > On Sat, Oct 14, 2017 at 12:02:50PM +0800, Chen-Yu Tsai wrote: > >> The display backend, as well as other peripherals that have a DRAM > >> clock gate and access DRAM directly, bypassing the system bus, > >> address the DRAM starting from 0x0, while physical addresses the > >> system uses starts from 0x40000000 (or 0x20000000 in A80's case). > >> > >> Correct the address configured into the backend layer registers > >> by PHYS_OFFSET to account for this. > > > > However, I'm a bit confused at this. > > > > The driver has been working so far, which it wouldn't have been able > > to if the address was wrong. How was this problem noticed, and how can > > that fix not be an issue in itself? >=20 > This problem was witnessed on the Cubietruck, which has 2GB of RAM. >=20 > I believe devices with less RAM function normally due to the DRAM > address wrapping around. CMA seems to always allocate its buffer > at a very high address, close to the end of DRAM. On a 1GB RAM > device, the physical address would be something like 0x78000000. > The DRAM address 0x78000000 would access the same DRAM region as > 0x38000000 on a system, as the DRAM address would only span 0x0 ~ > 0x3fffffff. The bit 0x40000000 is non-functional in this case. >=20 > However on the Cubietruck, the DRAM is 2GB. The physical address > is 0x40000000 ~ 0xbfffffff. The buffer would be something like > 0xb8000000. But the DRAM address span 0x0 ~ 0x7fffffff, meaning > the buffer address wraps around to 0x38000000, which is wrong. > The correct DRAM address for it should be 0x78000000. That looks great. Can you put that in the commit log? Thanks! Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --cilqbw6aznkc5cuo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZ5RNzAAoJEBx+YmzsjxAgJhMP/AmZKZuUWumtW/fgGJUvT0T9 /OmbP8qIOuaad9gZGiQgWYi+daMp+yR7+ZmpYwu+lZT/sgL57ZVFGUZdMhsYDesI 5sh2aGA+D9/4Nh1o51PwOqVkcXYscOAaW7Tbo8xBsuZ2u1yEFTU1od3ZdKTVWRzq hKIHEam7qOySIT9/B8/hH/tWpdKYTH2pK42mJqioest2P/ZhOOXgy7yuiip53Pu7 fA2M608/124qLrYj/O0hTj5rNBg2uKaa9wxSuM8QmJ5L+hvHegRvyVHCa/wGMsed 0kZrrtrp0ccPZzSDIWHQUj9cuipwtTrcw4SVBzS7lw374cqAeB47R1qgBBCMSYnA ee+wvBi7wqH0wuipHZag2kyGWZWUSLF5M5qSsDY4vrzn8+W8zyQpzp8woOZVA+Vh n4TxMvzkeP3mRYsU92urWA84GrIjPdae+CyrTvTrZJWTNYMndQr27T6yXy8rJhv3 I7BYIuyJRa8/mqP1CNtfq8bTAac20Ao5RvhnY5m+Oliluy7zO2rjtHC2OVIcZhaZ R8vOAlkkHwc3X52cOe8W1z83fR/lAhHwX/y1xSXv8W6R/QkBLd1jsRC464ttomJb VD1vZQhaOyIsraeP/Z903FZ30vidWOa/IRI9o6gjutK0+M653vbllGUmTgcI9vEx 7W63mrBfr9YW8xQ4LkAe =FBbk -----END PGP SIGNATURE----- --cilqbw6aznkc5cuo--