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

[Kumar Gala]

On Jan 21, 2015, at 7:53 PM, Bjorn Andersson <bjorn@xxxxxxx> wrote:

> On Wed, Jan 21, 2015 at 5:13 PM, Olof Johansson <olof@xxxxxxxxx> wrote:
> [..]
>> On Mon, Aug 4, 2014 at 6:31 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote:
>>> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/