From: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Jerome Glisse <jglisse@redhat.com>,
Alex Deucher <alexdeucher@gmail.com>
Cc: Brian King <brking@linux.vnet.ibm.com>,
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/radeon: Disable writeback by default on ppc
Date: Wed, 04 Dec 2013 20:16:05 -0200 [thread overview]
Message-ID: <529FA9A5.4060706@linux.vnet.ibm.com> (raw)
In-Reply-To: <5293E73E.8050704@linux.vnet.ibm.com>
On 11/25/2013 10:11 PM, Kleber Sacilotto de Souza wrote:
> On 11/24/2013 09:15 PM, Benjamin Herrenschmidt wrote:
>> On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
>>> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
>>>> On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
>>>>
>>>>> Weird. I wonder if there is an issue with cache snoops on PPC. We
>>>>> currently use the gart in cached mode (GPU snoops CPU cache) with
>>>>> cached pages. I wonder if we need to use uncached pages on PPC.
>>>> There is no such issue and no known bugs with DMA writes on those
>>>> PCIe host bridges (and they do get hammered pretty bad here).
>>>>
>>>> This needs further investigation by the lab/hw guys to find out what's
>>>> actually happening on the bus and the host bridge.
>>>>
>>>> Thadeu, Kleber: Jerome suggested writing a test case in userspace that
>>>> continuously writes to a spare scratch register (thus triggering the
>>>> corresponding writeback DMA) and checks the memory location to compare
>>>> the writeback value (using a debugfs file for example, or mmap).
I was not able to reproduce the issue with this method, even after a
weekend run.
However, doing some more investigation it seems the problem is here,
where we read the ring rptr:
u32 radeon_ring_generic_get_rptr(struct radeon_device *rdev,
struct radeon_ring *ring)
{
u32 rptr;
if (rdev->wb.enabled)
rptr = le32_to_cpu(rdev->wb.wb[ring->rptr_offs/4]);
else
rptr = RREG32(ring->rptr_reg);
return rptr;
}
I realized that the DMA'ed rptr value has always the opposite byte order
from the MMIO value. Since RREG32 already returns the register value on
the CPU byte order, it seems we don't need to byte-swap the DMA'ed
value. If I remove the le32_to_cpu() call and use the DMA'ed value
directly, I don't get the IB scheduling failures and piglit results are
the same as with writeback disabled.
Is the adapter chipset swapping the bytes before doing the DMA to a
big-endian host?
--
Kleber Sacilotto de Souza
IBM Linux Technology Center
next prev parent reply other threads:[~2013-12-04 22:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 14:06 [PATCH] drm/radeon: Disable writeback by default on ppc Adam Jackson
2013-06-17 15:04 ` Alex Deucher
2013-06-17 16:07 ` Adam Jackson
2013-06-17 22:57 ` Alex Deucher
2013-11-07 22:29 ` Benjamin Herrenschmidt
2013-11-08 13:43 ` Kleber Sacilotto de Souza
2013-11-24 23:15 ` Benjamin Herrenschmidt
2013-11-26 0:11 ` Kleber Sacilotto de Souza
2013-12-04 22:16 ` Kleber Sacilotto de Souza [this message]
2013-12-04 23:56 ` Alex Deucher
2013-12-05 0:05 ` Alex Deucher
2013-12-05 1:39 ` Benjamin Herrenschmidt
2013-12-05 2:29 ` Michel Dänzer
2013-12-05 4:06 ` Benjamin Herrenschmidt
2013-12-05 14:42 ` Alex Deucher
2013-12-06 13:58 ` Kleber Sacilotto de Souza
2013-12-06 15:59 ` Alex Deucher
2013-12-10 0:48 ` Alex Deucher
2013-12-10 2:20 ` Michel Dänzer
2013-12-10 15:04 ` Alex Deucher
2013-12-10 15:12 ` Alex Deucher
2014-01-02 20:54 ` Kleber Sacilotto de Souza
2014-01-02 22:48 ` Alex Deucher
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=529FA9A5.4060706@linux.vnet.ibm.com \
--to=klebers@linux.vnet.ibm.com \
--cc=alexdeucher@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=brking@linux.vnet.ibm.com \
--cc=cascardo@linux.vnet.ibm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jglisse@redhat.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 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.