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 55A03C7EE23 for ; Wed, 24 May 2023 10:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=B6EezX+QhUoAO0wrk5CqrwAVTH mH8oj+2obrSSIuIuN/oI/4BPjzwCIrUSxAIFd/ynUTeUYrxljn3kJCND4OJoa5vzMpm7HAA5i0T16 OZoDE0iuON8W4UJCUikCHWWBeDhG+VQCRF9ZC3Nu4Wp4xFptXE3FQf8l/e87XycrsRuvyeiZ5pQbt wvhW1PqB77U6yTXwXdx8TL6ckkxvtwTW78D0BXWh+z4kiylyoIuoTvCmBvrO9SFa9pXMsdGtUVLwm MOskknxfxyZOeRO5Hwrzao+CXEMziaskZervZwQoJ/ztf4pV4ayNTxUnYdpAmptS07ZByp9qU35i0 /fQsW8eA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1lv1-00DDYk-1g; Wed, 24 May 2023 10:40:35 +0000 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1luy-00DDTP-0g for linux-mediatek@lists.infradead.org; Wed, 24 May 2023 10:40:34 +0000 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-96f72e6925cso16223566b.1 for ; Wed, 24 May 2023 03:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1684924828; x=1687516828; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=MsncBU0Xz5NtTD5S78mXMEeC4K94W2pwnNzWeSZrGQG5dJS82huGUy3CeFMYH9IiDt uJrbvxQOo8WvI+Zx2GRQ6Z3AbzchyrDuGEXD5OdYlnDK9XhsxexvCXh09C24BvmE40dX 9mvid7TkCoJwkRNQPQd8tZNSIFdp98fDgbtnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684924828; x=1687516828; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=VzCTsBOpn9/cEgKmPg+0XlZsgYVBOA04UDSy5idqIEM5kGcRz5utpYPmpaqj1cs1tO 9Og6FbWzzRcx05fXyHNNklXrNZrOoIwu5vYP9QBNDlJJtQGcVh1JdprXl/WVDRpfBCVp rInum6cizDnaX6YwSUgpLVWgizimTQ8i/TBj5S++noSf6yBWurKpYmmDwAmDPhE373AW YGmmov9sR7OtyOYDEpmJz58TOjeLpKeCBX70Yq3jzg0grgQZ2XFwWNvLgqwsXVZjPBNL XlidmTw2zKwT58OWPWGP6pCrynPTw300lrqYrrpoFfuChlQnzI1ACSBdV58IAf/c38Z9 2NYQ== X-Gm-Message-State: AC+VfDwuDoO8hhezeOtKSO9obOAi9L7Z+ChvI/OurC2hoxzeZExff698 NWvvK2n7CAyymnGrtrBMWR74Aw== X-Google-Smtp-Source: ACHHUZ4KUw5NB3BOPHGF+oh7fuHhF9gCQe2opcFl/h4sFdwHa3h9ymnCb0ViPZg5quW6K3zoFzNnhA== X-Received: by 2002:a17:906:72ce:b0:96f:56ab:c69b with SMTP id m14-20020a17090672ce00b0096f56abc69bmr1766954ejl.3.1684924827732; Wed, 24 May 2023 03:40:27 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-33.fiber7.init7.net. [212.51.149.33]) by smtp.gmail.com with ESMTPSA id c25-20020a170906155900b0094f282fc29asm5554047ejd.207.2023.05.24.03.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 03:40:27 -0700 (PDT) Date: Wed, 24 May 2023 12:40:25 +0200 From: Daniel Vetter To: Oded Gabbay Cc: Kevin Hilman , Jeffrey Hugo , Alexandre Bailon , airlied@gmail.com, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, 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) Message-ID: Mail-Followup-To: Oded Gabbay , Kevin Hilman , Jeffrey Hugo , Alexandre Bailon , airlied@gmail.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, 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 References: <20230517145237.295461-1-abailon@baylibre.com> <7ha5xud3m7.fsf@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 6.1.0-7-amd64 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230524_034032_253589_36CA392F X-CRM114-Status: GOOD ( 45.63 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Wed, May 24, 2023 at 01:27:00PM +0300, Oded Gabbay wrote: > On Wed, May 24, 2023 at 2:34 AM Kevin Hilman wrote: > > > > 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? > Maybe model it according to the tiny driver in drm display ? You can > then call it tiny_apu :-) > Disclosure: It was Daniel's suggestion, he can chime in with more > details on the tiny driver concept. Yeah so maybe a bit more detail on my thoughts: First this smells like a need bypass of the entire "we want open userspace for accel drivers" rule. The rule isn't quite a strict as for drm gpu drivers (not sure we ended up documenting exactly what, but iirc the consensus was that for build-time only dependencies we're ok with downstream compilers), but it's still there. And at least from a quick look apu.ko and libapu just look like a generic accel interface, and that's not enough. For the big training engines it's more or less "enough to run pytorch, but it can be really slow", not sure what the right standard for these inference-only drivers should be. So that's the first reason why I don't like this. The other is that I think if we do end up with a pile of tiny accel drivers, we should probably look into something like simmpledrm for the tiny display drivers. Probably still IP specific ioctls (at least most) so that IP specific job knows and all that are easy, but then just pass to a framework that simplifies a drm gem driver to "write ptes" and "run job" callback, maybe with an optional "create/destroy vm/ctx" for hw which can do that. So maybe we end up with a drivers/accel/tiny and a bunch more helpers around the existing gem ones. The rule we have for drm/tiny is "1 file, less than 1kloc", and there's a bunch of them. I do think we can achieve the same for tiny accel inference engines (but it's still a bit a road). Maybe tiny accel is more like "less than 5kloc" since you need a bit more glue for the driver specific ioctl stuff - maybe that's only needed for the submit ioctl, maybe also for buffer map/unmap and creation. Also note that there's an entire pile of in-flight work for adding new helpers to the gem world to make this all easier. Once we have gpuva and exec helpers there not much glue left to tie it all together with the scheduler. But the real crux is that an accel inference driver really needs to have enough userspace to do an actual inference job with some android/cros/whatever framework for inference (there's just too many). -Daniel > Oded > > > > > 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 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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 C9196C77B7A for ; Wed, 24 May 2023 10:41:05 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HYoobnzQ16W3CSdzPc9zzwb8EGZLBUuPEeYz4KB9GCU=; b=Yjfsb5TlvI+WId DU0cqeMo1v/nAQ804zVjxExTo1u61gxCoiD7ZfEvp7lpNBG1+6DFrVcSKtKZxzYvzeYz9+uWxfi3H EkFIss59AJ5AEveTgVU+5SEbJTa9DEhlXVVZf1xh6fLSR0wn84Nf3Qeb8RR/29DBJmilDHnSjKUw6 DjWE3uK+L4yF5bJyosEwNUAbYJuQUA7Xfxrbp7SiYdoz72L/7KS75jS2NIHpdQx42YRsP5m0DYlnS 1HKRxiapkjl8ybQxliiF3wHJMYAjwMvLEUnXZ7+EtvfQI5NiJng4aK3zqVfSIEogmxwKXfFVXPvE1 TP5aNf16AzZjygEGqFcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1lv2-00DDZF-0M; Wed, 24 May 2023 10:40:36 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1luy-00DDTI-0f for linux-arm-kernel@lists.infradead.org; Wed, 24 May 2023 10:40:34 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-50a20bfe366so273358a12.0 for ; Wed, 24 May 2023 03:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1684924828; x=1687516828; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=MsncBU0Xz5NtTD5S78mXMEeC4K94W2pwnNzWeSZrGQG5dJS82huGUy3CeFMYH9IiDt uJrbvxQOo8WvI+Zx2GRQ6Z3AbzchyrDuGEXD5OdYlnDK9XhsxexvCXh09C24BvmE40dX 9mvid7TkCoJwkRNQPQd8tZNSIFdp98fDgbtnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684924828; x=1687516828; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=SKCMo7a1b+e/ZqnI9/h10kkd/jD2RsQ4zkpuI3MyJ2J+nje1znHIX+H8KqBkGj/lfi Hv80Urmu0wHpNE7/3pPGRVkCzkbqXbTKEhMtDjPL8EdWiGrzCib5Z+KsD2pdN1h+lwxw FFmo6LaZqYDqBgmO91xiLDy5k9QI20xEfQh636P6A2jNcJ+MxCwH4759s/DqWAWnGa3I 922AI7s3I67a7WFR/aJnhlMcF8LUqF/mGI56ciGi+LC1wp1E4M5usYgLhRxKE2NlFfbG 6/jJRVociQzURW8JINSWWjV9fp4G7CrPH528gZp6sTaXNwyCj4ygoioIGoNgz4paiahw Tn+g== X-Gm-Message-State: AC+VfDywVw2g+Z9Bomh+xaR+hiUWYRKjT389gT0vOTOdbstdqMbhWbtz HXmWzVFa5xUic9TleRx610wiXg== X-Google-Smtp-Source: ACHHUZ4KUw5NB3BOPHGF+oh7fuHhF9gCQe2opcFl/h4sFdwHa3h9ymnCb0ViPZg5quW6K3zoFzNnhA== X-Received: by 2002:a17:906:72ce:b0:96f:56ab:c69b with SMTP id m14-20020a17090672ce00b0096f56abc69bmr1766954ejl.3.1684924827732; Wed, 24 May 2023 03:40:27 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-33.fiber7.init7.net. [212.51.149.33]) by smtp.gmail.com with ESMTPSA id c25-20020a170906155900b0094f282fc29asm5554047ejd.207.2023.05.24.03.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 03:40:27 -0700 (PDT) Date: Wed, 24 May 2023 12:40:25 +0200 From: Daniel Vetter To: Oded Gabbay Cc: Kevin Hilman , Jeffrey Hugo , Alexandre Bailon , airlied@gmail.com, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, 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) Message-ID: Mail-Followup-To: Oded Gabbay , Kevin Hilman , Jeffrey Hugo , Alexandre Bailon , airlied@gmail.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, 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 References: <20230517145237.295461-1-abailon@baylibre.com> <7ha5xud3m7.fsf@baylibre.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 6.1.0-7-amd64 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230524_034032_255493_22B28600 X-CRM114-Status: GOOD ( 46.95 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBNYXkgMjQsIDIwMjMgYXQgMDE6Mjc6MDBQTSArMDMwMCwgT2RlZCBHYWJiYXkgd3Jv dGU6Cj4gT24gV2VkLCBNYXkgMjQsIDIwMjMgYXQgMjozNOKAr0FNIEtldmluIEhpbG1hbiA8a2hp bG1hbkBiYXlsaWJyZS5jb20+IHdyb3RlOgo+ID4KPiA+IEplZmZyZXkgSHVnbyA8cXVpY19qaHVn b0BxdWljaW5jLmNvbT4gd3JpdGVzOgo+ID4KPiA+ID4gT24gNS8xNy8yMDIzIDg6NTIgQU0sIEFs ZXhhbmRyZSBCYWlsb24gd3JvdGU6Cj4gPiA+PiBUaGlzIGFkZHMgYSBEUk0gZHJpdmVyIHRoYXQg aW1wbGVtZW50cyBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIENQVSBhbmQgYW4KPiA+ID4+IEFQ VS4gVGhlIGRyaXZlciB0YXJnZXQgZW1iZWRkZWQgZGV2aWNlIHRoYXQgdXN1YWxseSBydW4gaW5m ZXJlbmNlIHVzaW5nIHNvbWUKPiA+ID4+IHByZWJ1aWx0IG1vZGVscy4gVGhlIGdvYWwgaXMgdG8g cHJvdmlkZSBjb21tb24gaW5mcmFzdHJ1Y3R1cmUgdGhhdCBjb3VsZCBiZQo+ID4gPj4gcmUtdXNl ZCB0byBzdXBwb3J0IG1hbnkgYWNjZWxlcmF0b3JzLiBCb3RoIGtlcm5lbCwgdXNlcnNwYWNlIGFu ZCBmaXJtd2FyZSB0cmllcwo+ID4gPj4gdG8gdXNlIHN0YW5kYXJkIGFuZCBleGlzdGluZyB0byBs ZXZlcmFnZSB0aGUgZGV2ZWxvcG1lbnQgYW5kIG1haW50ZW5hbmNlIGVmZm9ydC4KPiA+ID4+IFRo ZSBzZXJpZXMgaW1wbGVtZW50cyB0d28gcGxhdGZvcm0gZHJpdmVycywgb25lIGZvciBzaW11bGF0 aW9uIGFuZCBhbm90aGVyIG9uZSBmb3IKPiA+ID4+IHRoZSBtdDgxODMgKGNvbXBhdGlibGUgd2l0 aCBtdDgzNjUpLgo+ID4gPgo+ID4gPiBUaGlzIGxvb2tzIGxpa2UgdGhlIDMgZXhpc3RpbmcgQWNj ZWwgZHJpdmVycy4gIFdoeSBpcyB0aGlzIGluIERSTT8KPiA+Cj4gPiBZZXMsIHRoaXMgYmVsb25n cyBpbiBhY2NlbC4gIEkgdGhpbmsgQWxleCBoYWQgc29tZSBpc3N1ZXMgYXJvdW5kIHRoZQo+ID4g aW5mcmEgaW4gYWNjZWwgd2l0aCBkZXZpY2Ugbm9kZXMgbm90IGFwcGVhcmluZy9vcGVuaW5nIHBy b3Blcmx5LCBidXQKPiA+IEknbGwgbGV0IGhpbSBjb21tZW50IHRoZXJlLiAgQnV0IGVpdGhlciB3 YXksIHRoZSByaWdodCBhcHByb2FjaCBzaG91bGQKPiA+IGJlIHRvIGZpeCBhbnkgaXNzdWVzIGlu IGFjY2VsIGFuZCBtb3ZlIGl0IHRoZXJlLgo+ID4KPiA+IFsuLi5dCj4gPgo+ID4gPj4gICAuLi4v ZGV2aWNldHJlZS9iaW5kaW5ncy9ncHUvbXRrLGFwdS1kcm0ueWFtbCAgfCAgMzggKysKPiA+ID4+ ICAgZHJpdmVycy9ncHUvZHJtL0tjb25maWcgICAgICAgICAgICAgICAgICAgICAgIHwgICAyICsK PiA+ID4+ICAgZHJpdmVycy9ncHUvZHJtL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgIHwg ICAxICsKPiA+ID4+ICAgZHJpdmVycy9ncHUvZHJtL2FwdS9LY29uZmlnICAgICAgICAgICAgICAg ICAgIHwgIDIyICsKPiA+ID4+ICAgZHJpdmVycy9ncHUvZHJtL2FwdS9NYWtlZmlsZSAgICAgICAg ICAgICAgICAgIHwgIDEwICsKPiA+ID4+ICAgZHJpdmVycy9ncHUvZHJtL2FwdS9hcHVfZHJ2LmMg ICAgICAgICAgICAgICAgIHwgMjgyICsrKysrKysrKwo+ID4gPj4gICBkcml2ZXJzL2dwdS9kcm0v YXB1L2FwdV9nZW0uYyAgICAgICAgICAgICAgICAgfCAyMzAgKysrKysrKwo+ID4gPj4gICBkcml2 ZXJzL2dwdS9kcm0vYXB1L2FwdV9pbnRlcm5hbC5oICAgICAgICAgICAgfCAyMDUgKysrKysrCj4g PiA+PiAgIGRyaXZlcnMvZ3B1L2RybS9hcHUvYXB1X3NjaGVkLmMgICAgICAgICAgICAgICB8IDU5 MiArKysrKysrKysrKysrKysrKysKPiA+ID4+ICAgZHJpdmVycy9ncHUvZHJtL2FwdS9zaW11X2Fw dS5jICAgICAgICAgICAgICAgIHwgMzEzICsrKysrKysrKwo+ID4gPj4gICBpbmNsdWRlL3VhcGkv ZHJtL2FwdV9kcm0uaCAgICAgICAgICAgICAgICAgICAgfCAgODEgKysrCj4gPiA+Cj4gPiA+ICJh cHUiIHNlZW1zIHRvbyBnZW5lcmljLiAgV2UgYWxyZWFkeSBoYXZlIDMgIkFJIHByb2Nlc3Npbmcg dW5pdHMiIG92ZXIKPiA+ID4gaW4gZHJpdmVycy9hY2NlbCBhbHJlYWR5Li4uCj4gPgo+ID4gSW5k ZWVkLCBpdCBpcyBnZW5lcmljLCBidXQgdGhhdCdzIGtpbmQgb2YgdGhlIHBvaW50IGZvciB0aGlz IGRyaXZlcgo+ID4gc2luY2UgaXQncyB0YXJnZXR0ZWQgYXQgZ2VuZXJhbGl6aW5nIHRoZSBpbnRl cmZhY2Ugd2l0aCAiQUkgcHJvY2Vzc2luZwo+ID4gdW5pdHMiIG9uIGEgZ3Jvd2luZyBudW1iZXIg b2YgZW1iZWRkZWQgU29DcyAoQVJNLCBSSVNDLVYsIGV0Yy4pICBJbgo+ID4gYWRkaXRpb24sIHRo ZSBnZW5lcmljIG5hbWluZyBpcyBpbnRlbnRpb25hbCBiZWNhdXNlIHRoZSBnb2FsIGlzIGJpZ2dl cgo+ID4gdGhhbiB0aGUga2VybmVsIGFuZCBpcyB3b3JraW5nIHRvd2FyZHMgYSBnZW5lcmljLCBz aGFyZWQgImxpYkFQVSIKPiA+IHVzZXJzcGFjZVsxXSwgYnV0IGFsc28gY29tbW9uIGZpcm13YXJl IGZvciBEU1Atc3R5bGUgaW5mZXJlbmNlIGVuZ2luZXMKPiA+IChlLmcuIGFuYWxnb3VzIFNvdW5k IE9wZW4gRmlybXdhcmUgZm9yIGF1ZGlvIERTUHMuKQo+ID4KPiA+IEFzIHVzdWFsLCB0aGUgdmFy aW91cyBTb0MgdmVuZG9ycyB1c2UgZGlmZmVyZW50IG5hbWVzIChBUFUsIE5QVSwgTk4KPiA+IHVu aXQsIGV0Yy4pICBidXQgd2UnZCBsaWtlIGEgZ2VuZXJpYyBuYW1lIGZvciB0aGUgY2xhc3Mgb2Yg ZGV2aWNlcwo+ID4gdGFyZ2V0dGVkIGJ5IHRoaXMgZHJpdmVyLiAgQW5kIHVuZm9ydHVuYXRlbHks IGl0IGxvb2tzIGxpa2UgdGhlIGVxdWFsbHkKPiA+IGdlbmVyaWMgIlZlcnNhdGlsZSBwcm9jZXNz aW5nIHVuaXQiIGlzIGFscmVhZHkgdGFrZW4gSW50ZWwncwo+ID4gZHJpdmVycy9hY2NlbC9pdnB1 LiA6KQo+ID4KPiA+IE1heWJlIHNpbmNlIHRoaXMgaXMgbW9yZSBhYm91dCBnZW5lcmFsaXppbmcg dGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZQo+ID4gQ1BVIHJ1bm5pbmcgbGludXggYW5kIHRoZSBB UFUsIHdoYXQgYWJvdXQgdGhlIG5hbWUgYXB1X2lmPyAgQnV0IEkgZ3Vlc3MKPiA+IHRoYXQgYXBw bGllcyB0byB0aGUgb3RoZXIgMyBkcml2ZXJzIGluIGRyaXZlcnMvYWNjZWxsIGFsc28uICBIbW1t Li4uCj4gPgo+ID4gTmFtaW5nIHRoaW5ncyBpcyBoYXJkWzJdLCBzbyB3ZSdyZSBkZWZpbml0bHkg b3BlbiB0byBvdGhlciBpZGVhcy4gIEFueQo+ID4gc3VnZ2VzdGlvbnM/Cj4gTWF5YmUgbW9kZWwg aXQgYWNjb3JkaW5nIHRvIHRoZSB0aW55IGRyaXZlciBpbiBkcm0gZGlzcGxheSA/IFlvdSBjYW4K PiB0aGVuIGNhbGwgaXQgdGlueV9hcHUgOi0pCj4gRGlzY2xvc3VyZTogSXQgd2FzIERhbmllbCdz IHN1Z2dlc3Rpb24sIGhlIGNhbiBjaGltZSBpbiB3aXRoIG1vcmUKPiBkZXRhaWxzIG9uIHRoZSB0 aW55IGRyaXZlciBjb25jZXB0LgoKWWVhaCBzbyBtYXliZSBhIGJpdCBtb3JlIGRldGFpbCBvbiBt eSB0aG91Z2h0czoKCkZpcnN0IHRoaXMgc21lbGxzIGxpa2UgYSBuZWVkIGJ5cGFzcyBvZiB0aGUg ZW50aXJlICJ3ZSB3YW50IG9wZW4gdXNlcnNwYWNlCmZvciBhY2NlbCBkcml2ZXJzIiBydWxlLiBU aGUgcnVsZSBpc24ndCBxdWl0ZSBhIHN0cmljdCBhcyBmb3IgZHJtIGdwdQpkcml2ZXJzIChub3Qg c3VyZSB3ZSBlbmRlZCB1cCBkb2N1bWVudGluZyBleGFjdGx5IHdoYXQsIGJ1dCBpaXJjIHRoZQpj b25zZW5zdXMgd2FzIHRoYXQgZm9yIGJ1aWxkLXRpbWUgb25seSBkZXBlbmRlbmNpZXMgd2UncmUg b2sgd2l0aApkb3duc3RyZWFtIGNvbXBpbGVycyksIGJ1dCBpdCdzIHN0aWxsIHRoZXJlLgoKQW5k IGF0IGxlYXN0IGZyb20gYSBxdWljayBsb29rIGFwdS5rbyBhbmQgbGliYXB1IGp1c3QgbG9vayBs aWtlIGEgZ2VuZXJpYwphY2NlbCBpbnRlcmZhY2UsIGFuZCB0aGF0J3Mgbm90IGVub3VnaC4KCkZv ciB0aGUgYmlnIHRyYWluaW5nIGVuZ2luZXMgaXQncyBtb3JlIG9yIGxlc3MgImVub3VnaCB0byBy dW4gcHl0b3JjaCwgYnV0Cml0IGNhbiBiZSByZWFsbHkgc2xvdyIsIG5vdCBzdXJlIHdoYXQgdGhl IHJpZ2h0IHN0YW5kYXJkIGZvciB0aGVzZQppbmZlcmVuY2Utb25seSBkcml2ZXJzIHNob3VsZCBi ZS4KClNvIHRoYXQncyB0aGUgZmlyc3QgcmVhc29uIHdoeSBJIGRvbid0IGxpa2UgdGhpcy4KClRo ZSBvdGhlciBpcyB0aGF0IEkgdGhpbmsgaWYgd2UgZG8gZW5kIHVwIHdpdGggYSBwaWxlIG9mIHRp bnkgYWNjZWwKZHJpdmVycywgd2Ugc2hvdWxkIHByb2JhYmx5IGxvb2sgaW50byBzb21ldGhpbmcg bGlrZSBzaW1tcGxlZHJtIGZvciB0aGUKdGlueSBkaXNwbGF5IGRyaXZlcnMuIFByb2JhYmx5IHN0 aWxsIElQIHNwZWNpZmljIGlvY3RscyAoYXQgbGVhc3QgbW9zdCkgc28KdGhhdCBJUCBzcGVjaWZp YyBqb2Iga25vd3MgYW5kIGFsbCB0aGF0IGFyZSBlYXN5LCBidXQgdGhlbiBqdXN0IHBhc3MgdG8g YQpmcmFtZXdvcmsgdGhhdCBzaW1wbGlmaWVzIGEgZHJtIGdlbSBkcml2ZXIgdG8gIndyaXRlIHB0 ZXMiIGFuZCAicnVuIGpvYiIKY2FsbGJhY2ssIG1heWJlIHdpdGggYW4gb3B0aW9uYWwgImNyZWF0 ZS9kZXN0cm95IHZtL2N0eCIgZm9yIGh3IHdoaWNoIGNhbgpkbyB0aGF0LgoKU28gbWF5YmUgd2Ug ZW5kIHVwIHdpdGggYSBkcml2ZXJzL2FjY2VsL3RpbnkgYW5kIGEgYnVuY2ggbW9yZSBoZWxwZXJz CmFyb3VuZCB0aGUgZXhpc3RpbmcgZ2VtIG9uZXMuIFRoZSBydWxlIHdlIGhhdmUgZm9yIGRybS90 aW55IGlzICIxIGZpbGUsCmxlc3MgdGhhbiAxa2xvYyIsIGFuZCB0aGVyZSdzIGEgYnVuY2ggb2Yg dGhlbS4gSSBkbyB0aGluayB3ZSBjYW4gYWNoaWV2ZQp0aGUgc2FtZSBmb3IgdGlueSBhY2NlbCBp bmZlcmVuY2UgZW5naW5lcyAoYnV0IGl0J3Mgc3RpbGwgYSBiaXQgYSByb2FkKS4KTWF5YmUgdGlu eSBhY2NlbCBpcyBtb3JlIGxpa2UgImxlc3MgdGhhbiA1a2xvYyIgc2luY2UgeW91IG5lZWQgYSBi aXQgbW9yZQpnbHVlIGZvciB0aGUgZHJpdmVyIHNwZWNpZmljIGlvY3RsIHN0dWZmIC0gbWF5YmUg dGhhdCdzIG9ubHkgbmVlZGVkIGZvcgp0aGUgc3VibWl0IGlvY3RsLCBtYXliZSBhbHNvIGZvciBi dWZmZXIgbWFwL3VubWFwIGFuZCBjcmVhdGlvbi4KCkFsc28gbm90ZSB0aGF0IHRoZXJlJ3MgYW4g ZW50aXJlIHBpbGUgb2YgaW4tZmxpZ2h0IHdvcmsgZm9yIGFkZGluZyBuZXcKaGVscGVycyB0byB0 aGUgZ2VtIHdvcmxkIHRvIG1ha2UgdGhpcyBhbGwgZWFzaWVyLiBPbmNlIHdlIGhhdmUgZ3B1dmEg YW5kCmV4ZWMgaGVscGVycyB0aGVyZSBub3QgbXVjaCBnbHVlIGxlZnQgdG8gdGllIGl0IGFsbCB0 b2dldGhlciB3aXRoIHRoZQpzY2hlZHVsZXIuCgpCdXQgdGhlIHJlYWwgY3J1eCBpcyB0aGF0IGFu IGFjY2VsIGluZmVyZW5jZSBkcml2ZXIgcmVhbGx5IG5lZWRzIHRvIGhhdmUKZW5vdWdoIHVzZXJz cGFjZSB0byBkbyBhbiBhY3R1YWwgaW5mZXJlbmNlIGpvYiB3aXRoIHNvbWUKYW5kcm9pZC9jcm9z L3doYXRldmVyIGZyYW1ld29yayBmb3IgaW5mZXJlbmNlICh0aGVyZSdzIGp1c3QgdG9vIG1hbnkp LgotRGFuaWVsCgo+IE9kZWQKPiAKPiA+Cj4gPiBLZXZpbgo+ID4KPiA+IFsxXSBodHRwczovL2dp dGxhYi5iYXlsaWJyZS5jb20vYmF5bGlicmUvbGliYXB1L2xpYmFwdQo+ID4KPiA+IFsyXQo+ID4g IlRoZXJlIGFyZSAyIGhhcmQgcHJvYmxlbXMgaW4gY29tcHV0ZXIgc2NpZW5jZTogY2FjaGUgaW52 YWxpZGF0aW9uLAo+ID4gIG5hbWluZyB0aGluZ3MgYW5kIG9mZi1ieS0xIGVycm9ycy4iCj4gPiAg LS0gaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWNyZXRHZWVrL3N0YXR1cy83MjY5OTk3ODY4Cj4gPgoK LS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCmh0 dHA6Ly9ibG9nLmZmd2xsLmNoCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVs QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 08A58C77B7A for ; Wed, 24 May 2023 10:40:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5861F10E654; Wed, 24 May 2023 10:40:31 +0000 (UTC) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by gabe.freedesktop.org (Postfix) with ESMTPS id 74BFF10E64F for ; Wed, 24 May 2023 10:40:29 +0000 (UTC) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-96f72e6925cso16223666b.1 for ; Wed, 24 May 2023 03:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1684924828; x=1687516828; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=MsncBU0Xz5NtTD5S78mXMEeC4K94W2pwnNzWeSZrGQG5dJS82huGUy3CeFMYH9IiDt uJrbvxQOo8WvI+Zx2GRQ6Z3AbzchyrDuGEXD5OdYlnDK9XhsxexvCXh09C24BvmE40dX 9mvid7TkCoJwkRNQPQd8tZNSIFdp98fDgbtnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684924828; x=1687516828; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vSBx3Jy1mTVvH1DDifa+BTFAVrVdzMfrjrerJocMzTc=; b=KQ2dEtCXOkpKmVvJhiD0V1OCE7Rb8NFiRAwOmAVIF+InJ0r5ac7qX9e1q0nehW74N5 +N+V7ZKj/DVzmbxhP/AvA79rxvDORoAZbtzVjgi7l9G+xNYgagOCH26i1HDcdxWxtWko 3joPDmNAPyXOOVmTXhvjDxlIJOqJrbyxJMirx0qq7IBj7R6UTxjFzVA7i4c4VY13sKsJ EqxphVWmkaBm2NXk6cYeR/Axdz3SFP2QrQUZ78Tp7Mp2vt4JpAKOzYHAogOMVDd4vSCi ZSPDC56CcFTDfEG+UG1nc3zYxsa3tdpiCMSENYC2eQ02ittjgjfaDL6pLix7M8MUpjQC FxvQ== X-Gm-Message-State: AC+VfDzlBH5kxGPIv36YG9t0V8mBMjNU67aMHBjTagxkD/AI4atv8Pcx N32WDT7bP1S5TC2wKTaDWPxR4Q== X-Google-Smtp-Source: ACHHUZ4KUw5NB3BOPHGF+oh7fuHhF9gCQe2opcFl/h4sFdwHa3h9ymnCb0ViPZg5quW6K3zoFzNnhA== X-Received: by 2002:a17:906:72ce:b0:96f:56ab:c69b with SMTP id m14-20020a17090672ce00b0096f56abc69bmr1766954ejl.3.1684924827732; Wed, 24 May 2023 03:40:27 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-33.fiber7.init7.net. [212.51.149.33]) by smtp.gmail.com with ESMTPSA id c25-20020a170906155900b0094f282fc29asm5554047ejd.207.2023.05.24.03.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 03:40:27 -0700 (PDT) Date: Wed, 24 May 2023 12:40:25 +0200 From: Daniel Vetter To: Oded Gabbay Subject: Re: [PATCH 0/7] Add a DRM driver to support AI Processing Unit (APU) Message-ID: Mail-Followup-To: Oded Gabbay , Kevin Hilman , Jeffrey Hugo , Alexandre Bailon , airlied@gmail.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, 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 References: <20230517145237.295461-1-abailon@baylibre.com> <7ha5xud3m7.fsf@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 6.1.0-7-amd64 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: dri-devel@lists.freedesktop.org, Alexandre Bailon , krzysztof.kozlowski+dt@linaro.org, sumit.semwal@linaro.org, bero@baylibre.com, Kevin Hilman , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org, Jeffrey Hugo , linaro-mm-sig@lists.linaro.org, robh+dt@kernel.org, linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com, jstephan@baylibre.com, nbelin@baylibre.com, angelogioacchino.delregno@collabora.com, linux-kernel@vger.kernel.org, tzimmermann@suse.de, christian.koenig@amd.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, May 24, 2023 at 01:27:00PM +0300, Oded Gabbay wrote: > On Wed, May 24, 2023 at 2:34 AM Kevin Hilman wrote: > > > > 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? > Maybe model it according to the tiny driver in drm display ? You can > then call it tiny_apu :-) > Disclosure: It was Daniel's suggestion, he can chime in with more > details on the tiny driver concept. Yeah so maybe a bit more detail on my thoughts: First this smells like a need bypass of the entire "we want open userspace for accel drivers" rule. The rule isn't quite a strict as for drm gpu drivers (not sure we ended up documenting exactly what, but iirc the consensus was that for build-time only dependencies we're ok with downstream compilers), but it's still there. And at least from a quick look apu.ko and libapu just look like a generic accel interface, and that's not enough. For the big training engines it's more or less "enough to run pytorch, but it can be really slow", not sure what the right standard for these inference-only drivers should be. So that's the first reason why I don't like this. The other is that I think if we do end up with a pile of tiny accel drivers, we should probably look into something like simmpledrm for the tiny display drivers. Probably still IP specific ioctls (at least most) so that IP specific job knows and all that are easy, but then just pass to a framework that simplifies a drm gem driver to "write ptes" and "run job" callback, maybe with an optional "create/destroy vm/ctx" for hw which can do that. So maybe we end up with a drivers/accel/tiny and a bunch more helpers around the existing gem ones. The rule we have for drm/tiny is "1 file, less than 1kloc", and there's a bunch of them. I do think we can achieve the same for tiny accel inference engines (but it's still a bit a road). Maybe tiny accel is more like "less than 5kloc" since you need a bit more glue for the driver specific ioctl stuff - maybe that's only needed for the submit ioctl, maybe also for buffer map/unmap and creation. Also note that there's an entire pile of in-flight work for adding new helpers to the gem world to make this all easier. Once we have gpuva and exec helpers there not much glue left to tie it all together with the scheduler. But the real crux is that an accel inference driver really needs to have enough userspace to do an actual inference job with some android/cros/whatever framework for inference (there's just too many). -Daniel > Oded > > > > > 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 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch