From: Rui Salvaterra <rsalvaterra@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Michel Dänzer" <michel@daenzer.net>,
"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
"debian-powerpc@lists.debian.org"
<debian-powerpc@lists.debian.org>,
"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>,
"Karoly Balogh (Charlie/SGR)" <charlie@scenergy.dfmk.hu>
Subject: Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Date: Wed, 13 May 2020 10:28:54 +0100 [thread overview]
Message-ID: <CALjTZvZNb-KbdZwM3kLU4yK8zH+NSh35k=iBtfGJMF1xyjpSFg@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uHv_Hj8BB8t_i=EXx1C4WXw1PnmxuTyNfrA=b5eQMaSLg@mail.gmail.com>
On Wed, 13 May 2020 at 08:19, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> i915 is even worse, we manually mess around with clflush. In
> userspace. So really there's 2 axis for dma memory: coherent vs.
> non-coherent (which is something the dma-api somewhat exposed), i.e.
> do you need to clflush or not, and cached vs uncached, i.e. are the
> PAT entries wc or wb.
So, the PowerPC AGP GART ends up being cached and non-coherent, right
(assuming there's no way to set the page attributes MTRR/PAT-style)?
Would something like a fixed memory carve-out help in these cases
(like CMA, but not allowing the CPU to access the reserved area)? Not
that I expect something like that to ever be implemented, of course,
just curious to understand the requirements.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-05-15 6:53 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 19:55 [RFC] Remove AGP support from Radeon/Nouveau/TTM John Paul Adrian Glaubitz
2020-05-11 20:05 ` Alex Deucher
2020-05-11 20:25 ` Rui Salvaterra
2020-05-11 20:51 ` Alex Deucher
2020-05-12 7:57 ` Michel Dänzer
2020-05-12 9:21 ` Rui Salvaterra
2020-05-12 9:40 ` Karoly Balogh (Charlie/SGR)
2020-05-12 13:22 ` Alex Deucher
2020-05-12 16:37 ` Daniel Vetter
2020-05-12 17:02 ` Rui Salvaterra
2020-05-12 18:21 ` Alex Deucher
2020-05-12 20:12 ` Dave Airlie
2020-05-13 7:26 ` Christian König
2020-05-12 18:22 ` Alex Deucher
2020-05-13 7:19 ` Daniel Vetter
2020-05-13 7:55 ` Christian König
2020-05-13 10:25 ` Daniel Vetter
2020-05-13 9:28 ` Rui Salvaterra [this message]
2020-05-13 10:26 ` Michel Dänzer
2020-05-13 10:29 ` Daniel Vetter
2020-05-13 10:32 ` Michel Dänzer
2020-05-13 10:39 ` Rui Salvaterra
2020-05-13 10:57 ` Michel Dänzer
2020-05-13 11:07 ` Rui Salvaterra
2020-05-13 13:44 ` Christian Zigotzky
2020-05-13 14:01 ` John Paul Adrian Glaubitz
2020-05-13 14:01 ` Rui Salvaterra
2020-05-13 20:19 ` Bertrand Dekoninck
2020-05-13 20:36 ` Rui Salvaterra
2020-05-11 20:41 ` John Paul Adrian Glaubitz
2020-05-11 20:46 ` Alex Deucher
2020-05-11 21:50 ` John Paul Adrian Glaubitz
2020-05-12 7:43 ` Christian König
2020-05-11 20:12 ` Christian König
2020-05-11 20:24 ` John Paul Adrian Glaubitz
2020-05-11 20:48 ` Gerhard Pircher
2020-05-12 5:04 ` David VANTYGHEM
2020-05-12 9:20 ` John Paul Adrian Glaubitz
-- strict thread matches above, loose matches on Subject: below --
2020-05-11 17:17 Christian König
2020-05-11 17:17 ` Christian König
2020-05-11 17:17 ` Christian König
[not found] ` <20200511171722.96576-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2020-05-11 20:14 ` Al Dunsmuir
2020-05-11 20:14 ` Al Dunsmuir
2020-05-11 20:14 ` Al Dunsmuir
[not found] ` <1815605280.20200511161440-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
2020-05-11 20:27 ` Alex Deucher
2020-05-11 20:27 ` Alex Deucher
2020-05-11 20:27 ` Alex Deucher
[not found] ` <CADnq5_MYPcAoWzCcBkJAkd858gCVbJpCJobiwH_BBbwgEdx5rA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-11 20:43 ` Dave Airlie
2020-05-11 20:43 ` Dave Airlie
2020-05-11 20:43 ` Dave Airlie
[not found] ` <CAPM=9tysbcgQ-KR8+icQ=3e6+SECxkwHdVpP8=w0Pmh9ML_+Lw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-11 20:56 ` Al Dunsmuir
2020-05-11 20:56 ` Al Dunsmuir
2020-05-11 20:56 ` Al Dunsmuir
[not found] ` <1266714942.20200511165648-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
2020-05-12 8:11 ` Christian König
2020-05-12 8:11 ` Christian König
2020-05-12 8:11 ` Christian König
2020-05-11 20:59 ` Emil Velikov
2020-05-11 20:59 ` Emil Velikov
2020-05-11 20:59 ` Emil Velikov
2020-05-11 20:46 ` Al Dunsmuir
2020-05-11 20:46 ` Al Dunsmuir
2020-05-11 20:46 ` Al Dunsmuir
2020-05-13 11:00 ` Thomas Zimmermann
2020-05-12 18:29 ` [Nouveau] " Thomas Zimmermann
2020-05-12 18:32 ` Alex Deucher
2020-05-12 19:10 ` Thomas Zimmermann
2020-05-12 19:47 ` Alex Deucher
[not found] ` <CADnq5_P6sWt=0zkRm6ySmOb1zr-7VTwLwx+ecEKg-ntJTRfY5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-13 9:27 ` Emil Velikov
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='CALjTZvZNb-KbdZwM3kLU4yK8zH+NSh35k=iBtfGJMF1xyjpSFg@mail.gmail.com' \
--to=rsalvaterra@gmail.com \
--cc=charlie@scenergy.dfmk.hu \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel@ffwll.ch \
--cc=debian-powerpc@lists.debian.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=michel@daenzer.net \
/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.