[PATCH] drm/radeon: Disable writeback by default on ppc

Alex Deucher alexdeucher at gmail.com
Thu Dec 5 06:42:07 PST 2013


On Wed, Dec 4, 2013 at 11:06 PM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> On Thu, 2013-12-05 at 11:29 +0900, Michel Dänzer wrote:
>> On Don, 2013-12-05 at 12:39 +1100, Benjamin Herrenschmidt wrote:
>> > On Wed, 2013-12-04 at 19:05 -0500, Alex Deucher wrote:
>> >
>> > > > Setting CP_RB_CNTL.BUF_SWAP causes the CP to use the selected byte
>> > > > swapping for just about everything accessed by the CP (rptr writeback,
>> > > > indirect buffers, etc.).  Looks like the DMA ring supports and enables
>> > > > rptr writeback as well (DMA_RB_CNTL.DMA_RPTR_WRITEBACK_SWAP_ENABLE) so
>> > > > I think we can drop the swapping of the rptr writeback.
>> > > >
>> > >
>> > > Obvious patch attached.
>> >
>> > This works all the way back to r300 ?
>>
>> I don't think so, as I have writeback working without this patch on the
>> RV350 in this PowerBook. So I think this function needs to be split,
>> probably between R600 and older.
>
> Or can we tell it to not swap (setup code) and continue doing
> le32_to_cpu in the kernel ? Sounds better to me.
>
>> Also, there's more code at least potentially affected by this, e.g. in:
>>
>>       * cik_compute_ring_get_rptr(), cik_compute_ring_get_wptr(),
>>         cik_compute_ring_set_wptr(), cik_get_ih_wptr()
>>       * si_get_ih_wptr()
>>       * evergreen_get_ih_wptr()
>>       * r600_get_ih_wptr()
>>       * radeon_fence_write(), radeon_fence_read()
>>       * radeon_ring_backup()
>
> Yeah I'd say just don't swap, write LE to memory and let the kernel use
> the right leXX_to_cpu.
>
> HW swapping is evil :-)

Well, we'd need to start swapping indirect buffers and the ring as
well then which would get tricky as the CP at least does not have
separate swapping controls for different things.  Probably easier to
fix up as appropriate for different asic families.  We have function
pointers for the rtpr and wptr fetchers now, so we can do this pretty
cleanly.

Alex

>
> Cheers,
> Ben.
>
>


More information about the dri-devel mailing list