Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4971642imm; Fri, 18 May 2018 14:02:10 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqrJxvz0focSAxJN7hV1Pz9yYw1M7ZHaxpvYrdYzO2fLpDErFZytblrGU8vSlWHeQG3qRO4 X-Received: by 2002:a17:902:b681:: with SMTP id c1-v6mr10968209pls.286.1526677330459; Fri, 18 May 2018 14:02:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526677330; cv=none; d=google.com; s=arc-20160816; b=XqjrEDftBwwIMwYGosEpiYYghdMYi+QtHGMveYz01Zt9cxxrPCyxFWtodiTcfhjXwP xATq5hIS4E9CHLLQKSW6AUEdxJGwIDcUh72PT4w2nTsiNt2HUwWFGNuPljOZhzMJbTOr E3JhSExMWAYmKX9poeY0SxQrk0MiZqGWYfgI7Py8MYzINCWxYrgX1GuFWTRX8Qb2cDXC tLwnQ2kmZ1FjLsA4Q1hipea1ID7b0iX03TmvVFJJ0XJBzLzuhOiUzrhrD5BRtsKxRIB+ 9wAR3r5KHO2J4woUdGNihStrAI2mfJUtuVyj0uzTbbi5/kh4JS7R/1Agoj1fXHf+FwLv wfNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=fQUKuMfGxuynJdri6LzQNp4C+dEW/Uv3cVhXMg0GVrw=; b=hxNPwOFNraRxpGbdeeVTLNP0O6o5t2wVYWWa7rq4vsJLEKIjwKK7xGKIiDlwAfgspk RRTTmWo2nbZ8aML6+Yie1MTC535CnwuCtni3aDI+TJfPOBcJ0ReGz7JSx07LPvAPjx9U fm8t5RX4pcW863ZUoTvk91KoHTZTTF+k2mrxJXoj8TbwDhjXysHXPTqRqVmjxL861gV9 WHY8ia3CzEbWS++iK8b2eHNMvNMU4m00F8R5HkShbsi/RPtcySiOCcg2aX2bzJTJ1ghg XGeCR8nrB+//tTheB9LJjzPNTlGxI20/jY4ovCq8x5kp6BvCfehIXZ0YIxBERXj1yRsv thHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dU1OFZj9; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u8-v6si8252753plm.134.2018.05.18.14.01.55; Fri, 18 May 2018 14:02:10 -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=@gmail.com header.s=20161025 header.b=dU1OFZj9; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751606AbeERVBa (ORCPT + 99 others); Fri, 18 May 2018 17:01:30 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:34928 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbeERVBZ (ORCPT ); Fri, 18 May 2018 17:01:25 -0400 Received: by mail-qt0-f196.google.com with SMTP id f5-v6so12066407qth.2; Fri, 18 May 2018 14:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fQUKuMfGxuynJdri6LzQNp4C+dEW/Uv3cVhXMg0GVrw=; b=dU1OFZj92qA1iyYHOknOSA/B6c6+QyPcknIlP0+ePB7GLPU5oWKFhthW0wh8UTgOZ6 n64pbBnPVmFmlLIOVRhLSaf6OEM2T1GpIpFoWr7nGUqyXILVK6KnfYO3u1ez29kkn7/U O/4bHab+qsYxLHdqDRalicc64qQdD8vcJHwbB2eq6OFR4jznZA0RNGkZqVQQDe4sc3KQ e5i5cWrcWL+L/tcf7EIvvUZqZM0nqXs/3rVH3GvJo8SyJ3o5PoFisP8bmjunIpw7rF2C kBLawYTizoqKcberPPMZgRGEvgCQdkb+XgVDfp1aVZLVyzgu/L1qjTMxBACRggcX7S3h RkqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fQUKuMfGxuynJdri6LzQNp4C+dEW/Uv3cVhXMg0GVrw=; b=FS5BjdqCfxJcq/G5p/pT4KZwVR83n8wAvIY83q39Lj3G/XwVHVJuICoAZkn+0ZhMHv hWisc5G/sX/6Ufl0U9NVJOgLMgrUCeH+p5SeemlaYWTrjDStAUaGbrxNOe2tmvRlXY0S HajDaGQktBEeVk1PJict1GmBWDMDcablsO6S5AY0xTSlkkkIgufTC6mp8TiBjUJlsHFM 1O3tB55ww9+qdZyQgSBo56AT4UACq56oLlKEcDEIW7RwgpS9HmXe4yOPJuyMEzRkcgsl cIY8Om8Nvzr9Jx/vHBFj+opvPcBVFsOUI7uIHkPA4L09SJW6SGvCN/ktgsgJnarRHSuD DKcQ== X-Gm-Message-State: ALKqPwcKDH7EWrdd14jqxFBUgiZXa/Z94mmVc9tqXmMBHIJXMTewnl05 EBCQ1TMCMxNgzdTtJVZnDK8C93HXDokMd1vjHmczi9Sc X-Received: by 2002:ac8:3487:: with SMTP id w7-v6mr10787087qtb.220.1526677285073; Fri, 18 May 2018 14:01:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.152.150 with HTTP; Fri, 18 May 2018 14:01:24 -0700 (PDT) In-Reply-To: <1526492623-20527-3-git-send-email-rishabhb@codeaurora.org> References: <1526492623-20527-1-git-send-email-rishabhb@codeaurora.org> <1526492623-20527-3-git-send-email-rishabhb@codeaurora.org> From: Andy Shevchenko Date: Sat, 19 May 2018 00:01:24 +0300 Message-ID: Subject: Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver To: Rishabh Bhatnagar Cc: linux-arm Mailing List , linux-arm-msm@vger.kernel.org, devicetree , Linux Kernel Mailing List , linux-arm@lists.infradead.org, tsoni@codeaurora.org, ckadabi@codeaurora.org, evgreen@chromium.org, Rob Herring Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: > LLCC (Last Level Cache Controller) provides additional cache memory > in the system. LLCC is partitioned into multiple slices and each > slice gets its own priority, size, ID and other config parameters. > LLCC driver programs these parameters for each slice. Clients that > are assigned to use LLCC need to get information such size & ID of the > slice they get and activate or deactivate the slice as needed. LLCC driver > provides API for the clients to perform these operations. > +static const struct of_device_id sdm845_qcom_llcc_of_match[] = { > + { .compatible = "qcom,sdm845-llcc", }, > + { }, Slightly better w/o comma > +}; > +static struct platform_driver sdm845_qcom_llcc_driver = { > + .driver = { > + .name = "sdm845-llcc", > + .owner = THIS_MODULE, No need. See below. > + .of_match_table = sdm845_qcom_llcc_of_match, > + }, > + .probe = sdm845_qcom_llcc_probe, > +}; > + > +static int __init sdm845_init_qcom_llcc_init(void) > +{ > + return platform_driver_register(&sdm845_qcom_llcc_driver); > +} > +module_init(sdm845_init_qcom_llcc_init); > + > +static void __exit sdm845_exit_qcom_llcc_exit(void) > +{ > + platform_driver_unregister(&sdm845_qcom_llcc_driver); > +} > +module_exit(sdm845_exit_qcom_llcc_exit); Why not to use module_platform_driver() macro? > +#define ACTIVATE 0x1 > +#define DEACTIVATE 0x2 > +#define ACT_CTRL_OPCODE_ACTIVATE 0x1 > +#define ACT_CTRL_OPCODE_DEACTIVATE 0x2 > +#define ACT_CTRL_ACT_TRIG 0x1 Are these bits? Perhaps BIT() ? > +#define ACT_CTRL_OPCODE_SHIFT 0x1 > +#define ATTR1_PROBE_TARGET_WAYS_SHIFT 0x2 > +#define ATTR1_FIXED_SIZE_SHIFT 0x3 > +#define ATTR1_PRIORITY_SHIFT 0x4 > +#define ATTR1_MAX_CAP_SHIFT 0x10 Better to use fixed size pattern, i.e. 0x01, 0x02, 0x03, 0x04, 0x10. > +#define ATTR0_RES_WAYS_MASK 0x00000fff > +#define ATTR0_BONUS_WAYS_MASK 0x0fff0000 GENMASK() > +#define LLCC_LB_CNT_MASK 0xf0000000 Ditto. > +#define MAX_CAP_TO_BYTES(n) (n * 1024) (n * SZ_1K) ? > +#define LLCC_TRP_ACT_CTRLn(n) (n * 0x1000) SZ_4K ? > +#define LLCC_TRP_STATUSn(n) (4 + n * 0x1000) Ditto. > +struct llcc_slice_desc *llcc_slice_getd(u32 uid) > +{ > + const struct llcc_slice_config *cfg; > + struct llcc_slice_desc *desc; > + u32 sz, count = 0; > + > + cfg = drv_data->cfg; > + sz = drv_data->cfg_size; > + > + while (cfg && count < sz) { > + if (cfg->usecase_id == uid) > + break; > + cfg++; > + count++; > + } > + if (cfg == NULL || count == sz) > + return ERR_PTR(-ENODEV); if (!cfg) return ERR_PTR(-ENODEV); while (cfg->... != uid) { cfg++; count++; } if (count == sz) return ... Though I would rather put it to for () loop. > +static int llcc_update_act_ctrl(u32 sid, > + u32 act_ctrl_reg_val, u32 status) > +{ > + u32 act_ctrl_reg; > + u32 status_reg; > + u32 slice_status; > + int ret = 0; Useless assignment. Check entire patch series for a such. > + ret = regmap_read_poll_timeout(drv_data->regmap, status_reg, > + slice_status, !(slice_status & status), 0, LLCC_STATUS_READ_DELAY); Wrong indentation. > + return ret; > +} > + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val, > + DEACTIVATE); Perhaps one line (~83 characters here is OK) ? > + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val, > + ACTIVATE); Ditto. > + attr1_cfg = bcast_off + > + LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id); > + attr0_cfg = bcast_off + > + LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id); Ditto. > + attr1_val |= llcc_table[i].probe_target_ways << > + ATTR1_PROBE_TARGET_WAYS_SHIFT; > + attr1_val |= llcc_table[i].fixed_size << > + ATTR1_FIXED_SIZE_SHIFT; > + attr1_val |= llcc_table[i].priority << ATTR1_PRIORITY_SHIFT; foo |= bar << SHIFT; would look slightly better. > +int qcom_llcc_probe(struct platform_device *pdev, > + const struct llcc_slice_config *llcc_cfg, u32 sz) > +{ > + drv_data->offsets = devm_kzalloc(dev, num_banks * sizeof(u32), > + GFP_KERNEL); > + if (!drv_data->offsets) > + return -ENOMEM; devm_kcalloc() ? > + > + for (i = 0; i < num_banks; i++) > + drv_data->offsets[i] = (i * BANK_OFFSET_STRIDE); Pointless parens. > + drv_data->bitmap = devm_kcalloc(dev, > + BITS_TO_LONGS(drv_data->max_slices), sizeof(unsigned long), > + GFP_KERNEL); > + if (!drv_data->bitmap) > + return -ENOMEM; Perhaps at some point someone will add bitmap_alloc() devm_bitmap_alloc() > + bitmap_zero(drv_data->bitmap, drv_data->max_slices); Pointless -- With Best Regards, Andy Shevchenko