[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D2D197AF-0072-42AC-A844-8D6BC9677949@canonical.com>
Date: Fri, 10 May 2019 23:18:52 +0800
From: Kai Heng Feng <kai.heng.feng@...onical.com>
To: Keith Busch <kbusch@...nel.org>
Cc: "Mario.Limonciello@...l.com" <Mario.Limonciello@...l.com>,
"hch@....de" <hch@....de>, "axboe@...com" <axboe@...com>,
"sagi@...mberg.me" <sagi@...mberg.me>,
"rafael@...nel.org" <rafael@...nel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"Busch, Keith" <keith.busch@...el.com>
Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3
on Suspend-to-Idle
> On May 10, 2019, at 10:02 PM, Keith Busch <kbusch@...nel.org> wrote:
>
> On Thu, May 09, 2019 at 11:05:42PM -0700, Kai-Heng Feng wrote:
>> Yes, that’ what I was told by the NVMe vendor, so all I know is to impose a
>> memory barrier.
>> If mb() shouldn’t be used here, what’s the correct variant to use in this
>> context?
>
> I'm afraid the requirement is still not clear to me. AFAIK, all our
> barriers routines ensure data is visible either between CPUs, or between
> CPU and devices. The CPU never accesses HMB memory, so there must be some
> other reasoning if this barrier is a real requirement for this device.
Sure, I’ll ask vendor what that MemRd is for.
Kai-Heng
Powered by blists - more mailing lists