Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally
- From: Mark Brown <broonie@xxxxxxxxxx>
- Date: Tue, 28 Sep 2021 12:25:19 +0100
- Cc: Arnd Bergmann <arnd@xxxxxxxxxx>, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Liam Girdwood <lgirdwood@xxxxxxxxx>, Simon Trimmer <simont@xxxxxxxxxxxxxxxxxxxxx>, Michael Ellerman <mpe@xxxxxxxxxxxxxx>, Russell King <linux@xxxxxxxxxxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>, "James E.J. Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, Helge Deller <deller@xxxxxx>, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, Albert Ou <aou@xxxxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Geert Uytterhoeven <geert+renesas@xxxxxxxxx>, Linus Walleij <linus.walleij@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>, Linux ARM <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, linux-ia64@xxxxxxxxxxxxxxx, "open list:BROADCOM NVRAM DRIVER" <linux-mips@xxxxxxxxxxxxxxx>, Parisc List <linux-parisc@xxxxxxxxxxxxxxx>, linux-riscv <linux-riscv@xxxxxxxxxxxxxxxxxxx>
- In-reply-to: <20210928092400.GH9223@ediswmail.ad.cirrus.com>
- References: <20210928075216.4193128-1-arnd@kernel.org> <20210928083751.GG9223@ediswmail.ad.cirrus.com> <CAK8P3a11c6eLRWKvQeSqvEicc9bMDeEEGV5fygTidoRzYf9KnQ@mail.gmail.com> <20210928092400.GH9223@ediswmail.ad.cirrus.com>
- User-agent: Mutt/1.10.1 (2018-07-13)
On Tue, Sep 28, 2021 at 09:24:00AM +0000, Charles Keepax wrote:
> On Tue, Sep 28, 2021 at 10:51:36AM +0200, Arnd Bergmann wrote:
> > 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.
Right, that was why I didn't suggest remoteproc - the DSPs wm_adsp
covers seem much smaller than fits comfortably with remoteproc. You
probably could make it fit though.
Attachment:
signature.asc
Description: PGP signature
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]