From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
Date: Tue, 2 Jun 2020 13:07:33 +0200 [thread overview]
Message-ID: <6d17452e-29ee-76dd-759c-b39d87bb82b8@physik.fu-berlin.de> (raw)
In-Reply-To: <CAMuHMdXUD4PNndjtxz84pYMdXaM68g7vWiRd+Gf18a35T-oA=Q@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
Date: Tue, 02 Jun 2020 11:07:33 +0000 [thread overview]
Message-ID: <6d17452e-29ee-76dd-759c-b39d87bb82b8@physik.fu-berlin.de> (raw)
In-Reply-To: <CAMuHMdXUD4PNndjtxz84pYMdXaM68g7vWiRd+Gf18a35T-oA=Q@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
Date: Tue, 2 Jun 2020 13:07:33 +0200 [thread overview]
Message-ID: <6d17452e-29ee-76dd-759c-b39d87bb82b8@physik.fu-berlin.de> (raw)
In-Reply-To: <CAMuHMdXUD4PNndjtxz84pYMdXaM68g7vWiRd+Gf18a35T-oA=Q@mail.gmail.com>
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-06-02 11:07 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200504232908eucas1p296927bc7c736ad924cefaea9a546459d@eucas1p2.samsung.com>
2020-05-04 23:29 ` [trivial PATCH] video: fbdev: Use IS_BUILTIN Joe Perches
2020-05-04 23:29 ` Joe Perches
2020-05-04 23:29 ` Joe Perches
2020-05-04 23:29 ` Joe Perches
2020-06-01 13:25 ` Bartlomiej Zolnierkiewicz
2020-06-01 13:25 ` Bartlomiej Zolnierkiewicz
2020-06-01 13:25 ` Bartlomiej Zolnierkiewicz
2020-06-01 13:25 ` Bartlomiej Zolnierkiewicz
2020-06-02 10:37 ` [PATCH 1/2] video: fbdev: amifb: remove dead APUS support Bartlomiej Zolnierkiewicz
2020-06-02 10:37 ` Bartlomiej Zolnierkiewicz
2020-06-02 10:37 ` Bartlomiej Zolnierkiewicz
2020-06-02 10:41 ` John Paul Adrian Glaubitz
2020-06-02 10:41 ` John Paul Adrian Glaubitz
2020-06-02 10:41 ` John Paul Adrian Glaubitz
2020-06-02 11:04 ` Geert Uytterhoeven
2020-06-02 11:04 ` Geert Uytterhoeven
2020-06-02 11:04 ` Geert Uytterhoeven
2020-06-02 11:07 ` John Paul Adrian Glaubitz [this message]
2020-06-02 11:07 ` John Paul Adrian Glaubitz
2020-06-02 11:07 ` John Paul Adrian Glaubitz
2020-06-02 11:27 ` Bartlomiej Zolnierkiewicz
2020-06-02 11:27 ` Bartlomiej Zolnierkiewicz
2020-06-02 11:27 ` Bartlomiej Zolnierkiewicz
2020-06-15 20:35 ` Emil Velikov
2020-06-15 20:35 ` Emil Velikov
2020-06-15 20:35 ` Emil Velikov
2020-06-15 21:26 ` Geert Uytterhoeven
2020-06-15 21:26 ` Geert Uytterhoeven
2020-06-15 21:26 ` Geert Uytterhoeven
2020-06-02 10:38 ` [PATCH 2/2] video: fbdev: amifb: add FIXMEs about {put,get}_user() failures Bartlomiej Zolnierkiewicz
2020-06-02 10:38 ` Bartlomiej Zolnierkiewicz
2020-06-02 10:38 ` Bartlomiej Zolnierkiewicz
2020-06-02 11:50 ` [PATCH v2 1/2] video: fbdev: amifb: add FIXME about dead APUS support Bartlomiej Zolnierkiewicz
2020-06-02 11:50 ` Bartlomiej Zolnierkiewicz
2020-06-02 11:50 ` Bartlomiej Zolnierkiewicz
2020-06-02 12:03 ` Geert Uytterhoeven
2020-06-02 12:03 ` Geert Uytterhoeven
2020-06-02 12:03 ` Geert Uytterhoeven
2020-06-02 16:12 ` Al Viro
2020-06-02 16:12 ` Al Viro
2020-06-02 16:12 ` Al Viro
2020-06-03 0:20 ` Finn Thain
2020-06-03 0:20 ` Finn Thain
2020-06-03 0:20 ` Finn Thain
2020-07-10 14:23 ` Bartlomiej Zolnierkiewicz
2020-07-10 14:23 ` Bartlomiej Zolnierkiewicz
2020-07-10 14:23 ` Bartlomiej Zolnierkiewicz
2020-06-02 11:52 ` [PATCH v2 2/2] video: fbdev: amifb: add FIXMEs about {put,get}_user() failures Bartlomiej Zolnierkiewicz
2020-06-02 11:52 ` Bartlomiej Zolnierkiewicz
2020-06-02 11:52 ` Bartlomiej Zolnierkiewicz
2020-06-02 12:03 ` Geert Uytterhoeven
2020-06-02 12:03 ` Geert Uytterhoeven
2020-06-02 12:03 ` Geert Uytterhoeven
2020-07-10 14:23 ` Bartlomiej Zolnierkiewicz
2020-07-10 14:23 ` Bartlomiej Zolnierkiewicz
2020-07-10 14:23 ` Bartlomiej Zolnierkiewicz
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=6d17452e-29ee-76dd-759c-b39d87bb82b8@physik.fu-berlin.de \
--to=glaubitz@physik.fu-berlin.de \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=viro@zeniv.linux.org.uk \
/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.