On Mon, Jul 16, 2018 at 11:25 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > 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@xxxxxxx> 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? Preferably: SPDX-License-Identifier: MIT or I suppose dual licensing (MIT or GPL 2.0) is ok too. Alex > > > thanks, > > Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
