From patchwork Thu Jul 18 07:33:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bin Meng X-Patchwork-Id: 1133572 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PvdV74Zd"; dkim-atps=neutral Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 45q5dt21GPz9s00 for ; Thu, 18 Jul 2019 17:40:33 +1000 (AEST) Received: by lists.denx.de (Postfix, from userid 105) id 9A6BEC21F7E; Thu, 18 Jul 2019 07:39:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=FREEMAIL_FROM, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 7C965C21F82; Thu, 18 Jul 2019 07:35:17 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id D47F4C21F68; Thu, 18 Jul 2019 07:35:01 +0000 (UTC) Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by lists.denx.de (Postfix) with ESMTPS id 4CABBC21F37 for ; Thu, 18 Jul 2019 07:34:57 +0000 (UTC) Received: by mail-pg1-f194.google.com with SMTP id w10so12474224pgj.7 for ; Thu, 18 Jul 2019 00:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references; bh=qde3ULwgnTBImYditqP7TzIBvDUKGC7rj4uKgKvFwZA=; b=PvdV74ZdQYfYbBxnWWCubAJ2O4CKTKtBX6IHrzaW9vXV78GxPa5Qp4ut0FyPGc8/2I m4jy+DuKxycwvY0VbgEi5qWifl+Kdj3r+h6pEcAAhrRuj2b2fGnex+QZji2nxRyC1+jY 3t/rY6GjaH9ny3opUrb+s8bOMOW9BbbkK1jcUX8RnPXwBxQKKKYxvgwq65prYlisSKLi F3wCuRa2noNGpxBFAecm7zTsVP7ZmqExNQbnw/m3zYaZ91Tyvmx/zdCN+XusmywMfx0C 3TQ417QpQvCJWG1Ji349FpT/KuPCaN+sIGPq3nCrBK7bFsiuxgUeSjnOn9U9ml4zmL3r 6uDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=qde3ULwgnTBImYditqP7TzIBvDUKGC7rj4uKgKvFwZA=; b=ezacs9Wsv19lahuEIQ6cKTWQKiNaP2DTnmQsLGEMllWCIzV8k8R9czbS/OyhNhX/Ik hJUWPwTfNN9Hsq+N//7HJUOIWJzkVz0ncmIquaoSqBelCNTQ8k1CZWXTqiguhWiL8ZGX i9BgHg+s7iXABHfIo3bSskEvVyR25CGfB3PLFJllhFfsHEvcFLFLrWSZxmXUeEng5PU/ dHCfT39kEqFzwRQQjIgGKvmE/p0MENOVp7ALiJ4729KzM4/aVjYFFeI7nlrVBsJVbgA6 J6oFpX8L1XSsRwmXvvwWjFI647NZFIlZsWgP/pM8Vq7w1z0P2k++VhEjPYqH7eO6mnKe 7uhA== X-Gm-Message-State: APjAAAX8QLhuMw+5cfSGJ/XeZxNS1hHEBdoC5Wir/tczcVb7IhEkXmsY xFNsXXnu2uKKrt2IcX9zBvQ= X-Google-Smtp-Source: APXvYqxBfMhthTlaIg/m/tRzdLxzsKvcg2l335vOZ/xs9EUsYsCNrI4ldCyWU0f2bQ6dShpPfI7Exw== X-Received: by 2002:a63:ed06:: with SMTP id d6mr46161951pgi.267.1563435295883; Thu, 18 Jul 2019 00:34:55 -0700 (PDT) Received: from localhost.localdomain (unknown-224-80.windriver.com. [147.11.224.80]) by smtp.gmail.com with ESMTPSA id q1sm39859821pfn.178.2019.07.18.00.34.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 18 Jul 2019 00:34:55 -0700 (PDT) From: Bin Meng To: Tom Rini , Simon Glass , Wolfgang Denk , Heinrich Schuchardt , Mario Six , U-Boot Mailing List Date: Thu, 18 Jul 2019 00:33:58 -0700 Message-Id: <1563435275-22326-14-git-send-email-bmeng.cn@gmail.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1563435275-22326-1-git-send-email-bmeng.cn@gmail.com> References: <1563435275-22326-1-git-send-email-bmeng.cn@gmail.com> Subject: [U-Boot] [PATCH 13/50] doc: driver-model: Convert remoteproc-framework.txt to reST X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" Convert plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Bin Meng --- doc/driver-model/index.rst | 1 + ...proc-framework.txt => remoteproc-framework.rst} | 181 +++++++++++---------- 2 files changed, 92 insertions(+), 90 deletions(-) rename doc/driver-model/{remoteproc-framework.txt => remoteproc-framework.rst} (50%) diff --git a/doc/driver-model/index.rst b/doc/driver-model/index.rst index fd33215..c6353dc 100644 --- a/doc/driver-model/index.rst +++ b/doc/driver-model/index.rst @@ -15,3 +15,4 @@ Driver Model of-plat pci-info pmic-framework + remoteproc-framework diff --git a/doc/driver-model/remoteproc-framework.txt b/doc/driver-model/remoteproc-framework.rst similarity index 50% rename from doc/driver-model/remoteproc-framework.txt rename to doc/driver-model/remoteproc-framework.rst index c6dc00d..f21de0a 100644 --- a/doc/driver-model/remoteproc-framework.txt +++ b/doc/driver-model/remoteproc-framework.rst @@ -1,19 +1,12 @@ -# SPDX-License-Identifier: GPL-2.0+ -# -# (C) Copyright 2015 -# Texas Instruments Incorporated - http://www.ti.com/ -# +.. SPDX-License-Identifier: GPL-2.0+ +.. (C) Copyright 2015 +.. Texas Instruments Incorporated - http://www.ti.com/ Remote Processor Framework ========================== -TOC: -1. Introduction -2. How does it work - The driver -3. Describing the device using platform data -4. Describing the device using device tree -1. Introduction -=============== +Introduction +------------ This is an introduction to driver-model for Remote Processors found on various System on Chip(SoCs). The term remote processor is used to @@ -24,43 +17,44 @@ the processor on which we are functional. The simplified model depends on a single UCLASS - UCLASS_REMOTEPROC UCLASS_REMOTEPROC: -- drivers/remoteproc/rproc-uclass.c -- include/remoteproc.h + - drivers/remoteproc/rproc-uclass.c + - include/remoteproc.h Commands: -- common/cmd_remoteproc.c + - common/cmd_remoteproc.c Configuration: -CONFIG_REMOTEPROC is selected by drivers as needed -CONFIG_CMD_REMOTEPROC for the commands if required. - -2. How does it work - The driver -================================= - -Overall, the driver statemachine transitions are typically as follows: - (entry) - +-------+ - +---+ init | - | | | <---------------------+ - | +-------+ | - | | - | | - | +--------+ | -Load| | reset | | - | | | <----------+ | - | +--------+ | | - | |Load | | - | | | | - | +----v----+ reset | | - +-> | | (opt) | | - | Loaded +-----------+ | - | | | - +----+----+ | - | Start | - +---v-----+ (opt) | - +->| Running | Stop | -Ping +- | +--------------------+ -(opt) +---------+ + - CONFIG_REMOTEPROC is selected by drivers as needed + - CONFIG_CMD_REMOTEPROC for the commands if required. + +How does it work - The driver +----------------------------- + +Overall, the driver statemachine transitions are typically as follows:: + + (entry) + +-------+ + +---+ init | + | | | <---------------------+ + | +-------+ | + | | + | | + | +--------+ | + Load| | reset | | + | | | <----------+ | + | +--------+ | | + | |Load | | + | | | | + | +----v----+ reset | | + +-> | | (opt) | | + | Loaded +-----------+ | + | | | + +----+----+ | + | Start | + +---v-----+ (opt) | + +->| Running | Stop | + Ping +- | +--------------------+ + (opt) +---------+ (is_running does not change state) opt: Optional state transition implemented by driver. @@ -83,23 +77,25 @@ The driver follows a standard UCLASS DM. in the bare minimum form: -static const struct dm_rproc_ops sandbox_testproc_ops = { - .load = sandbox_testproc_load, - .start = sandbox_testproc_start, -}; +.. code-block:: c -static const struct udevice_id sandbox_ids[] = { - {.compatible = "sandbox,test-processor"}, - {} -}; + static const struct dm_rproc_ops sandbox_testproc_ops = { + .load = sandbox_testproc_load, + .start = sandbox_testproc_start, + }; + + static const struct udevice_id sandbox_ids[] = { + {.compatible = "sandbox,test-processor"}, + {} + }; -U_BOOT_DRIVER(sandbox_testproc) = { - .name = "sandbox_test_proc", - .of_match = sandbox_ids, - .id = UCLASS_REMOTEPROC, - .ops = &sandbox_testproc_ops, - .probe = sandbox_testproc_probe, -}; + U_BOOT_DRIVER(sandbox_testproc) = { + .name = "sandbox_test_proc", + .of_match = sandbox_ids, + .id = UCLASS_REMOTEPROC, + .ops = &sandbox_testproc_ops, + .probe = sandbox_testproc_probe, + }; This allows for the device to be probed as part of the "init" command or invocation of 'rproc_init()' function as the system dependencies define. @@ -110,8 +106,8 @@ provide a load and start function. We assume here that the device needs to be loaded and started, else, there is no real purpose of using the remoteproc framework. -3. Describing the device using platform data -============================================ +Describing the device using platform data +----------------------------------------- *IMPORTANT* NOTE: THIS SUPPORT IS NOT MEANT FOR USE WITH NEWER PLATFORM SUPPORT. THIS IS ONLY FOR LEGACY DEVICES. THIS MODE OF INITIALIZATION @@ -121,16 +117,18 @@ TO DM/FDT. Considering that many platforms are yet to move to device-tree model, a simplified definition of a device is as follows: -struct dm_rproc_uclass_pdata proc_3_test = { - .name = "proc_3_legacy", - .mem_type = RPROC_INTERNAL_MEMORY_MAPPED, - .driver_plat_data = &mydriver_data; -}; +.. code-block:: c -U_BOOT_DEVICE(proc_3_demo) = { - .name = "sandbox_test_proc", - .platdata = &proc_3_test, -}; + struct dm_rproc_uclass_pdata proc_3_test = { + .name = "proc_3_legacy", + .mem_type = RPROC_INTERNAL_MEMORY_MAPPED, + .driver_plat_data = &mydriver_data; + }; + + U_BOOT_DEVICE(proc_3_demo) = { + .name = "sandbox_test_proc", + .platdata = &proc_3_test, + }; There can be additional data that may be desired depending on the remoteproc driver specific needs (for example: SoC integration @@ -138,30 +136,33 @@ details such as clock handle or something similar). See appropriate documentation for specific remoteproc driver for further details. These are passed via driver_plat_data. -3. Describing the device using device tree -========================================== -/ { - ... - aliases { +Describing the device using device tree +--------------------------------------- + +.. code-block: none + + / { ... - remoteproc0 = &rproc_1; - remoteproc1 = &rproc_2; + aliases { + ... + remoteproc0 = &rproc_1; + remoteproc1 = &rproc_2; - }; - ... + }; + ... - rproc_1: rproc@1 { - compatible = "sandbox,test-processor"; - remoteproc-name = "remoteproc-test-dev1"; - }; + rproc_1: rproc@1 { + compatible = "sandbox,test-processor"; + remoteproc-name = "remoteproc-test-dev1"; + }; - rproc_2: rproc@2 { - compatible = "sandbox,test-processor"; - internal-memory-mapped; - remoteproc-name = "remoteproc-test-dev2"; + rproc_2: rproc@2 { + compatible = "sandbox,test-processor"; + internal-memory-mapped; + remoteproc-name = "remoteproc-test-dev2"; + }; + ... }; - ... -}; aliases usage is optional, but it is usually recommended to ensure the users have a consistent usage model for a platform.