From: Vince Hsu <vinceh@nvidia.com>
To: Lucas Stach <dev@lynxeye.de>
Cc: <thierry.reding@gmail.com>, <swarren@wwwdotorg.org>,
<gnurou@gmail.com>, <bskeggs@redhat.com>, <martin.peres@free.fr>,
<seven@nimrod-online.com>, <samuel.pitoiset@gmail.com>,
<nouveau@lists.freedesktop.org>, <linux-tegra@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/11] ARM: tegra: add function to control the GPU rail clamp
Date: Mon, 29 Dec 2014 10:49:44 +0800 [thread overview]
Message-ID: <54A0C148.6030400@nvidia.com> (raw)
In-Reply-To: <1419539683.2165.6.camel@lynxeye.de>
On 12/26/2014 04:34 AM, Lucas Stach wrote:
> Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu:
>> On 12/24/2014 09:16 PM, Lucas Stach wrote:
>>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu:
>>>> The Tegra124 and later Tegra SoCs have a sepatate rail gating register
>>>> to enable/disable the clamp. The original function
>>>> tegra_powergate_remove_clamping() is not sufficient for the enable
>>>> function. So add a new function which is dedicated to the GPU rail
>>>> gating. Also don't refer to the powergate ID since the GPU ID makes no
>>>> sense here.
>>>>
>>>> Signed-off-by: Vince Hsu <vinceh@nvidia.com>
>>> To be honest I don't see the point of this patch.
>>> You are bloating the PMC interface by introducing another exported
>>> function that does nothing different than what the current function
>>> already does.
>>>
>>> If you need a way to assert the clamp I would have expected you to
>>> introduce a common function to do this for all power partitions.
>> I thought about adding an tegra_powergate_assert_clamping(), but that
>> doesn't make sense to all the power partitions except GPU. Note the
>> difference in TRM. Any suggestion for the common function?
> Is there anything speaking against adding this function and only accept
> the GPU partition as valid parameter for now. So at least the interface
> stays symmetric and can be easily extended if any future partitions have
> similar characteristics as the GPU one.
The register APBDEV_PMC_GPU_RG_CNTRL_0 is only for GPU and can be used
for assertion and deassertion. The APBDEV_PMC_REMOVE_CLAMPING_CMD_0 is
only used for deassertion. If we have any future partitions that can be
asserted by SW like GPU, we can improve the interface then.
>
>>> Other comments inline.
>>>
>>> Regards,
>>> Lucas
>>>
>>>> ---
>>>> drivers/soc/tegra/pmc.c | 34 +++++++++++++++++++++++-----------
>>>> include/soc/tegra/pmc.h | 2 ++
>>>> 2 files changed, 25 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>> index a2c0ceb95f8f..7798c530ead1 100644
>>>> --- a/drivers/soc/tegra/pmc.c
>>>> +++ b/drivers/soc/tegra/pmc.c
>>>> @@ -225,17 +225,6 @@ int tegra_powergate_remove_clamping(int id)
>>>> return -EINVAL;
>>>>
>>>> /*
>>>> - * The Tegra124 GPU has a separate register (with different semantics)
>>>> - * to remove clamps.
>>>> - */
>>>> - if (tegra_get_chip_id() == TEGRA124) {
>>>> - if (id == TEGRA_POWERGATE_3D) {
>>>> - tegra_pmc_writel(0, GPU_RG_CNTRL);
>>>> - return 0;
>>>> - }
>>>> - }
>>>> -
>>>> - /*
>>>> * Tegra 2 has a bug where PCIE and VDE clamping masks are
>>>> * swapped relatively to the partition ids
>>>> */
>>>> @@ -253,6 +242,29 @@ int tegra_powergate_remove_clamping(int id)
>>>> EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>>>>
>>>> /**
>>>> + * tegra_powergate_gpu_set_clamping - control GPU-SOC clamps
>>>> + *
>>>> + * The post-Tegra114 chips have a separate rail gating register to configure
>>>> + * clamps.
>>>> + *
>>>> + * @assert: true to assert clamp, and false to remove
>>>> + */
>>>> +int tegra_powergate_gpu_set_clamping(bool assert)
>>> Those functions with a bool parameter to set/unset something are really
>>> annoying. Please avoid this pattern. The naming of the original function
>>> is much more intuitive.
>> But the original function is not sufficient. Maybe add a
>> tegra_powergate_assert_gpu_clamping()? That way I will prefer to adding
>> one more removal function for GPU. And then again that's a bloat, too.
>>>> +{
>>>> + if (!pmc->soc)
>>>> + return -EINVAL;
>>>> +
>>>> + if (tegra_get_chip_id() == TEGRA124) {
>>>> + tegra_pmc_writel(assert ? 1 : 0, GPU_RG_CNTRL);
>>>> + tegra_pmc_readl(GPU_RG_CNTRL);
>>> You are reading the register back here, which to me seems like you are
>>> trying to make sure that the write is flushed. Why is this needed?
>>> I also observed the need to do this while working on Tegra124 PCIe in
>>> Barebox, otherwise the partition wouldn't power up. I didn't have time
>>> to follow up on this yet, so it would be nice if you could explain why
>>> this is needed, or if you don't know ask HW about it.
>> That's a read fence to assure the post of the previous writes through
>> Tegra interconnect. (copy-paster from
>> https://android.googlesource.com/kernel/tegra.git/+/28b107dcb3aa122de8e94e48af548140d519298f)
> I see what it does, the question is more about why this is needed.
> What is the Tegra interconnect? According to the TRM the Tegra contains
> some standard AXI <-> AHB <-> APB bridges. That a read is needed to
> assure the write is posted to the APB bus seems to imply that there is
> some write buffering in one of those bridges. Can we get this documented
> somewhere?
The TRM does mention a read after the write. Check the section 32.2.2.3.
Thanks,
Vince
>
> And isn't it needed for the other partition ungating function too then?
I believe yes.
>
> Regards,
> Lucas
>
>
next prev parent reply other threads:[~2014-12-29 2:49 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-23 10:39 [PATCH 0/11] Add suspend/resume support for GK20A Vince Hsu
2014-12-23 10:39 ` [PATCH 1/11] ARM: tegra: add function to control the GPU rail clamp Vince Hsu
2014-12-24 13:16 ` Lucas Stach
2014-12-25 2:28 ` Vince Hsu
2014-12-25 20:34 ` Lucas Stach
2014-12-29 2:49 ` Vince Hsu [this message]
2014-12-30 16:42 ` Lucas Stach
2015-01-05 6:55 ` Vince Hsu
2015-01-05 15:09 ` Thierry Reding
2015-01-06 2:11 ` Vince Hsu
2015-01-06 11:15 ` Thierry Reding
2015-01-06 12:03 ` Vince Hsu
2015-01-06 13:29 ` Thierry Reding
2015-01-06 13:51 ` Vince Hsu
2015-01-06 14:23 ` Thierry Reding
2015-01-07 10:19 ` Peter De Schrijver
2015-01-07 10:49 ` Vince Hsu
2015-01-07 13:27 ` Thierry Reding
2015-01-07 14:08 ` Peter De Schrijver
2015-01-07 14:28 ` Vince Hsu
2015-01-07 14:48 ` Thierry Reding
2015-01-08 4:25 ` Vince Hsu
2015-01-08 8:03 ` Thierry Reding
2015-01-07 14:12 ` Peter De Schrijver
2015-01-07 14:19 ` Vince Hsu
2015-01-07 15:12 ` Thierry Reding
2015-01-08 4:23 ` Vince Hsu
2015-01-08 9:32 ` Peter De Schrijver
2015-01-08 11:41 ` Thierry Reding
2015-01-08 12:41 ` Peter De Schrijver
2015-01-08 9:39 ` Peter De Schrijver
2015-01-08 11:44 ` Thierry Reding
2014-12-24 13:52 ` Dmitry Osipenko
2014-12-25 2:05 ` Vince Hsu
2014-12-23 10:39 ` [PATCH 2/11] memory: tegra: add mc flush support Vince Hsu
2015-01-06 14:18 ` Thierry Reding
2015-01-07 10:08 ` Peter De Schrijver
2015-01-07 13:34 ` Thierry Reding
2014-12-23 10:39 ` [PATCH 3/11] memory: tegra: add flush operation for Tegra124 memory clients Vince Hsu
2015-01-06 14:30 ` Thierry Reding
2015-01-06 15:07 ` Vince Hsu
2015-01-06 15:27 ` Thierry Reding
2015-01-06 15:53 ` Vince Hsu
2014-12-23 10:39 ` [PATCH 4/11] ARM: tegra: add mc node for Tegra124 GPU Vince Hsu
2014-12-23 10:39 ` [PATCH nouveau 05/11] platform: switch to the new gpu rail clamping function Vince Hsu
2014-12-23 10:39 ` [PATCH nouveau 06/11] platform: complete the power up/down sequence Vince Hsu
2014-12-24 13:23 ` Lucas Stach
2014-12-25 2:42 ` Vince Hsu
2015-01-05 15:25 ` Thierry Reding
2015-01-06 9:34 ` Vince Hsu
2015-01-06 11:36 ` Thierry Reding
2015-01-06 12:13 ` Vince Hsu
2015-01-06 13:55 ` Thierry Reding
2015-01-06 14:19 ` Vince Hsu
2015-01-06 14:24 ` Thierry Reding
2014-12-23 10:40 ` [PATCH nouveau 07/11] instmem: make nv50_instmem_priv public Vince Hsu
2014-12-23 10:40 ` [PATCH nouveau 08/11] instmem: add dummy support for GK20A Vince Hsu
2014-12-23 16:39 ` [Nouveau] " Ilia Mirkin
2014-12-24 2:44 ` Vince Hsu
2014-12-23 10:40 ` [PATCH nouveau 09/11] drm: export some variable and functions to resue the PM functions Vince Hsu
2014-12-30 2:34 ` [Nouveau] " Emil Velikov
2014-12-30 3:18 ` Vince Hsu
2015-01-05 15:32 ` Thierry Reding
2015-01-05 19:50 ` Alexandre Courbot
2015-01-06 9:36 ` Vince Hsu
2015-01-06 11:49 ` Thierry Reding
2015-01-06 12:27 ` Vince Hsu
2015-01-06 14:37 ` Thierry Reding
2015-01-06 14:44 ` Ilia Mirkin
2015-01-06 14:50 ` Thierry Reding
2015-01-06 15:03 ` Ilia Mirkin
2015-01-06 15:35 ` Thierry Reding
2014-12-23 10:40 ` [PATCH nouveau 10/11] platform: add suspend/resume support Vince Hsu
2014-12-23 10:40 ` [PATCH nouveau 11/11] platform: add PM runtime " Vince Hsu
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=54A0C148.6030400@nvidia.com \
--to=vinceh@nvidia.com \
--cc=bskeggs@redhat.com \
--cc=dev@lynxeye.de \
--cc=gnurou@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=martin.peres@free.fr \
--cc=nouveau@lists.freedesktop.org \
--cc=samuel.pitoiset@gmail.com \
--cc=seven@nimrod-online.com \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.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).