From: Alexey.Brodkin@synopsys.com (Alexey Brodkin)
To: linux-snps-arc@lists.infradead.org
Subject: etnaviv: PHYS_OFFSET usage
Date: Tue, 5 Dec 2017 09:32:23 +0000 [thread overview]
Message-ID: <1512466342.4977.77.camel@synopsys.com> (raw)
In-Reply-To: <1510768580.2835.15.camel@pengutronix.de>
Hi Lucas,
On Wed, 2017-11-15@18:56 +0100, Lucas Stach wrote:
> Am Mittwoch, den 15.11.2017, 17:36 +0000 schrieb Alexey Brodkin:
[snip]
> I'm not keen on having a private memory region for the GPU. Normally we
> just use the shared system CMA memory region (and we will point the
> linear memory window there on MC2.0 GPUs), which has the added benefit
> that we can map the contiguous framebuffers allocated by another device
> through the linear window, which is a crucial performance optimization
> for the MMUv1 GPUs.
>
> The only time where we really need to know the start of RAM is on MC1.0
> GPUs which have a hardware bug in the TS unit, so we try to avoid
> moving the linear window at all to work around that. In that case the
> PHYS_OFFSET check is really there to avoid the situation where the
> linear window would not allow any RAM to be reached at all. Then we
> need to move the window, but disable any TS functionality, impacting
> performance a lot.
Thanks a lot fro explanation!
> As MC1.0 GPUs are hopefully on the way out with new designs using MC2.0
> this shouldn't be much of a problem going forward. Maybe we can even
> simply solve this issue by just dropping the check if PHYS_OFFSET isn't
> defined.
I guess something like that should work then:
-------------------------------->8--------------------------------
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fc9a6a83dfc7..5ad191a605e2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -678,6 +678,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
????????????????goto fail;
????????}
?
+#ifdef PHYS_OFFSET
????????/*
?????????* Set the GPU linear window to be at the end of the DMA window, where
?????????* the CMA area is likely to reside. This ensures that we are able to
@@ -699,6 +700,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
????????????????gpu->memory_base = PHYS_OFFSET;
????????????????gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
????????}
+#endif
?
????????ret = etnaviv_hw_reset(gpu);
????????if (ret) {
-------------------------------->8--------------------------------
> At least I hope VeriSilicon didn't sell you a MC1.0 part at
> this time...
Given "chipMinorFeatures0_MC20" bit is set for us I would think that we
indeed have MC2.0 in our chip.
-Alexey
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "l.stach@pengutronix.de" <l.stach@pengutronix.de>
Cc: "christian.gmeiner@gmail.com" <christian.gmeiner@gmail.com>,
"Vineet.Gupta1@synopsys.com" <Vineet.Gupta1@synopsys.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>
Subject: Re: etnaviv: PHYS_OFFSET usage
Date: Tue, 5 Dec 2017 09:32:23 +0000 [thread overview]
Message-ID: <1512466342.4977.77.camel@synopsys.com> (raw)
In-Reply-To: <1510768580.2835.15.camel@pengutronix.de>
Hi Lucas,
On Wed, 2017-11-15 at 18:56 +0100, Lucas Stach wrote:
> Am Mittwoch, den 15.11.2017, 17:36 +0000 schrieb Alexey Brodkin:
[snip]
> I'm not keen on having a private memory region for the GPU. Normally we
> just use the shared system CMA memory region (and we will point the
> linear memory window there on MC2.0 GPUs), which has the added benefit
> that we can map the contiguous framebuffers allocated by another device
> through the linear window, which is a crucial performance optimization
> for the MMUv1 GPUs.
>
> The only time where we really need to know the start of RAM is on MC1.0
> GPUs which have a hardware bug in the TS unit, so we try to avoid
> moving the linear window at all to work around that. In that case the
> PHYS_OFFSET check is really there to avoid the situation where the
> linear window would not allow any RAM to be reached at all. Then we
> need to move the window, but disable any TS functionality, impacting
> performance a lot.
Thanks a lot fro explanation!
> As MC1.0 GPUs are hopefully on the way out with new designs using MC2.0
> this shouldn't be much of a problem going forward. Maybe we can even
> simply solve this issue by just dropping the check if PHYS_OFFSET isn't
> defined.
I guess something like that should work then:
-------------------------------->8--------------------------------
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fc9a6a83dfc7..5ad191a605e2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -678,6 +678,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}
+#ifdef PHYS_OFFSET
/*
* Set the GPU linear window to be at the end of the DMA window, where
* the CMA area is likely to reside. This ensures that we are able to
@@ -699,6 +700,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
gpu->memory_base = PHYS_OFFSET;
gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
}
+#endif
ret = etnaviv_hw_reset(gpu);
if (ret) {
-------------------------------->8--------------------------------
> At least I hope VeriSilicon didn't sell you a MC1.0 part at
> this time...
Given "chipMinorFeatures0_MC20" bit is set for us I would think that we
indeed have MC2.0 in our chip.
-Alexey
next prev parent reply other threads:[~2017-12-05 9:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 16:24 etnaviv: PHYS_OFFSET usage Alexey Brodkin
2017-11-15 16:24 ` Alexey Brodkin
2017-11-15 16:44 ` Lucas Stach
2017-11-15 16:44 ` Lucas Stach
2017-11-15 16:44 ` Lucas Stach
2017-11-15 17:36 ` Alexey Brodkin
2017-11-15 17:36 ` Alexey Brodkin
2017-11-15 17:56 ` Lucas Stach
2017-11-15 17:56 ` Lucas Stach
2017-11-15 17:56 ` Lucas Stach
2017-12-05 9:32 ` Alexey Brodkin [this message]
2017-12-05 9:32 ` Alexey Brodkin
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=1512466342.4977.77.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=linux-snps-arc@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.