Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752280AbdCCSYg (ORCPT ); Fri, 3 Mar 2017 13:24:36 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:42698 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751660AbdCCSXr (ORCPT ); Fri, 3 Mar 2017 13:23:47 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org D0CBE607A5 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Fri, 3 Mar 2017 10:23:02 -0800 From: Stephen Boyd To: "Dwivedi, Avaneesh Kumar (avani)" Cc: bjorn.andersson@linaro.org, agross@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org Subject: Re: [PATCH v2 3/3] remoteproc: qcom: Add msm8996 specific changes in mss rproc driver. Message-ID: <20170303182302.GU25384@codeaurora.org> References: <1485773044-31489-1-git-send-email-akdwived@codeaurora.org> <1485773044-31489-4-git-send-email-akdwived@codeaurora.org> <20170227224800.GE25384@codeaurora.org> <82ef090c-71fb-dd20-f54b-b52931e78d08@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82ef090c-71fb-dd20-f54b-b52931e78d08@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1209 Lines: 34 On 03/03, Dwivedi, Avaneesh Kumar (avani) wrote: > On 2/28/2017 4:18 AM, Stephen Boyd wrote: > >On 01/30, Avaneesh Kumar Dwivedi wrote: > >>@@ -1213,6 +1299,47 @@ static int q6v5_remove(struct platform_device *pdev) > >> return 0; > >> } > >>+static const struct rproc_hexagon_res msm8996_mss = { > >>+ .hexagon_mba_image = "mba.mbn", > >>+ .proxy_supply = (struct qcom_mss_reg_res[]) { > >>+ { > >>+ .supply = "vdd_mx", > >>+ .uV = 6, > >>+ }, > >>+ { > >>+ .supply = "vdd_cx", > >>+ .uV = 7, > >>+ .uA = 100000, > >>+ }, > >vdd cx and vdd mx are corners. The plan is to _not_ use the > >regulator framework for those, so treating them like supplies is > >incorrect here. > vdd cx and mx though in downstream are voted for corner but they are > always ON domain upstream as per regulator team when i discussed > with them. > should i drop them altogether? I would say yes, drop them. The on/off state doesn't matter here. This code wants to max out the corner for a period of time until the remote processor has booted far enough to make their own vote on these RPM resources. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project