Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp60573ybb; Tue, 7 Apr 2020 16:52:56 -0700 (PDT) X-Google-Smtp-Source: APiQypL178bPn6MVZ1sfy7ghuFHE3linGQLmih4KgFkp7b76o5ngNAKjTLnlVrLjlCIuUky5ikQt X-Received: by 2002:aca:5d04:: with SMTP id r4mr514541oib.94.1586303576524; Tue, 07 Apr 2020 16:52:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586303576; cv=none; d=google.com; s=arc-20160816; b=KabiFWQn0a7oB6gODOovyYcgJjF5oc90X6Q3clPHgBNWu8sBtXPNMHekAPcvlDsLWk dsBs6DO1tywMfi9PIMUtEpMcnZxMzYqPYlp/0V5ESDtkosXJ6OVLU0lWTXE2ye3EQgAa 1PE1BRYBfPy2nqrhrAtAnxHbL92DcCtoR805hKkNOlZoE66I6gj+rNjPvqj/XPnE4ZlY a1wr+ruTipt/pGM9hYVAgpDr+QNiY5HUWAGW6z0BfR0ukMFXYdTCEd8+FCSjnGP3i3RJ M/w1d2TwI3JBVyoqH2/nehdQ5EXx4izT2aCInsKUtQVhUSiipUpauZcZ2HAK0cHI+52A wpXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=pFQkRgh1REqkDpACcdt+UfCfvgHDToGduy/d5MuknNk=; b=L5xC8xC9GLYqcR1T2dR1NxWX4A/MlK24/I4b8gxnwaj2tYjAQZl+TVL8P7zeWaSShD xzmuTChtCuUpBxizQdFoqnqiDAj+dBF8LUQmKcTxNKmpskkFv4z16Iv8HPTyk9zhHD6s iPyrYxeEbcyMy9Ju5UNrm2ndTagC/hVnJa107MyW7el3ItG9H2fns6boVvsCd1bI5RaG PLpvyTeCr4QRUg5JWMwJAptmvqM+RXJcDcjXRc/TdcNnU55wkxhxywIADwjy//W4DoFP oWI0IU4JzFThT3MBqt10TfzD66TrlqbVkk+THowWqZzLGs2izzjN6MBgsyJcizdAOzgn +rCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=i6mWkU87; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o4si427083otk.113.2020.04.07.16.52.42; Tue, 07 Apr 2020 16:52:56 -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=@chromium.org header.s=google header.b=i6mWkU87; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726591AbgDGXvD (ORCPT + 99 others); Tue, 7 Apr 2020 19:51:03 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:42377 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726546AbgDGXvC (ORCPT ); Tue, 7 Apr 2020 19:51:02 -0400 Received: by mail-pl1-f193.google.com with SMTP id v2so461141plp.9 for ; Tue, 07 Apr 2020 16:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=pFQkRgh1REqkDpACcdt+UfCfvgHDToGduy/d5MuknNk=; b=i6mWkU87+EqLGVlkeycAW1iqUek2kXI9xDjkNbOX1OCNtE37+/M7EnkQyBbmOAA+Ot WZi5rmOu3vhA45q9b4Hfu0nV6VvC8YxidTH10xQY+mlpUdn7Cq1oXCvybmgIzmmUBfZC 5PXT6Fg1Ag7Msgk85ncRN8AJve5gwNG0UzERE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=pFQkRgh1REqkDpACcdt+UfCfvgHDToGduy/d5MuknNk=; b=eDspHWRlHNqvV7OGnpWw7G+oSFscMvn5uVQLBhKJ6iOBtRqM7YqcXVXHxXmXpkia0H FiypAspk4Pg57VEyZXpYKbx/ML9kURuRNSfI83E0P+CFssgiwe0zbuPe1NmRYc8/2kkB hf9aKH+l75e8LlrsHOfVS6P1nrjc8JwJHI5SqTnISXSq7/7x3DQTuStKFth4Prwm3/nZ 3Fi2QprhPzN8nCjufxGWrmlqIVYm/U8d02C1Rg0/Lsnc5ENIQvBhGfbbzkHjeEw3TrmG umiUbICz1RhtRuquEI8aox6I/TBqsQKQYtCb2twxPZ4XMW1To9rTa22aNQQCBhqz+jzD cmQQ== X-Gm-Message-State: AGi0PubQiIrRpB6u5ZCNvLks2eUebIZJ6AVr92j/81hlZ7RbxqBnhyVZ pxAF2Kxm2AqbgEbwRLW+uTWvIg== X-Received: by 2002:a17:90a:fa17:: with SMTP id cm23mr2019144pjb.121.1586303461516; Tue, 07 Apr 2020 16:51:01 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id s27sm14467165pgn.90.2020.04.07.16.51.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 16:51:01 -0700 (PDT) From: Douglas Anderson To: Andy Gross , Bjorn Andersson , Maulik Shah Cc: mka@chromium.org, Lina Iyer , Rajendra Nayak , swboyd@chromium.org, evgreen@chromium.org, Douglas Anderson , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 05/10] drivers: qcom: rpmh-rsc: Kill cmd_cache and find_match() with fire Date: Tue, 7 Apr 2020 16:50:19 -0700 Message-Id: <20200407164915.v3.5.I6d3d0a3ec810dc72ff1df3cbf97deefdcdeb8eef@changeid> X-Mailer: git-send-email 2.26.0.292.g33ef6b2f38-goog In-Reply-To: <20200407235024.260460-1-dianders@chromium.org> References: <20200407235024.260460-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The "cmd_cache" in RPMH wasn't terribly sensible. Specifically: - The current code doesn't realy detect "conflicts" properly any case where the sequence being checked has more than one entry. One simple way to see this in the current code is that if cmd[0].addr isn't found that cmd[1].addr is never checked. - The code attempted to use the "cmd_cache" to update an existing message in a sleep/wake TCS with new data. The goal appeared to be to update part of a TCS while leaving the rest of the TCS alone. We never actually do this. We always fully invalidate and re-write everything. - If/when we try to optimize things to not fully invalidate / re-write every time we update the TCSes we'll need to think it through very carefully. Specifically requirement of find_match() that the new sequence of addrs must match exactly the old sequence of addrs seems inflexible. It's also not documented in rpmh_write() and rpmh_write_batch(). In any case, if we do decide to require updates to keep the exact same sequence and length then presumably the API and data structures should be updated to understand groups more properly. The current algorithm doesn't really keep track of the length of the old sequence and there are several boundary-condition bugs because of that. Said another way: if we decide to do something like this in the future we should start from scratch and thus find_match() isn't useful to keep around. This patch isn't quite a no-op. Specifically: - It should be a slight performance boost of not searching through so many arrays. - The old code would have done something useful in one case: it would allow someone calling rpmh_write() to override the data that came from rpmh_write_batch(). I don't believe that actually happens in reality. Signed-off-by: Douglas Anderson --- Changes in v3: - Kill find_match moves from patch #9 to patch #5 (Maulik). - Rewrote commit message to adjust for patch order. Changes in v2: - Got rid of useless "if (x) continue" at end of for loop. drivers/soc/qcom/rpmh-internal.h | 2 -- drivers/soc/qcom/rpmh-rsc.c | 47 -------------------------------- 2 files changed, 49 deletions(-) diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h index e9a90cb7773e..6a6d776ccca9 100644 --- a/drivers/soc/qcom/rpmh-internal.h +++ b/drivers/soc/qcom/rpmh-internal.h @@ -30,7 +30,6 @@ struct rsc_drv; * @ncpt: number of commands in each TCS * @lock: lock for synchronizing this TCS writes * @req: requests that are sent from the TCS - * @cmd_cache: flattened cache of cmds in sleep/wake TCS * @slots: indicates which of @cmd_addr are occupied */ struct tcs_group { @@ -42,7 +41,6 @@ struct tcs_group { int ncpt; spinlock_t lock; const struct tcs_request *req[MAX_TCS_PER_TYPE]; - u32 *cmd_cache; DECLARE_BITMAP(slots, MAX_TCS_SLOTS); }; diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c index 855a1dab7718..da1045c92b38 100644 --- a/drivers/soc/qcom/rpmh-rsc.c +++ b/drivers/soc/qcom/rpmh-rsc.c @@ -522,42 +522,12 @@ int rpmh_rsc_send_data(struct rsc_drv *drv, const struct tcs_request *msg) return ret; } -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) { - if (tcs->cmd_cache[i] != cmd[0].addr) - continue; - if (i + len >= tcs->num_tcs * tcs->ncpt) - goto seq_err; - for (j = 0; j < len; j++) { - if (tcs->cmd_cache[i + j] != cmd[j].addr) - goto seq_err; - } - return i; - } - - return -ENODATA; - -seq_err: - WARN(1, "Message does not match previous sequence.\n"); - return -EINVAL; -} - static int find_slots(struct tcs_group *tcs, const struct tcs_request *msg, int *tcs_id, int *cmd_id) { int slot, offset; int i = 0; - /* Find if we already have the msg in our TCS */ - 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, @@ -567,11 +537,7 @@ static int find_slots(struct tcs_group *tcs, const struct tcs_request *msg, i += tcs->ncpt; } while (slot + msg->num_cmds - 1 >= i); -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; *tcs_id = offset + tcs->offset; @@ -763,19 +729,6 @@ 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; - - tcs->cmd_cache = devm_kcalloc(&pdev->dev, - tcs->num_tcs * ncpt, sizeof(u32), - GFP_KERNEL); - if (!tcs->cmd_cache) - return -ENOMEM; } drv->num_tcs = st; -- 2.26.0.292.g33ef6b2f38-goog