From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: [RESEND PATCH v4 5/7] remoteproc: qcom: Modify reset sequence for hexagon to support v56 1.5.0 Date: Tue, 13 Dec 2016 14:07:30 -0800 Message-ID: <20161213220730.GK3439@tuxbot> References: <1479981638-32069-1-git-send-email-akdwived@codeaurora.org> <1479981638-32069-6-git-send-email-akdwived@codeaurora.org> <20161209043510.GS30492@tuxbot> <0f3dbcbb-4ed5-dac8-a9c7-a22d597f4be5@codeaurora.org> <20161213180924.GG3439@tuxbot> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pg0-f52.google.com ([74.125.83.52]:35356 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932705AbcLMWOU (ORCPT ); Tue, 13 Dec 2016 17:14:20 -0500 Received: by mail-pg0-f52.google.com with SMTP id p66so290592pga.2 for ; Tue, 13 Dec 2016 14:14:19 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: "Dwivedi, Avaneesh Kumar (avani)" Cc: sboyd@codeaurora.org, agross@codeaurora.org, linux-arm-msm@vger.kernel.org On Tue 13 Dec 11:45 PST 2016, Dwivedi, Avaneesh Kumar (avani) wrote: > On 12/13/2016 11:39 PM, Bjorn Andersson wrote: [..] > >Either way, using the non-_relaxed version of writel() will be > >equivalent to what you have now. > Do you mean if writel is used , udelay() should be removed? No, I mean that looping writel_relaxed() + wmb() is roughly equivalent to writel(). So with the overall comment of you replacing readl_relaxed() and writel_relaxed() with their plain readl/writel counterparts takes care of the wmb(). > i understand > writel will not return before register write operation is actually done. > udelay() is to give enough time so that after writel , there is some time > available to turn on mem peripheral and data array. As far as I understand, wmb() will ensure that any cache coherent or write-back buffered writes are committed before any subsequent writes. But that this is not the same as the write has finished. As far as I can see, the downstream code (msm-3.18) do: for (i = 19; i >= 0; i--) { val |= BIT(i); writel_relaxed(val, MEM_PWR_CTL); val |= readl_relaxed(MEM_PWR_CTL); udelay(1); } I.e. for this particular version it actually does read back the value, which will cause a wait for the write to be propagated. But I'm not sure why this is the only version doing this. Regards, Bjorn