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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2EA0AC7EE2E for ; Tue, 23 May 2023 23:34:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wNrVeK98zFWQJoEUW3FdUwcmgHQs2Gb8hIRxGaS+p8Q=; b=V7WCiQes7F8ybH G+pMAkgq3D/1u8JibSd+/utI78kApDktwEuND/oLuCXfMBFjsBPzYTtFqNuCnth90Unnfk1vPc/xd hRtMslz+QJalZgXJUR74qduwNWP7Tbj58CZ/Z9hlllzdEoaiEHGTCeMvY6wxgT6ea0j8B706IUfqQ ko9VoSeBIQyUnAvxBVWNPqh4yH/JZpsE+pYrS+31iBHGo/fCASDnJebi1/orCqXVis72cLUz6JobY EyNBDXBx2AOvAfvX4hc/pgANuMgh3h1X1p4JjEzl/SEjhfckfS9sLWee98ntLC0Kp47ODPGc+laPP wzzytW+Q61HkuWpjppKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1bWC-00BnbL-2I; Tue, 23 May 2023 23:34:16 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1bW9-00BnZv-0u for linux-arm-kernel@lists.infradead.org; Tue, 23 May 2023 23:34:15 +0000 Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-25367154308so234101a91.1 for ; Tue, 23 May 2023 16:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20221208.gappssmtp.com; s=20221208; t=1684884850; x=1687476850; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=MNA57LFsEAjv0YnO7XAE11SZw6Ds4IrSm19nvlVJk98=; b=wF+aug1ydohk/cr8Rfez98IIlwqb13f0RxZ6y479XbKidTrvL03zg77sxMin+zGFGx l5eXByrl4nPZWQWmqQncYvX9EBJ2jhKSQOmxQvgaHwbuXn34nx47cTnpfrrrJzj+8zQw 4pNfP+xtaTEDb3tmNzMbZ9lq1FvB1h3Y/9o0b9L7TTlVcKFXDAGLKRDd9xXEgp7O259E JEOObHH4XNk6aUQOdhlo/FfoEEjn3MqFmkmu5jjMJ2GV+T7Gsu/kuTOHMZ3neHBb56qU VtYRMrOu288bwsGXUhDF1P0SpaYg4k2ai2BHS88fM94NGHU7+411tXSKeuvtY4mY+E9V VdhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684884850; x=1687476850; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MNA57LFsEAjv0YnO7XAE11SZw6Ds4IrSm19nvlVJk98=; b=M0/F761DYtjK5nyMgNq/0r0gGuIR5VuY9CeMJJLEMWWv0gTCgAsmVyrrwld1sH5YIf Um3j35XycngcrcGBgUc1SWAJZIL9jz8TuU1V900QNJEZ/RCFd4AXOo0qrkSzeGM6liQ1 O5JrZqo8FAGSqI1Rv2EO0EB5ofQb75SdYAg3Gn2KNh2z9Er7G4CYizhM48btW215rZzq 1NHdlkLkID0c5BOCyZjvbEoDCGoOleYApkDz6HAVWnVlCnvDL3h0zX8fMlsL/QCm8f/j c89eV14HiK1+tV9u2VQJX4wFRa+Zy7XuxST930OgBg/oCHlTM4hD+h0hvNN/EEbIoe3k S0AQ== X-Gm-Message-State: AC+VfDxmXrDI/LPTTWyKjZ8q5E6OsSRfstNzFGCU3uMe84GEcDCaIOpA YbslQd4VGkXmpWsiHL4KAYoUlg== X-Google-Smtp-Source: ACHHUZ4/S/KRgTtfzWmFTkvHxw3NShbPiyY6ElSBnhSbSlY2KYV0gjG/Ka+9HzWGVYgXMdo2hQhd0g== X-Received: by 2002:a17:90b:a45:b0:253:947f:af51 with SMTP id gw5-20020a17090b0a4500b00253947faf51mr13745197pjb.5.1684884849781; Tue, 23 May 2023 16:34:09 -0700 (PDT) Received: from localhost ([75.172.135.98]) by smtp.gmail.com with ESMTPSA id gl21-20020a17090b121500b00253305f36c4sm100944pjb.18.2023.05.23.16.34.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 16:34:09 -0700 (PDT) From: Kevin Hilman To: Jeffrey Hugo , Alexandre Bailon , airlied@gmail.com, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, bero@baylibre.com, jstephan@baylibre.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, christian.koenig@amd.com, linaro-mm-sig@lists.linaro.org, robh+dt@kernel.org, linux-mediatek@lists.infradead.org, nbelin@baylibre.com, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, linux-media@vger.kernel.org, sumit.semwal@linaro.org, linux-arm-kernel@lists.infradead.org, angelogioacchino.delregno@collabora.com Subject: Re: [PATCH 0/7] Add a DRM driver to support AI Processing Unit (APU) In-Reply-To: References: <20230517145237.295461-1-abailon@baylibre.com> Date: Tue, 23 May 2023 16:34:08 -0700 Message-ID: <7ha5xud3m7.fsf@baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230523_163413_539234_53A90CB1 X-CRM114-Status: GOOD ( 19.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Jeffrey Hugo writes: > On 5/17/2023 8:52 AM, Alexandre Bailon wrote: >> This adds a DRM driver that implements communication between the CPU and an >> APU. The driver target embedded device that usually run inference using some >> prebuilt models. The goal is to provide common infrastructure that could be >> re-used to support many accelerators. Both kernel, userspace and firmware tries >> to use standard and existing to leverage the development and maintenance effort. >> The series implements two platform drivers, one for simulation and another one for >> the mt8183 (compatible with mt8365). > > This looks like the 3 existing Accel drivers. Why is this in DRM? Yes, this belongs in accel. I think Alex had some issues around the infra in accel with device nodes not appearing/opening properly, but I'll let him comment there. But either way, the right approach should be to fix any issues in accel and move it there. [...] >> .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 ++ >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/apu/Kconfig | 22 + >> drivers/gpu/drm/apu/Makefile | 10 + >> drivers/gpu/drm/apu/apu_drv.c | 282 +++++++++ >> drivers/gpu/drm/apu/apu_gem.c | 230 +++++++ >> drivers/gpu/drm/apu/apu_internal.h | 205 ++++++ >> drivers/gpu/drm/apu/apu_sched.c | 592 ++++++++++++++++++ >> drivers/gpu/drm/apu/simu_apu.c | 313 +++++++++ >> include/uapi/drm/apu_drm.h | 81 +++ > > "apu" seems too generic. We already have 3 "AI processing units" over > in drivers/accel already... Indeed, it is generic, but that's kind of the point for this driver since it's targetted at generalizing the interface with "AI processing units" on a growing number of embedded SoCs (ARM, RISC-V, etc.) In addition, the generic naming is intentional because the goal is bigger than the kernel and is working towards a generic, shared "libAPU" userspace[1], but also common firmware for DSP-style inference engines (e.g. analgous Sound Open Firmware for audio DSPs.) As usual, the various SoC vendors use different names (APU, NPU, NN unit, etc.) but we'd like a generic name for the class of devices targetted by this driver. And unfortunately, it looks like the equally generic "Versatile processing unit" is already taken Intel's drivers/accel/ivpu. :) Maybe since this is more about generalizing the interface between the CPU running linux and the APU, what about the name apu_if? But I guess that applies to the other 3 drivers in drivers/accell also. Hmmm... Naming things is hard[2], so we're definitly open to other ideas. Any suggestions? Kevin [1] https://gitlab.baylibre.com/baylibre/libapu/libapu [2] "There are 2 hard problems in computer science: cache invalidation, naming things and off-by-1 errors." -- https://twitter.com/secretGeek/status/7269997868 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel