On Tue, Feb 24, 2015 at 09:41:41AM -0800, Bob Paauwe wrote: > On Tue, 24 Feb 2015 17:17:18 +0100 > Daniel Vetter <daniel@xxxxxxxx> wrote: > > Internally in the driver the only work needed to do would be to add any > > missing properties. All the acpi atomic update code should be fully i915 > > agnostic and only use generic atomic update interfaces. > > ACPI isn't really driver agnostic since it's only available to IA based > drivers. So I'm not sure I follow your thinking here. Maybe it will > make more sense to me as I look at the atomic properties. Yeah I don't expect anyone else but i915 to use this, but reusing the atomic interface (which is already abi towards userspace) means we don't have another slightly different interface where abi compatibility matters. Hence why I want to reuse the atomic interface. ARM ofc has the cross-vendor dt, so there even code reuse would be possible. And there's still rumours that at least some arm64 platforms will only ship with acpi, so maybe there's even some room to share that code. But really my main goal is to not create another ABI layer but instead try to fully reuse the atomic one by using a mechanical mapping for acpi. > I needed to get some fresh eyes looking at this which is why I posted > it. I appreciate the feedback and will be incorporating it into the > next version. Well I haven't looked at it in details. And I dont think anyone but your group has a need for this, so not sure who could do a more in-depth review if you want that. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
