Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Am 11.05.20 um 22:24 schrieb John Paul Adrian Glaubitz: > On 5/11/20 10:12 PM, Christian König wrote: >> I unfortunately only have an x86 Mac to test this on, but as far as I know >> the Radeon >> AGP support for PowerPC is disabled for years already because it didn't >> worked reliable. > > I have a current Debian unstable running on an iBook G4 with Radeon graphics > enabled > on a current kernel and graphics stack and it runs fine. Not sure though > whether > it currently employs all AGP features, but I would like to be able to continue > using it and so are the users on the debian-powerpc mailing list. I didn't have much luck with agp_uninorth and radeon DRM on my MacMini G4 (2xx) with current Debian unstable (yet have to send an installation report, sorry!). The X server didn't even come up with AGP enabled. The only thing that works is, if the radeon driver is forced to use PCIGART, which was even the default after install, if I remember correctly. Problem is that graphics acceleration over PCI is very, very slow... :-( So the idea here is to just go ahead and remove the support from Radeon and Nouveau and then drop the necessary code from TTM. For Radeon this means that we just switch over to the driver specific page tables and everything should more or less continue to work. For Nouveau I'm not 100% sure, but from the code it of hand looks like we can do it similar to Radeon. Please comment what you think about this. >>> I would be against such a move as AGP graphics is still used by people >>> running the powerpc >>> and ppc64 Debian ports on their vintage hardware [1]. >> >> Please note that at least the Mac I was able to test with Radeon hardware >> just continuous >> to work. But it is certainly possible that some pre r3xx generation hardware >> will break with this. >> >> We just stop using this bogus idea of trying to use uncached system memory >> as "extension" of the >> on board video memory and instead switch to the reliable device internal >> GART. > > Well, the title "Remove AGP support" in the subject implied something else to > me which > is why I wrote this mail. If this just applies to the mechanism to allow > system memory > to be used as graphics memory, the results may be different. I was also following the discussion about AGP some time ago on the PowerPC Linux mailing list and honestly also understood it in the way that AGP would be entirely removed. :-) But I guess what is planned is to use the radeon/TTM drivers PCIGART functionality while preserving the setup of the fast AGP transfer modes (maybe by using a static AGPGART, if necessary?). Is that what Linux developers have in mind with "Remove AGP support"? >> Maybe we should just deprecate the configuration option first? > > Would this change imply the removal of CONFIG_AGP_*? If yes, I assume that > would > kill CONFIG_AGP_UNINORTH which we have enabled on our PowerPC kernels for > powerpc > and ppc64. > > Adrian > Gerhard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
Am 09.04.20 um 10:54 schrieb Benjamin Herrenschmidt:
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
>> On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
>>> If this code was broken for non-coherent caches a crude powerpc hack
>>> isn't going to help anyone else. Remove the hack as it is the last
>>> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
>>
>> Well Ben added this to make stuff work on ppc, ofc the home grown dma
>> layer in drm from back then isn't going to work in other places. I guess
>> should have at least an ack from him, in case anyone still cares about
>> this on ppc. Adding Ben to cc.
>
> This was due to some drivers (radeon ?) trying to use vmalloc pages for
> coherent DMA, which means on those 4xx powerpc's need to be non-cached.
>
> There were machines using that (440 based iirc), though I honestly
> can't tell if anybody still uses any of it.
The first-gen amigaone platform (6xx/book32s) uses the radeon driver
together with non-coherent DMA. However this only ever worked reliably
for DRI1.
br,
Gerhard
> Cheers,
> Ben.
>
>> -Daniel
>>
>>>
>>> Signed-off-by: Christoph Hellwig
>>> ---
>>> drivers/gpu/drm/drm_scatter.c | 11 +--
>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
>>> index ca520028b2cb..f4e6184d1877 100644
>>> --- a/drivers/gpu/drm/drm_scatter.c
>>> +++ b/drivers/gpu/drm/drm_scatter.c
>>> @@ -43,15 +43,6 @@
>>>
>>> #define DEBUG_SCATTER 0
>>>
>>> -static inline void *drm_vmalloc_dma(unsigned long size)
>>> -{
>>> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
>>> - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
>>> -#else
>>> - return vmalloc_32(size);
>>> -#endif
>>> -}
>>> -
>>> static void drm_sg_cleanup(struct drm_sg_mem * entry)
>>> {
>>> struct page *page;
>>> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void
>>> *data,
>>> return -ENOMEM;
>>> }
>>>
>>> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
>>> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
>>> if (!entry->virtual) {
>>> kfree(entry->busaddr);
>>> kfree(entry->pagelist);
>>> --
>>> 2.25.1
>>>
>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
