Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6442158rwb; Mon, 12 Dec 2022 01:47:07 -0800 (PST) X-Google-Smtp-Source: AA0mqf6Gd+zH4qIQPsKLyIal7cVARW9GluAXRXZQ/evlZ6V4wtjYEqRjTwP0fNj46tXQ8XjIGwuc X-Received: by 2002:a17:902:ce02:b0:186:5d29:1633 with SMTP id k2-20020a170902ce0200b001865d291633mr17314642plg.50.1670838427363; Mon, 12 Dec 2022 01:47:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670838427; cv=none; d=google.com; s=arc-20160816; b=pAOzQ2PxOinchHvZxDygDndIqIj1OS+n/5uiWbzR93lV99vw0Cys+lnD3P12ARZyRi qnhq6rp+oIcCdgOGVwB/yh1XruWl3VuWVhreMAHlGrxeZCCODxMmc2Z7EVer4UhaCC0A Arwow5m4gDCcG1ZAp1odaX6TnaVZhq26Cyp8hr/VZ+aDsMugexZISMuBsR9mt+j7sxG4 3cX1HEKBn6ggC4n7mvMUuuUPISqLlbkfspwE065MOqGM4CUaINr4c8bOzG7gtd8IDR2K 9pYE/HYyd3JnGBIYEMY2bikQbxjPyfyZQXhjXaPindSjPKyg1tMDTfIXqKtC8CBZLhzs oMaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=/ugxOO4h97CH/54fmJvRAowJOYQpQfbhIWUc055D2to=; b=KBGM7UHOqACDA8KN6aPHaHVfjUqtxSPVd6XKXroy+4i/J2m424jlzsURegz19nAYLL OORmVw0r5bCUo7wbtSeEVYpdVN5QqhYFP/NXDRcsPUlSd2FHDYkYmk3SP+REzuYQK1R7 8Hu4m+UMHoKsygjQ4WHDQR9Vswr+VmP3oFWdnHl+8/Y3wvw7+kxrjum32vRaihsoefdC Vc7XH4nPwTZUZ+qxVQp5UVVYqNNr2Kcn6cj+NIvxNLDFtedKoKF71a9rNVsXCsm1toaR 8Re3gfZu8TzzjpSWO/CR+poP3FTT+B3DTkdfmeEuoms/bi6SEZcQPjRl5RbJ9YLU5bWs mupQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tB0jPT22; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id im22-20020a170902bb1600b00186ba56bda8si8548970plb.61.2022.12.12.01.46.57; Mon, 12 Dec 2022 01:47:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tB0jPT22; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231599AbiLLJTg (ORCPT + 75 others); Mon, 12 Dec 2022 04:19:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231851AbiLLJSg (ORCPT ); Mon, 12 Dec 2022 04:18:36 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F4E91082; Mon, 12 Dec 2022 01:17:53 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B5E75B80BD9; Mon, 12 Dec 2022 09:17:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6215C433D2; Mon, 12 Dec 2022 09:17:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670836670; bh=1J+2d5+KvpjVI5MmaRd9+WDqn+ERDvdaS29aqYsYa/Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=tB0jPT22rUA0Zv5wTTTjEgcYyrnXRIHk5CWAT3kHJaDGTcpzkRsJ5H/cY80k+sk95 kLMJHHg2NwjoeYdQYG0ia+kx3dDvJUAhsdEGLKkDHE1PuhW1ULtmL8rDYMsIP9cF5p BYK8zgOj3iPuoHt+5cNWwKQUYfWsfvfypQD8WOika4mVQDE/x7gT+RxB7eJDEIhh04 6odPC/RP2+1+oNUwUUljXc0+Fff9h0eSW3GOEiYLKjVmOw70666kL0JZGBe6c/riC/ OJiQovjdKXOvKc90Tk379+kLC+5segGoy52cuhWmJyDMCmI/lyEAwtWtHo6aY9S0YL 4NbSGlqYE8+vw== Message-ID: <7d73a0a4-c5e2-74bb-4ef9-9bc2dadd6272@kernel.org> Date: Mon, 12 Dec 2022 11:17:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [EXTERNAL] Re: [PATCH v11 3/6] remoteproc: pru: Add APIs to get and put the PRU cores Content-Language: en-US To: Md Danish Anwar , MD Danish Anwar , Mathieu Poirier , Krzysztof Kozlowski , Rob Herring Cc: Suman Anna , "Andrew F . Davis" , nm@ti.com, vigneshr@ti.com, srk@ti.com, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20221207110411.441692-1-danishanwar@ti.com> <20221207110411.441692-4-danishanwar@ti.com> <77d79939-53bb-bc27-a8f8-ea5bf509a15f@kernel.org> From: Roger Quadros In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Danish, On 09/12/2022 06:55, Md Danish Anwar wrote: > Hi Roger, > > On 08/12/22 16:05, Roger Quadros wrote: >> Hi, >> >> On 07/12/2022 13:04, MD Danish Anwar wrote: >>> Add two new APIs, pru_rproc_get() and pru_rproc_put(), to the PRU >>> driver to allow client drivers to acquire and release the remoteproc >>> device associated with a PRU core. The PRU cores are treated as >>> resources with only one client owning it at a time. >>> >>> The pru_rproc_get() function returns the rproc handle corresponding >>> to a PRU core identified by the device tree "ti,prus" property under >>> the client node. The pru_rproc_put() is the complementary function >>> to pru_rproc_get(). >>> >>> Signed-off-by: Suman Anna >>> Signed-off-by: Tero Kristo >>> Signed-off-by: Grzegorz Jaszczyk >>> Signed-off-by: MD Danish Anwar >>> --- >>> drivers/remoteproc/pru_rproc.c | 133 ++++++++++++++++++++++++++++++++- >>> include/linux/pruss.h | 29 +++++++ >>> 2 files changed, 160 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c >>> index a1a208b31846..7d4ed39b3772 100644 >>> --- a/drivers/remoteproc/pru_rproc.c >>> +++ b/drivers/remoteproc/pru_rproc.c >>> @@ -2,12 +2,14 @@ >>> /* >>> * PRU-ICSS remoteproc driver for various TI SoCs >>> * >>> - * Copyright (C) 2014-2020 Texas Instruments Incorporated - https://www.ti.com/ >>> + * Copyright (C) 2014-2022 Texas Instruments Incorporated - https://www.ti.com/ >>> * >>> * Author(s): >>> * Suman Anna >>> * Andrew F. Davis >>> * Grzegorz Jaszczyk for Texas Instruments >>> + * Puranjay Mohan >>> + * Md Danish Anwar >>> */ >>> >>> #include >>> @@ -112,6 +114,8 @@ struct pru_private_data { >>> * @rproc: remoteproc pointer for this PRU core >>> * @data: PRU core specific data >>> * @mem_regions: data for each of the PRU memory regions >>> + * @client_np: client device node >>> + * @lock: mutex to protect client usage >>> * @fw_name: name of firmware image used during loading >>> * @mapped_irq: virtual interrupt numbers of created fw specific mapping >>> * @pru_interrupt_map: pointer to interrupt mapping description (firmware) >>> @@ -127,6 +131,8 @@ struct pru_rproc { >>> struct rproc *rproc; >>> const struct pru_private_data *data; >>> struct pruss_mem_region mem_regions[PRU_IOMEM_MAX]; >>> + struct device_node *client_np; >>> + struct mutex lock; >>> const char *fw_name; >>> unsigned int *mapped_irq; >>> struct pru_irq_rsc *pru_interrupt_map; >>> @@ -147,6 +153,125 @@ void pru_control_write_reg(struct pru_rproc *pru, unsigned int reg, u32 val) >>> writel_relaxed(val, pru->mem_regions[PRU_IOMEM_CTRL].va + reg); >>> } >>> >>> +static struct rproc *__pru_rproc_get(struct device_node *np, int index) >>> +{ >>> + struct rproc *rproc; >>> + phandle rproc_phandle; >>> + int ret; >>> + >>> + ret = of_property_read_u32_index(np, "ti,prus", index, &rproc_phandle); >>> + if (ret) >>> + return ERR_PTR(ret); >>> + >>> + rproc = rproc_get_by_phandle(rproc_phandle); >>> + if (!rproc) { >>> + ret = -EPROBE_DEFER; >>> + goto err_no_rproc_handle; >>> + } >>> + >>> + /* make sure it is PRU rproc */ >>> + if (!is_pru_rproc(rproc->dev.parent)) { >>> + rproc_put(rproc); >>> + return ERR_PTR(-ENODEV); >>> + } >>> + >>> + return rproc; >>> + >>> +err_no_rproc_handle: >>> + rproc_put(rproc); >>> + return ERR_PTR(ret); >>> +} >>> + >>> +/** >>> + * pru_rproc_get() - get the PRU rproc instance from a device node >>> + * @np: the user/client device node >>> + * @index: index to use for the ti,prus property >>> + * @pru_id: optional pointer to return the PRU remoteproc processor id >>> + * >>> + * This function looks through a client device node's "ti,prus" property at >>> + * index @index and returns the rproc handle for a valid PRU remote processor if >>> + * found. The function allows only one user to own the PRU rproc resource at a >>> + * time. Caller must call pru_rproc_put() when done with using the rproc, not >>> + * required if the function returns a failure. >>> + * >>> + * When optional @pru_id pointer is passed the PRU remoteproc processor id is >>> + * returned. >>> + * >>> + * Return: rproc handle on success, and an ERR_PTR on failure using one >>> + * of the following error values >>> + * -ENODEV if device is not found >>> + * -EBUSY if PRU is already acquired by anyone >>> + * -EPROBE_DEFER is PRU device is not probed yet >>> + */ >>> +struct rproc *pru_rproc_get(struct device_node *np, int index, >>> + enum pruss_pru_id *pru_id) >>> +{ >>> + struct rproc *rproc; >>> + struct pru_rproc *pru; >>> + struct device *dev; >>> + int ret; >>> + >>> + rproc = __pru_rproc_get(np, index); >>> + if (IS_ERR(rproc)) >>> + return rproc; >>> + >>> + pru = rproc->priv; >>> + dev = &rproc->dev; >>> + >>> + mutex_lock(&pru->lock); >>> + >>> + if (pru->client_np) { >>> + mutex_unlock(&pru->lock); >>> + put_device(dev); >> >> Is this put_device() to counter balance the get_device() you had earlier? >> Is it still needed? >>> Did we do the right thing by getting rid of the additional get_device()? >> I didn't see a reason for it. >> > > The previous get_device() in __pru_rproc_get() was additional/not required as > the same get_device() was called by rproc_get_by_phandle() API before it's > completion. > > So that get_device() is not needed. > > The put_device() here is to counter the get_device() called by > rproc_get_by_phandle() in the API __pru_rproc_get(). > > So I think, this put_device() is still needed. But at the end of this function we are calling rproc_put() which also does a put_device(), right? > >>> + ret = -EBUSY; >>> + goto err_no_rproc_handle; >>> + } >>> + >>> + pru->client_np = np; >>> + >>> + mutex_unlock(&pru->lock); >>> + >>> + if (pru_id) >>> + *pru_id = pru->id; >>> + >>> + return rproc; >>> + >>> +err_no_rproc_handle: >>> + rproc_put(rproc); >>> + return ERR_PTR(ret); >>> +} >>> +EXPORT_SYMBOL_GPL(pru_rproc_get); cheers, -roger