From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161684AbbBDUpl (ORCPT ); Wed, 4 Feb 2015 15:45:41 -0500 Received: from smtp.codeaurora.org ([198.145.11.231]:51086 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161474AbbBDUph convert rfc822-to-8bit (ORCPT ); Wed, 4 Feb 2015 15:45:37 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20) From: Kumar Gala In-Reply-To: Date: Wed, 4 Feb 2015 14:45:31 -0600 Cc: "arm@kernel.org" , Kevin Hilman , Arnd Bergmann , linux-arm-msm , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Stephen Boyd , Lina Iyer , Saravana Kannan , Olav Haugan , Vikram Mulukutla Content-Transfer-Encoding: 8BIT Message-Id: <9F29C4A8-BD35-4E87-9765-56597A38F134@codeaurora.org> References: <20150122011521.GA31815@quad.lixom.net> To: Olof Johansson X-Mailer: Apple Mail (2.1878.6) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> I'd be OK with merging this, send a request and tag. Would that let >>> the DRM folks make progress too? >> >> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver. >> >>> If you need a common place for this, drivers/firmware seems like a >>> better home than drivers/soc. >> >> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface? > > Are there any other SoCs out there with similar requirements on > firmware interfaces? I think most of them so far have been fairly > simple compared to the complexity of the qualcomm firmware. > > Would it make sense to use firmware_ops for the common pieces and have > direct smc calls for the rest? I'm not sure that would buy us all that > much. Hm. > > Well, at least it's an internal implementation detail. If we move it > now and find a better way to do it down the road it can be refactored. So I’ve been looking at the ARM firmware_ops and I’m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around. The firmware_ops don’t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value. I’ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project