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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 564DAC433F5 for ; Wed, 29 Sep 2021 14:18:06 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 1FAA7613CD for ; Wed, 29 Sep 2021 14:18:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1FAA7613CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=KptFBsM0lPl6lxxvOMtE9WF2qjnYOnnsFHlEceTMAkM=; b=V5Yh2PosMIpc9X XvqE1l64MTQzrJTUw71RyI1hMSammFDGZ08cmyNBm/C+g9vmTj69N0fXNSZO71uv7kUjb2BeHvqd4 RaC1QG6uVwcTHYos7C+hUonlQmbHy7azaSSun9Gt7MehM7QZdF6XPrLmxIj2YGly8Gu6TXmaDWU7H Zv6BBxQrTv/QQCxXd9UDYioKIedk8NFFzx5d2XtEiSvkX3suavMXyU6gCpvSyjc4aAMC5wip2XsBu zT+oMikFrdHFTH5qojOlSG2s0Yf4Ijm+TVMu8n01ZvUgTdZggqDJrw6u9+UdBaHbv/MJsHvpA8PER AHbSIdnvTWsCrpW5P+SQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVaN5-00BHcC-Th; Wed, 29 Sep 2021 14:15:44 +0000 Received: from mail-ot1-x334.google.com ([2607:f8b0:4864:20::334]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVaMy-00BHZy-RF for linux-arm-kernel@lists.infradead.org; Wed, 29 Sep 2021 14:15:41 +0000 Received: by mail-ot1-x334.google.com with SMTP id g62-20020a9d2dc4000000b0054752cfbc59so3046592otb.1 for ; Wed, 29 Sep 2021 07:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1bOpTf6Jukz1rQn04/kh8ik747nwWUC8rE65lhqO1Xs=; b=MLodxKDCjbPbVfHqmbcLc+lFz7Fm4nAzcqoQdx/1K7UeQ8nwYJyY9ZgA2Viz20B1Wf FHqkYzOZFhsSWsnJyzin379oB7znNmpJnokdu8kAnQKBU1z0UmsmeSGDtWoZuzX2X8Fk lJYSuwZwGQW0BhwNYWdBnNh4lKmHhHBKx3X3b5X9fBrRGdWjm/MeGfr0jJAwCMhE6DoP DNQv24J1CTfdOSXLezlSaN00GTfkp2rpHcNAxUNxpBKFHdL3jRSaTXs2geRHaYhVDMuO 0YTHrb/j5JJfDzPIkXN+WMGpSKYtRpZvvGBWdf+KOnDRFnVY8mBeUnh0VzB3NX56xC8u e4Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1bOpTf6Jukz1rQn04/kh8ik747nwWUC8rE65lhqO1Xs=; b=qnKHcMhuHn9PEroXJbIimrrpDRNCJ2hoyCB1NJ3pFKNzZ/zL2Q/pD89WY/1VTR/NfP UMpYL1596PbyKxBINubs33eDejk2I6OfrV/m5IhaBKMKStqZk0YVQsg66ieqxelMofzH N9f/GAgxeBQXOa/WBcms7IL6jidoqfNytpP+pJnEr7J1EP8EdnQBtl2f1NM+bDMQ+XMt uIAjLNi7GbkxGIhCGA3/i/IQAXMRcpzm4nwbSNmlR+FBGcwKtPLb+3S332SxnuWOZ5cQ 3y+pbxv9IFnH6bwtr5oyRVNKUxPzK3wlBYHt5GLFgvlRX98ZYjS74NPuCpwvkAWYOdA+ 6wYg== X-Gm-Message-State: AOAM532+EHC/6IfanOYkts35xI8O2TlBMv+SKbuJmAu7ALUyvHUtTArJ 3RE4KKtIJEvhB7Qz13Y9WAN7dA== X-Google-Smtp-Source: ABdhPJy89LkTd283QjwrvqhgJMbYUlI7RUIpOdWGGkYh7mMYYiT+wqNtJ9odI5KEX39BP+qpFI+L7A== X-Received: by 2002:a05:6830:455:: with SMTP id d21mr228973otc.300.1632924934665; Wed, 29 Sep 2021 07:15:34 -0700 (PDT) Received: from yoga (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id s29sm468815otg.60.2021.09.29.07.15.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 07:15:34 -0700 (PDT) Date: Wed, 29 Sep 2021 09:15:31 -0500 From: Bjorn Andersson To: Charles Keepax Cc: Arnd Bergmann , Arnd Bergmann , Mark Brown , Liam Girdwood , Simon Trimmer , Michael Ellerman , Russell King , Catalin Marinas , Will Deacon , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Paul Walmsley , Palmer Dabbelt , Albert Ou , Thomas Gleixner , Ingo Molnar , Borislav Petkov , the arch/x86 maintainers , "H. Peter Anvin" , Geert Uytterhoeven , Linus Walleij , Andrew Morton , Greg Kroah-Hartman , Linux ARM , Linux Kernel Mailing List , linux-ia64@vger.kernel.org, "open list:BROADCOM NVRAM DRIVER" , Parisc List , linux-riscv Subject: Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally Message-ID: References: <20210928075216.4193128-1-arnd@kernel.org> <20210928083751.GG9223@ediswmail.ad.cirrus.com> <20210928092400.GH9223@ediswmail.ad.cirrus.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210928092400.GH9223@ediswmail.ad.cirrus.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210929_071536_989411_24A29A47 X-CRM114-Status: GOOD ( 45.28 ) 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 On Tue 28 Sep 04:24 CDT 2021, Charles Keepax wrote: > On Tue, Sep 28, 2021 at 10:51:36AM +0200, Arnd Bergmann wrote: > > On Tue, Sep 28, 2021 at 10:37 AM Charles Keepax > > wrote: > > > I guess the question might be where else would said code go? > > > drivers/firmware seemed most obvious, all the other locations > > > I can think of don't really make sense. Can't really put it a bus > > > like spi/i2c etc. because we have parts on many buses. Can't > > > really put it in a functional subsystem (audio/input etc.) since > > > the whole idea was to try and get some independence from that so > > > we don't have parts including subsystems they don't use. Could > > > maybe put it in MFD, but no hard guarantee every part using it > > > will be an MFD device and I am fairly confident Lee will feel it > > > isn't MFD code as it doesn't relate to managing multiple devices. > > > Only other option I can think of would be to make some sort of > > > drivers/dsp or maybe drivers/cs_dsp, but not clear to me that is > > > obviously better than using drivers/firmware. > > > > Other DSPs use the drivers/remoteproc/ subsystem, but that > > is more for general-purpose DSPs that can load application > > specific firmware rather than loading a single firmware blob > > as you'd normally do with the request_firmware() style interface. > > > > Not sure if that fits what you do. Can you point to a high-level > > description of what this DSP does besides audio, and how > > flexible it is? That might help find the right place for this. > > Hm... wasn't aware of that one, we should probably investigate that > a little more at this end. From a quick look, seems a bit more like > it is designed for much larger more general purpose probably memory > mapped DSPs. I guess our code is a little more firmware parsing > and loading, and a bit less generic remote proceedure call stuff. > You're correct, remoteproc tends to situations where you have multi-function firmware; be it at a single point in time, or due to different firmware choices. Where you essentially boot some firmware on the remoteproc and from that instantiate one of more functional devices based on the loaded firmware. > I am not sure there is great deal available publically on the > DSP core. It is talked about in a few of our datasheets, see > section 4.4 in [1]. But a basic description might be it is a > signal processing focused, very small DSP core. If can be loaded > with different firmwares at runtime, and indeed might be doing say > echo cancellation in one use-case, or always on voice detect in > another. Functionally it is very unlikely to be used for anything > besides signal processing inside the device it is in, since it is > typically quite integrated with that hardware and will be sitting > behind a slow bus, like I2C or SPI. > To me it sounds like the main difference compared to above is that you have a single function that owns and controls the DSP and implements that function - i.e. the audio driver probes, boots the DSP, if there's a problem the audio driver will handle it etc. When it comes to firmware parsing, that might be a somewhat unrelated topic. E.g. in the Qualcomm case, the same customized ELF header is used in both for remoteproc devices and in function-specific devices. For this we extracted the relevant functions into a library of some common helpers, which can be found in drivers/soc/qcom/mdt_loader.c. Regards, Bjorn > Current users are all audio, planning to upstream some haptics > parts soon, with possible other uses in the future. > > [1] https://statics.cirrus.com/pubs/proDatasheet/CS48L32_DS1219F4.pdf > > Thanks, > Charles _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel