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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6948BC4363D for ; Sat, 3 Oct 2020 09:04:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 25434207DE for ; Sat, 3 Oct 2020 09:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601715898; bh=Lis1UA7evOjm7bj9t1+4kqOmMH5ClghWGtsEc9Jpi0Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=rMPWXTyHdlYu7cmyOw7XXQOznHiYInsX09gXGY2Rj1N7oNAud4EemFSdXPMcHp4hJ sIBXfEbRKudu2p+RYvMw157/cicXGWJxy+1SledFTJkuM8XkoosON5q1veeo11ZgGq aAN3CSbx0thZyLIhqh76YzBZ/TMDw25PBosAKKNc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725790AbgJCJE5 (ORCPT ); Sat, 3 Oct 2020 05:04:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:39308 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725648AbgJCJE5 (ORCPT ); Sat, 3 Oct 2020 05:04:57 -0400 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B8BE4206F8; Sat, 3 Oct 2020 09:04:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601715896; bh=Lis1UA7evOjm7bj9t1+4kqOmMH5ClghWGtsEc9Jpi0Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KVzsukWHXL/c7SXWnZp/QRL7nS9XxxcbR2/JjOr45weKpTJfvY71zKb/pFzxEOttn TqJDKNCX0Ye0aZg/HP+fM8Ew/4pEzF9p1MeaepR46SjJDODP+MJ2GXGSCajI2vz/Oz JZvPTSvVbDYUjBbMd6Qmcl6QdZG4P9lAxd7R4M7A= Date: Sat, 3 Oct 2020 12:04:52 +0300 From: Leon Romanovsky To: Dave Ertman , gregkh@linuxfoundation.org Cc: linux-rdma@vger.kernel.org, linux-netdev , alsa-devel@alsa-project.org Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client support Message-ID: <20201003090452.GF3094@unreal> References: <20201001050534.890666-1-david.m.ertman@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201001050534.890666-1-david.m.ertman@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org Hi Dave, I don't know why did you send this series separately to every mailing list, but it is not correct thing to do. RDMA ML and discussion: https://lore.kernel.org/linux-rdma/20201001050534.890666-1-david.m.ertman@intel.com/T/#t Netdev ML (completely separated): https://lore.kernel.org/netdev/20201001050851.890722-1-david.m.ertman@intel.com/ Alsa ML (separated too): https://lore.kernel.org/alsa-devel/20200930225051.889607-1-david.m.ertman@intel.com/ Thanks On Wed, Sep 30, 2020 at 10:05:28PM -0700, Dave Ertman wrote: > Brief history of Ancillary Bus > ============================== > The ancillary bus code was originally submitted upstream as virtual > bus, and was submitted through the netdev tree.  This process generated > up to v4.  This discussion can be found here: > https://lore.kernel.org/netdev/0200520070227.3392100-2-jeffrey.t.kirsher@intel.com/T/#u > > At this point, GregKH requested that we take the review and revision > process to an internal mailing list and garner the buy-in of a respected > kernel contributor. > > The ancillary bus (then known as virtual bus) was originally submitted > along with implementation code for the ice driver and irdma drive, > causing the complication of also having dependencies in the rdma tree. > This new submission is utilizing an ancillary bus consumer in only the > sound driver tree to create the initial implementation and a single > user. > > Since implementation work has started on this patch set, there have been > multiple inquiries about the time frame of its completion. It appears > that there will be numerous consumers of this functionality. > > The process of internal review and implementation using the sound > drivers generated 19 internal versions.  The changes, including the name > change from virtual bus to ancillary bus, from these versions can be > summarized as the following: > > - Fixed compilation and checkpatch errors > - Improved documentation to address the motivation for virtual bus. > - Renamed virtual bus to ancillary bus > - increased maximum device name size > - Correct order in Kconfig and Makefile > - removed the mid-layer adev->release layer for device unregister > - pushed adev->id management to parent driver > - all error paths out of ancillary_device_register return error code > - all error paths out of ancillary_device_register use put_device > - added adev->name element > - modname in register cannot be NULL > - added KBUILD_MODNAME as prefix for match_name > - push adev->id responsibility to registering driver > - uevent now parses adev->dev name > - match_id function now parses adev->dev name > - changed drivers probe function to also take an ancillary_device_id param > - split ancillary_device_register into device_initialize and device_add > - adjusted what is done in device_initialize and device_add > - change adev to ancildev and adrv to ancildrv > - change adev to ancildev in documentation > > This submission is the first time that this patch set will be sent to > the alsa-devel mailing list, so it is currently being submitted as > version 1. > > ========================== > > Introduces the ancillary bus implementation along with the example usage > in the Sound Open Firmware(SOF) audio driver. > > In some subsystems, the functionality of the core device > (PCI/ACPI/other) may be too complex for a single device to be managed as > a monolithic block or a part of the functionality might need to be > exposed to a different subsystem. Splitting the functionality into > smaller orthogonal devices makes it easier to manage data, power > management and domain-specific communication with the hardware. Also, > common ancillary_device functionality across primary devices can be > handled by a common ancillary_device. A key requirement for such a split > is that there is no dependency on a physical bus, device, register > accesses or regmap support. These individual devices split from the core > cannot live on the platform bus as they are not physical devices that > are controlled by DT/ACPI. The same argument applies for not using MFD > in this scenario as it relies on individual function devices being > physical devices that are DT enumerated. > > An example for this kind of requirement is the audio subsystem where a > single IP handles multiple entities such as HDMI, Soundwire, local > devices such as mics/speakers etc. The split for the core's > functionality can be arbitrary or be defined by the DSP firmware > topology and include hooks for test/debug. This allows for the audio > core device to be minimal and tightly coupled with handling the > hardware-specific logic and communication. > > The ancillary bus is intended to be minimal, generic and avoid > domain-specific assumptions. Each ancillary bus device represents a part > of its parent functionality. The generic behavior can be extended and > specialized as needed by encapsulating an ancillary bus device within > other domain-specific structures and the use of .ops callbacks. > > The SOF driver adopts the ancillary bus for implementing the > multi-client support. A client in the context of the SOF driver > represents a part of the core device's functionality. It is not a > physical device but rather an ancillary device that needs to communicate > with the DSP via IPCs. With multi-client support,the sound card can be > separated into multiple orthogonal ancillary devices for local devices > (mic/speakers etc), HDMI, sensing, probes, debug etc. In this series, > we demonstrate the usage of the ancillary bus with the help of the IPC > test client which is used for testing the serialization of IPCs when > multiple clients talk to the DSP at the same time. > > Dave Ertman (1): > Add ancillary bus support > > Fred Oh (1): > ASoC: SOF: debug: Remove IPC flood test support in SOF core > > Ranjani Sridharan (4): > ASoC: SOF: Introduce descriptors for SOF client > ASoC: SOF: Create client driver for IPC test > ASoC: SOF: ops: Add ops for client registration > ASoC: SOF: Intel: Define ops for client registration > > Documentation/driver-api/ancillary_bus.rst | 230 +++++++++++++++ > Documentation/driver-api/index.rst | 1 + > drivers/bus/Kconfig | 3 + > drivers/bus/Makefile | 3 + > drivers/bus/ancillary.c | 191 +++++++++++++ > include/linux/ancillary_bus.h | 58 ++++ > include/linux/mod_devicetable.h | 8 + > scripts/mod/devicetable-offsets.c | 3 + > scripts/mod/file2alias.c | 8 + > sound/soc/sof/Kconfig | 29 +- > sound/soc/sof/Makefile | 7 + > sound/soc/sof/core.c | 12 + > sound/soc/sof/debug.c | 230 --------------- > sound/soc/sof/intel/Kconfig | 9 + > sound/soc/sof/intel/Makefile | 3 + > sound/soc/sof/intel/apl.c | 18 ++ > sound/soc/sof/intel/bdw.c | 18 ++ > sound/soc/sof/intel/byt.c | 22 ++ > sound/soc/sof/intel/cnl.c | 18 ++ > sound/soc/sof/intel/intel-client.c | 49 ++++ > sound/soc/sof/intel/intel-client.h | 26 ++ > sound/soc/sof/ops.h | 14 + > sound/soc/sof/sof-client.c | 117 ++++++++ > sound/soc/sof/sof-client.h | 65 +++++ > sound/soc/sof/sof-ipc-test-client.c | 314 +++++++++++++++++++++ > sound/soc/sof/sof-priv.h | 16 +- > 26 files changed, 1233 insertions(+), 239 deletions(-) > create mode 100644 Documentation/driver-api/ancillary_bus.rst > create mode 100644 drivers/bus/ancillary.c > create mode 100644 include/linux/ancillary_bus.h > create mode 100644 sound/soc/sof/intel/intel-client.c > create mode 100644 sound/soc/sof/intel/intel-client.h > create mode 100644 sound/soc/sof/sof-client.c > create mode 100644 sound/soc/sof/sof-client.h > create mode 100644 sound/soc/sof/sof-ipc-test-client.c > > -- > 2.26.2 >