On Thu, Jan 23, 2014 at 8:57 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> Thanks for clarification! >> Maybe we can add output info (eg. display port number) to the eld entries under /proc/asound/cardx. Is it okay? > > It's possible, but the proc file is just a help. It can't be the > API. For accessing the information, we'll need some new API, or let > inform via sysfs of the new device. Links in sysfs sound like the best approach. drm already has nodes for each connector, so on the gfx side there's a natural endpoint already. sysfs links also avoids any naming issues from the start, e.g. the above DP connector id might lead to clashes with multiple cards. >> And I have a question: how to assure the audio/gfx client find its right peer? >> On a x86 platform, there can be an integrated GPU and an discrete GPU. So there can be two audio controllers and two GPUs. >> We need to assure audio controller find the proper GPU, and vice versa. Maybe we need the peer audio/gfx to register with a same identifier (something like vendor ID) for peering. > > Yes, it's an open issue. So far, the binding with vga_switcheroo is > done by a rough guess with PCI ID. Yeah, I guess we need platform/bus specific hints. E.g. on x86 we could use the pci id of the gfx card + enumeration of all the audio input pins (and just hope that there's no one insane enough to route different codecs to the same gfx card or something like that). On ARM we could just fish device refernences out of dt. So probably we need some platform specific code to fish out the right avsink from the audio side. -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
