linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: Andy Gross <agross@kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
	Baolin Wang <baolin.wang7@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] hwspinlock: qcom: Allow mmio usage in addition to syscon
Date: Thu, 14 May 2020 10:00:13 -0700	[thread overview]
Message-ID: <20200514170013.GX2165@builder.lan> (raw)
In-Reply-To: <20200514141523.GW14092@vkoul-mobl>

On Thu 14 May 07:15 PDT 2020, Vinod Koul wrote:

> On 12-05-20, 17:54, Bjorn Andersson wrote:
> > In all modern Qualcomm platforms the mutex region of the TCSR is forked
> > off into its own block, all with a offset of 0 and stride of 4096. So
> > add support for directly memory mapping this register space, to avoid
> > the need to represent this block using a syscon.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >  drivers/hwspinlock/qcom_hwspinlock.c | 72 +++++++++++++++++++++-------
> >  1 file changed, 56 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/hwspinlock/qcom_hwspinlock.c b/drivers/hwspinlock/qcom_hwspinlock.c
> > index f0da544b14d2..d8d4d729816c 100644
> > --- a/drivers/hwspinlock/qcom_hwspinlock.c
> > +++ b/drivers/hwspinlock/qcom_hwspinlock.c
> > @@ -70,41 +70,81 @@ static const struct of_device_id qcom_hwspinlock_of_match[] = {
> >  };
> >  MODULE_DEVICE_TABLE(of, qcom_hwspinlock_of_match);
> >  
> > -static int qcom_hwspinlock_probe(struct platform_device *pdev)
> > +static struct regmap *qcom_hwspinlock_probe_syscon(struct platform_device *pdev,
> > +						   u32 *base, u32 *stride)
> >  {
> > -	struct hwspinlock_device *bank;
> >  	struct device_node *syscon;
> > -	struct reg_field field;
> >  	struct regmap *regmap;
> > -	size_t array_size;
> > -	u32 stride;
> > -	u32 base;
> >  	int ret;
> > -	int i;
> >  
> >  	syscon = of_parse_phandle(pdev->dev.of_node, "syscon", 0);
> > -	if (!syscon) {
> > -		dev_err(&pdev->dev, "no syscon property\n");
> 
> any reason to drop the log?
> 

Given that we first check for the syscon and then fall back to trying to
use the reg, keeping this line would cause this log line to always show
up on targets putting this under /soc.

So I think it's better to drop the line and then require the presence of
either syscon or reg using the DT schema.

> > -		return -ENODEV;
> > -	}
> > +	if (!syscon)
> > +		return ERR_PTR(-ENODEV);
> >  
> >  	regmap = syscon_node_to_regmap(syscon);
> >  	of_node_put(syscon);
> >  	if (IS_ERR(regmap))
> > -		return PTR_ERR(regmap);
> > +		return regmap;
> >  
> > -	ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, &base);
> > +	ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1, base);
> >  	if (ret < 0) {
> >  		dev_err(&pdev->dev, "no offset in syscon\n");
> > -		return -EINVAL;
> > +		return ERR_PTR(-EINVAL);
> >  	}
> >  
> > -	ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, &stride);
> > +	ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 2, stride);
> >  	if (ret < 0) {
> >  		dev_err(&pdev->dev, "no stride syscon\n");
> > -		return -EINVAL;
> > +		return ERR_PTR(-EINVAL);
> >  	}
> >  
> > +	return regmap;
> > +}
> > +
> > +static const struct regmap_config tcsr_mutex_config = {
> > +	.reg_bits		= 32,
> > +	.reg_stride		= 4,
> > +	.val_bits		= 32,
> > +	.max_register		= 0x40000,
> > +	.fast_io		= true,
> > +};
> > +
> > +static struct regmap *qcom_hwspinlock_probe_mmio(struct platform_device *pdev,
> > +						 u32 *offset, u32 *stride)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct resource *res;
> > +	void __iomem *base;
> > +
> > +	/* All modern platform has offset 0 and stride of 4k */
> > +	*offset = 0;
> > +	*stride = 0x1000;
> 
> Wouldn't it make sense to read this from DT rather than code in kernel?
> 

I did consider this as well as platform specific compatibles, but
realized that pretty much all 64-bit targets have these values. So given
that we still can represent this using the syscon approach I don't think
we need to add yet another mechanism to specify these.

Thanks,
Bjorn

  reply	other threads:[~2020-05-14 17:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13  0:54 [PATCH 0/4] hwspinlock: qcom: Allow dropping the intermediate TCSR mutex syscon Bjorn Andersson
2020-05-13  0:54 ` [PATCH 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML Bjorn Andersson
2020-05-14 14:19   ` Vinod Koul
2020-05-27 19:31   ` Rob Herring
2020-05-13  0:54 ` [PATCH 2/4] dt-bindings: hwlock: qcom: Allow device on mmio bus Bjorn Andersson
2020-05-14 14:19   ` Vinod Koul
2020-05-13  0:54 ` [PATCH 3/4] hwspinlock: qcom: Allow mmio usage in addition to syscon Bjorn Andersson
2020-05-13  3:57   ` Baolin Wang
2020-05-14 17:06     ` Bjorn Andersson
2020-05-14 14:15   ` Vinod Koul
2020-05-14 17:00     ` Bjorn Andersson [this message]
2020-05-14 17:32       ` Vinod Koul
2020-05-13  0:54 ` [PATCH 4/4] arm64: dts: qcom: sm8250: Drop tcsr_mutex syscon Bjorn Andersson
2020-05-14 14:19   ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200514170013.GX2165@builder.lan \
    --to=bjorn.andersson@linaro.org \
    --cc=agross@kernel.org \
    --cc=baolin.wang7@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).