On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: > On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@xxxxxxxxx> 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. -- 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
