On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark wrote:
> On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson 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.
>
> I think the question is probably "how do downstream HDCP
> implementations work on these other SoCs".. so far, I think qcom is
> the first to try to upstream HDCP support, but I know there have to be
> at least a few downstream implementations lurking out there.
>
This isn't a concern on exynos, fwiw.
> And I'm sure as some others come out of the woodwork there will be
> some things to refactor.. like possibly shared helpers for
> implementing the state machine, etc.
>
Shared helpers would be useful to have once there's another hdcp
implementation upstream. I haven't looked at our downstream hdcp
implementation in a while, so it's difficult to say how much could be
factored out. It's on my TODO stack... somewhere.
Sean
> BR,
> -R
>
>> 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.
