lkml.org 
[lkml]   [2020]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
From
Date
Hi!

On 6/2/20 1:04 PM, Geert Uytterhoeven wrote:
>> What do you mean with the sentence "when arch/ppc/ was still king"?
>
> Ah, Bartl copied that from my email ;-)
>
> There used to be APUS support under arch/ppc/.
> Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\
> architecture port under arch/powerpc/, and the old ones were dropped.
> APUS was never converted, and thus dropped.

Ah, yes. Similar to the merge with x86.

>> Does that mean - in the case we would re-add APUS support in the future, that
>> these particular changes would not be necessary?
>
> They would still be necessary, as PowerPC doesn't grok m68k instructions.
> Alternatively, we could just drop the m68k inline asm, and retain the C
> version instead? I have no idea how big of a difference that would make
> on m68k, using a more modern compiler than when the code was written
> originally.

Hmm, no idea. I would keep the assembly for the time being. This was just
a question out of curiosity. We could still consider such a change if
someone should consider working on APUS support again.

> Note that all of this is used only for cursor handling, which I doubt is
> actually used by any user space application. The only exception is the
> DIVUL() macro, which is used once during initialization, thus also not
> performance critical.
I see, thanks.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

\
 
 \ /
  Last update: 2020-06-02 13:08    [W:0.042 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site