From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EADD6C433E0 for ; Tue, 2 Jun 2020 11:04:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF284206A4 for ; Tue, 2 Jun 2020 11:04:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726243AbgFBLEs (ORCPT ); Tue, 2 Jun 2020 07:04:48 -0400 Received: from mail-oo1-f68.google.com ([209.85.161.68]:44234 "EHLO mail-oo1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725802AbgFBLEr (ORCPT ); Tue, 2 Jun 2020 07:04:47 -0400 Received: by mail-oo1-f68.google.com with SMTP id e8so1632751ooi.11; Tue, 02 Jun 2020 04:04:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SnU67PM5tYuOxOQ+ffnEXx7IP/EaDf221A3j8p4Bihs=; b=TZfncMOjIFrBbaZ31JJa1FvBWRjbJUH8oifaOiq7nQowyup+3lWbN2xdrz7AeqUloV PKalo02TpG5AAwmjcWrmPwVj0x0CEUwfPHbpqVwLi3iCcoW/7e3Hb8HcMUieiN0iZTY2 S15uZR43Jw6J8Hc7+D8c+NbB7EqJc9ebsow6TT/ZuWfFfGyR6t4MEW0nh+ZL2Ecsfz1E iEU8lHzAAb4bM80vZpJryLB5GupO9xAX7oT6DjgI1iwYS52ud9hqo8jB7csR/hKmPfSQ PL3wG8fSQrW5DxzugA/LyhmM1eSqs0V20P+mHt1B4Em+RowYW/jhqX0T3F3kZUrIEa3t 9bIg== X-Gm-Message-State: AOAM533YoHfZ5+Iqq7eZAOvlspirNN4zYA88IZz0buk3xLgjgrcN2133 /rSxmEOvzZ/18QVf+wNDY/MiDoV/d5g3TTwpZjc= X-Google-Smtp-Source: ABdhPJx5LJM1BuqsyoFrXnT/JqbG5sPPQGLYtu772FLIRUMwlABs9hqY840TLSR+IxcpPBkOXCjVdX5M39D3Q54TX0I= X-Received: by 2002:a4a:e295:: with SMTP id k21mr20587446oot.11.1591095884883; Tue, 02 Jun 2020 04:04:44 -0700 (PDT) MIME-Version: 1.0 References: <839133dd-8ed4-5fec-c311-ce9f8abf3d5f@samsung.com> <72e0871c-d4bb-4887-4d6f-a60fd905bec1@physik.fu-berlin.de> In-Reply-To: <72e0871c-d4bb-4887-4d6f-a60fd905bec1@physik.fu-berlin.de> From: Geert Uytterhoeven Date: Tue, 2 Jun 2020 13:04:33 +0200 Message-ID: Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support To: John Paul Adrian Glaubitz Cc: Bartlomiej Zolnierkiewicz , Linux Fbdev development list , DRI Development , Linux Kernel Mailing List , linux-m68k , Al Viro Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Adrian, On Tue, Jun 2, 2020 at 12:41 PM John Paul Adrian Glaubitz wrote: > On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote: > >> These #ifdefs are relics from APUS (Amiga Power-Up System), which > >> added a PPC board. APUS support was killed off a long time ago, > >> when arch/ppc/ was still king, but these #ifdefs were missed, because > >> they didn't test for CONFIG_APUS. > > > > Reported-by: Al Viro > > Reported-by: Geert Uytterhoeven > > Signed-off-by: Bartlomiej Zolnierkiewicz > > --- > > drivers/video/fbdev/amifb.c | 63 -------------------------------------------- > > 1 file changed, 63 deletions(-) > > 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. > 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. 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Tue, 02 Jun 2020 11:04:33 +0000 Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support Message-Id: List-Id: References: <839133dd-8ed4-5fec-c311-ce9f8abf3d5f@samsung.com> <72e0871c-d4bb-4887-4d6f-a60fd905bec1@physik.fu-berlin.de> In-Reply-To: <72e0871c-d4bb-4887-4d6f-a60fd905bec1@physik.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: John Paul Adrian Glaubitz Cc: Linux Fbdev development list , Bartlomiej Zolnierkiewicz , Linux Kernel Mailing List , DRI Development , linux-m68k , Al Viro Hi Adrian, On Tue, Jun 2, 2020 at 12:41 PM John Paul Adrian Glaubitz wrote: > On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote: > >> These #ifdefs are relics from APUS (Amiga Power-Up System), which > >> added a PPC board. APUS support was killed off a long time ago, > >> when arch/ppc/ was still king, but these #ifdefs were missed, because > >> they didn't test for CONFIG_APUS. > > > > Reported-by: Al Viro > > Reported-by: Geert Uytterhoeven > > Signed-off-by: Bartlomiej Zolnierkiewicz > > --- > > drivers/video/fbdev/amifb.c | 63 -------------------------------------------- > > 1 file changed, 63 deletions(-) > > 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. > 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. 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14224C433DF for ; Tue, 2 Jun 2020 11:04:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0105206A4 for ; Tue, 2 Jun 2020 11:04:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0105206A4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 50AEF6E143; Tue, 2 Jun 2020 11:04:52 +0000 (UTC) Received: from mail-oo1-f67.google.com (mail-oo1-f67.google.com [209.85.161.67]) by gabe.freedesktop.org (Postfix) with ESMTPS id 824736E141 for ; Tue, 2 Jun 2020 11:04:50 +0000 (UTC) Received: by mail-oo1-f67.google.com with SMTP id v3so2078127oot.1 for ; Tue, 02 Jun 2020 04:04:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SnU67PM5tYuOxOQ+ffnEXx7IP/EaDf221A3j8p4Bihs=; b=tm9ZZJbpzno3VGp/+R/xCzsAIOxh3q/DbXL/OA1PopZiivoFEiJh4GCi4G1fST/Tgg uFFMFAm7+SL2cZJ3dy0akwijRpXrLlHJwlSdHqmBEWu/WFYTUCfBzmrdNA0GW78kMVZ/ mCRs+sMvlKOfyoUQJ2wRYb2JjWA6KRA7Qg4HMbAO5b0iZenAYp3NA9MIXtzFVrXRFySW 1RWuPluJzhvdCOfJLWcJCgFARooIfzxMgGj29IUQz/zj8RIpRLJ8a/ZRvfMTFUhFcnhZ JLorETPWooeL0b6pv9W8mM87Lo0cNHSChm/JBXfWy4WY4/kpK6osJcHIEJOcJ2+sx2Gm r6kQ== X-Gm-Message-State: AOAM531pGUX5ef4gfrSIa4gk+mkjtuJFVaj4Mqk8UadRlqDuk7JlAzjH xKbP+ajZdL4QcRoGq29HWKVxcnq37CZfHCmjwXs= X-Google-Smtp-Source: ABdhPJx5LJM1BuqsyoFrXnT/JqbG5sPPQGLYtu772FLIRUMwlABs9hqY840TLSR+IxcpPBkOXCjVdX5M39D3Q54TX0I= X-Received: by 2002:a4a:e295:: with SMTP id k21mr20587446oot.11.1591095884883; Tue, 02 Jun 2020 04:04:44 -0700 (PDT) MIME-Version: 1.0 References: <839133dd-8ed4-5fec-c311-ce9f8abf3d5f@samsung.com> <72e0871c-d4bb-4887-4d6f-a60fd905bec1@physik.fu-berlin.de> In-Reply-To: <72e0871c-d4bb-4887-4d6f-a60fd905bec1@physik.fu-berlin.de> From: Geert Uytterhoeven Date: Tue, 2 Jun 2020 13:04:33 +0200 Message-ID: Subject: Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support To: John Paul Adrian Glaubitz X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux Fbdev development list , Bartlomiej Zolnierkiewicz , Linux Kernel Mailing List , DRI Development , linux-m68k , Al Viro Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Adrian, On Tue, Jun 2, 2020 at 12:41 PM John Paul Adrian Glaubitz wrote: > On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote: > >> These #ifdefs are relics from APUS (Amiga Power-Up System), which > >> added a PPC board. APUS support was killed off a long time ago, > >> when arch/ppc/ was still king, but these #ifdefs were missed, because > >> they didn't test for CONFIG_APUS. > > > > Reported-by: Al Viro > > Reported-by: Geert Uytterhoeven > > Signed-off-by: Bartlomiej Zolnierkiewicz > > --- > > drivers/video/fbdev/amifb.c | 63 -------------------------------------------- > > 1 file changed, 63 deletions(-) > > 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. > 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. 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel