Thread (17 messages) 17 messages, 6 authors, 2015-01-23

[PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom

From: Kumar Gala <hidden>
Date: 2015-01-22 16:50:08
Also in: linux-arm-msm, lkml

On Jan 21, 2015, at 7:53 PM, Bjorn Andersson [off-list ref] wrote:
On Wed, Jan 21, 2015 at 5:13 PM, Olof Johansson [off-list ref] wrote:
[..]
quoted
On Mon, Aug 4, 2014 at 6:31 PM, Stephen Boyd [off-list ref] wrote:
quoted
Architectural changes in the ARM Linux kernel tree mandate
the eventual removal of the mach-* directories. Move the
scm driver to drivers/soc/qcom and the scm header to
include/soc/qcom to support that removal.
The idea is not blindly move one dumping ground to a new place.

I see only two exported functions from scm.c:

scm_get_version: This is not used anywhere in the kernel and can just be removed
scm_call: This is used by scm-boot, and would be better to translate
over to firmware_ops in the first place.
Hi Olof,

I started this a while ago, as it felt like the right thing to do <tm>.

The problem with this approach is that e.g. firmware loading is
partially handled through this interface. So implementing a remoteproc
driver for wifi etc required me to add 6 new ops to the struct,
loading the modem looks like it requires one more. HDMI requires one.

Looking at the downstream branch there's a bunch more (20+), so we
would explode the firmware_ops struct with Qualcomm "specific" ops.
This is not necessarily a bad idea, but needs to be considered before
we jump the gun.


I haven't looked at the arm64 stuff in detail, but it looks to be
shared between the two platforms, so either way it seems like the
right approach to have this moved out to drivers/soc/qcom.
As Bjorn says the scm interface ends up having a number of qcom specific calls that I don?t think the firmware ops should be implementing.  I don?t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection.

I?m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today.  However, I?m not clear on what the view of extending firmware_ops to arm64 is.  If we do this do we move the firmware_ops code into drivers/soc ?

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help