qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala [off-list ref] wrote:

quoted

quoted

quoted

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.

quoted

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.

Ok. Thanks for investigating.

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.

Yeah, that'd be preferred.


-Olof