> On Tue, May 20, 2014 at 05:29:07PM +0300, Imre Deak 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. > > If we are able create and mandate that HDMI display controller is parent and > audio is child device, then this wouldn't be an issue and PM frameowrk will > ensure parent is suspended last. > If there is a scenario where HDMI audio has to active but display has to go to low power, then parent-child device is not optimal. There needs to be a mechanism to turn on/off individual hw blocks within the controller. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
