Received: by 10.192.165.156 with SMTP id m28csp237128imm; Tue, 10 Apr 2018 20:38:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Z6gwtRdU0PmIierYv21VAqxjwngWTVYZ3l0FwtiLeIHAeckZz6+hGN6C9nr4TecSL++uV X-Received: by 2002:a17:902:778e:: with SMTP id o14-v6mr3216352pll.294.1523417913110; Tue, 10 Apr 2018 20:38:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523417913; cv=none; d=google.com; s=arc-20160816; b=f24/FOe/AIHWDtuFWhDoMsJsbChGIpRqn33OyYFGCoERMeOcCVmSv/sxnObSn0Okl8 4nC+9KTvWgFMziFAjtfvEQuMZblfNZ+kRxDNcKD/FDxdiLH3WI+Sxp+YV+MU7JpYXRID AEQvMVdypbozJuOvBI8V6F5LCKePKWpRFtHLpTUa+kC0aOcfXhyjgzHZeFjafQx4MxBG lePC3XtQyCPT7rA5qE1LRWOmGYBNJi/my3T8Y+iftu5h3ihp6bV+7J6aJ8/uAGU3O2XB EAgyX+FpZgXt2yaHsQKbx4uv9ERjIOSX2Xy8MbebE4Sqj2VBRk8/unuHenr2qMqxXXdj cnUw== 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:dkim-signature:arc-authentication-results; bh=4yVJ+ebZjLxv4nVt3ilZPK4Xusri5x/L4n4kVcUqNc0=; b=Uf4gdYuXeyoiWxbSj5BxAF1JV7UaIpZnXSo0ofVJBSYkRAocWeLFcZJ8XSMOkALSb/ NTM8fo9RXmT1KKTw2at7Pb96Rnk+zwKnzPmBeCMRWDCP2ABPmvvVPNaziOO4Fb2P1Sh/ tje0s8v2vKgiYpxJgp3yr7apyLSb/j3j+gicCiqctNPjNpEFbZbeUrRjhwHDAP+fTadO HR/DYfew9QMs+EtyVYAAvk8fmCG1zz5Q8IDAWGnF2CceTOz4TibjYWraw2dnn8jsxNhG AWWnJNQG5QKWs08YrIlaxTb8R2F0j2Jue7zs0Z9o5LCMA8qBX/LGysy1KK/5s3qy88F8 VSnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Am1BDKCF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x32-v6si219585pld.591.2018.04.10.20.37.56; Tue, 10 Apr 2018 20:38:33 -0700 (PDT) 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=@linaro.org header.s=google header.b=Am1BDKCF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752215AbeDKAbs (ORCPT + 99 others); Tue, 10 Apr 2018 20:31:48 -0400 Received: from mail-pl0-f51.google.com ([209.85.160.51]:40582 "EHLO mail-pl0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751991AbeDKAbr (ORCPT ); Tue, 10 Apr 2018 20:31:47 -0400 Received: by mail-pl0-f51.google.com with SMTP id x4-v6so76654pln.7 for ; Tue, 10 Apr 2018 17:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4yVJ+ebZjLxv4nVt3ilZPK4Xusri5x/L4n4kVcUqNc0=; b=Am1BDKCFhUaJ6xp0X6Pbh912QPYK/Z5UZQ5ecj7z46/XLuvv1j4jK6Rzs5BdCWgNQ3 /epalQeQPS62+WkO7ougNCNRCT5ZNRxBMvMv2bb9i8T5i0wNLTS1CuM5NmVzcobrGeHI uVGfEv56t4uRoRLy4mMWStNPe4/UBH+2qQbEA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4yVJ+ebZjLxv4nVt3ilZPK4Xusri5x/L4n4kVcUqNc0=; b=FhkthAQES3rgPfoeIHlDj7tBngPc74MDovaxomsiozY50eTJRmcn3jWEVq7DRyjN0/ /mL5ermt1uEQj4jIV9ja88b+yUSFABgYO/cMl7u1MCESKVMZR6V4jhVzUTeCm1BsvKq1 mOXX8M5m1dUOutykN4cptmANlYnftaUj/cP3sp5V2t538qbpjXA0Up/8dSWSZES8ws2d nulyUjhIjKXpEFfhw4Gmf74SoUUiIWvFX1hIOcPcUGkNoN/kHq1DdohTH0onNiTCRJSf 5zftpr+u1DZbpAj7qUf80M+6F6DFbeVorZfl9QLEaAnhwWh8pFDh05RgG8AJgOvLN1Yp QX/g== X-Gm-Message-State: ALQs6tCYHvIYr2TRPZV5qaZUYRYL20Xcd3iYabOtQ8N+449CRKk3VyTa 9pheTpuXf3bavWWPL73M/lL2ag== X-Received: by 2002:a17:902:ab81:: with SMTP id f1-v6mr2570746plr.5.1523406702205; Tue, 10 Apr 2018 17:31:42 -0700 (PDT) Received: from builder (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id 67sm9473710pfp.122.2018.04.10.17.31.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 10 Apr 2018 17:31:41 -0700 (PDT) Date: Tue, 10 Apr 2018 17:31:39 -0700 From: Bjorn Andersson To: Lina Iyer Cc: andy.gross@linaro.org, david.brown@linaro.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, rnayak@codeaurora.org, linux-kernel@vger.kernel.org, sboyd@kernel.org, evgreen@chromium.org, dianders@chromium.org Subject: Re: [PATCH v5 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS Message-ID: <20180411003139.GE6727@builder> References: <20180405161834.3850-1-ilina@codeaurora.org> <20180405161834.3850-6-ilina@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180405161834.3850-6-ilina@codeaurora.org> 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 05 Apr 09:18 PDT 2018, Lina Iyer wrote: > diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h [..] > @@ -439,6 +445,107 @@ int rpmh_rsc_send_data(struct rsc_drv *drv, const struct tcs_request *msg) > } > EXPORT_SYMBOL(rpmh_rsc_send_data); > > +static int find_match(const struct tcs_group *tcs, const struct tcs_cmd *cmd, > + int len) > +{ > + int i, j; > + > + /* Check for already cached commands */ > + for_each_set_bit(i, tcs->slots, MAX_TCS_SLOTS) { Wouldn't it be good if this cared about TCS boundaries? > + for (j = 0; j < len; j++) { > + if (tcs->cmd_cache[i] != cmd[0].addr) { > + if (j == 0) > + break; > + WARN(tcs->cmd_cache[i + j] != cmd[j].addr, > + "Message does not match previous sequence.\n"); > + return -EINVAL; > + } else if (j == len - 1) { > + return i; > + } > + } > + } > + > + return -ENODATA; > +} > + > +static int find_slots(struct tcs_group *tcs, const struct tcs_request *msg, > + int *m, int *n) > +{ > + int slot, offset; > + int i = 0; > + > + /* Find if we already have the msg in our TCS */ "Search for the sequence of addresses in our tcs group" > + slot = find_match(tcs, msg->cmds, msg->num_cmds); > + if (slot >= 0) > + goto copy_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_cmds, 0); > + if (slot == MAX_TCS_SLOTS) > + return -ENOMEM; > + i += tcs->ncpt; > + } while (slot + msg->num_cmds - 1 >= i); Does this conditional check that the sequence of free slots that we found doesn't extend past the boundary of a TCS? I'm sorry, but this code is hard to understand. I would find this much easier to read if there was one bitmap per TCS and you just looped over them to find free regions. > + > +copy_data: > + bitmap_set(tcs->slots, slot, msg->num_cmds); > + /* Copy the addresses of the resources over to the slots */ > + for (i = 0; i < msg->num_cmds; i++) > + tcs->cmd_cache[slot + i] = msg->cmds[i].addr; > + > + offset = slot / tcs->ncpt; > + *m = offset + tcs->offset; > + *n = slot % tcs->ncpt; > + > + return 0; > +} > + > +static int tcs_ctrl_write(struct rsc_drv *drv, const struct tcs_request *msg) > +{ > + struct tcs_group *tcs; > + int m = 0, n = 0; > + unsigned long flags; > + int ret; > + > + tcs = get_tcs_for_msg(drv, msg); > + if (IS_ERR(tcs)) > + return PTR_ERR(tcs); > + > + spin_lock_irqsave(&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->lock, flags); > + > + return ret; > +} > + > +/** > + * rpmh_rsc_write_ctrl_data: Write request to the controller > + * > + * @drv: the controller > + * @msg: the data to be written to the controller > + * > + * There is no response returned for writing the request to the controller. > + */ > +int rpmh_rsc_write_ctrl_data(struct rsc_drv *drv, const struct tcs_request *msg) So this is exactly the same thing as rpmh_rsc_send_data() but for one of the non-active TCSs? Can't we have a single API for writing msg to the hardware and if it's active we "send" it as well? > +{ > + if (!msg || !msg->cmds || !msg->num_cmds || > + msg->num_cmds > MAX_RPMH_PAYLOAD) { > + pr_err("Payload error\n"); > + return -EINVAL; > + } > + > + /* Data sent to this API will not be sent immediately */ > + if (msg->state == RPMH_ACTIVE_ONLY_STATE) > + return -EINVAL; If you're concerned about this then the API isn't clear enough. > + > + return tcs_ctrl_write(drv, msg); > +} > +EXPORT_SYMBOL(rpmh_rsc_write_ctrl_data); > + > static int rpmh_probe_tcs_config(struct platform_device *pdev, > struct rsc_drv *drv) > { > @@ -512,6 +619,19 @@ static int rpmh_probe_tcs_config(struct platform_device *pdev, > tcs->mask = ((1 << tcs->num_tcs) - 1) << st; > 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; Rather than "the rest of this loop shouldn't be done for the active tcs group" just make another loop... Or at least make the comment relate directly to the code it's adjacent. > + > + tcs->cmd_cache = devm_kcalloc(&pdev->dev, > + tcs->num_tcs * ncpt, sizeof(u32), > + GFP_KERNEL); > + if (!tcs->cmd_cache) > + return -ENOMEM; Regards, Bjorn