mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wens@csie.org>
To: Maxime Ripard <maxime.ripard@free-electrons.com>,
	David Airlie <airlied@linux.ie>
Cc: Chen-Yu Tsai <wens@csie.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-sunxi@googlegroups.com
Subject: [PATCH v2 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address
Date: Tue, 17 Oct 2017 12:23:47 +0800	[thread overview]
Message-ID: <20171017042349.31743-6-wens@csie.org> (raw)
In-Reply-To: <20171017042349.31743-1-wens@csie.org>

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).

This issue was witnessed on the Cubietruck, which has 2GB of RAM.

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.

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.

Correct the address configured into the backend layer registers
by PHYS_OFFSET to account for this.

Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 4fefd8add714..d18d7e88d511 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -216,6 +216,13 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
 	paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
 	DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
 
+	/*
+	 * backend DMA accesses DRAM directly, bypassing the system
+	 * bus. As such, the address range is different and the buffer
+	 * address needs to be corrected.
+	 */
+	paddr -= PHYS_OFFSET;
+
 	/* Write the 32 lower bits of the address (in bits) */
 	lo_paddr = paddr << 3;
 	DRM_DEBUG_DRIVER("Setting address lower bits to 0x%x\n", lo_paddr);
-- 
2.14.2

  parent reply	other threads:[~2017-10-17  4:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-17  4:23 [PATCH 0/7] drm/sun4i: More cleanups Chen-Yu Tsai
2017-10-17  4:23 ` [PATCH v2 1/7] drm/sun4i: don't add components that are already in the queue Chen-Yu Tsai
2017-10-17  4:23 ` [PATCH v2 2/7] drm/sun4i: backend: Create regmap after access is possible Chen-Yu Tsai
2017-10-17  4:23 ` [PATCH v2 3/7] drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory Chen-Yu Tsai
2017-10-17  4:23 ` [PATCH v2 4/7] drm/sun4i: backend: Add comment explaining why registers are cleared Chen-Yu Tsai
2017-10-17  4:23 ` Chen-Yu Tsai [this message]
2017-10-17 14:26   ` [PATCH v2 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address Maxime Ripard
2017-10-17  4:23 ` [PATCH v2 6/7] drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits Chen-Yu Tsai
2017-10-17  4:23 ` [PATCH v2 7/7] drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function Chen-Yu Tsai
2017-10-17  4:25 ` [PATCH 0/7] drm/sun4i: More cleanups Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171017042349.31743-6-wens@csie.org \
    --to=wens@csie.org \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®