[GIT PULL] qcom SoC changes for v3.20

On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark [off-list ref] wrote:

On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson [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.

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

quoted

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.