Received: by 10.223.185.116 with SMTP id b49csp213023wrg; Thu, 8 Mar 2018 15:59:45 -0800 (PST) X-Google-Smtp-Source: AG47ELtXBUEN8xHeRwUA5rwFNsoEejAN4GeAc9scWAr38O64/WpzIdbm9qw3Uw2UmausidA8UyQ1 X-Received: by 10.99.123.79 with SMTP id k15mr22747903pgn.173.1520553585681; Thu, 08 Mar 2018 15:59:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520553585; cv=none; d=google.com; s=arc-20160816; b=Me8/x+rvJcd1tQe0fexsGSEM+gD4A5kQOAmNFNDPXo7m13BakwMKjp7X1bG7isn5Lo 3Vy+vWvnA7wbhCaMLp0IfxeexJRwKYe5jnc9Vq2PBN2Dv0CX2KkBClRN6J4RUooXUZho 4TzIpL0EPEosbAJi0Zwq89YnyUWNTj0IK0VxxZyCwSfHBkQPtFnbfVVm+eeEZJbrXcNo rhgsEc5g7kNV7QE0mYxw4KklI5Grf+PDTLIhHKfMERHcil5riXuPuLm4uyS/3Ol5Shh8 0pdukDmG8XyDKrX/vNwehHJj/rODHEj0eVdaDlGLgNgjbcxCAqPC5U+LM6gv6coVSKKQ jfHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=ZA5e1582LALe4W1vosCX8ma4CuVr7Mm8Ghth59C2Kdc=; b=d8AyT31AAZQAOieO6GvE7ULWdfH+LPzGVS1aXmM+G0lDk+cN44iywiJZCNlyKq2b5V s+o0rj8ywhvXlySSfpFEU59nwKpYQyxoh8PDpm2noU58ZHyByJAd52V1yvFJ9MVoQJ5D cOji04uEYJWBNFVfHmEE7CHJ4Ztg+1iG2i2WX3a3jMuG/9VTM3kWlQhWs9ZgBDhcq+u/ V9d3Nkq0rgLPTIu7S/w04xkwM3Vbcm8lW9pNZKdPqMnfpD357n2mpPwRLmdiTn3vSyG8 rmL6Ik6QbvlrwrFceD0d/Mh6qh8crM6Bu3QRybQed1hMm+OhhGzYm1n92UgbGrZe30lf dZWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=L0o1WvlL; dkim=pass header.i=@codeaurora.org header.s=default header.b=Vtk0/bjv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 61-v6si15765278plf.640.2018.03.08.15.59.29; Thu, 08 Mar 2018 15:59:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=L0o1WvlL; dkim=pass header.i=@codeaurora.org header.s=default header.b=Vtk0/bjv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751189AbeCHX6e (ORCPT + 99 others); Thu, 8 Mar 2018 18:58:34 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:49294 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbeCHX6d (ORCPT ); Thu, 8 Mar 2018 18:58:33 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id AB7976022C; Thu, 8 Mar 2018 23:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520553512; bh=XmuPghc8Ub17voN+vyRppwmmE30N7OxHcM7AsPe5yaY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L0o1WvlL68SKOPLdzMA7JHRKLlunVmXADVHcLvK++KSLHjw0CFvqyN3WN9qv25ahm xAXYoAn+iVSjWbeAajaDBaUqh4Pvf/Wansj1ZSRt62eDmi8vFXK2fmy3xRfmPqQ9pv 38cCnASBSoP1Dh4DOZzENG2duGwjElQIqPbWseqM= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ilina@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 78CBA6022C; Thu, 8 Mar 2018 23:58:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520553511; bh=XmuPghc8Ub17voN+vyRppwmmE30N7OxHcM7AsPe5yaY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vtk0/bjvy9nKYh7AZyCIveZ6q5+T2ErM40Ibev2MpXkpQod7MJT2TwiN9MsKEB0Q8 mc7bSAYTmqxeEe1uNEDsyEuXgMkskBd8k6HSJDQn3H9Gx6Vjhl3bLdt5x19gqX3m+X VFwxt91WhvZ70QYO2MiSFJHIiBYNMPh89eq5o+i4= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 78CBA6022C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=ilina@codeaurora.org Date: Thu, 8 Mar 2018 16:58:30 -0700 From: Lina Iyer To: Stephen Boyd Cc: andy.gross@linaro.org, david.brown@linaro.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, rnayak@codeaurora.org, bjorn.andersson@linaro.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS Message-ID: <20180308235830.GC3577@codeaurora.org> References: <20180302164317.10554-1-ilina@codeaurora.org> <20180302164317.10554-6-ilina@codeaurora.org> <152053809443.219802.15873554351627646762@swboyd.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <152053809443.219802.15873554351627646762@swboyd.mtv.corp.google.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 08 2018 at 12:41 -0700, Stephen Boyd wrote: >Quoting Lina Iyer (2018-03-02 08:43:12) >> Sleep and wake requests are sent when the application processor >> subsystem of the SoC is entering deep sleep states like in suspend. >> These requests help lower the system power requirements when the >> resources are not in use. >> >> Sleep and wake requests are written to the TCS slots but are not >> triggered at the time of writing. The TCS are triggered by the firmware >> after the last of the CPUs has executed its WFI. Since these requests >> may come in different batches of requests, it is job of this controller > >it is the job? > >> driver to find arrange the requests into the available TCSes. > >find and arrange? > Ok to both. >> >> Signed-off-by: Lina Iyer >> --- >> drivers/soc/qcom/rpmh-internal.h | 7 +++ >> drivers/soc/qcom/rpmh-rsc.c | 128 +++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 135 insertions(+) >> >> diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h >> index 1442a64ac4c5..65dfe1716265 100644 >> --- a/drivers/soc/qcom/rpmh-internal.h >> +++ b/drivers/soc/qcom/rpmh-internal.h >> @@ -13,6 +13,7 @@ >> #define MAX_CMDS_PER_TCS 16 >> #define MAX_TCS_PER_TYPE 3 >> #define MAX_TCS_NR (MAX_TCS_PER_TYPE * TCS_TYPE_NR) >> +#define MAX_TCS_SLOTS (MAX_CMDS_PER_TCS * MAX_TCS_PER_TYPE) >> >> struct rsc_drv; >> >> @@ -44,6 +45,8 @@ struct tcs_response { >> * @ncpt: number of commands in each TCS >> * @tcs_lock: lock for synchronizing this TCS writes >> * @responses: response objects for requests sent from each TCS >> + * @cmd_addr: flattened cache of cmds in sleep/wake TCS > >Maybe 'cmds' or 'cmd_cache'? > Ok >> + * @slots: indicates which of @cmd_addr are occupied >> */ >> struct tcs_group { >> struct rsc_drv *drv; >> @@ -54,6 +57,9 @@ struct tcs_group { >> int ncpt; >> spinlock_t tcs_lock; >> struct tcs_response *responses[MAX_TCS_PER_TYPE]; >> + u32 *cmd_addr; >> + DECLARE_BITMAP(slots, MAX_TCS_SLOTS); >> + > >Drop the newline please. > Done. >> }; >> >> /** >> @@ -450,6 +457,114 @@ int rpmh_rsc_send_data(struct rsc_drv *drv, struct tcs_request *msg) >> } >> EXPORT_SYMBOL(rpmh_rsc_send_data); >> >> +static int find_match(struct tcs_group *tcs, struct tcs_cmd *cmd, int len) > >const tcs and cmd? > Ok >> +{ >> + bool found = false; > >Drop. > Ok >> + int i = 0, j; >> + >> + /* Check for already cached commands */ >> + while ((i = find_next_bit(tcs->slots, MAX_TCS_SLOTS, i)) < > >for_each_set_bit(... ? > Ok >> + MAX_TCS_SLOTS) { >> + if (tcs->cmd_addr[i] != cmd[0].addr) { >> + i++; >> + continue; >> + } >> + /* sanity check to ensure the seq is same */ >> + for (j = 1; j < len; j++) { >> + WARN((tcs->cmd_addr[i + j] != cmd[j].addr), >> + "Message does not match previous sequence.\n"); >> + return -EINVAL; >> + } > >Can you fold the if and for loop together? > > for (j = 0; j < len; j++) { > if (tcs->cmd_addr[i + j] != cmd[j].addr) { > if (j == 0) > break; /* Try another slot */ > WARN("Message doesn't match previous sequence\n"); > return -EINVAL; > } else if (j == len - 1) { > return i; > } > } > } > > return -ENODATA; > OK >> + found = true; >> + break; >> + } >> + >> + return found ? i : -1; > >Is there space between slots? Just trying to understand how we >differentiate two adjacent cmd buffers with the bitmap scheme if this >loop is looking for free bits to find slots. Or maybe we need two >bitmaps where one is the allocated region and the other is something >indicating the start bit of a message > there could be holes and we may have a set of commands that we would like to fit together but may not sufficiently fit into any hole. So we pick the first contiguous available slots and go with it. We don't need multiple bitmaps. >> +} >> + >> +static int find_slots(struct tcs_group *tcs, struct tcs_request *msg, >> + int *m, int *n) >> +{ >> + int slot, offset; >> + int i = 0; >> + >> + /* Find if we already have the msg in our TCS */ >> + slot = find_match(tcs, msg->payload, msg->num_payload); >> + if (slot >= 0) >> + goto copy_data; > >Shouldn't this goto skip setting the bits in tcs->slots? > No, we overwrite what we found with this new data. >> + >> + /* Do over, until we can fit the full payload in a TCS */ >> + do { >> + slot = bitmap_find_next_zero_area(tcs->slots, MAX_TCS_SLOTS, >> + i, msg->num_payload, 0); >> + if (slot == MAX_TCS_SLOTS) >> + break; >> + i += tcs->ncpt; >> + } while (slot + msg->num_payload - 1 >= i); >> + >> + if (slot == MAX_TCS_SLOTS) >> + return -ENOMEM; > >Would be nice to remove this duplicate condition somehow. Maybe a goto? > I would return instead of the break earlier instead of this here. >> + >> +copy_data: >> + bitmap_set(tcs->slots, slot, msg->num_payload); >> + /* Copy the addresses of the resources over to the slots */ >> + if (tcs->cmd_addr) { > >find_match() above didn't check for tcs->cmd_addr. Does this ever happen >to fail? > Not allocated for active TCSes. I should be checking for it there as well. Not sure how I didnt see a failure. >> + for (i = 0; i < msg->num_payload; i++) >> + tcs->cmd_addr[slot + i] = msg->payload[i].addr; >> + } >> + >> + offset = slot / tcs->ncpt; >> + *m = offset + tcs->tcs_offset; >> + *n = slot % tcs->ncpt; >> + >> + return 0; >> +} >> + >> +static int tcs_ctrl_write(struct rsc_drv *drv, struct tcs_request *msg) >> +{ >> + struct tcs_group *tcs; >> + int m = 0, n = 0; >> + unsigned long flags; >> + int ret = 0; > >Drop initial assignment please. > Ok >> + >> + tcs = get_tcs_for_msg(drv, msg); >> + if (IS_ERR(tcs)) >> + return PTR_ERR(tcs); >> + >> + spin_lock_irqsave(&tcs->tcs_lock, flags); >> + /* find the m-th TCS and the n-th position in the TCS to write to */ >> + ret = find_slots(tcs, msg, &m, &n); >> + if (!ret) >> + __tcs_buffer_write(drv, m, n, msg); >> + spin_unlock_irqrestore(&tcs->tcs_lock, flags); >> + >> + return ret; >> +} >> + >[...] >> @@ -530,6 +645,19 @@ static int rpmh_probe_tcs_config(struct platform_device *pdev, >> tcs->tcs_mask = ((1 << tcs->num_tcs) - 1) << st; >> tcs->tcs_offset = st; >> st += tcs->num_tcs; >> + >> + /* >> + * Allocate memory to cache sleep and wake requests to >> + * avoid reading TCS register memory. >> + */ >> + if (tcs->type == ACTIVE_TCS) >> + continue; >> + >> + tcs->cmd_addr = devm_kzalloc(&pdev->dev, > >devm_kcalloc(&pdev->dev, tcs->num_tcs * ncpt, sizeof(u32) ? > Ok Thanks, Lina >> + sizeof(u32) * tcs->num_tcs * ncpt, >> + GFP_KERNEL); >> + if (!tcs->cmd_addr) >> + return -ENOMEM;