From: jonathanh@nvidia•com (Jon Hunter)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V3 02/19] memory: tegra: Add MC flush support
Date: Mon, 20 Jul 2015 09:46:02 +0100 [thread overview]
Message-ID: <55ACB54A.4080103@nvidia.com> (raw)
In-Reply-To: <20150717113124.GP3057@ulmo>
On 17/07/15 12:31, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Fri, Jul 17, 2015 at 01:20:49PM +0300, Peter De Schrijver wrote:
>> On Fri, Jul 17, 2015 at 11:57:55AM +0200, Thierry Reding wrote:
>>>> Old Signed by an unknown key
>>>
>>> On Mon, Jul 13, 2015 at 01:39:40PM +0100, Jon Hunter wrote:
>>>> The Tegra memory controller implements a flush feature to flush pending
>>>> accesses and prevent further accesses from occurring. This feature is
>>>> used when powering down IP blocks to ensure the IP block is in a good
>>>> state. The flushes are organised by software groups and IP blocks are
>>>> assigned in hardware to the different software groups. Add helper
>>>> functions for requesting a handle to an MC flush for a given
>>>> software group and enabling/disabling the MC flush itself.
>>>>
>>>> This is based upon a change by Vince Hsu <vinceh@nvidia•com>.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia•com>
>>>> ---
>>>> drivers/memory/tegra/mc.c | 110 ++++++++++++++++++++++++++++++++++++++++++++++
>>>> drivers/memory/tegra/mc.h | 2 +
>>>> include/soc/tegra/mc.h | 34 ++++++++++++++
>>>> 3 files changed, 146 insertions(+)
>>>
>>> Do we know if this is actually necessary? I remember having a discussion
>>> with Arnd Bergmann a while ago, and the Linux driver model kind of
>>> assumes that by the time a device is disabled all outstanding accesses
>>> will have stopped.
>>>
>>> Do we have a way to determine that this even makes a difference? Can we
>>> trigger a case where not doing this would cause breakage and see that
>>> adding this fixes that particular issue?
>>>
>>
>> Most likely it is. The memory controller can still be processing requests
>> when the peripheral domain is powergated. This would mean the response cannot
>> be delivered in that case. So we need to be sure there are no outstanding
>> requests before shutting down the domain.
>
> My point is that that's the driver's responsibility anyway, hence making
> the explicit flush unnecessary.
I see your point and it is interesting. The trouble is that we would
need to test every memory client in every power domain to prove this. So
I don't think that is a trivial thing to do. Furthermore, looking at
what we have done in kernel used for android products (which probably
stress PM the most) this is done and so I don't know of any shipping
product that stresses PM that does not do this. May be someone else
might. I personally would not be comfortable removing this without
testing, but as I mentioned it is not a trivial thing to test correctly.
However, I will let you and the other maintainers decide what's best here.
Jon
next prev parent reply other threads:[~2015-07-20 8:46 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 12:39 [PATCH V3 00/19] Add generic PM domain support for Tegra SoCs Jon Hunter
2015-07-13 12:39 ` [PATCH V3 01/19] reset: add of_reset_control_get_by_index() Jon Hunter
2015-07-17 12:08 ` Philipp Zabel
2015-07-13 12:39 ` [PATCH V3 02/19] memory: tegra: Add MC flush support Jon Hunter
2015-07-17 9:57 ` Thierry Reding
2015-07-17 10:20 ` Peter De Schrijver
2015-07-17 11:31 ` Thierry Reding
2015-07-20 8:46 ` Jon Hunter [this message]
2015-07-20 9:17 ` Thierry Reding
2015-07-20 9:59 ` Peter De Schrijver
2015-07-20 13:14 ` Thierry Reding
2015-07-21 10:57 ` Peter De Schrijver
2015-07-13 12:39 ` [PATCH V3 03/19] memory: tegra: add flush operation for Tegra30 memory clients Jon Hunter
2015-07-17 10:03 ` Thierry Reding
2015-07-21 8:54 ` Jon Hunter
2015-07-13 12:39 ` [PATCH V3 04/19] memory: tegra: add flush operation for Tegra114 " Jon Hunter
2015-07-17 10:05 ` Thierry Reding
2015-07-13 12:39 ` [PATCH V3 05/19] memory: tegra: add flush operation for Tegra124 " Jon Hunter
2015-07-17 10:05 ` Thierry Reding
2015-07-13 12:39 ` [PATCH V3 06/19] clk: tegra: remove TEGRA_PLL_USE_LOCK for PLLD/PLLD2 Jon Hunter
2015-07-13 13:41 ` Peter De Schrijver
2015-07-13 14:02 ` Jon Hunter
2015-07-14 11:59 ` Jon Hunter
2015-07-15 8:16 ` Peter De Schrijver
2015-07-13 12:39 ` [PATCH V3 07/19] soc: tegra: pmc: Wait for powergate state to change Jon Hunter
2015-07-17 10:17 ` Thierry Reding
2015-07-21 9:34 ` Jon Hunter
2015-07-13 12:39 ` [PATCH V3 08/19] soc: tegra: pmc: Clean-up PMC helper functions Jon Hunter
2015-07-17 10:25 ` Thierry Reding
2015-07-21 9:38 ` Jon Hunter
2015-07-13 12:39 ` [PATCH V3 09/19] soc: tegra: pmc: Prepare for migrating to generic PM domains Jon Hunter
2015-07-13 12:39 ` [PATCH V3 10/19] drm/tegra: dc: Prepare for " Jon Hunter
2015-07-17 10:41 ` Thierry Reding
2015-07-28 8:30 ` Jon Hunter
2015-07-28 11:20 ` Thierry Reding
2015-07-28 15:30 ` Jon Hunter
2015-07-13 12:39 ` [PATCH V3 11/19] PCI: tegra: Add support " Jon Hunter
2015-07-17 10:45 ` Thierry Reding
2015-07-28 8:35 ` Jon Hunter
2015-07-13 12:39 ` [PATCH V3 12/19] ata: ahci_tegra: " Jon Hunter
2015-07-13 12:39 ` [PATCH V3 13/19] drm/tegra: gr3d: " Jon Hunter
2015-07-13 12:39 ` [PATCH V3 14/19] Documentation: DT: bindings: Add power domain info for NVIDIA PMC Jon Hunter
2015-07-17 9:38 ` Thierry Reding
2015-07-13 12:39 ` [PATCH V3 15/19] soc: tegra: pmc: Add generic PM domain support Jon Hunter
2015-07-17 11:29 ` Thierry Reding
2015-07-13 12:39 ` [PATCH V3 16/19] soc: tegra: pmc: Remove the deprecated powergate APIs Jon Hunter
2015-07-13 12:39 ` [PATCH V3 17/19] ARM: tegra: Add PM domain device nodes to Tegra124 DT Jon Hunter
2015-07-13 12:39 ` [PATCH V3 18/19] ARM: tegra: add GPU power supply to Jetson TK1 DT Jon Hunter
2015-07-17 9:28 ` Thierry Reding
2015-07-13 12:39 ` [PATCH V3 19/19] ARM: tegra: select PM_GENERIC_DOMAINS Jon Hunter
2015-07-13 13:50 ` Peter De Schrijver
2015-07-13 14:03 ` Jon Hunter
2015-07-14 11:59 ` Jon Hunter
2015-07-15 8:17 ` Peter De Schrijver
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=55ACB54A.4080103@nvidia.com \
--to=jonathanh@nvidia$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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