From: Jon Hunter <jonathanh@nvidia.com>
To: Timo Alho <talho@nvidia.com>,
treding@nvidia.com, sivaramn@nvidia.com, robh@kernel.org
Cc: linux-tegra@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH V2 3/4] firmware: tegra: add bpmp driver for Tegra210
Date: Thu, 24 Jan 2019 13:57:41 +0000 [thread overview]
Message-ID: <abdd2153-e8eb-7caf-2483-aeb43ed4c55d@nvidia.com> (raw)
In-Reply-To: <ab9d0f38-a717-016f-6e80-2f18cbdfbee8@nvidia.com>
On 24/01/2019 13:41, Timo Alho wrote:
> Hi Jon,
>
> Thanks for reviewing :)
>
> On 24.1.2019 14.16, Jon Hunter wrote:
>
> ...
>
>>> +static int tegra210_bpmp_ring_doorbell(struct tegra_bpmp *bpmp)
>>> +{
>>> + struct tegra210_bpmp *priv = bpmp->priv;
>>> + struct irq_data *irq_data;
>>> +
>>> + /* Tegra Legacy Interrupt Controller (LIC) is used to notify
>>> + * BPMP of available messages
>>> + */
>>> + irq_data = irq_get_irq_data(priv->txirq);
>>> + if (!irq_data)
>>> + return -EINVAL;
>>
>> Why not check this in probe?
>>
>
> Indeed I can move irq_get_irq_data() to probe and store the return value
> directly to priv->txirq instead. I'll just do that then.
>
>>> +
>>> + return irq_data->chip->irq_retrigger(irq_data);
>>
>> We should check that the irq_retrigger is populated as well.
>
> I'll add a check.
>
>> In general, I am not sure if there is a better way to do this, but I
>> don't see an alternative.
>>
>
> I'd be also happy to hear if someone has good alternative.
>
> ...
>
>>> +static int tegra210_bpmp_init(struct tegra_bpmp *bpmp)
>>> +{
>>> + struct platform_device *pdev = to_platform_device(bpmp->dev);
>>> + struct tegra210_bpmp *priv;
>>> + struct resource *res;
>>> + unsigned int i;
>>> + int err;
>>> +
>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> +
>>> + bpmp->priv = priv;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + priv->atomics = devm_ioremap_resource(&pdev->dev, res);
>>> + if (IS_ERR(priv->atomics))
>>> + return PTR_ERR(priv->atomics);
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> + priv->arb_sema = devm_ioremap_resource(&pdev->dev, res);
>>> + if (IS_ERR(priv->arb_sema))
>>> + return PTR_ERR(priv->arb_sema);
>>> +
>>> + err = tegra210_bpmp_channel_init(bpmp->tx_channel, bpmp,
>>> + bpmp->soc->channels.cpu_tx.offset);
>>> + if (err < 0)
>>> + return err;
>>> +
>>> + err = tegra210_bpmp_channel_init(bpmp->rx_channel, bpmp,
>>> + bpmp->soc->channels.cpu_rx.offset);
>>> + if (err < 0)
>>> + return err;
>>
>> Don't we need to unmap any iomem on error that we mapped in
>> tegra210_bpmp_channel_init()?
>
> Good point. I'll just replace ioremap() with devm_ioremap(). I think
> that should do it.
>
> ...
>
>>> diff --git a/drivers/firmware/tegra/bpmp.c
>>> b/drivers/firmware/tegra/bpmp.c
>>> index c6716ec..22c91ab 100644
>>> --- a/drivers/firmware/tegra/bpmp.c
>>> +++ b/drivers/firmware/tegra/bpmp.c
>>> @@ -765,17 +765,23 @@ static int tegra_bpmp_probe(struct
>>> platform_device *pdev)
>>> if (err < 0)
>>> goto free_mrq;
>>> - err = tegra_bpmp_init_clocks(bpmp);
>>> - if (err < 0)
>>> - goto free_mrq;
>>> + if (of_find_property(pdev->dev.of_node, "#clock-cells", NULL)) {
>>> + err = tegra_bpmp_init_clocks(bpmp);
>>> + if (err < 0)
>>> + goto free_mrq;
>>> + }
>>> - err = tegra_bpmp_init_resets(bpmp);
>>> - if (err < 0)
>>> - goto free_mrq;
>>> + if (of_find_property(pdev->dev.of_node, "#reset-cells", NULL)) {
>>> + err = tegra_bpmp_init_resets(bpmp);
>>> + if (err < 0)
>>> + goto free_mrq;
>>> + }
>>> - err = tegra_bpmp_init_powergates(bpmp);
>>> - if (err < 0)
>>> - goto free_mrq;
>>> + if (of_find_property(pdev->dev.of_node, "#power-domain-cells",
>>> NULL)) {
>>> + err = tegra_bpmp_init_powergates(bpmp);
>>> + if (err < 0)
>>> + goto free_mrq;
>>> + }
>>
>> Should we use soc_data for these rather than relying on the nodes to be
>> populated correctly in DT?
>
> There are some t210 systems where BPMP functions as clocks provider (for
> EMC), and some where it does not. So controlling this via device tree
> can be handier.
Is it the same T210 device or could the compatibility string be used
here for this?
Cheers
Jon
--
nvpublic
next prev parent reply other threads:[~2019-01-24 13:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 12:28 [PATCH V2 0/4] add Tegra210 BPMP driver Timo Alho
2019-01-21 12:28 ` [PATCH V2 1/4] firmware: tegra: reword messaging terminology Timo Alho
2019-01-24 11:33 ` Jon Hunter
2019-01-24 12:25 ` Timo Alho
2019-01-21 12:28 ` [PATCH V2 2/4] firmware: tegra: refactor bpmp driver Timo Alho
2019-01-24 11:45 ` Jon Hunter
2019-01-24 14:26 ` Timo Alho
2019-01-21 12:28 ` [PATCH V2 3/4] firmware: tegra: add bpmp driver for Tegra210 Timo Alho
2019-01-24 12:16 ` Jon Hunter
2019-01-24 13:41 ` Timo Alho
2019-01-24 13:57 ` Jon Hunter [this message]
2019-01-21 12:28 ` [PATCH V2 4/4] dt-bindings: firmware: Add bindings for Tegra210 BPMP Timo Alho
2019-01-21 17:38 ` Rob Herring
2019-01-24 12:19 ` Jon Hunter
2019-01-24 13:02 ` Jon Hunter
2019-01-24 14:49 ` Timo Alho
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=abdd2153-e8eb-7caf-2483-aeb43ed4c55d@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sivaramn@nvidia.com \
--cc=talho@nvidia.com \
--cc=treding@nvidia.com \
/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).