Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2426619pxb; Fri, 8 Oct 2021 07:35:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzX4L2/LPaVIQ61XQGMT19qnin/BUe4SYK8ce5T2/I2lv1B3fbWbcp4wJm8hRjGYSoRkIwH X-Received: by 2002:a62:6d07:0:b0:446:c141:7d2d with SMTP id i7-20020a626d07000000b00446c1417d2dmr10375943pfc.28.1633703756619; Fri, 08 Oct 2021 07:35:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633703756; cv=none; d=google.com; s=arc-20160816; b=MHrjcQSNbKoz9RUbOh9+y61N+4kBEodECJhre5f60xHoB5F4Np+VN28lOgs55yfCsr M82QJN8CprM1ECvRqhWf0WmEuEcv1EtnbT79gVY9DirLSXUj+MPUkadoewma8q+FTkL1 Paqt8Ksv4+ZktDPJE5/LNppgojOWp1wRzyijrITy0aRQ5Lf8RuH6CLHcUwhQWTU6Xk6a WMkfPNjoONKZmAO8kpXiPBE28kh4KXKyaZ/7Pi3dJxqygh0iTcNZkzi68BXESm7u9JHG f0L3YyasoSqgmAGS6XXnoabqY6vg+KNWnuODLgKjRqRivQb+oUagHEZkUkGSmv+XkSFC fOjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=QgfxwBmF1+monDAdjg0g2KuWwbKnod/mIT9QO6h2iro=; b=FMWYdyHH9hig4f5y47ZOWBp1nDkJSa07NTzfhpA0yt38RQ336XddonrW3xPGZ78QgU D34bvp3tFpzzcmt9MVHzykTfsBW1zcm8qv6pDy0O3l5Ok71kb6ot7mj/lcLoUn2xPQT6 nz0s8DwAoKuyVQOzcRzyDdlJuUZlnd1Zp0/uZSCgKZy5v5eYztFupQIXHejhDMmwnvHz arbY6q258WarbY01QwEtGDqnaIyFnRKQxgafUjKYwP+n0k2Y7vPHyrGomItxwtRoylqO 6eKKRr9wkjrfxafS3sao6rG+CSzw7ot+MJurHKa7m5SaC7avOpj2qEVjNyF6NXDueG/2 wDPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kZZWfT+P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id 13si2003141pjo.181.2021.10.08.07.35.43; Fri, 08 Oct 2021 07:35:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kZZWfT+P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S229756AbhJHOfb (ORCPT + 99 others); Fri, 8 Oct 2021 10:35:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230171AbhJHOfa (ORCPT ); Fri, 8 Oct 2021 10:35:30 -0400 Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BF67C061755 for ; Fri, 8 Oct 2021 07:33:35 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id g125so7276939oif.9 for ; Fri, 08 Oct 2021 07:33:34 -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; bh=QgfxwBmF1+monDAdjg0g2KuWwbKnod/mIT9QO6h2iro=; b=kZZWfT+PowKkZ01WdnR/B1jT/bbJbNn/nk3qm9dOEkSnkXGMSnwCE5oj5OyGVzAKlD 8g7BU3Wbwxtygo0NG7m8z1G1h91Zn2H8Uzr6zZItNJ+ctbiNn8SP2V+Uei79rv/VMoD6 ntkssCThEGK9QfAG36PGku21bWbycBVhaBd+4krVLC28qKTTxXCMLIp6Q6SLREmWI5YP poopFO0ZBSFYuieiYcNJh9uxZr4n3JzdYH53+9son7vCgu+hw17EoMk6xX/GYczF28lB NvWQ/hyqS4KHgD/S6OdDWD81XkhNT9Q0SJewpDCE1gE/AYAeqc74WsjlHK9Oj/CEj1Sk MeqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=QgfxwBmF1+monDAdjg0g2KuWwbKnod/mIT9QO6h2iro=; b=ICgVq2LKkkmVKVVgZHzd+SGLAIeRpdEdY/NfTA80j8TveKMqGSCQiWN3pKIjw2KRui pYeZT4osSiMYismnZ2KGTFTdPTWr1D7LoS88rRwOeOJOYV13jGK2xA7FsLhNNeGkAOlq Eo564xU+7FNkgBhxhWGkJ3rmQMABcsxjPmXlKTJ/r4QW2eNW+68mkipkHdM2NIm7dDlI xnfrPmnLorEfwJ/T4T3aczaf9ZcW0IGT4Nz/2xcSTmIT/lGQ6HD8PceqOKVP5G/MCqNq b/vDYsF+GVhoyQfCyZs3lQL6BF1ZMKSeLzKZhb6I2WmMGE4b3w3Ifx1cAVQw7yX4/5yC hPsQ== X-Gm-Message-State: AOAM530Ac/YYwQZ96FsY3/9LXz4BAGxqlkeMS30z3g3t954+ryrkpIK/ jvdFostPuUIVXnBz28fSSGKrZA== X-Received: by 2002:aca:3656:: with SMTP id d83mr16497564oia.176.1633703614214; Fri, 08 Oct 2021 07:33:34 -0700 (PDT) Received: from ripper ([2600:1700:a0:3dc8:205:1bff:fec0:b9b3]) by smtp.gmail.com with ESMTPSA id u9sm720809oiu.19.2021.10.08.07.33.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 07:33:33 -0700 (PDT) Date: Fri, 8 Oct 2021 07:35:12 -0700 From: Bjorn Andersson To: Srinivasa Rao Mandadapu Cc: agross@kernel.org, lgirdwood@gmail.com, broonie@kernel.org, robh+dt@kernel.org, plai@codeaurora.org, bgoswami@codeaurora.org, perex@perex.cz, tiwai@suse.com, srinivas.kandagatla@linaro.org, rohitkr@codeaurora.org, linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, swboyd@chromium.org, judyhsiao@chromium.org, Venkata Prasad Potturu Subject: Re: [PATCH v3] ASoC: qcom: soundwire: Enable soundwire bus clock for version 1.6 Message-ID: References: <1633671232-30310-1-git-send-email-srivasam@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1633671232-30310-1-git-send-email-srivasam@codeaurora.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 07 Oct 22:33 PDT 2021, Srinivasa Rao Mandadapu wrote: > Add support for soundwire 1.6 version to gate RX/TX bus clock. > Are you really adding soundwire 1.6 support in order to gate RX/TX bus clock? Could it be that you're ungating the bus clock so that soundwire 1.6 starts working? The commit message should properly describe why you're doing your change. > Signed-off-by: Venkata Prasad Potturu > Signed-off-by: Srinivasa Rao Mandadapu Venkata is the first who certified the origin of this patch, yet you're the author. Either this should be From Venkata (i.e. git commit --author) or perhaps you need a Co-developed-by here to say that you collaborated on this and both certify its origin. > --- > Changes since v2: > -- Update error check after ioremap. What about the other things I noted in v2? > Changes since v1: > -- Add const name to mask value. > > drivers/soundwire/qcom.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c > index 0ef79d6..bd6fabd 100644 > --- a/drivers/soundwire/qcom.c > +++ b/drivers/soundwire/qcom.c > @@ -109,6 +109,7 @@ > #define SWR_MAX_CMD_ID 14 > #define MAX_FIFO_RD_RETRY 3 > #define SWR_OVERFLOW_RETRY_COUNT 30 > +#define SWRM_HCTL_REG_MASK ~BIT(1) > > struct qcom_swrm_port_config { > u8 si; > @@ -127,6 +128,7 @@ struct qcom_swrm_ctrl { > struct device *dev; > struct regmap *regmap; > void __iomem *mmio; > + char __iomem *swrm_hctl_reg; > struct completion broadcast; > struct completion enumeration; > struct work_struct slave_work; > @@ -610,6 +612,12 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl) > val = FIELD_PREP(SWRM_MCP_FRAME_CTRL_BANK_ROW_CTRL_BMSK, ctrl->rows_index); > val |= FIELD_PREP(SWRM_MCP_FRAME_CTRL_BANK_COL_CTRL_BMSK, ctrl->cols_index); > > + if (ctrl->swrm_hctl_reg) { > + val = ioread32(ctrl->swrm_hctl_reg); > + val &= SWRM_HCTL_REG_MASK; Make a define with a name that clarifies what BIT(1) is and use that here, hiding a magic number in an empty define isn't making this more maintainable. Essentially put the name of the bit in the register description in a define and use that here. > + iowrite32(val, ctrl->swrm_hctl_reg); > + } > + > ctrl->reg_write(ctrl, SWRM_MCP_FRAME_CTRL_BANK_ADDR(0), val); > > /* Enable Auto enumeration */ > @@ -1200,7 +1208,7 @@ static int qcom_swrm_probe(struct platform_device *pdev) > struct qcom_swrm_ctrl *ctrl; > const struct qcom_swrm_data *data; > int ret; > - u32 val; > + int val, swrm_hctl_reg = 0; Don't you get a warning from passing val as an int to a function that takes a u32 pointer? Also there's no reason to zero-initialize swrm_hctl_reg. > > ctrl = devm_kzalloc(dev, sizeof(*ctrl), GFP_KERNEL); > if (!ctrl) > @@ -1251,6 +1259,11 @@ static int qcom_swrm_probe(struct platform_device *pdev) > ctrl->bus.port_ops = &qcom_swrm_port_ops; > ctrl->bus.compute_params = &qcom_swrm_compute_params; > > + if (!of_property_read_u32(dev->of_node, "qcom,swrm-hctl-reg", &swrm_hctl_reg)) { As I said in my feedback of v2, this property is not documented in the DT binding. But more important, upstream we do not approve of the downstream methodology of having properties pointing to single registers in some memory block somewhere. Describe the hardware block that you reference fully in devicetree and make a proper reference to it. Unfortunately your patch lacks details necessary to know where this register lives, so it's not possible for me to recommend a proper design. Regards, Bjorn > + ctrl->swrm_hctl_reg = devm_ioremap(&pdev->dev, swrm_hctl_reg, 0x4); > + if (!ctrl->swrm_hctl_reg) > + return -ENODEV; > + } > ret = qcom_swrm_get_port_config(ctrl); > if (ret) > goto err_clk; > -- > Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., > is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. >