Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1090517rwd; Wed, 31 May 2023 09:19:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4vz/ALw9v6YSeGBx6kW4DS+GoBRPbDJXF8RR0r1Xcfsob/mfE5K2o2rEEbbogdt5wNsyEx X-Received: by 2002:a05:6a00:1949:b0:643:4d69:efb8 with SMTP id s9-20020a056a00194900b006434d69efb8mr7366664pfk.6.1685549961791; Wed, 31 May 2023 09:19:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685549961; cv=none; d=google.com; s=arc-20160816; b=yAcItodfFJiEx7vo2WEWB1OM1N1BQCiwhlPv8Nn5mJiiufE8j4TWdULcsGSI+0mbWx O61/OYozprVKKsv9vLUlNmOEbNdnw/lm2Z0uoMf9eVm+YPhU/RflQCDNXs//F+nHjT9D +VN874OUdvRwCF3v2oV/eUwUKruQH6yfLdrPv2BkEHfeFjADrN0neD4j5klj4hPZq83B /KLIflDPixBIkp3RCf5vjojOR3CQXjJiBiMxPxd7o4C4t9ZB/kif1DfglMBV6DWMJ/ns p/MroeHpoj7mTYRyk7pRfiHHiBgSFKwnLBC9a1ft0AmLsteQd90VWI/8xPNcYjy6sSa+ sqXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id; bh=U1/X8zdGhVr9DCnEglNXrhcnrrboDPik70vId2Wwjcs=; b=mXIKHEcorm+/ylKbq1MEe0PoXkbKbxwROAGOycTMEJrfJlnlP8Pl2fEp4p6HbwGLYv tUT43C5f0XHhGRIQaMlySGt81G6jrv1b9lpOSxCso6oFTFgeQol1y+0Oudvu6Z1PoDJB Tow0gEFF8nShyMaDQShlt6eBol8/eMwfgsf/FQncOsurQ29qErfhtJWs8rDZ1S+7F/1f pU2UrWqjDtDutYx4x72Vs0QCXadW4s0ZCdpCYeYv8x+jsCsHoeGPAZNfKBDcNGfbGveH 54fFZXOr+th7ocps5Vi1Vmg6tLhGPsomBR/jrKO3JmNBbWQDGE1oGMuoG7Dl8yEThUac bSlw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x24-20020a63db58000000b0052c688e6608si1143081pgi.505.2023.05.31.09.19.06; Wed, 31 May 2023 09:19:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229491AbjEaQIt (ORCPT + 99 others); Wed, 31 May 2023 12:08:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229455AbjEaQIs (ORCPT ); Wed, 31 May 2023 12:08:48 -0400 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1C320D9 for ; Wed, 31 May 2023 09:08:44 -0700 (PDT) Received: from loongson.cn (unknown [10.20.42.43]) by gateway (Coremail) with SMTP id _____8DxNvELcXdkqwIDAA--.6645S3; Thu, 01 Jun 2023 00:08:43 +0800 (CST) Received: from [10.20.42.43] (unknown [10.20.42.43]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Cx77MJcXdkY5uCAA--.16244S3; Thu, 01 Jun 2023 00:08:41 +0800 (CST) Message-ID: <950fdaaa-b62c-7f36-a499-9eca71c8bc47@loongson.cn> Date: Thu, 1 Jun 2023 00:08:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v6 5/6] drm/etnaviv: add driver support for the PCI devices Content-Language: en-US To: Bjorn Helgaas Cc: Lucas Stach , Russell King , Christian Gmeiner , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org, loongson-kernel@lists.loongnix.cn, Li Yi References: From: Sui Jingfeng Organization: Loongson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8Cx77MJcXdkY5uCAA--.16244S3 X-CM-SenderInfo: xvxlyxpqjiv03j6o00pqjv00gofq/ X-Coremail-Antispam: 1Uk129KBjvJXoW3Jw17Wry8uFWftFW7urW3ZFb_yoWxZw4DpF W5JayYkrWkWFW8K3s7XF43ZFy3tw4SqFyF934Ut3sFv390vry8GryrtF4YkF9xXrZagFyI vF4UKrW7uF45JaDanT9S1TB71UUUUjDqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bDxYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVWUJVW8JwAaw2AF wI0_JF0_Jw1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27w Aqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_JF0_Jw1lYx0Ex4A2jsIE 14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1c AE67vIY487MxkF7I0En4kS14v26r126r1DMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMxCIbckI1I0E14v26r126r1DMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1I6r4UMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6x AIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY 1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUcbAwUUUUU X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 2023/5/31 03:02, Bjorn Helgaas wrote: > On Wed, May 31, 2023 at 12:06:42AM +0800, Sui Jingfeng wrote: >> This patch adds PCI driver support on top of what already have. Take the >> GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device driver. >> There is only one GPU core for the GC1000 in the LS7A1000 and LS2K1000. >> Therefore, component frameworks can be avoided. Because we want to bind the >> DRM driver service to the PCI driver manually. >> + * Loongson Mips and LoongArch CPU(ls3a5000, ls3a4000, ls2k1000la) >> + * maintain cache coherency by hardware >> + */ >> + if (IS_ENABLED(CONFIG_CPU_LOONGSON64) || IS_ENABLED(CONFIG_LOONGARCH)) >> + priv->has_cached_coherent = true; > This looks like something that should be a runtime check, not a > compile-time check. > > If it's possible to build a single kernel image that runs on Loongson > MIPS or LoongArch CPU and, in addition, runs on other platforms, you > cannot assume that all the others maintain this cache coherency. Nice catch! I don't even realize this! LS3A4000 is mips64r2 with MSA SIMD, while LS3A5000 is LoongArch, instruction set, compiler, and binary interface are totally changed. Therefore, it's impossible to build a single kernel image that runs on all Loongson CPUs. Currently, I can guarantee that this works on the Loongson platform. My initial intent here is to let priv->has_cached_coherent be *true* on the Loongson platform (both mips and loongarch). I do know there are some other vendors who bought GPU IP from Vivante. say GC7000, and integrate it into their discrete GPU product. But it is also a PCI device, but this is another story; it deserves another patch. I don't know if Etnaviv folk find some similar hardware on Arm Arch, Some Arm CPUs do not maintain cached coherency on hardware. The has_cached_coherent member can be set to false on such hardware. For us, it seems that there is no need to do runtime checking, because they are all cached coherent by default. Can I improve this in the future, currently I don't have a good idea. >> +static struct etnaviv_drm_private *etna_private_s; > A static pointer looks wrong because it probably limits you to a > single instance of something. This structure is shared by all GPU cores. Originally, Etnaviv was a component-based driver. It's one driver wrangler for all GPU cores. (One piece of driver rules them all.) This structure is shared by all GPU cores and does not have a copy per GPU core. >> @@ -727,6 +756,12 @@ static int __init etnaviv_init(void) >> if (ret != 0) >> goto unregister_gpu_driver; >> >> +#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER >> + ret = pci_register_driver(&etnaviv_pci_driver); >> +#endif >> + if (ret != 0) >> + goto unregister_platform_driver; > Why is this outside the #ifdef? If CONFIG_DRM_ETNAVIV_PCI_DRIVER is > not set, you already tested "ret != 0" above and will never take this > goto. On arch/platform without CONFIG_PCI enabled, CONFIG_DRM_ETNAVIV_PCI_DRIVER config option will not be enabled. On such cases, GCC complains when compile with  W=1: drivers/gpu/drm/etnaviv/etnaviv_drv.c: In function ‘etnaviv_init’: drivers/gpu/drm/etnaviv/etnaviv_drv.c:787:1: warning: label ‘unregister_platform_driver’ defined but not used [-Wunused-label]   787 | unregister_platform_driver:       | ^~~~~~~~~~~~~~~~~~~~~~~~~~ This is the pain that #ifdefs and #endif bring to us. We want to zero out compile warnings. Otherwise, Intel's compiler test robot will come here and warn you! Yet another test for "ret != 0" doesn't hurt much, probably could be optimized out by the compiler. We are afraid of warnings. >> +static int etnaviv_gpu_plat_drv_init(struct etnaviv_gpu *gpu, bool component) >> +{ >> + struct device *dev = gpu->dev; >> + struct platform_device *pdev = to_platform_device(dev); >> + int err; >> + >> + /* Map registers: */ >> + gpu->mmio = devm_platform_ioremap_resource(pdev, 0); >> + if (IS_ERR(gpu->mmio)) >> + return PTR_ERR(gpu->mmio); >> + >> + if (component) { >> + err = component_add(dev, &gpu_ops); >> + if (err < 0) { >> + dev_err(dev, "failed to register component: %d\n", err); >> + return err; >> + } >> + } >> + >> + return 0; >> +} > All this platform driver rearrangement looks like it should be a > separate patch so adding PCI support only adds PCI-related stuff. > Indeed, this is acceptable. >> +++ b/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c >> @@ -0,0 +1,87 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> + >> +#include >> + >> +#include "etnaviv_drv.h" >> +#include "etnaviv_gpu.h" >> +#include "etnaviv_pci_drv.h" >> + >> +enum etnaviv_pci_gpu_family { >> + GC1000_IN_LS7A1000 = 0, >> + GC1000_IN_LS2K1000 = 1, > Seems unused; why is this here? Want to use it to provide device-specific information. For example, LS2K1000 is an SoC, and LS7A1000 is a bridge chipset. The GC1000 in those chips is a 32-bit GPU. even though the host is a 64-bit system. This GPU can only access memory below 4 GB. This can be used to provide information known at compile time. Attach the has_cached_coherent member to the chip model defined here? >> +static int etnaviv_pci_probe(struct pci_dev *pdev, >> + const struct pci_device_id *ent) >> +{ >> + struct device *dev = &pdev->dev; >> + int ret; >> + >> + ret = pcim_enable_device(pdev); >> + if (ret) { >> + dev_err(&pdev->dev, "failed to enable\n"); > Use "dev", no need for "&pdev->dev" since you already looked it up > above. Also below for dma_set_mask_and_coherent(). Ok, acceptable.  You are a really serious man and quite professional. > >> + return ret; >> + } >> + >> + pci_set_master(pdev); >> + >> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); >> +static const struct pci_device_id etnaviv_pci_id_lists[] = { >> + {0x0014, 0x7a15, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GC1000_IN_LS7A1000}, >> + {0x0014, 0x7a05, PCI_ANY_ID, PCI_ANY_ID, 0, 0, GC1000_IN_LS2K1000}, >> + {0, 0, 0, 0, 0, 0, 0} > Should probably use PCI_DEVICE_DATA(). Use PCI_VENDOR_ID_LOONGSON. Originally, I wanted to keep them on the same line, at the same time, avoiding complaints from checkpatch.pl. PCI_VENDOR_ID_LOONGSON is too long. No problem, will be fixed in the next version. > Only "{ }" required to terminate. > >> +++ b/drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h >> @@ -0,0 +1,12 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> + >> +#ifndef __ETNAVIV_PCI_DRV_H__ >> +#define __ETNAVIV_PCI_DRV_H__ >> + >> +#include > This #include isn't required by this file. Let me give you a reason to do this: My initial idea is that other source files only need to include "etnaviv_pci_drv.h", OK, new.  will be fixed in the next version. >> +#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER >> +extern struct pci_driver etnaviv_pci_driver; >> +#endif >> + >> +#endif -- Jingfeng