>>> 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
On Wed, Feb 4, 2015 at 12:45 PM, Kumar Gala <[email protected]> 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