On Tue, 2014-05-20 at 20:05 +0530, Vinod Koul wrote: > 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. To my understanding we can't really do that since that's already fixed by the physical bus topology. That is in the Intel case the parent of both the audio and display device is the corresponding PCI bridge device. But avsync could be a new virtual device and you could let that be the child of the display device. --Imre
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
