On Mon, 16 Jul 2018 17:10:43 +0200, Harry Wentland wrote: > > > > On 2018-07-15 10:36 AM, Alex Deucher wrote: > > On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai <tiwai at suse.de> wrote: > >> On Sat, 14 Jul 2018 14:03:26 +0200, > >> jimqu wrote: > >>> > >>> > >>> > >>> å?¨ 2018/7/13 23:07, Takashi Iwai å??é??: > >>>> On Wed, 11 Jul 2018 13:12:01 +0200, > >>>> Takashi Iwai wrote: > >>>>> And the forced runtime PM is still an issue, and this would need the > >>>>> other notification mechanism than the HD-audio unsolicited event as > >>>>> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit. > >>>> Since we had a nice "hack week" in this week at SUSE, I spent some > >>>> time to write some patches for the support of the direct hotplug > >>>> notification / ELD query between HD-audio and radeon/amdgpu. It > >>>> re-utilizes the audio component framework for i915 but in a slightly > >>>> more flexible way. > >>>> > >>>> The patches are found in topic/hda-acomp branch of my sound.git tree: > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > >>>> > >>>> The following commits are relevant: > >>>> drm/i915: Split audio component to a generic type > >>>> ALSA: hda/i915: Allow delayed i915 audio component binding > >>>> ALSA: hda/i915: Associate audio component with devres > >>>> ALSA: hda: Make audio component support more generic > >>>> ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI > >>>> ALSA: hda/hdmi: Use single mutex unlock in error paths > >>>> drm/radeon: Add audio component support > >>>> drm/amdgpu: Add audio component support > >>>> > >>>> The branch should be cleanly pullable onto the latest 4.18-rc. > >>>> > >>>> I couldn't test amdgpu but the test with a radeon driver on an old > >>>> laptop seemed working through a very quick test. > >>>> > >>>> Please give it a try. > >>> > >>> That is really wonderful work. I will check it on our AMD > >>> platform. > >> > >> Thanks, it'll be great if you can check whether the current code works > >> or not. I'd love to push the stuff for 4.19. Hopefully I'll start > >> submitting the preparation patches in the next week. > >> > >> Basically this also opens the door of the similar capability for > >> nouveau, and I guess it's also trivial enough. > >> > >>> BTW, For display, AMD has moved to use DC to support new > >>> asics. so there also need a patch for amdgpu in DC code. > >> > >> Could you give a more hint? I'll try adapt the code if such a change > >> is already in upstream tree. > > > > The new code is in drivers/gpu/drm/amd/display. > > > > In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event. Thanks, I'm currently struggling to read down the whole complex DC code tree, and it's a very helpful hint. How is the audio enable/disable call associated with the pipe index? IOW, if I add a hook to call a notifier callback to pass the pipe index that is enabled/disabled, how can it be deduced? Similarly, when DC driver gets the query about the ELD on the given pipe, where can I convert it to which object? DC is quite another beast, so I still haven't figured out the structures yet... > I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well. Oh I just didn't know that amdgpu code was with MIT. Indeed the driver module is provided via "GPL and additional rights". I'm fine to change the license to follow other code bits there. What exactly SPDX tag should be put there? thanks, Takashi
