Return-path: Received: from smtp.codeaurora.org ([198.145.11.231]:38076 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933403AbbBBTP4 (ORCPT ); Mon, 2 Feb 2015 14:15:56 -0500 Message-ID: <54CFCCCF.900@codeaurora.org> (sfid-20150202_201559_539710_53FA2B92) Date: Mon, 02 Feb 2015 11:15:27 -0800 From: Peter Oh MIME-Version: 1.0 To: Johannes Berg , Peter Oh CC: linux-wireless@vger.kernel.org, Bob Copeland , ath10k@lists.infradead.org Subject: Re: [PATCH] ath10k: Replace ioread with wmb for data sync References: <1422311118-11320-1-git-send-email-poh@qca.qualcomm.com> <20150127213349.GA24933@localhost> <54C824DC.5080804@qca.qualcomm.com> <20150128043005.GB24933@localhost> <54C875FD.3070101@qca.qualcomm.com> (sfid-20150128_064104_435635_7E681844) <1422430643.1973.1.camel@sipsolutions.net> <54CC0B71.9050301@codeaurora.org> <1422882133.1930.10.camel@sipsolutions.net> <54CFB4F4.1070807@qca.qualcomm.com> <1422903279.8755.1.camel@sipsolutions.net> In-Reply-To: <1422903279.8755.1.camel@sipsolutions.net> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 02/02/2015 10:54 AM, Johannes Berg wrote: > On Mon, 2015-02-02 at 09:33 -0800, Peter Oh wrote: > >>> The code (as it is before your patch) implies that it's trying to make >>> sure that before it continues, any previous writes to the PCIe > device's >>> registers are posted. The only way to ensure that is to do a read to > the >>> registers, as the code does now. >> Do you know how the read ensure that although the read code does not >> check the return value? >> Can you explain how a read ensures that posted write reaches PCIe > device? > > You basically have the following sequence: > > iowrite() > ioread() > > If you look, you'll see that iowrite() is actually done (or should be, > or perhaps with appropriate syncs) on an uncached mapping. since it's mmio, iowrite will be map to write, not out which is cached mapping. That's why we address "posted write" here. If it's un-cached mapping which is volatile, we don't even need ioread. > As a result, > the only thing you care about here is the PCIe bus, not the CPU cache > flush. And from there on that's just a question of PCIe bus semantics. So how does ioread guarantee PCIe bus transaction done? > > johannes > > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k Regards, Peter