On Tue, May 20, 2014 at 4:29 PM, Imre Deak <imre.deak@xxxxxxxxx> wrote: > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote: >> This RFC is based on previous discussion to set up a generic >> communication channel between display and audio driver and >> an internal design of Intel MCG/VPG HDMI audio driver. It's still an >> initial draft and your advice would be appreciated >> to improve the design. >> >> The basic idea is to create a new avsink module and let both drm and >> alsa depend on it. >> This new module provides a framework and APIs for synchronization >> between the display and audio driver. >> >> 1. Display/Audio Client >> >> The avsink core provides APIs to create, register and lookup a >> display/audio client. >> A specific display driver (eg. i915) or audio driver (eg. HD-Audio >> driver) can create a client, add some resources >> objects (shared power wells, display outputs, and audio inputs, >> register ops) to the client, and then register this >> client to avisink core. The peer driver can look up a registered >> client by a name or type, or both. If a client gives >> a valid peer client name on registration, avsink core will bind the >> two clients as peer for each other. And we >> expect a display client and an audio client to be peers for each other >> in a system. > > One problem we have at the moment is the order of calling the system > suspend/resume handlers of the display driver wrt. that of the audio > driver. Since the power well control is part of the display HW block, we > need to run the display driver's resume handler first, initialize the > HW, and only then let the audio driver's resume handler run. For similar > reasons we have to call the audio suspend handler first and only then > the display driver resume handler. Currently we solve this using the > display driver's late/early suspend/resume hooks, but we'd need a more > robust solution. > > This seems to be a similar issue to the load time ordering problem that > you describe later. Having a real device for avsync that would be a > child of the display device would solve the ordering issue in both > cases. I admit I haven't looked into it if this is feasible, but I would > like to see some solution to this as part of the plan. Yeah, this is a big reason why I want real devices - we have piles of infrastructure to solve these ordering issues as soon as there's a struct device around. If we don't use that, we need to reinvent all those wheels ourselves. -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
