On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala <galak@xxxxxxxxxxxxxx> wrote: >>>> 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
