From: Florian Fainelli <f.fainelli@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>,
Florian Fainelli <f.fainelli@gmail.com>,
linux-kernel@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
"maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE"
<bcm-kernel-feedback-list@broadcom.com>,
Gregory Fong <gregory.0xf0@gmail.com>,
Brian Norris <computersforpeace@gmail.com>,
"moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] reset: Add Broadcom STB SW_INIT reset controller driver
Date: Wed, 2 Jan 2019 12:38:02 -0800 [thread overview]
Message-ID: <7387643e-b22e-fe25-08e9-1f641f8b306a@gmail.com> (raw)
In-Reply-To: <1546425895.3457.1.camel@pengutronix.de>
Hi Philipp,
On 1/2/19 2:44 AM, Philipp Zabel wrote:
> Hi Florian,
>
> On Thu, 2018-12-20 at 17:34 -0800, Florian Fainelli wrote:
>> Add support for resetting blocks through the Linux reset controller
>> subsystem when reset lines are provided through a SW_INIT-style reset
>> controller on Broadcom STB SoCs.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Thank you, this looks mostly good to me. I just have a few small
> nitpicks and I'm curious about the mdelays, see below.
Thanks, answers inline.
[snip]
>> +struct brcmstb_reset {
>> + void __iomem *base;
>
>> + unsigned int n_words;
>> + struct device *dev;
>
> These two variables are not used anywhere.
Indeed, the first one should actually be added as a check to make sure
we have a correct resource size being passed, I will add that back in.
>
>> + struct reset_controller_dev rcdev;
>> +};
>> +
>> +#define SW_INIT_SET 0x00
>> +#define SW_INIT_CLEAR 0x04
>> +#define SW_INIT_STATUS 0x08
>> +
>> +#define SW_INIT_BIT(id) BIT((id) & 0x1f)
>> +#define SW_INIT_BANK(id) (id >> 5)
>
> Checkpatch suggests to use ((id) >> 5) here.
>
>> +
>> +#define SW_INIT_BANK_SIZE 0x18
>> +
>> +static inline
>> +struct brcmstb_reset *to_brcmstb(struct reset_controller_dev *rcdev)
>> +{
>> + return container_of(rcdev, struct brcmstb_reset, rcdev);
>> +}
>> +
>> +static int brcmstb_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + unsigned int off = SW_INIT_BANK(id) * SW_INIT_BANK_SIZE;
>> + struct brcmstb_reset *priv = to_brcmstb(rcdev);
>> +
>> + writel_relaxed(SW_INIT_BIT(id), priv->base + off + SW_INIT_SET);
>> + msleep(10);
>
> What is the purpose of the msleep(10)? Is it guaranteed that the writel
> takes effect before the msleep, or could it be lingering in some store
> buffer for (a part of) the duration? Also, checkpatch warns about this
> being < 20 ms. You could increase the delay or use usleep_range.
Good point, let me check what the real delay requirements are with the
design team, since I suspect they were just overly conservative in their
recommendations previously
>
>> + return 0;
>> +}
>> +
>> +static int brcmstb_reset_deassert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + unsigned int off = SW_INIT_BANK(id) * SW_INIT_BANK_SIZE;
>> + struct brcmstb_reset *priv = to_brcmstb(rcdev);
>> +
>> + writel_relaxed(SW_INIT_BIT(id), priv->base + off + SW_INIT_CLEAR);
>> + msleep(10);
>
> Same as above, what has to be delayed for 10 ms after deasserting the
> reset? Is this the same for all reset lines handled by this controller?
AFAICT, all lines behave the same way, as per our SoCs reset architecture.
>
>> +
>> + return 0;
>> +}
>> +
>> +static int brcmstb_reset_status(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + unsigned int off = SW_INIT_BANK(id) * SW_INIT_BANK_SIZE;
>> + struct brcmstb_reset *priv = to_brcmstb(rcdev);
>> +
>> + return readl_relaxed(priv->base + off + SW_INIT_STATUS);
>
> Should this be
>
> + return readl_relaxed(priv->base + off + SW_INIT_STATUS) &
> + SW_INIT_BANK(id);
>
> i.e. do the SW_INIT_STATUS registers contain 32 status bits, one for
> each reset line?
Yes they do. The same bits are used for SET/CLEAR/STATUS so this should
be something along the lines of:
return readl_relaxed(priv->base + off + SW_INIT_STATUS) & BIT(id));
thanks for spotting that!
>
>> +}
>> +
>> +static const struct reset_control_ops brcmstb_reset_ops = {
>> + .assert = brcmstb_reset_assert,
>> + .deassert = brcmstb_reset_deassert,
>> + .status = brcmstb_reset_status,
>> +};
>> +
>> +static int brcmstb_reset_probe(struct platform_device *pdev)
>> +{
>> + struct device *kdev = &pdev->dev;
>> + struct brcmstb_reset *priv;
>> + struct resource *res;
>> +
>> + priv = devm_kzalloc(kdev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + priv->base = devm_ioremap_resource(kdev, res);
>> + if (IS_ERR(priv->base))
>> + return PTR_ERR(priv->base);
>> +
>> + dev_set_drvdata(kdev, priv);
>> +
>> + priv->rcdev.owner = THIS_MODULE;
>> + priv->rcdev.nr_resets = (resource_size(res) / SW_INIT_BANK_SIZE) * 32;
>> + priv->rcdev.ops = &brcmstb_reset_ops;
>> + priv->rcdev.of_node = kdev->of_node;
>> + /* Use defaults: 1 cell and simple xlate function */
>> + priv->dev = kdev;
>
> priv->dev could be removed.
Indeed, I had sprinkled dev_*() messages during debug, which required
it, but this is no longer required indeed.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-01-02 20:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-21 1:34 [PATCH 0/2] reset: Add Broadcom STB SW_INIT reset controller driver Florian Fainelli
2018-12-21 1:34 ` [PATCH 1/2] dt-bindings: reset: Add document for Broadcom STB reset controller Florian Fainelli
2018-12-31 23:13 ` Scott Branden
2019-01-02 20:38 ` Florian Fainelli
2019-01-03 17:41 ` Rob Herring
2019-01-03 18:53 ` Florian Fainelli
2019-01-03 19:19 ` Rob Herring
2019-01-03 19:31 ` Florian Fainelli
2019-01-03 22:54 ` Rob Herring
2019-01-11 18:51 ` Florian Fainelli
2018-12-21 1:34 ` [PATCH 2/2] reset: Add Broadcom STB SW_INIT reset controller driver Florian Fainelli
2019-01-02 10:44 ` Philipp Zabel
2019-01-02 20:38 ` Florian Fainelli [this message]
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=7387643e-b22e-fe25-08e9-1f641f8b306a@gmail.com \
--to=f.fainelli@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=gregory.0xf0@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@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).