Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Takashi, In order to let audio power-save work even with charger connected, two parameters need be modified in userspace pm-utils scripts. I tested the changes under Ubuntu 13.10 on Harris Beach, no matter charger connected or not, runtime power-saving works and power-well will Be released as expected. Here's my test under Ubuntu 13.04, the changes are: 1) /usr/lib/pm-utils/power.d/intel-audio-powersave case $1 in true) audio_powersave 1 ;; +false) audio_powersave 10 ;; -false) audio_powersave 0 ;; help) help;; *) exit $NA esac Audio will enter power-save mode after 10s inactive period. 2) /usr/lib/pm-utils/power.d/pci_devices 0x040300) # audio echo Setting Audio device $id to $1 + echo auto $dev/power/control -echo $1 $dev/power/control This keep audio subsystem always on. This way the user may not let audio subsystem always active, may bring some delay from codec/controllers, or harm some chips. Do you think we should add an exception for Haswell only or just make it as a common solution for audio subsystem? Thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Wednesday, July 24, 2013 10:00 PM To: Takashi Iwai Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio -p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. Oh yes I found the hook: ./pm/power.d/intel-audio-powersave --xingchao The former is unknown, but better to check pm-utils hooks and udev rules. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Paulo, Would you help verify attached patch to fix this issue for you? The patch is based on Takashi's tree, the last commit is: commit 9b298cfe296c0f8e088b9ed9a670783a06005e6b I think it should be safe to merge into your tree. :) I tested the patch on Harris Beach, it would let audio driver release power-well even with charger connected. Please note maybe this is not the final solution for this issue as it breaks some rule from user's point of view. Some background of this issue: This patch intended to fix power-well regression on Haswell. On Harris Beach(Ultrabook with battery), there's only eDP panel connected by default, no HDMI/DP. And gfx driver needs enable some HW feature for eDP, power-well *must* be disabled in this scenario. - Witout charger connected, power-well feature is perfect - with charger connected, audio never release power-well. Basically, power-well should be release if audio driver doesnot use it, that's why we enabled runtime power-save feature. In second case above, with charger connected, the parameter under /sys/devices/../power/control become on always. In audio driver side, power_save was set to 0, which disable power_down the codecs and controller, thus never release power-usage_count. And this blocks audio driver release power-well. In the second case, if audio driver detect hdmi pins are free and no Apps opened device, it will eanble runtime power-save feature as an exception. I test this patch on Harris beach with charger connected, the power-well could be released as expected. Thanks --xingchao -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Thursday, July 18, 2013 5:35 PM To: Wang, Xingchao Cc: Daniel Vetter; Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Thu, 18 Jul 2013 09:23:57 +, Wang, Xingchao wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, July 18, 2013 2:44 PM To: Wang, Xingchao Cc: Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; Takashi Iwai; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote: Hi Paulo/Daniel, Do you agree to export an API in gfx side for eDP case? Basically the api will let audio drver know which pipe in use. i.e. in the eDP only caes, audio driver Will know gfx is not using HDMI/DP and would like to let power-well off. As there's the conflict when user expect display audio driver always active but gfx need audio driver off. Audio driver could make decision to release power-well if it knows the eDP only case through the API. OTOH, I think audio driver could also export an API for gfx side, if gfx driver need audio driver release power-well but it's in usage, It will call this API and audio drvier will release power-well accordingly. This change make HDMI/DP hotplug handling complicated in audio driver side, if audio driver release power-well, it would enter suspend mode. Meanwhile the user may expect it's in active mode, this may cause some confuse. Afaik (and I know very little about audio) the audio side already knows which pipes have audio enabled, since we set the respective bit only when it's needed. And audio will receive the unsolicited even interrupt (or whatever it's called) when this happens. For haswell, Audio driver can get DDI port/Pin usage information according to the unsolicited event, not Pipe info. However at this stage, seems only that is enough: if no pin has valid ELD, audio driver can think about that no monitor connected with DDI ports. In this case, Audio driver could release power-well and enter suspend mode automatically, this avoid blocking eDP feature enabling. And once gfx dirver Detect external monitor connected, it will also wake up audio driver. Takashi, do you think this solution acceptable? It's the current situation, isn't it? So the question is only whether this works _as expected_. Basically system/user needs to set up two parameters for the audio power-saving. If both are set well, but it still doesn't work, we need to debug. Of course, we can improve things, for example, the default runtime PM setup. (Note that this is about the default value, not the value force to set.) Takashi Thanks --xingchao So I think we already have the means (albeit with that quirky hw interface, but it seems to have been good enough
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-power save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save Thanks --xingchao Trying to modify the kernel to work around that would be insane. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. The former is unknown, but better to check pm-utils hooks and udev rules. Okay, thank you all for pointing out to the right direction. I'm checking the pm-utils mentioned from David. :) Thanks --xingchao Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. Oh yes I found the hook: ./pm/power.d/intel-audio-powersave --xingchao The former is unknown, but better to check pm-utils hooks and udev rules. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Wang, Xingchao Sent: Wednesday, July 24, 2013 10:00 PM To: 'Takashi Iwai' Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio -p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. Oh yes I found the hook: ./pm/power.d/intel-audio-powersave --xingchao The former is unknown, but better to check pm-utils hooks and udev rules. Sound like it's from below hook under Ubuntu: /usr/lib/pm-utils/power.d/ pci_devices Here's the output of power control from all pci devices : xingchao@xingchao-harris-beach:~$ cat /sys/devices/pci\:00/\:00\:*/power/control on on auto ... On The only auto is for audio pci device as applied my patch. And I donot know how Ubuntu change the ac/battery policy yet. Thanks --xingchao Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, July 18, 2013 2:44 PM To: Wang, Xingchao Cc: Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; Takashi Iwai; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote: Hi Paulo/Daniel, Do you agree to export an API in gfx side for eDP case? Basically the api will let audio drver know which pipe in use. i.e. in the eDP only caes, audio driver Will know gfx is not using HDMI/DP and would like to let power-well off. As there's the conflict when user expect display audio driver always active but gfx need audio driver off. Audio driver could make decision to release power-well if it knows the eDP only case through the API. OTOH, I think audio driver could also export an API for gfx side, if gfx driver need audio driver release power-well but it's in usage, It will call this API and audio drvier will release power-well accordingly. This change make HDMI/DP hotplug handling complicated in audio driver side, if audio driver release power-well, it would enter suspend mode. Meanwhile the user may expect it's in active mode, this may cause some confuse. Afaik (and I know very little about audio) the audio side already knows which pipes have audio enabled, since we set the respective bit only when it's needed. And audio will receive the unsolicited even interrupt (or whatever it's called) when this happens. For haswell, Audio driver can get DDI port/Pin usage information according to the unsolicited event, not Pipe info. However at this stage, seems only that is enough: if no pin has valid ELD, audio driver can think about that no monitor connected with DDI ports. In this case, Audio driver could release power-well and enter suspend mode automatically, this avoid blocking eDP feature enabling. And once gfx dirver Detect external monitor connected, it will also wake up audio driver. Takashi, do you think this solution acceptable? Thanks --xingchao So I think we already have the means (albeit with that quirky hw interface, but it seems to have been good enough for a long time already) to do that. Or do I miss something? -Daniel Thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Thursday, July 18, 2013 7:18 AM To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 10:22 PM To: David Henningsson Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 16:05:43 +0200, David Henningsson wrote: On 07/17/2013 04:00 PM, Takashi Iwai wrote: At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote: 2013/7/17 Wang, Xingchao xingchao.w...@intel.com: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 4:18 PM To: Wang, Xingchao Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; david.hennings...@canonical.com Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 3:34 PM To: Wang, Xingchao Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; david.hennings...@canonical.com Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote: Hi Takashi/Paulo, would you change it to auto and test again. Runtime power save should be enabled with auto. Doesn't solve the problem. Should I open a bug report somewhere? Having the power well enabled prevents some power
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features
from the graphics driver.
Is the HD-audio power-saving itself working? You can check it via
watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that many
DEs change this value dynamically per AC-cable plug/unplug depending
on the configuration, and often it's set to 0 (= no power save) when
AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors connected, It's
using internal eDP and totally no audio support. Power-well usage in such case
also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy when
charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be changed,
instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the power_save
option and it's set up dynamically by the desktop system. We shouldn't
override it in the driver.
If the power well *must* be off when only an eDP is used (e.g. otherwise the
hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
If it's the case, controlling the power well based on the runtime PM is
likely a
bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
Thanks
--xingchao
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check it
via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that
many DEs change this value dynamically per AC-cable plug/unplug
depending on the configuration, and often it's set to 0 (= no
power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors
connected, It's
using internal eDP and totally no audio support. Power-well usage in
such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy
when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs
power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long as this
parameter is set. And this is the parameter user controls, and not what the
driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is active and
requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
thanks
--xingchao
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 10:22 PM
To: David Henningsson
Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 16:05:43 +0200,
David Henningsson wrote:
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300,
Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report
somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check
it via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note
that many DEs change this value dynamically per AC-cable
plug/unplug depending on the configuration, and often it's
set to 0 (= no power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display
audio controller. Moreover, in this board, if no external
monitors connected, It's
using internal eDP and totally no audio support. Power-well
usage in such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power
policy when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A
controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should
be changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A
controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the
runtime PM is likely a bad design, as it relies on the parameter user
sets.
(And remember that the power-saving of the audio can be
disabled completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active,
it needs power
and should request power-well from gfx side.
In above case, audio controller should not be active but user
set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long
as this parameter is set. And this is the parameter user
controls, and not what the driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is
active
and requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
On our driver we try to disable the power well whenever possible,
as soon as possible. We don't
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Paulo/Daniel,
Do you agree to export an API in gfx side for eDP case?
Basically the api will let audio drver know which pipe in use. i.e. in the eDP
only caes, audio driver
Will know gfx is not using HDMI/DP and would like to let power-well off.
As there's the conflict when user expect display audio driver always active but
gfx need audio driver off.
Audio driver could make decision to release power-well if it knows the eDP only
case through the API.
OTOH, I think audio driver could also export an API for gfx side, if gfx driver
need audio driver release power-well but it's in usage,
It will call this API and audio drvier will release power-well accordingly.
This change make HDMI/DP hotplug handling complicated in audio driver side, if
audio driver release power-well, it would enter suspend mode.
Meanwhile the user may expect it's in active mode, this may cause some confuse.
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Thursday, July 18, 2013 7:18 AM
To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni
Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch;
intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon
Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 10:22 PM
To: David Henningsson
Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel
Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 16:05:43 +0200,
David Henningsson wrote:
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7]
Power-well API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report
somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check
it via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note
that many DEs change this value dynamically per AC-cable
plug/unplug depending on the configuration, and often it's
set to 0 (= no power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with
charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display
audio controller. Moreover, in this board, if no external
monitors connected, It's
using internal eDP and totally no audio support. Power-well
usage in such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power
policy when charger
connected but it's necessary to add support in this particular
case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A
controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this
should be changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop
system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features from
the graphics driver.
Is the HD-audio power-saving itself working? You can check it via watching
/sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that many DEs
change this value dynamically per AC-cable plug/unplug depending on the
configuration, and often it's set to 0 (= no power save) when AC-cable is
plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger connected, and
see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio controller.
Moreover, in this board, if no external monitors connected,
It's using internal eDP and totally no audio support. Power-well usage in such
case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio controller/codec
suspend in such case?
Thanks
--xingchao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell
On Sat, Jul 06, 2013 at 08:20:59AM +0200, Takashi Iwai wrote:
drm-intel-next. I'll show up in the next linux-next and I'll
forward it to
Dave for mergin into drm-next in roughly 2 weeks.
So today I unblacklisted the audio modules on one of my Haswell
machines and booted it with i915.disable_power_well=1. I only have an
eDP output (it doesn't have audio) and I see the power well is
enabled. This is wrong, the power well should be disabled since we
right, if no application using audio it should be in runtime suspend
mode.
And maybe your system didnot enable runtime suspend by default, would
you
tell me the output below?
cat /sys/devices/pci:00/:00:03.0/power/control
It says on.
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features from
the graphics driver.
Is the HD-audio power-saving itself working? You can check it via
watching /sys/class/hwC*/power_{on|off}_acct files.
I have two Haswell boards, one with auto power-save setting, the other one
has setting on. Here's the power_on/off_acct values:
1) with control setting auto
power_on_acct 14328
power_off_acct 3231848
2) with control setting on
power_on_acct 6330528
power_off_acct 0
So for the second one, power is always on.
Paulo, would you check with your BIOS version?
At least i found BIOS 131 has the default setting on while BIOS 128 has
auto setting.
thanks
--xingchao
power_save option has to be adjusted appropriately. Note that many
DEs change this value dynamically per AC-cable plug/unplug depending
on the configuration, and often it's set to 0 (= no power save) when
AC-cable is plugged.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell
On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote: 2013/6/6 Daniel Vetter dan...@ffwll.ch: On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote: Hi all, This is V7 and here're some changes notes: change from V6--V7: - rename variable - use HAS_POWER_WELL instead of IS_HASWELL - put structure inside drm_i915_private - use WARN_ON for global pointer check change from V5--V6: - Remove duplication code in new introduced probe work - move duplication code in azx_probe_continue - remove unused #ifdef - replace request_module with symbol_request - replace spin_lock_irq with spin_lock_irqsave in gfx side - other typo fixes (review by Takashi) change from V4--V5: - fix reference count bug - new patch on general runtime pm support for audio pci device - new patch to avoid request_module() deadlock change between V3--V4: - add new structure i915_power_well - initialize drm_device pointer at module init time - change function name change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Takashi Iwai (1): ALSA: hda - Move azx_first_init() into azx_probe_continue() Wang Xingchao (3): ALSA: hda - Fix runtime PM check ALSA: hda - Add power-welll support for haswell HDA i915/drm: Add private api for power well usage After discussion with Dave and Takashi I've merged the entire series to drm-intel-next. I'll show up in the next linux-next and I'll forward it to Dave for mergin into drm-next in roughly 2 weeks. So today I unblacklisted the audio modules on one of my Haswell machines and booted it with i915.disable_power_well=1. I only have an eDP output (it doesn't have audio) and I see the power well is enabled. This is wrong, the power well should be disabled since we right, if no application using audio it should be in runtime suspend mode. And maybe your system didnot enable runtime suspend by default, would you tell me the output below? cat /sys/devices/pci:00/:00:03.0/power/control thanks --xingchao only have an eDP panel, and we don't support audio on eDP. I checked on dmesg and the audio driver requests the power well but never releases it. So I decided to do the same test on another Haswell machine, and on that specific machine the audio driver gets the power well and then releases it at azx_runtime_suspend. This machine is also eDP-only I was expecting that on both cases the audio driver would release the power well as soon as it sees there's no connected output capable of HD audio. How can I help debugging this? Thanks, Paulo Thanks, Daniel drivers/gpu/drm/i915/i915_dma.c |6 +++ drivers/gpu/drm/i915/i915_drv.h | 12 ++ drivers/gpu/drm/i915/intel_drv.h |4 ++ drivers/gpu/drm/i915/intel_pm.c | 81 --- include/drm/i915_powerwell.h | 36 sound/pci/hda/Kconfig| 10 + sound/pci/hda/Makefile |2 + sound/pci/hda/hda_i915.c | 75 sound/pci/hda/hda_i915.h | 35 +++ sound/pci/hda/hda_intel.c| 87 ++ 10 files changed, 324 insertions(+), 24 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell
On Thu, Jul 04, 2013 at 10:24:15AM -0300, Paulo Zanoni wrote: 2013/7/4 Wang xingchao xingchao.w...@linux.intel.com: On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote: 2013/6/6 Daniel Vetter dan...@ffwll.ch: On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote: Hi all, This is V7 and here're some changes notes: change from V6--V7: - rename variable - use HAS_POWER_WELL instead of IS_HASWELL - put structure inside drm_i915_private - use WARN_ON for global pointer check change from V5--V6: - Remove duplication code in new introduced probe work - move duplication code in azx_probe_continue - remove unused #ifdef - replace request_module with symbol_request - replace spin_lock_irq with spin_lock_irqsave in gfx side - other typo fixes (review by Takashi) change from V4--V5: - fix reference count bug - new patch on general runtime pm support for audio pci device - new patch to avoid request_module() deadlock change between V3--V4: - add new structure i915_power_well - initialize drm_device pointer at module init time - change function name change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Takashi Iwai (1): ALSA: hda - Move azx_first_init() into azx_probe_continue() Wang Xingchao (3): ALSA: hda - Fix runtime PM check ALSA: hda - Add power-welll support for haswell HDA i915/drm: Add private api for power well usage After discussion with Dave and Takashi I've merged the entire series to drm-intel-next. I'll show up in the next linux-next and I'll forward it to Dave for mergin into drm-next in roughly 2 weeks. So today I unblacklisted the audio modules on one of my Haswell machines and booted it with i915.disable_power_well=1. I only have an eDP output (it doesn't have audio) and I see the power well is enabled. This is wrong, the power well should be disabled since we right, if no application using audio it should be in runtime suspend mode. And maybe your system didnot enable runtime suspend by default, would you tell me the output below? cat /sys/devices/pci:00/:00:03.0/power/control It says on. would you change it to auto and test again. Runtime power save should be enabled with auto. --xingchao thanks --xingchao only have an eDP panel, and we don't support audio on eDP. I checked on dmesg and the audio driver requests the power well but never releases it. So I decided to do the same test on another Haswell machine, and on that specific machine the audio driver gets the power well and then releases it at azx_runtime_suspend. This machine is also eDP-only I was expecting that on both cases the audio driver would release the power well as soon as it sees there's no connected output capable of HD audio. How can I help debugging this? Thanks, Paulo Thanks, Daniel drivers/gpu/drm/i915/i915_dma.c |6 +++ drivers/gpu/drm/i915/i915_drv.h | 12 ++ drivers/gpu/drm/i915/intel_drv.h |4 ++ drivers/gpu/drm/i915/intel_pm.c | 81 --- include/drm/i915_powerwell.h | 36 sound/pci/hda/Kconfig| 10 + sound/pci/hda/Makefile |2 + sound/pci/hda/hda_i915.c | 75 sound/pci/hda/hda_i915.h | 35 +++ sound/pci/hda/hda_intel.c| 87 ++ 10 files changed, 324 insertions(+), 24 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] ALSA: hda - Avoid choose same converter for unused pins
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0 or pin 2, pin 1 could get audio data too.
This patch configure unused pins to choose different converter.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/patch_hdmi.c | 89 +---
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 8983747..e887584 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1110,26 +1110,15 @@ static int hdmi_setup_stream(struct hda_codec *codec,
hda_nid_t cvt_nid,
return 0;
}
-/*
- * HDA PCM callbacks
- */
-static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
-struct hda_codec *codec,
-struct snd_pcm_substream *substream)
+static int hdmi_choose_cvt(struct hda_codec *codec,
+ int pin_idx, int *cvt_id, int *mux_id)
{
struct hdmi_spec *spec = codec-spec;
- struct snd_pcm_runtime *runtime = substream-runtime;
- int pin_idx, cvt_idx, mux_idx = 0;
struct hdmi_spec_per_pin *per_pin;
- struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int cvt_idx, mux_idx = 0;
- /* Validate hinfo */
- pin_idx = hinfo_to_pin_index(spec, hinfo);
- if (snd_BUG_ON(pin_idx 0))
- return -EINVAL;
per_pin = get_pin(spec, pin_idx);
- eld = per_pin-sink_eld;
/* Dynamically assign converter to stream */
for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) {
@@ -1147,10 +1136,77 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
continue;
break;
}
+
/* No free converters */
if (cvt_idx == spec-num_cvts)
return -ENODEV;
+ if (cvt_id)
+ *cvt_id = cvt_idx;
+ if (mux_id)
+ *mux_id = mux_idx;
+
+ return 0;
+}
+
+static void haswell_config_cvts(struct hda_codec *codec,
+ int pin_id, int mux_id)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct hdmi_spec_per_pin *per_pin;
+ int pin_idx, mux_idx;
+ int curr = -1;
+ int err;
+
+ for (pin_idx = 0; pin_idx spec-num_pins; pin_idx++) {
+ per_pin = get_pin(spec, pin_idx);
+
+ if (pin_idx == pin_id)
+ continue;
+
+ curr = snd_hda_codec_read(codec, per_pin-pin_nid, 0,
+ AC_VERB_GET_CONNECT_SEL, 0);
+
+ /* Choose another unused converter */
+ if (curr == mux_id) {
+ err = hdmi_choose_cvt(codec, pin_idx, NULL, mux_idx);
+ if (err 0)
+ return;
+ snd_printk(HDMI: choose converter %d for pin %d\n,
mux_idx, pin_idx);
+ snd_hda_codec_write(codec, per_pin-pin_nid, 0,
+ AC_VERB_SET_CONNECT_SEL,
+ mux_idx);
+ }
+ }
+}
+
+/*
+ * HDA PCM callbacks
+ */
+static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
+struct hda_codec *codec,
+struct snd_pcm_substream *substream)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ int pin_idx, cvt_idx, mux_idx = 0;
+ struct hdmi_spec_per_pin *per_pin;
+ struct hdmi_eld *eld;
+ struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int err;
+
+ /* Validate hinfo */
+ pin_idx = hinfo_to_pin_index(spec, hinfo);
+ if (snd_BUG_ON(pin_idx 0))
+ return -EINVAL;
+ per_pin = get_pin(spec, pin_idx);
+ eld = per_pin-sink_eld;
+
+ err = hdmi_choose_cvt(codec, pin_idx, cvt_idx, mux_idx);
+ if (err 0)
+ return err;
+
+ per_cvt = get_cvt(spec, cvt_idx);
/* Claim converter */
per_cvt-assigned = 1;
hinfo-nid = per_cvt-cvt_nid;
@@ -1158,6 +1214,11 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
snd_hda_codec_write(codec, per_pin-pin_nid, 0,
AC_VERB_SET_CONNECT_SEL,
mux_idx);
+
+ /* configure unused pins to choose other converters */
+ if (codec-vendor_id == 0x80862807)
+ haswell_config_cvts(codec, pin_idx, mux_idx);
+
snd_hda_spdif_ctls_assign(codec, pin_idx, per_cvt-cvt_nid);
/* Initially set the converter's capabilities */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx
Re: [Intel-gfx] [PATCH] ALSA: hda - Avoid choose same converter for unused pins
Hi Takashi/Daniel,
This patch could be used to replace below two:
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029076.html
http://lists.freedesktop.org/archives/intel-gfx/2013-June/029077.html
It could avoid lots of changes in gfx side.
I test the patch and it could fix the same routing issues.
thanks
--xingchao
-Original Message-
From: Wang Xingchao [mailto:xingchao.w...@linux.intel.com]
Sent: Tuesday, June 18, 2013 4:32 PM
To: ti...@suse.de
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Wang, Xingchao; Wang Xingchao
Subject: [PATCH] ALSA: hda - Avoid choose same converter for unused pins
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0 or pin 2, pin 1 could get audio data too.
This patch configure unused pins to choose different converter.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/patch_hdmi.c | 89
+---
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index
8983747..e887584 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1110,26 +1110,15 @@ static int hdmi_setup_stream(struct hda_codec
*codec, hda_nid_t cvt_nid,
return 0;
}
-/*
- * HDA PCM callbacks
- */
-static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
- struct hda_codec *codec,
- struct snd_pcm_substream *substream)
+static int hdmi_choose_cvt(struct hda_codec *codec,
+ int pin_idx, int *cvt_id, int *mux_id)
{
struct hdmi_spec *spec = codec-spec;
- struct snd_pcm_runtime *runtime = substream-runtime;
- int pin_idx, cvt_idx, mux_idx = 0;
struct hdmi_spec_per_pin *per_pin;
- struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int cvt_idx, mux_idx = 0;
- /* Validate hinfo */
- pin_idx = hinfo_to_pin_index(spec, hinfo);
- if (snd_BUG_ON(pin_idx 0))
- return -EINVAL;
per_pin = get_pin(spec, pin_idx);
- eld = per_pin-sink_eld;
/* Dynamically assign converter to stream */
for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) { @@ -1147,10
+1136,77 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
continue;
break;
}
+
/* No free converters */
if (cvt_idx == spec-num_cvts)
return -ENODEV;
+ if (cvt_id)
+ *cvt_id = cvt_idx;
+ if (mux_id)
+ *mux_id = mux_idx;
+
+ return 0;
+}
+
+static void haswell_config_cvts(struct hda_codec *codec,
+ int pin_id, int mux_id)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct hdmi_spec_per_pin *per_pin;
+ int pin_idx, mux_idx;
+ int curr = -1;
+ int err;
+
+ for (pin_idx = 0; pin_idx spec-num_pins; pin_idx++) {
+ per_pin = get_pin(spec, pin_idx);
+
+ if (pin_idx == pin_id)
+ continue;
+
+ curr = snd_hda_codec_read(codec, per_pin-pin_nid, 0,
+ AC_VERB_GET_CONNECT_SEL, 0);
+
+ /* Choose another unused converter */
+ if (curr == mux_id) {
+ err = hdmi_choose_cvt(codec, pin_idx, NULL, mux_idx);
+ if (err 0)
+ return;
+ snd_printk(HDMI: choose converter %d for pin %d\n,
mux_idx,
pin_idx);
+ snd_hda_codec_write(codec, per_pin-pin_nid, 0,
+ AC_VERB_SET_CONNECT_SEL,
+ mux_idx);
+ }
+ }
+}
+
+/*
+ * HDA PCM callbacks
+ */
+static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
+ struct hda_codec *codec,
+ struct snd_pcm_substream *substream) {
+ struct hdmi_spec *spec = codec-spec;
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ int pin_idx, cvt_idx, mux_idx = 0;
+ struct hdmi_spec_per_pin *per_pin;
+ struct hdmi_eld *eld;
+ struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int err;
+
+ /* Validate hinfo */
+ pin_idx = hinfo_to_pin_index(spec, hinfo);
+ if (snd_BUG_ON(pin_idx 0))
+ return -EINVAL;
+ per_pin = get_pin(spec, pin_idx);
+ eld = per_pin-sink_eld;
+
+ err = hdmi_choose_cvt(codec, pin_idx, cvt_idx, mux_idx);
+ if (err 0)
+ return err;
+
+ per_cvt = get_cvt(spec, cvt_idx);
/* Claim converter */
per_cvt-assigned = 1
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add display audio routing APIs for ALSA
Hi Daniel, -Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Tuesday, June 18, 2013 3:13 PM To: Wang, Xingchao Cc: Daniel Vetter; Wang Xingchao; Takashi Iwai; alsa-de...@alsa-project.org; intel-gfx; David Henningsson Subject: Re: [PATCH 3/4] drm/i915: Add display audio routing APIs for ALSA On Mon, Jun 17, 2013 at 12:52:41PM +, Wang, Xingchao wrote: Hi Daniel, -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Sent: Saturday, June 15, 2013 3:18 AM To: Wang Xingchao Cc: Takashi Iwai; alsa-de...@alsa-project.org; intel-gfx; David Henningsson; Wang, Xingchao Subject: Re: [PATCH 3/4] drm/i915: Add display audio routing APIs for ALSA On Fri, Jun 14, 2013 at 5:20 PM, Wang Xingchao xingchao.w...@linux.intel.com wrote: ALSA audio driver need know current audio routing infomation. i.e. Route map between codec pins(DDI ports) and Transcoders(Pipe). Also the new API let audio driver disable unused audio pin's output. This fixed the bug when three pins *ALL* have monitors connected, playing audio on one pin would cause audio output to all minitors. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com So I've started to have a real look at audio on haswell and audio on i915 in general, and I'm seriously confused. Random observations, but I fear this isn't the real story by far yet: - On haswell we now have a hooping 3 places that set up these audio routing register: haswell_write_eld (called from the connector enable callbacks), intel_enable/disable_ddi and now the new hooks you're adding here. That's 2 places too many. If we really need all three places those need to be refactored so that the bit-frobbing logic is all in one place. But I seriously doubt that we need them all. Yeah I agree to put audio stuff in One place. Let me give you some background about the issue this Patch fixed. Basically audio side need such API in gfx side to enable/disable audio, that's three PIPE based audio enable bits. The issue comes when two monitors connected on DDI port B and port C, like: DDI B(pin 0) -- DP monitor DDI C(pin 1) -- HDMI minitor In haswell the pins default choose converter 0(hardware level) as data source, so it's like: Converter 0 -- pin 0 + pin 1 + pin2 And when play audio on pin 0, pin 1 could get audio data too. Meanwhile pin 1 has HDMi minitor connected, you can hear audio. To fix this issue, I tried several solutions: 1) Disable pin 1/2 when play audio on pin 0, or disable pin 0/2 when play audio on pin 1 2) mute pin 1/2 when play audio on pin 0, or mute pin 0/2 when play audio on pin 1 3) configure pin 1/2 to choose other converters when play audio on pin 0. 4) disable audio output enable in gfx side, this is implemented in current patchset. I prefer 1) or 2) it's very simple, but it doesnot work on Haswell. It's the issue I'm trying to fix: Pin 0 must be output-eanbe/unmute when playing audio on pin 1. Seems pin 1 has dependency on pin 0, and I have to disable audio output in gfx side. I don't think it's bad if we implement such API in gfx side, the question is you point out, to make it clean and simple. If Dp1.2 is needed in future, audio side need the pipe-DDI port connections map too. We can reuse power-well module to export such information. To implement solution 4) above, audio side handle request to disable audio output in gfx side: - if only pin 0 is busy playing audio and using valid pipe, disable audio output for pin 1/2. It's the same logic when only pin1 or pin 2 is busy playing audio. - if both pin0 and pin 1 are busy playing audio, only disable pin 2. - if all pins are playing audio, do nothing. In above case when both Pin 0 and pin 1 are connected with Dp and HDMI monitor, if only playing audio on pin 0, disable pin 1's audio output in gfx side Would cause eld info refresh in audio driver side, but that doesnot matter as when you need playing audio on pin 1, the audio output enable bit would be set again. The patch could fix the issue when playing audio on one pin, audio would route to another pin too. In such case, we can drop the second patch in fact. Just reading through your description I prefer option 3) since that should be possible to implement in the audio side only. To reiterate why I don't really like 4) is that touching these bits will result in unsolicted even interrupts on the audio side. So your patch doesn't seem to just disable/enable audio, but there's a big chain of follow-up events going on. So I'm afraid that there's some really subtile dependency in there making your current solution fragile. So what's the downside of option 3? I've rework the patch and sent for Takashi's review. The new patch only has changes in audio
Re: [Intel-gfx] [PATCH] ALSA: hda - Avoid choose same converter for unused pins
Hi Takashi,
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, June 18, 2013 8:07 PM
To: Wang Xingchao
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Wang, Xingchao
Subject: Re: [PATCH] ALSA: hda - Avoid choose same converter for unused pins
At Tue, 18 Jun 2013 16:32:01 +0800,
Wang Xingchao wrote:
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin
with physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0 or pin 2, pin 1 could get audio data too.
This patch configure unused pins to choose different converter.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/patch_hdmi.c | 89
+---
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 8983747..e887584 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1110,26 +1110,15 @@ static int hdmi_setup_stream(struct hda_codec
*codec, hda_nid_t cvt_nid,
return 0;
}
-/*
- * HDA PCM callbacks
- */
-static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
-struct hda_codec *codec,
-struct snd_pcm_substream *substream)
+static int hdmi_choose_cvt(struct hda_codec *codec,
+ int pin_idx, int *cvt_id, int *mux_id)
{
struct hdmi_spec *spec = codec-spec;
- struct snd_pcm_runtime *runtime = substream-runtime;
- int pin_idx, cvt_idx, mux_idx = 0;
struct hdmi_spec_per_pin *per_pin;
- struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int cvt_idx, mux_idx = 0;
- /* Validate hinfo */
- pin_idx = hinfo_to_pin_index(spec, hinfo);
- if (snd_BUG_ON(pin_idx 0))
- return -EINVAL;
per_pin = get_pin(spec, pin_idx);
- eld = per_pin-sink_eld;
/* Dynamically assign converter to stream */
for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) { @@ -1147,10
+1136,77 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
continue;
break;
}
+
/* No free converters */
if (cvt_idx == spec-num_cvts)
return -ENODEV;
+ if (cvt_id)
+ *cvt_id = cvt_idx;
+ if (mux_id)
+ *mux_id = mux_idx;
+
+ return 0;
+}
+
+static void haswell_config_cvts(struct hda_codec *codec,
+ int pin_id, int mux_id)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct hdmi_spec_per_pin *per_pin;
+ int pin_idx, mux_idx;
+ int curr = -1;
Unnecessary initialization.
+ int err;
+
+ for (pin_idx = 0; pin_idx spec-num_pins; pin_idx++) {
+ per_pin = get_pin(spec, pin_idx);
+
+ if (pin_idx == pin_id)
+ continue;
+
+ curr = snd_hda_codec_read(codec, per_pin-pin_nid, 0,
+ AC_VERB_GET_CONNECT_SEL, 0);
+
+ /* Choose another unused converter */
+ if (curr == mux_id) {
+ err = hdmi_choose_cvt(codec, pin_idx, NULL, mux_idx);
+ if (err 0)
+ return;
+ snd_printk(HDMI: choose converter %d for pin %d\n,
mux_idx,
+pin_idx);
It'd be annoying to spew this at each time. It's merely a debug print.
+ snd_hda_codec_write(codec, per_pin-pin_nid, 0,
+ AC_VERB_SET_CONNECT_SEL,
+ mux_idx);
This should be snd_hda_codec_write_cache(), so that the connection will be
restored properly after resume.
(And yes, the original code has the same bug, it should be *_cached(),
too.)
Other than that, the patch looks OK.
Did you confirm that the patch really works?
Yes, in my test it's the same test result as previous patchset.
Please wait a moment, I would ask QA for verify the patch in his side.
Then I will rework the patch and send it for you.
Thanks
--xingchao
thanks,
Takashi
+ }
+ }
+}
+
+/*
+ * HDA PCM callbacks
+ */
+static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
+struct hda_codec *codec,
+struct snd_pcm_substream *substream) {
+ struct hdmi_spec *spec = codec-spec;
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ int pin_idx, cvt_idx, mux_idx = 0;
+ struct hdmi_spec_per_pin *per_pin;
+ struct hdmi_eld *eld;
+ struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int err;
+
+ /* Validate hinfo */
+ pin_idx = hinfo_to_pin_index(spec, hinfo);
+ if (snd_BUG_ON(pin_idx 0
[Intel-gfx] [PATCH V1] ALSA: hda - Avoid choose same converter for unused pins
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin with
physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0 or pin 2, pin 1 could get audio data too.
This patch configure unused pins to choose different converter.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/patch_hdmi.c | 91
1 file changed, 76 insertions(+), 15 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 8983747..43f8b76 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1110,26 +1110,15 @@ static int hdmi_setup_stream(struct hda_codec *codec,
hda_nid_t cvt_nid,
return 0;
}
-/*
- * HDA PCM callbacks
- */
-static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
-struct hda_codec *codec,
-struct snd_pcm_substream *substream)
+static int hdmi_choose_cvt(struct hda_codec *codec,
+ int pin_idx, int *cvt_id, int *mux_id)
{
struct hdmi_spec *spec = codec-spec;
- struct snd_pcm_runtime *runtime = substream-runtime;
- int pin_idx, cvt_idx, mux_idx = 0;
struct hdmi_spec_per_pin *per_pin;
- struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int cvt_idx, mux_idx = 0;
- /* Validate hinfo */
- pin_idx = hinfo_to_pin_index(spec, hinfo);
- if (snd_BUG_ON(pin_idx 0))
- return -EINVAL;
per_pin = get_pin(spec, pin_idx);
- eld = per_pin-sink_eld;
/* Dynamically assign converter to stream */
for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) {
@@ -1147,17 +1136,89 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
continue;
break;
}
+
/* No free converters */
if (cvt_idx == spec-num_cvts)
return -ENODEV;
+ if (cvt_id)
+ *cvt_id = cvt_idx;
+ if (mux_id)
+ *mux_id = mux_idx;
+
+ return 0;
+}
+
+static void haswell_config_cvts(struct hda_codec *codec,
+ int pin_id, int mux_id)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct hdmi_spec_per_pin *per_pin;
+ int pin_idx, mux_idx;
+ int curr;
+ int err;
+
+ for (pin_idx = 0; pin_idx spec-num_pins; pin_idx++) {
+ per_pin = get_pin(spec, pin_idx);
+
+ if (pin_idx == pin_id)
+ continue;
+
+ curr = snd_hda_codec_read(codec, per_pin-pin_nid, 0,
+ AC_VERB_GET_CONNECT_SEL, 0);
+
+ /* Choose another unused converter */
+ if (curr == mux_id) {
+ err = hdmi_choose_cvt(codec, pin_idx, NULL, mux_idx);
+ if (err 0)
+ return;
+ snd_printdd(HDMI: choose converter %d for pin %d\n,
mux_idx, pin_idx);
+ snd_hda_codec_write_cache(codec, per_pin-pin_nid, 0,
+ AC_VERB_SET_CONNECT_SEL,
+ mux_idx);
+ }
+ }
+}
+
+/*
+ * HDA PCM callbacks
+ */
+static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
+struct hda_codec *codec,
+struct snd_pcm_substream *substream)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ int pin_idx, cvt_idx, mux_idx = 0;
+ struct hdmi_spec_per_pin *per_pin;
+ struct hdmi_eld *eld;
+ struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int err;
+
+ /* Validate hinfo */
+ pin_idx = hinfo_to_pin_index(spec, hinfo);
+ if (snd_BUG_ON(pin_idx 0))
+ return -EINVAL;
+ per_pin = get_pin(spec, pin_idx);
+ eld = per_pin-sink_eld;
+
+ err = hdmi_choose_cvt(codec, pin_idx, cvt_idx, mux_idx);
+ if (err 0)
+ return err;
+
+ per_cvt = get_cvt(spec, cvt_idx);
/* Claim converter */
per_cvt-assigned = 1;
hinfo-nid = per_cvt-cvt_nid;
- snd_hda_codec_write(codec, per_pin-pin_nid, 0,
+ snd_hda_codec_write_cache(codec, per_pin-pin_nid, 0,
AC_VERB_SET_CONNECT_SEL,
mux_idx);
+
+ /* configure unused pins to choose other converters */
+ if (codec-vendor_id == 0x80862807)
+ haswell_config_cvts(codec, pin_idx, mux_idx);
+
snd_hda_spdif_ctls_assign(codec, pin_idx, per_cvt-cvt_nid);
/* Initially set the converter's capabilities */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx
Re: [Intel-gfx] [PATCH V1] ALSA: hda - Avoid choose same converter for unused pins
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, June 18, 2013 10:14 PM
To: Wang Xingchao
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Wang, Xingchao
Subject: Re: [PATCH V1] ALSA: hda - Avoid choose same converter for unused
pins
At Tue, 18 Jun 2013 21:42:14 +0800,
Wang Xingchao wrote:
For Intel Haswell HDMI codecs, the pins choose converter 0 by default.
This would cause conflict when playing audio on unused pins,the pin
with physical device connected would get audio data too.
i.e. Pin 0/1/2 default choose converter 0, pin 1 has HDMI monitor connected.
when play audio on Pin 0 or pin 2, pin 1 could get audio data too.
This patch configure unused pins to choose different converter.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/patch_hdmi.c | 91
1 file changed, 76 insertions(+), 15 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 8983747..43f8b76 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1110,26 +1110,15 @@ static int hdmi_setup_stream(struct hda_codec
*codec, hda_nid_t cvt_nid,
return 0;
}
-/*
- * HDA PCM callbacks
- */
-static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
-struct hda_codec *codec,
-struct snd_pcm_substream *substream)
+static int hdmi_choose_cvt(struct hda_codec *codec,
+ int pin_idx, int *cvt_id, int *mux_id)
{
struct hdmi_spec *spec = codec-spec;
- struct snd_pcm_runtime *runtime = substream-runtime;
- int pin_idx, cvt_idx, mux_idx = 0;
struct hdmi_spec_per_pin *per_pin;
- struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int cvt_idx, mux_idx = 0;
- /* Validate hinfo */
- pin_idx = hinfo_to_pin_index(spec, hinfo);
- if (snd_BUG_ON(pin_idx 0))
- return -EINVAL;
per_pin = get_pin(spec, pin_idx);
- eld = per_pin-sink_eld;
/* Dynamically assign converter to stream */
for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) { @@ -1147,17
+1136,89 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
continue;
break;
}
+
/* No free converters */
if (cvt_idx == spec-num_cvts)
return -ENODEV;
+ if (cvt_id)
+ *cvt_id = cvt_idx;
+ if (mux_id)
+ *mux_id = mux_idx;
+
+ return 0;
+}
+
+static void haswell_config_cvts(struct hda_codec *codec,
+ int pin_id, int mux_id)
+{
+ struct hdmi_spec *spec = codec-spec;
+ struct hdmi_spec_per_pin *per_pin;
+ int pin_idx, mux_idx;
+ int curr;
+ int err;
+
+ for (pin_idx = 0; pin_idx spec-num_pins; pin_idx++) {
+ per_pin = get_pin(spec, pin_idx);
+
+ if (pin_idx == pin_id)
+ continue;
+
+ curr = snd_hda_codec_read(codec, per_pin-pin_nid, 0,
+ AC_VERB_GET_CONNECT_SEL, 0);
+
+ /* Choose another unused converter */
+ if (curr == mux_id) {
+ err = hdmi_choose_cvt(codec, pin_idx, NULL, mux_idx);
+ if (err 0)
+ return;
+ snd_printdd(HDMI: choose converter %d for pin %d\n,
mux_idx, pin_idx);
+ snd_hda_codec_write_cache(codec, per_pin-pin_nid, 0,
+ AC_VERB_SET_CONNECT_SEL,
+ mux_idx);
+ }
+ }
+}
+
+/*
+ * HDA PCM callbacks
+ */
+static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
+struct hda_codec *codec,
+struct snd_pcm_substream *substream) {
+ struct hdmi_spec *spec = codec-spec;
+ struct snd_pcm_runtime *runtime = substream-runtime;
+ int pin_idx, cvt_idx, mux_idx = 0;
+ struct hdmi_spec_per_pin *per_pin;
+ struct hdmi_eld *eld;
+ struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int err;
+
+ /* Validate hinfo */
+ pin_idx = hinfo_to_pin_index(spec, hinfo);
+ if (snd_BUG_ON(pin_idx 0))
+ return -EINVAL;
+ per_pin = get_pin(spec, pin_idx);
+ eld = per_pin-sink_eld;
+
+ err = hdmi_choose_cvt(codec, pin_idx, cvt_idx, mux_idx);
+ if (err 0)
+ return err;
+
+ per_cvt = get_cvt(spec, cvt_idx);
/* Claim converter */
per_cvt-assigned = 1;
hinfo-nid = per_cvt-cvt_nid;
- snd_hda_codec_write(codec, per_pin-pin_nid, 0,
+ snd_hda_codec_write_cache(codec, per_pin-pin_nid, 0,
AC_VERB_SET_CONNECT_SEL,
mux_idx);
You shouldn't mix this fix into your patch.
This change should be applied as a separate
Re: [Intel-gfx] [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device
-Original Message- From: David Henningsson [mailto:david.hennings...@canonical.com] Sent: Monday, June 17, 2013 4:24 PM To: Wang Xingchao Cc: ti...@suse.de; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Wang, Xingchao Subject: Re: [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device On 06/14/2013 05:20 PM, Wang Xingchao wrote: when user open HDMI device 3/7/8, if it has no physical device connected, return error. This patch will cause regressions in two big use cases: 1) Older chipsets (at least from non-Intel vendors) might not support correct ELD reporting. Thus this will cause HDMI audio to stop working there. Thanks for pointing this out. It's a good case I missed. :) I thought ELD info was monitor specific, and reported on common platforms. But sometimes user get confused when opening a hdmi device and started to play audio,but hear nothing, even there's no error message. Is there any way for old chipset which has no correct ELD reporting but do have audio functionality? App should check before really play audio on the device. 2) In PulseAudio's current design, PulseAudio probes the device at startup and caches the result. Unfortunately, there is no reprobing at plug/unplug, so if the monitor is hotplugged, it will not work unless PulseAudio is restarted afterwards. For haswell ult board only, DDI port D is not supported, this results in screen flicker when playing on third pin. But for other haswell boards, the DDI port D is normal. So at first glance my idea is to disable opening device without physical device connecting. Thanks --xingchao The bug is from Haswell platform, All pins choose converter 0 by default in hardware level, maybe only pin 1 had valid monitor connected. if user play audio on pin 0/2, pin 1 can get audio data too. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com --- sound/pci/hda/patch_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 8db5eb6..d766f40 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1139,6 +1139,9 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo, per_pin = get_pin(spec, pin_idx); eld = per_pin-sink_eld; + if (!eld-monitor_present || !eld-eld_valid) + return -EIO; + if (codec-vendor_id == 0x80862807) hsw_verify_cvt_D0(spec, codec); -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] ALSA: hda - Haswell converter power state D0 verify
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Monday, June 17, 2013 5:01 PM
To: Wang Xingchao
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; david.hennings...@canonical.com; Wang,
Xingchao
Subject: Re: [PATCH 1/4] ALSA: hda - Haswell converter power state D0 verify
At Fri, 14 Jun 2013 23:20:26 +0800,
Wang Xingchao wrote:
Haswell converters maybe in wrong power state before usage.
i.e. only converter 0 is in D0, converter 1/2 are in D3.
When pin choose converter 1/2, there's no audio output.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
Isn't this needed in hdmi_setup_stream() instead of open, like
haswell_verify_pin_D0() does? Note that the open callback won't be called at
PM resume. Also, if it's just a matter of the connected converter from the
specific pin, you can check the power state of the specific converter,
instead of
checking the all converters at each time.
If my guess above is correct, the better code would be to merge the power
check of converter into haswell_verify_pin_D0().
Good point, will merge it into haswell_verify_pin_D0(), should the API name
change accordingly?
Thanks
--xingchao
thanks,
Takashi
---
sound/pci/hda/patch_hdmi.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index e12f7a0..8db5eb6 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1053,6 +1053,23 @@ static void haswell_verify_pin_D0(struct
hda_codec *codec, hda_nid_t nid)
}
}
+static void hsw_verify_cvt_D0(struct hdmi_spec *spec,
+struct hda_codec *codec)
+{
+ struct hdmi_spec_per_cvt *per_cvt;
+ int pwr, cvt_idx;
+
+ for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) {
+ per_cvt = get_cvt(spec, cvt_idx);
+ pwr = snd_hda_codec_read(codec, per_cvt-cvt_nid, 0,
+ AC_VERB_GET_POWER_STATE, 0);
+ pwr = (pwr AC_PWRST_ACTUAL) AC_PWRST_ACTUAL_SHIFT;
+ if (pwr != AC_PWRST_D0)
+ snd_hda_codec_write(codec, per_cvt-cvt_nid, 0,
AC_VERB_SET_POWER_STATE,
+ AC_PWRST_D0);
+ }
+}
+
/*
* Callbacks
*/
@@ -1122,6 +1139,9 @@ static int hdmi_pcm_open(struct
hda_pcm_stream *hinfo,
per_pin = get_pin(spec, pin_idx);
eld = per_pin-sink_eld;
+ if (codec-vendor_id == 0x80862807)
+ hsw_verify_cvt_D0(spec, codec);
+
/* Dynamically assign converter to stream */
for (cvt_idx = 0; cvt_idx spec-num_cvts; cvt_idx++) {
per_cvt = get_cvt(spec, cvt_idx);
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add display audio routing APIs for ALSA
Hi Daniel, -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Sent: Saturday, June 15, 2013 3:18 AM To: Wang Xingchao Cc: Takashi Iwai; alsa-de...@alsa-project.org; intel-gfx; David Henningsson; Wang, Xingchao Subject: Re: [PATCH 3/4] drm/i915: Add display audio routing APIs for ALSA On Fri, Jun 14, 2013 at 5:20 PM, Wang Xingchao xingchao.w...@linux.intel.com wrote: ALSA audio driver need know current audio routing infomation. i.e. Route map between codec pins(DDI ports) and Transcoders(Pipe). Also the new API let audio driver disable unused audio pin's output. This fixed the bug when three pins *ALL* have monitors connected, playing audio on one pin would cause audio output to all minitors. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com So I've started to have a real look at audio on haswell and audio on i915 in general, and I'm seriously confused. Random observations, but I fear this isn't the real story by far yet: - On haswell we now have a hooping 3 places that set up these audio routing register: haswell_write_eld (called from the connector enable callbacks), intel_enable/disable_ddi and now the new hooks you're adding here. That's 2 places too many. If we really need all three places those need to be refactored so that the bit-frobbing logic is all in one place. But I seriously doubt that we need them all. Yeah I agree to put audio stuff in One place. Let me give you some background about the issue this Patch fixed. Basically audio side need such API in gfx side to enable/disable audio, that's three PIPE based audio enable bits. The issue comes when two monitors connected on DDI port B and port C, like: DDI B(pin 0) -- DP monitor DDI C(pin 1) -- HDMI minitor In haswell the pins default choose converter 0(hardware level) as data source, so it's like: Converter 0 -- pin 0 + pin 1 + pin2 And when play audio on pin 0, pin 1 could get audio data too. Meanwhile pin 1 has HDMi minitor connected, you can hear audio. To fix this issue, I tried several solutions: 1) Disable pin 1/2 when play audio on pin 0, or disable pin 0/2 when play audio on pin 1 2) mute pin 1/2 when play audio on pin 0, or mute pin 0/2 when play audio on pin 1 3) configure pin 1/2 to choose other converters when play audio on pin 0. 4) disable audio output enable in gfx side, this is implemented in current patchset. I prefer 1) or 2) it's very simple, but it doesnot work on Haswell. It's the issue I'm trying to fix: Pin 0 must be output-eanbe/unmute when playing audio on pin 1. Seems pin 1 has dependency on pin 0, and I have to disable audio output in gfx side. I don't think it's bad if we implement such API in gfx side, the question is you point out, to make it clean and simple. If Dp1.2 is needed in future, audio side need the pipe-DDI port connections map too. We can reuse power-well module to export such information. To implement solution 4) above, audio side handle request to disable audio output in gfx side: - if only pin 0 is busy playing audio and using valid pipe, disable audio output for pin 1/2. It's the same logic when only pin1 or pin 2 is busy playing audio. - if both pin0 and pin 1 are busy playing audio, only disable pin 2. - if all pins are playing audio, do nothing. In above case when both Pin 0 and pin 1 are connected with Dp and HDMI monitor, if only playing audio on pin 0, disable pin 1's audio output in gfx side Would cause eld info refresh in audio driver side, but that doesnot matter as when you need playing audio on pin 1, the audio output enable bit would be set again. The patch could fix the issue when playing audio on one pin, audio would route to another pin too. In such case, we can drop the second patch in fact. - I've quickly read through the haswell audio modeset sequence. On a glance I could see no reason why we need to have 3 different places to set up the gfx side of the audio support, since it's much simpler apparently: Enable sequence: 1. gfx side sets up registers 2. gfx side sets the audio enable bit, which generates the interrup 3. audio side completes the setup on its side. Disable sequence is just the inverse. So I don't think we need 3 different places for this. - Both on ibx/cpt and also on haswell here we seem to rely on BIOS preset values way too often. Or at least I didn't figure out where these registes get initialized (pretty sure nowhere in i915.ko). We have countless bugs where the BIOS tried to be fancy and set up something we don't actually support. So please, if there's no really good reason why we need to do things differently, have explicit register setups. If there's something we need to preserve from the BIOS, it needs to be done explicitly and must have a comment. - No global state or stuffing random things into dev_priv/crtc any more. Our modeset infrastructure has a transactional state machine now: First we compute
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Add display audio routing API for haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Monday, June 17, 2013 5:04 PM
To: Wang Xingchao
Cc: daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; david.hennings...@canonical.com; Wang,
Xingchao
Subject: Re: [PATCH 4/4] ALSA: hda - Add display audio routing API for haswell
At Fri, 14 Jun 2013 23:20:29 +0800,
Wang Xingchao wrote:
ALSA side use these apis to know display audio routing map in gfx
side. And use the API to disable unused pin's audio output.
Adding more and more such exported functions doesn't look scaling.
Better to define an ops struct and export it.
Thanks Takashi, under discussion with Daniel in another thread, need
improvement to make the API clean.
I will rework the patch when get some agreement.
Thanks
--xingchao
Takashi
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c | 83
++
sound/pci/hda/hda_i915.h | 4 +++
sound/pci/hda/patch_hdmi.c | 20 +--
3 files changed, 104 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c index
76c13d5..7ac446f 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -22,9 +22,73 @@
#include drm/i915_powerwell.h
#include hda_i915.h
+/* Haswell power well */
static void (*get_power)(void);
static void (*put_power)(void);
+/* Haswell audio routing */
+static int (*get_using_pipe)(int);
+static int (*disable_unused_pipe)(int, int *); static int
+(*restore_eld)(void);
+
+#define i915_pipe_name(p) ((p) + 'A')
+
+static int busy_pins[3] = {0, 0, 0};
+
+int hdmi_disable_unused_pipe(int pin_idx, int pipe_idx) {
+ busy_pins[pin_idx] = 1;
+ if (disable_unused_pipe)
+ disable_unused_pipe(pipe_idx, busy_pins);
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_disable_unused_pipe);
+
+void hdmi_restore_pineld(int pin_idx) {
+ busy_pins[pin_idx] = 0;
+ if (restore_eld)
+ restore_eld();
+}
+EXPORT_SYMBOL(hdmi_restore_pineld);
+
+int hdmi_get_using_pipe(int pin_idx)
+{
+ int pipe = -1;
+
+ if (get_using_pipe)
+ pipe = get_using_pipe(pin_idx);
+
+ if (pipe != -1)
+ snd_printd(HDMI: pin %d get using pipe %c\n, pin_idx,
+i915_pipe_name(pipe));
+
+ return pipe;
+}
+EXPORT_SYMBOL(hdmi_get_using_pipe);
+
+static int init_audio_routing(void)
+{
+ get_using_pipe = symbol_request(i915_using_pipe);
+ if (!get_using_pipe)
+ return -ENODEV;
+
+ disable_unused_pipe = symbol_request(i915_disable_pipe);
+ if (!disable_unused_pipe) {
+ get_using_pipe = NULL;
+ return -ENODEV;
+ }
+
+ restore_eld = symbol_request(i915_restore_pineld);
+ if (!restore_eld) {
+ restore_eld = NULL;
+ get_using_pipe = NULL;
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
void hda_display_power(bool enable)
{
if (!get_power || !put_power)
@@ -57,6 +121,10 @@ int hda_i915_init(void)
snd_printd(HDA driver get symbol successfully from i915 module\n);
+ err = init_audio_routing();
+ if (err 0)
+ snd_printd(HDA driver get audior routing APIs failed!\n);
+
return err;
}
@@ -71,5 +139,20 @@ int hda_i915_exit(void)
put_power = NULL;
}
+ if (get_using_pipe) {
+ symbol_put(get_using_pipe);
+ get_using_pipe = NULL;
+ }
+
+ if (disable_unused_pipe) {
+ symbol_put(disable_unused_pipe);
+ disable_unused_pipe = NULL;
+ }
+
+ if (restore_eld) {
+ symbol_put(restore_eld);
+ restore_eld = NULL;
+ }
+
return 0;
}
diff --git a/sound/pci/hda/hda_i915.h b/sound/pci/hda/hda_i915.h index
5a63da2..52d6f09 100644
--- a/sound/pci/hda/hda_i915.h
+++ b/sound/pci/hda/hda_i915.h
@@ -32,4 +32,8 @@ static inline int hda_i915_exit(void) } #endif
+extern int hdmi_get_using_pipe(int pin_idx); extern int
+hdmi_disable_unused_pipe(int pin_idx, int pipe_idx); extern void
+hdmi_restore_pineld(int pin_idx);
+
#endif
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index d766f40..2a1e977 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -39,6 +39,7 @@
#include hda_codec.h
#include hda_local.h
#include hda_jack.h
+#include hda_i915.h
static bool static_hdmi_pcm;
module_param(static_hdmi_pcm, bool, 0644); @@ -1131,6 +1132,7 @@
static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
struct hdmi_spec_per_pin *per_pin;
struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int pipe_idx;
/* Validate hinfo */
pin_idx = hinfo_to_pin_index(spec, hinfo); @@ -1139,12 +1141,21 @@
static int
Re: [Intel-gfx] [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device
Hi Daniel, Do you know the issue I mentioned below? Is it a known issue in gfx side? On Haswell ULT, when playing audio on the third pin, DP monitor would cause flicker while HDMI monitor is fine. Thanks --xingchao -Original Message- From: David Henningsson [mailto:david.hennings...@canonical.com] Sent: Monday, June 17, 2013 8:15 PM To: Wang, Xingchao Cc: Wang Xingchao; ti...@suse.de; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org Subject: Re: [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device On 06/17/2013 01:54 PM, Wang, Xingchao wrote: -Original Message- From: David Henningsson [mailto:david.hennings...@canonical.com] Sent: Monday, June 17, 2013 4:24 PM To: Wang Xingchao Cc: ti...@suse.de; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Wang, Xingchao Subject: Re: [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device On 06/14/2013 05:20 PM, Wang Xingchao wrote: when user open HDMI device 3/7/8, if it has no physical device connected, return error. This patch will cause regressions in two big use cases: 1) Older chipsets (at least from non-Intel vendors) might not support correct ELD reporting. Thus this will cause HDMI audio to stop working there. Thanks for pointing this out. It's a good case I missed. :) I thought ELD info was monitor specific, and reported on common platforms. We have a generation of Nvidia cards that does not support presence detect (and no ELD) for the audio codec at all. I'm not sure if we also have cards where presence detect works, but there never comes any ELD. Or if this can potentially vary depending on the connected monitor. But I think this should also be handled in the best way. But sometimes user get confused when opening a hdmi device and started to play audio,but hear nothing, even there's no error message. Is there any way for old chipset which has no correct ELD reporting but do have audio functionality? App should check before really play audio on the device. PulseAudio (with support from some of the GUIs) support looking at the Presence Detect, and hiding the device if nothing is currently connected. I agree in principle with that you should be given some warning if you try to play back to unconnected things, but for me it's not a high priority to improve. E g, the situation is the same for analog audio - imagine a small desktop with only a headphone output: you can still play audio to the headphone output even when there's no headphone connected in the jack. 2) In PulseAudio's current design, PulseAudio probes the device at startup and caches the result. Unfortunately, there is no reprobing at plug/unplug, so if the monitor is hotplugged, it will not work unless PulseAudio is restarted afterwards. For haswell ult board only, DDI port D is not supported, this results in screen flicker when playing on third pin. But for other haswell boards, the DDI port D is normal. So at first glance my idea is to disable opening device without physical device connecting. Maybe it's possible to fix on the gfx side? It sounds like a graphic driver bug if the screen flickers due to anything happening on the audio side. Thanks --xingchao The bug is from Haswell platform, All pins choose converter 0 by default in hardware level, maybe only pin 1 had valid monitor connected. if user play audio on pin 0/2, pin 1 can get audio data too. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com --- sound/pci/hda/patch_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 8db5eb6..d766f40 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1139,6 +1139,9 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo, per_pin = get_pin(spec, pin_idx); eld = per_pin-sink_eld; + if (!eld-monitor_present || !eld-eld_valid) + return -EIO; + if (codec-vendor_id == 0x80862807) hsw_verify_cvt_D0(spec, codec); -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Haswell Display audio routing bug fix
This patchset used to fix some display audio issues on Haswell platform. I tested this patch on Haswell ult board, C0 stepping, with eDP pannel, HDMI monitor, DP monitor. The fixed issues: 1) when only HDMI or DP monitor connected, hear sound on ALL three HDMI devices. 2) when HDMI + DP monitors connected, hear sound on HDMI and DP at the same time no matter you're playing audio on DP or HDMI device. 3) When DP + HDMI + eDP connected, no sound could be heard. 4) After bootup, play audio on HDMI device 7(use second pin), no sound. If play audio on device 3 at first(use first pin), it has sound again. There's quite different hardware changes for haswell display audio, compared with previous Ivybridge/Sandybridge. The common hd-a driver and hdmi driver need make improvement to support. Haswell chip supports Dp1.2 feature(see ref 1). This is very cool feture windows had supported. We get confirm linux gfx team has plan to support Dp1.2 in future too. We're ready to support dp1.2 feature in audio side, as the converter selection dependency is fixed in this patchset. Also we need some improvement in HDA driver side because Haswell added new Verb to support DP1.2. here’s a video show about DP1.2 feature http://www.club-3d.com/index.php/products/reader.en/product/mst-hub-1-3.html Please apply the patches based on Daniel's drm-intel-next-queued branch: http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-next-queued last commit 80e83831a64b9a5d49e844691037b2d4be0f14f9 Please feel free to let me know the issues you meet during test. Wang Xingchao (4): ALSA: hda - Haswell converter power state D0 verify ALSA: hda - Return error when open empty hdmi device drm/i915: Add display audio routing APIs for ALSA ALSA: hda - Add display audio routing API for haswell drivers/gpu/drm/i915/i915_drv.h | 18 + drivers/gpu/drm/i915/intel_ddi.c | 131 +-- drivers/gpu/drm/i915/intel_display.c | 7 +- drivers/gpu/drm/i915/intel_drv.h | 1 + include/drm/i915_powerwell.h | 5 ++ sound/pci/hda/hda_i915.c | 83 ++ sound/pci/hda/hda_i915.h | 4 ++ sound/pci/hda/patch_hdmi.c | 37 ++ 8 files changed, 281 insertions(+), 5 deletions(-) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] ALSA: hda - Return error when open empty hdmi device
when user open HDMI device 3/7/8, if it has no physical device connected, return error. The bug is from Haswell platform, All pins choose converter 0 by default in hardware level, maybe only pin 1 had valid monitor connected. if user play audio on pin 0/2, pin 1 can get audio data too. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com --- sound/pci/hda/patch_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 8db5eb6..d766f40 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1139,6 +1139,9 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo, per_pin = get_pin(spec, pin_idx); eld = per_pin-sink_eld; + if (!eld-monitor_present || !eld-eld_valid) + return -EIO; + if (codec-vendor_id == 0x80862807) hsw_verify_cvt_D0(spec, codec); -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Add display audio routing APIs for ALSA
ALSA audio driver need know current audio routing infomation.
i.e. Route map between codec pins(DDI ports) and Transcoders(Pipe).
Also the new API let audio driver disable unused audio pin's output.
This fixed the bug when three pins *ALL* have monitors connected, playing
audio on one pin would cause audio output to all minitors.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 18 +
drivers/gpu/drm/i915/intel_ddi.c | 131 +--
drivers/gpu/drm/i915/intel_display.c | 7 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
include/drm/i915_powerwell.h | 5 ++
5 files changed, 157 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10a56c9..8248048 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -87,6 +87,7 @@ enum port {
I915_MAX_PORTS
};
#define port_name(p) ((p) + 'A')
+#define pin2port(p) ((p) + PORT_B)
enum intel_display_power_domain {
POWER_DOMAIN_PIPE_A,
@@ -785,6 +786,20 @@ struct i915_power_well {
int i915_request;
};
+#define DEFAULT_PIPE -1
+/* Dp1.2 mode, one DDI port can choose multiple pipes */
+struct dp12_port {
+ int pipes[I915_MAX_PIPES];
+ int count;
+};
+
+/* audio routing info for haswell */
+struct i915_audio {
+ /* route map between pipe and DDI port */
+ struct dp12_port active_pipes[I915_MAX_PORTS];
+ int pin_eld;
+};
+
struct i915_dri1_state {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
@@ -1147,6 +1162,9 @@ typedef struct drm_i915_private {
/* Haswell power well */
struct i915_power_well power_well;
+ /* Haswell audio routing */
+ struct i915_audio audio_route;
+
enum no_fbc_reason no_fbc_reason;
struct drm_mm_node *compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 224ce25..82823b8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -286,8 +286,11 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct drm_crtc *crtc = encoder-crtc;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
+ struct i915_audio *hsw_audio = dev_priv-audio_route;
+ struct dp12_port *hsw_port;
int port = intel_ddi_get_encoder_port(intel_encoder);
int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
@@ -296,6 +299,12 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
port_name(port), pipe_name(pipe));
intel_crtc-eld_vld = false;
+
+ /* store pipe routing info */
+ hsw_port = hsw_audio-active_pipes[port];
+ hsw_port-pipes[0] = pipe;
+ hsw_port-count = 1;
+
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_digital_port *intel_dig_port =
@@ -306,8 +315,8 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
intel_dp-DP |= DDI_PORT_WIDTH(intel_dp-lane_count);
if (intel_dp-has_audio) {
- DRM_DEBUG_DRIVER(DP audio on pipe %c on DDI\n,
-pipe_name(intel_crtc-pipe));
+ DRM_DEBUG_DRIVER(DP audio on pipe %c on DDI %c\n,
+pipe_name(intel_crtc-pipe),
port_name(port));
/* write eld */
DRM_DEBUG_DRIVER(DP audio: write eld information\n);
@@ -324,8 +333,8 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
* and a new set of registers, so we leave it for future
* patch bombing.
*/
- DRM_DEBUG_DRIVER(HDMI audio on pipe %c on DDI\n,
-pipe_name(intel_crtc-pipe));
+ DRM_DEBUG_DRIVER(HDMI audio on pipe %c on DDI %c \n,
+pipe_name(intel_crtc-pipe),
port_name(port));
/* write eld */
DRM_DEBUG_DRIVER(HDMI audio: write eld information\n);
@@ -1135,6 +1144,9 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
int type = intel_encoder-type;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct i915_audio *hsw_audio = dev_priv-audio_route;
+ struct dp12_port *hsw_port;
+ enum port port = intel_ddi_get_encoder_port(intel_encoder);
uint32_t tmp
[Intel-gfx] [PATCH 4/4] ALSA: hda - Add display audio routing API for haswell
ALSA side use these apis to know display audio routing map
in gfx side. And use the API to disable unused pin's audio output.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c | 83 ++
sound/pci/hda/hda_i915.h | 4 +++
sound/pci/hda/patch_hdmi.c | 20 +--
3 files changed, 104 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index 76c13d5..7ac446f 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -22,9 +22,73 @@
#include drm/i915_powerwell.h
#include hda_i915.h
+/* Haswell power well */
static void (*get_power)(void);
static void (*put_power)(void);
+/* Haswell audio routing */
+static int (*get_using_pipe)(int);
+static int (*disable_unused_pipe)(int, int *);
+static int (*restore_eld)(void);
+
+#define i915_pipe_name(p) ((p) + 'A')
+
+static int busy_pins[3] = {0, 0, 0};
+
+int hdmi_disable_unused_pipe(int pin_idx, int pipe_idx)
+{
+ busy_pins[pin_idx] = 1;
+ if (disable_unused_pipe)
+ disable_unused_pipe(pipe_idx, busy_pins);
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_disable_unused_pipe);
+
+void hdmi_restore_pineld(int pin_idx)
+{
+ busy_pins[pin_idx] = 0;
+ if (restore_eld)
+ restore_eld();
+}
+EXPORT_SYMBOL(hdmi_restore_pineld);
+
+int hdmi_get_using_pipe(int pin_idx)
+{
+ int pipe = -1;
+
+ if (get_using_pipe)
+ pipe = get_using_pipe(pin_idx);
+
+ if (pipe != -1)
+ snd_printd(HDMI: pin %d get using pipe %c\n, pin_idx,
i915_pipe_name(pipe));
+
+ return pipe;
+}
+EXPORT_SYMBOL(hdmi_get_using_pipe);
+
+static int init_audio_routing(void)
+{
+ get_using_pipe = symbol_request(i915_using_pipe);
+ if (!get_using_pipe)
+ return -ENODEV;
+
+ disable_unused_pipe = symbol_request(i915_disable_pipe);
+ if (!disable_unused_pipe) {
+ get_using_pipe = NULL;
+ return -ENODEV;
+ }
+
+ restore_eld = symbol_request(i915_restore_pineld);
+ if (!restore_eld) {
+ restore_eld = NULL;
+ get_using_pipe = NULL;
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
void hda_display_power(bool enable)
{
if (!get_power || !put_power)
@@ -57,6 +121,10 @@ int hda_i915_init(void)
snd_printd(HDA driver get symbol successfully from i915 module\n);
+ err = init_audio_routing();
+ if (err 0)
+ snd_printd(HDA driver get audior routing APIs failed!\n);
+
return err;
}
@@ -71,5 +139,20 @@ int hda_i915_exit(void)
put_power = NULL;
}
+ if (get_using_pipe) {
+ symbol_put(get_using_pipe);
+ get_using_pipe = NULL;
+ }
+
+ if (disable_unused_pipe) {
+ symbol_put(disable_unused_pipe);
+ disable_unused_pipe = NULL;
+ }
+
+ if (restore_eld) {
+ symbol_put(restore_eld);
+ restore_eld = NULL;
+ }
+
return 0;
}
diff --git a/sound/pci/hda/hda_i915.h b/sound/pci/hda/hda_i915.h
index 5a63da2..52d6f09 100644
--- a/sound/pci/hda/hda_i915.h
+++ b/sound/pci/hda/hda_i915.h
@@ -32,4 +32,8 @@ static inline int hda_i915_exit(void)
}
#endif
+extern int hdmi_get_using_pipe(int pin_idx);
+extern int hdmi_disable_unused_pipe(int pin_idx, int pipe_idx);
+extern void hdmi_restore_pineld(int pin_idx);
+
#endif
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index d766f40..2a1e977 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -39,6 +39,7 @@
#include hda_codec.h
#include hda_local.h
#include hda_jack.h
+#include hda_i915.h
static bool static_hdmi_pcm;
module_param(static_hdmi_pcm, bool, 0644);
@@ -1131,6 +1132,7 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
struct hdmi_spec_per_pin *per_pin;
struct hdmi_eld *eld;
struct hdmi_spec_per_cvt *per_cvt = NULL;
+ int pipe_idx;
/* Validate hinfo */
pin_idx = hinfo_to_pin_index(spec, hinfo);
@@ -1139,12 +1141,21 @@ static int hdmi_pcm_open(struct hda_pcm_stream *hinfo,
per_pin = get_pin(spec, pin_idx);
eld = per_pin-sink_eld;
+ if (codec-vendor_id == 0x80862807) {
+ hsw_verify_cvt_D0(spec, codec);
+
+ pipe_idx = hdmi_get_using_pipe(pin_idx);
+ if (pipe_idx 0)
+ snd_printdd(HDMI: Pin %d has no valid pipe in use\n,
pin_idx);
+ else {
+ hdmi_disable_unused_pipe(pin_idx, pipe_idx);
+ msleep(10);
+ }
+ }
+
if (!eld-monitor_present || !eld-eld_valid)
return -EIO;
- if (codec-vendor_id == 0x80862807)
- hsw_verify_cvt_D0(spec, codec);
-
/* Dynamically assign converter
Re: [Intel-gfx] [PATCH 4/4 V6] i915/drm: Add private api for power well usage
Hi Damien,
Thanks your review, comments inline. :)
-Original Message-
From: intel-gfx-bounces+xingchao.wang=intel@lists.freedesktop.org
[mailto:intel-gfx-bounces+xingchao.wang=intel@lists.freedesktop.org] On
Behalf Of Damien Lespiau
Sent: Thursday, May 30, 2013 2:11 AM
To: Wang Xingchao
Cc: alsa-de...@alsa-project.org; Girdwood, Liam R; ti...@suse.de;
intel-gfx@lists.freedesktop.org; Li, Jocelyn; david.hennings...@canonical.com
Subject: Re: [Intel-gfx] [PATCH 4/4 V6] i915/drm: Add private api for power
well
usage
On Mon, May 27, 2013 at 05:15:16PM +0800, Wang Xingchao wrote:
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
Daniel, you probably want to give your opinion on the 2 APIs to manage the
power well discussion below.
In case, the logic seems correct so: with or without the two nitpicks below
(that we can address later if deemed necessary):
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
drivers/gpu/drm/i915/i915_dma.c |6 +++
drivers/gpu/drm/i915/i915_drv.h | 12 +
drivers/gpu/drm/i915/intel_drv.h |4 ++
drivers/gpu/drm/i915/intel_pm.c | 92
+++---
include/drm/i915_powerwell.h | 36 +++
5 files changed, 143 insertions(+), 7 deletions(-) create mode
100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index f5addac..b702915 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1652,6 +1652,9 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
/* Start out suspended */
dev_priv-mm.suspended = 1;
+ if (IS_HASWELL(dev))
+ i915_init_power_well(dev);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = i915_load_modeset_init(dev);
if (ret 0) {
@@ -1708,6 +1711,9 @@ int i915_driver_unload(struct drm_device *dev)
intel_gpu_ips_teardown();
+ if (IS_HASWELL(dev))
+ i915_remove_power_well(dev);
+
i915_teardown_sysfs(dev);
if (dev_priv-mm.inactive_shrinker.shrink)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 14817de..ea94e5e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -720,6 +720,15 @@ struct intel_ilk_power_mgmt {
struct drm_i915_gem_object *renderctx; };
+/* Power well structure for haswell */ struct i915_power_well {
+ struct drm_device *device;
+ spinlock_t lock;
+ /* power well enable/disable usage count */
+ int count;
+ int i915_request;
+};
+
struct i915_dri1_state {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
@@ -1073,6 +1082,9 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /* Haswell power well */
+ struct i915_power_well *hsw_pwr;
+
We usually just put the structure inside struct drm_i915_private and pass it's
pointer around instead of an allocation for a few bytes.
We also try quite hard to not be platform specific but feature specific in our
code (eg. HAS_POWER_WELL() and not IS_HASWELL()). hsw_pwr should
probably be renamed to power_well.
Good point. I will make changes accordingly in next version.
enum no_fbc_reason no_fbc_reason;
struct drm_mm_node *compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 0f35545..8b5017d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -754,6 +754,10 @@ extern void intel_update_fbc(struct drm_device
*dev); extern void intel_gpu_ips_init(struct drm_i915_private
*dev_priv); extern void intel_gpu_ips_teardown(void);
+/* Power well */
+extern int i915_init_power_well(struct drm_device *dev); extern void
+i915_remove_power_well(struct drm_device *dev);
+
extern bool intel_display_power_enabled(struct drm_device *dev,
enum intel_display_power_domain
domain); extern
void
intel_init_power_well(struct drm_device *dev); diff --git
a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1a76572..f429347 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4502,18 +4502,12 @@ bool intel_display_power_enabled(struct
drm_device *dev,
}
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void __intel_set_power_well(struct drm_device *dev, bool
+enable
[Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi all, This is V7 and here're some changes notes: change from V6--V7: - rename variable - use HAS_POWER_WELL instead of IS_HASWELL - put structure inside drm_i915_private - use WARN_ON for global pointer check change from V5--V6: - Remove duplication code in new introduced probe work - move duplication code in azx_probe_continue - remove unused #ifdef - replace request_module with symbol_request - replace spin_lock_irq with spin_lock_irqsave in gfx side - other typo fixes (review by Takashi) change from V4--V5: - fix reference count bug - new patch on general runtime pm support for audio pci device - new patch to avoid request_module() deadlock change between V3--V4: - add new structure i915_power_well - initialize drm_device pointer at module init time - change function name change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Takashi Iwai (1): ALSA: hda - Move azx_first_init() into azx_probe_continue() Wang Xingchao (3): ALSA: hda - Fix runtime PM check ALSA: hda - Add power-welll support for haswell HDA i915/drm: Add private api for power well usage drivers/gpu/drm/i915/i915_dma.c |6 +++ drivers/gpu/drm/i915/i915_drv.h | 12 ++ drivers/gpu/drm/i915/intel_drv.h |4 ++ drivers/gpu/drm/i915/intel_pm.c | 81 --- include/drm/i915_powerwell.h | 36 sound/pci/hda/Kconfig| 10 + sound/pci/hda/Makefile |2 + sound/pci/hda/hda_i915.c | 75 sound/pci/hda/hda_i915.h | 35 +++ sound/pci/hda/hda_intel.c| 87 ++ 10 files changed, 324 insertions(+), 24 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4 V7] ALSA: hda - Fix runtime PM check
The device can support runtime PM no matter whether it support
signal wakeup or not. For some chips like Haswell which doesnot
support PME by default, this patch let haswell Display HD-A controller
enter runtime suspend, and bring more power saving whith power-well
feature enabled.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
Reviewed-by: Takashi Iwai ti...@suse.de
Reviewed-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
sound/pci/hda/hda_intel.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 418bfc0..cf3d36c 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -3091,8 +3091,13 @@ static int register_vga_switcheroo(struct azx *chip)
*/
static int azx_free(struct azx *chip)
{
+ struct pci_dev *pci = chip-pci;
int i;
+ if ((chip-driver_caps AZX_DCAPS_PM_RUNTIME)
+chip-running)
+ pm_runtime_get_noresume(pci-dev);
+
azx_del_card_list(chip);
azx_notifier_unregister(chip);
@@ -3726,9 +3731,6 @@ static int azx_probe(struct pci_dev *pci,
goto out_free;
}
- if (pci_dev_run_wake(pci))
- pm_runtime_put_noidle(pci-dev);
-
dev++;
complete_all(chip-probe_wait);
return 0;
@@ -3741,6 +3743,7 @@ out_free:
static int azx_probe_continue(struct azx *chip)
{
+ struct pci_dev *pci = chip-pci;
int dev = chip-dev_index;
int err;
@@ -3788,6 +3791,8 @@ static int azx_probe_continue(struct azx *chip)
power_down_all_codecs(chip);
azx_notifier_register(chip);
azx_add_card_list(chip);
+ if (chip-driver_caps AZX_DCAPS_PM_RUNTIME)
+ pm_runtime_put_noidle(pci-dev);
return 0;
@@ -3800,9 +3805,6 @@ static void azx_remove(struct pci_dev *pci)
{
struct snd_card *card = pci_get_drvdata(pci);
- if (pci_dev_run_wake(pci))
- pm_runtime_get_noresume(pci-dev);
-
if (card)
snd_card_free(card);
pci_set_drvdata(pci, NULL);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] ALSA: hda - Move azx_first_init() into azx_probe_continue()
From: Takashi Iwai ti...@suse.de
This is a preliminary work for the upcoming Haswell HDMI audio fixes.
azx_first_init() function can be safely called after the f/w loader,
since the f/w loader doesn't require the sound hardware initialization
beforehand. Moving it into azx_probe_continue() cleans up the code
flow a bit.
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_intel.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index cf3d36c..49cc942 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2977,7 +2977,6 @@ static void azx_notifier_unregister(struct azx *chip)
unregister_reboot_notifier(chip-reboot_notifier);
}
-static int azx_first_init(struct azx *chip);
static int azx_probe_continue(struct azx *chip);
#ifdef SUPPORT_VGA_SWITCHEROO
@@ -3004,8 +3003,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
snd_printk(KERN_INFO SFX
%s: Start delayed initialization\n,
pci_name(chip-pci));
- if (azx_first_init(chip) 0 ||
- azx_probe_continue(chip) 0) {
+ if (azx_probe_continue(chip) 0) {
snd_printk(KERN_ERR SFX
%s: initialization error\n,
pci_name(chip-pci));
@@ -3706,11 +3704,6 @@ static int azx_probe(struct pci_dev *pci,
}
probe_now = !chip-disabled;
- if (probe_now) {
- err = azx_first_init(chip);
- if (err 0)
- goto out_free;
- }
#ifdef CONFIG_SND_HDA_PATCH_LOADER
if (patch[dev] *patch[dev]) {
@@ -3747,6 +3740,10 @@ static int azx_probe_continue(struct azx *chip)
int dev = chip-dev_index;
int err;
+ err = azx_first_init(chip);
+ if (err 0)
+ goto out_free;
+
#ifdef CONFIG_SND_HDA_INPUT_BEEP
chip-beep_mode = beep_mode[dev];
#endif
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4 V7] ALSA: hda - Add power-welll support for haswell HDA
For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) - azx_probe - module_request
(or symbol_request) - modprobe (userspace) - i915 init -
drm_pci_init - pci_register_driver - bus_add_driver - driver_attach -
which in turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.
This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
Reviewed-by: Takashi Iwai ti...@suse.de
Reviewed-by: Liam Girdwood liam.r.girdw...@intel.com
Reviewed-by: David Henningsson david.hennings...@canonical.com
---
sound/pci/hda/Kconfig | 10 ++
sound/pci/hda/Makefile|2 ++
sound/pci/hda/hda_i915.c | 75 +
sound/pci/hda/hda_i915.h | 35 +
sound/pci/hda/hda_intel.c | 60 ++--
5 files changed, 179 insertions(+), 3 deletions(-)
create mode 100644 sound/pci/hda/hda_i915.c
create mode 100644 sound/pci/hda/hda_i915.h
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index 80a7d44..c5a872c 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -152,6 +152,16 @@ config SND_HDA_CODEC_HDMI
snd-hda-codec-hdmi.
This module is automatically loaded at probing.
+config SND_HDA_I915
+ bool Build Display HD-audio controller/codec power well support for
i915 cards
+ depends on DRM_I915
+ help
+ Say Y here to include full HDMI and DisplayPort HD-audio
controller/codec
+ power-well support for Intel Haswell graphics cards based on the i915
driver.
+
+ Note that this option must be enabled for Intel Haswell C+ stepping
machines, otherwise
+ the GPU audio controller/codecs will not be initialized or damaged
when exit from S3 mode.
+
config SND_HDA_CODEC_CIRRUS
bool Build Cirrus Logic codec support
default y
diff --git a/sound/pci/hda/Makefile b/sound/pci/hda/Makefile
index 24a2514..c091438 100644
--- a/sound/pci/hda/Makefile
+++ b/sound/pci/hda/Makefile
@@ -1,4 +1,6 @@
snd-hda-intel-objs := hda_intel.o
+# for haswell power well
+snd-hda-intel-$(CONFIG_SND_HDA_I915) +=hda_i915.o
snd-hda-codec-y := hda_codec.o hda_jack.o hda_auto_parser.o
snd-hda-codec-$(CONFIG_SND_HDA_GENERIC) += hda_generic.o
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
new file mode 100644
index 000..76c13d5
--- /dev/null
+++ b/sound/pci/hda/hda_i915.c
@@ -0,0 +1,75 @@
+/*
+ * hda_i915.c - routines for Haswell HDA controller power well support
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include sound/core.h
+#include drm/i915_powerwell.h
+#include hda_i915.h
+
+static void (*get_power)(void);
+static void (*put_power)(void);
+
+void hda_display_power(bool enable)
+{
+ if (!get_power || !put_power)
+ return;
+
+ snd_printdd(HDA display power %s \n,
+ enable ? Enable : Disable);
+ if (enable)
+ get_power();
+ else
+ put_power();
+}
+
+int hda_i915_init(void)
+{
+ int err = 0;
+
+ get_power = symbol_request(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
+ return -ENODEV;
+ }
+
+ put_power = symbol_request(i915_release_power_well);
+ if (!put_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ return -ENODEV;
+ }
+
+ snd_printd(HDA driver get symbol successfully from i915 module\n);
+
+ return err;
+}
+
+int hda_i915_exit(void)
+{
+ if (get_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ }
+ if (put_power) {
+ symbol_put(i915_release_power_well);
+ put_power = NULL
[Intel-gfx] [PATCH 4/4 V7] i915/drm: Add private api for power well usage
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
Reviewed-by: Takashi Iwai ti...@suse.de
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |6 +++
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/intel_drv.h |4 ++
drivers/gpu/drm/i915/intel_pm.c | 81 ++
include/drm/i915_powerwell.h | 36 +
5 files changed, 132 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f5addac..d709776 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1652,6 +1652,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
/* Start out suspended */
dev_priv-mm.suspended = 1;
+ if (HAS_POWER_WELL(dev))
+ i915_init_power_well(dev);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = i915_load_modeset_init(dev);
if (ret 0) {
@@ -1708,6 +1711,9 @@ int i915_driver_unload(struct drm_device *dev)
intel_gpu_ips_teardown();
+ if (HAS_POWER_WELL(dev))
+ i915_remove_power_well(dev);
+
i915_teardown_sysfs(dev);
if (dev_priv-mm.inactive_shrinker.shrink)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14817de..bd53a6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -720,6 +720,15 @@ struct intel_ilk_power_mgmt {
struct drm_i915_gem_object *renderctx;
};
+/* Power well structure for haswell */
+struct i915_power_well {
+ struct drm_device *device;
+ spinlock_t lock;
+ /* power well enable/disable usage count */
+ int count;
+ int i915_request;
+};
+
struct i915_dri1_state {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
@@ -1073,6 +1082,9 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /* Haswell power well */
+ struct i915_power_well power_well;
+
enum no_fbc_reason no_fbc_reason;
struct drm_mm_node *compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0f35545..8b5017d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -754,6 +754,10 @@ extern void intel_update_fbc(struct drm_device *dev);
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+/* Power well */
+extern int i915_init_power_well(struct drm_device *dev);
+extern void i915_remove_power_well(struct drm_device *dev);
+
extern bool intel_display_power_enabled(struct drm_device *dev,
enum intel_display_power_domain domain);
extern void intel_init_power_well(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1a76572..eeba875 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4502,18 +4502,12 @@ bool intel_display_power_enabled(struct drm_device *dev,
}
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void __intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE;
@@ -4536,6 +4530,79 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
}
}
+static struct i915_power_well *hsw_pwr;
+
+/* Display audio driver power well request */
+void i915_request_power_well(void)
+{
+ if (WARN_ON(!hsw_pwr))
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+ if (!hsw_pwr-count++
+ !hsw_pwr-i915_request)
+ __intel_set_power_well(hsw_pwr-device, true);
+ spin_unlock_irq(hsw_pwr-lock);
+}
+EXPORT_SYMBOL_GPL(i915_request_power_well);
+
+/* Display audio driver power well release */
+void i915_release_power_well(void)
+{
+ if (WARN_ON(!hsw_pwr))
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+ WARN_ON(!hsw_pwr-count);
+ if (!--hsw_pwr-count
Re: [Intel-gfx] Haswell: Ensuring HDA codec pins refer to physical outputs
On Thu, May 16, 2013 at 09:00:06AM +0200, David Henningsson wrote: Hi, I want to take this problem up again, because it's important we get this right. The HDA driver assumes that a codec pin widget node always refers to the same physical output. With Haswell, it seems like this is not guaranteed to be true. I would like to see this fixed on the graphics side. If not, I don't know how to work around it on the audio side. in gfx side, eld valid bit was set according to *pipe*, not physical outputs. For haswell, the codec pin output connected to transcoder(pipe) directly. I cannot confirm whether the three codec Pins are fixed connected to three transcoders(pipes) atm, i assume it is as i cannot find any programing manual in bspec(please correct me if i'm wrong here). And between transcoder and external DDI ports, there's cross-point mux used for selection: pipe/transcoder can select the output DDI ports. i.e. the physical HDMI cable is connected to DDI port B. if current using pipe is PIPE A, the eld valid bit for PIPE A is set. But we cannot guarantee only the first hdmi device is available for audio output. when play audio through first codec pin, it means output audio data to Transcoder A(Pipe A), that depends on whether PIPE A select DDI port B. If output data to second codec PIN, it outputs data to PIPE B, if pipe B select DDI B too, you can hear sound, even the second pin doesnt have valid eld info. thanks --xingchao The problems that occur on the audio side are: 1) Some BIOSes set default pin config. E g, if the machine has a single HDMI out, it can set two of the codec pins to not connected and let the third remain jack. As a result, the HDA driver will ignore the two codec pins and only enable the third. As such, HDMI audio will not work correctly, unless it's the third codec pin that is connected to the physical output. 2) Saving and restoring mutes, volumes etc is done on a per-pin basis. E g, imagine that a user has a dual monitor setup and always wants audio output from the left side monitor, and keep the right side monitor silent. If it is not reliable which codec pin refers to which physical output, one day suddenly the sound might come out on the right side monitor instead. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4 V6] Power-well API implementation for Haswell
Hi all, This is V6 and here're some changes notes: change from V5--V6: - Remove duplication code in new introduced probe work - move duplication code in azx_probe_continue - remove unused #ifdef - replace request_module with symbol_request - replace spin_lock_irq with spin_lock_irqsave in gfx side - other typo fixes (review by Takashi) change from V4--V5: - fix reference count bug - new patch on general runtime pm support for audio pci device - new patch to avoid request_module() deadlock change between V3--V4: - add new structure i915_power_well - initialize drm_device pointer at module init time - change function name change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Takashi Iwai (1): ALSA: hda - Move azx_first_init() into azx_probe_continue() Wang Xingchao (3): ALSA: hda - Fix runtime PM check ALSA: hda - Add power-welll support for haswell HDA i915/drm: Add private api for power well usage drivers/gpu/drm/i915/i915_dma.c |6 +++ drivers/gpu/drm/i915/i915_drv.h | 12 + drivers/gpu/drm/i915/intel_drv.h |4 ++ drivers/gpu/drm/i915/intel_pm.c | 92 +++--- include/drm/i915_powerwell.h | 36 +++ sound/pci/hda/Kconfig| 10 + sound/pci/hda/Makefile |2 + sound/pci/hda/hda_i915.c | 75 +++ sound/pci/hda/hda_i915.h | 35 +++ sound/pci/hda/hda_intel.c| 87 --- 10 files changed, 335 insertions(+), 24 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] ALSA: hda - Move azx_first_init() into azx_probe_continue()
From: Takashi Iwai ti...@suse.de
This is a preliminary work for the upcoming Haswell HDMI audio fixes.
azx_first_init() function can be safely called after the f/w loader,
since the f/w loader doesn't require the sound hardware initialization
beforehand. Moving it into azx_probe_continue() cleans up the code
flow a bit.
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/hda_intel.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index cf3d36c..49cc942 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2977,7 +2977,6 @@ static void azx_notifier_unregister(struct azx *chip)
unregister_reboot_notifier(chip-reboot_notifier);
}
-static int azx_first_init(struct azx *chip);
static int azx_probe_continue(struct azx *chip);
#ifdef SUPPORT_VGA_SWITCHEROO
@@ -3004,8 +3003,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
snd_printk(KERN_INFO SFX
%s: Start delayed initialization\n,
pci_name(chip-pci));
- if (azx_first_init(chip) 0 ||
- azx_probe_continue(chip) 0) {
+ if (azx_probe_continue(chip) 0) {
snd_printk(KERN_ERR SFX
%s: initialization error\n,
pci_name(chip-pci));
@@ -3706,11 +3704,6 @@ static int azx_probe(struct pci_dev *pci,
}
probe_now = !chip-disabled;
- if (probe_now) {
- err = azx_first_init(chip);
- if (err 0)
- goto out_free;
- }
#ifdef CONFIG_SND_HDA_PATCH_LOADER
if (patch[dev] *patch[dev]) {
@@ -3747,6 +3740,10 @@ static int azx_probe_continue(struct azx *chip)
int dev = chip-dev_index;
int err;
+ err = azx_first_init(chip);
+ if (err 0)
+ goto out_free;
+
#ifdef CONFIG_SND_HDA_INPUT_BEEP
chip-beep_mode = beep_mode[dev];
#endif
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4 V6] ALSA: hda - Add power-welll support for haswell HDA
For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) - azx_probe - module_request
(or symbol_request) - modprobe (userspace) - i915 init -
drm_pci_init - pci_register_driver - bus_add_driver - driver_attach -
which in turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.
This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/Kconfig | 10 ++
sound/pci/hda/Makefile|2 ++
sound/pci/hda/hda_i915.c | 75 +
sound/pci/hda/hda_i915.h | 35 +
sound/pci/hda/hda_intel.c | 60 ++--
5 files changed, 179 insertions(+), 3 deletions(-)
create mode 100644 sound/pci/hda/hda_i915.c
create mode 100644 sound/pci/hda/hda_i915.h
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index 80a7d44..c5a872c 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -152,6 +152,16 @@ config SND_HDA_CODEC_HDMI
snd-hda-codec-hdmi.
This module is automatically loaded at probing.
+config SND_HDA_I915
+ bool Build Display HD-audio controller/codec power well support for
i915 cards
+ depends on DRM_I915
+ help
+ Say Y here to include full HDMI and DisplayPort HD-audio
controller/codec
+ power-well support for Intel Haswell graphics cards based on the i915
driver.
+
+ Note that this option must be enabled for Intel Haswell C+ stepping
machines, otherwise
+ the GPU audio controller/codecs will not be initialized or damaged
when exit from S3 mode.
+
config SND_HDA_CODEC_CIRRUS
bool Build Cirrus Logic codec support
default y
diff --git a/sound/pci/hda/Makefile b/sound/pci/hda/Makefile
index 24a2514..c091438 100644
--- a/sound/pci/hda/Makefile
+++ b/sound/pci/hda/Makefile
@@ -1,4 +1,6 @@
snd-hda-intel-objs := hda_intel.o
+# for haswell power well
+snd-hda-intel-$(CONFIG_SND_HDA_I915) +=hda_i915.o
snd-hda-codec-y := hda_codec.o hda_jack.o hda_auto_parser.o
snd-hda-codec-$(CONFIG_SND_HDA_GENERIC) += hda_generic.o
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
new file mode 100644
index 000..76c13d5
--- /dev/null
+++ b/sound/pci/hda/hda_i915.c
@@ -0,0 +1,75 @@
+/*
+ * hda_i915.c - routines for Haswell HDA controller power well support
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include sound/core.h
+#include drm/i915_powerwell.h
+#include hda_i915.h
+
+static void (*get_power)(void);
+static void (*put_power)(void);
+
+void hda_display_power(bool enable)
+{
+ if (!get_power || !put_power)
+ return;
+
+ snd_printdd(HDA display power %s \n,
+ enable ? Enable : Disable);
+ if (enable)
+ get_power();
+ else
+ put_power();
+}
+
+int hda_i915_init(void)
+{
+ int err = 0;
+
+ get_power = symbol_request(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
+ return -ENODEV;
+ }
+
+ put_power = symbol_request(i915_release_power_well);
+ if (!put_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ return -ENODEV;
+ }
+
+ snd_printd(HDA driver get symbol successfully from i915 module\n);
+
+ return err;
+}
+
+int hda_i915_exit(void)
+{
+ if (get_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ }
+ if (put_power) {
+ symbol_put(i915_release_power_well);
+ put_power = NULL;
+ }
+
+ return 0;
+}
diff --git a/sound/pci/hda/hda_i915.h b/sound/pci/hda/hda_i915.h
new file mode 100644
index 000..5a63da2
--- /dev/null
[Intel-gfx] [PATCH 4/4 V6] i915/drm: Add private api for power well usage
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c |6 +++
drivers/gpu/drm/i915/i915_drv.h | 12 +
drivers/gpu/drm/i915/intel_drv.h |4 ++
drivers/gpu/drm/i915/intel_pm.c | 92 +++---
include/drm/i915_powerwell.h | 36 +++
5 files changed, 143 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f5addac..b702915 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1652,6 +1652,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
/* Start out suspended */
dev_priv-mm.suspended = 1;
+ if (IS_HASWELL(dev))
+ i915_init_power_well(dev);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = i915_load_modeset_init(dev);
if (ret 0) {
@@ -1708,6 +1711,9 @@ int i915_driver_unload(struct drm_device *dev)
intel_gpu_ips_teardown();
+ if (IS_HASWELL(dev))
+ i915_remove_power_well(dev);
+
i915_teardown_sysfs(dev);
if (dev_priv-mm.inactive_shrinker.shrink)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14817de..ea94e5e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -720,6 +720,15 @@ struct intel_ilk_power_mgmt {
struct drm_i915_gem_object *renderctx;
};
+/* Power well structure for haswell */
+struct i915_power_well {
+ struct drm_device *device;
+ spinlock_t lock;
+ /* power well enable/disable usage count */
+ int count;
+ int i915_request;
+};
+
struct i915_dri1_state {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
@@ -1073,6 +1082,9 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /* Haswell power well */
+ struct i915_power_well *hsw_pwr;
+
enum no_fbc_reason no_fbc_reason;
struct drm_mm_node *compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0f35545..8b5017d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -754,6 +754,10 @@ extern void intel_update_fbc(struct drm_device *dev);
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+/* Power well */
+extern int i915_init_power_well(struct drm_device *dev);
+extern void i915_remove_power_well(struct drm_device *dev);
+
extern bool intel_display_power_enabled(struct drm_device *dev,
enum intel_display_power_domain domain);
extern void intel_init_power_well(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1a76572..f429347 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4502,18 +4502,12 @@ bool intel_display_power_enabled(struct drm_device *dev,
}
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void __intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE;
@@ -4536,6 +4530,90 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
}
}
+static struct i915_power_well *hsw_pwr;
+
+/* Display audio driver power well request */
+void i915_request_power_well(void)
+{
+ if (hsw_pwr == NULL)
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+ if (!hsw_pwr-count++
+ !hsw_pwr-i915_request)
+ __intel_set_power_well(hsw_pwr-device, true);
+ spin_unlock_irq(hsw_pwr-lock);
+}
+EXPORT_SYMBOL_GPL(i915_request_power_well);
+
+/* Display audio driver power well release */
+void i915_release_power_well(void)
+{
+ if (hsw_pwr == NULL)
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+ WARN_ON(!hsw_pwr-count);
+ if (!--hsw_pwr-count
+ !hsw_pwr-i915_request)
+ __intel_set_power_well(hsw_pwr-device, false);
+ spin_unlock_irq(hsw_pwr-lock);
+}
+EXPORT_SYMBOL_GPL
Re: [Intel-gfx] [PATCH 3/4] ALSA: hda - Fix runtime PM check
Hi Takashi, -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Thursday, May 23, 2013 2:03 PM To: Wang Xingchao Cc: dan...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; david.hennings...@canonical.com; Girdwood, Liam R; Li, Jocelyn; Wang, Xingchao Subject: Re: [PATCH 3/4] ALSA: hda - Fix runtime PM check At Thu, 23 May 2013 01:04:15 +0800, Wang Xingchao wrote: The device can support runtime PM no matter whether it support signal wakeup or not. For some chips like Haswell which doesnot support PME by default, this patch let haswell Display HD-A controller enter runtime suspend, and bring more power saving whith power-well feature enabled. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com This change has nothing to do with the power well fix, thus no reason to put in the series. But power-well feature depends on HD-A controller's power-save enabling, without this patch, Power-well would not be shutdown automatically, thus cause more power. So I thought it should be part of the patchset. Anyway it's a more general fix not only for Haswell, so better to leave it alone. I will split it from the patchset in next version. Thanks --xingchao Takashi --- sound/pci/hda/hda_intel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 54c7c22..f20a88c 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -3755,7 +3755,7 @@ static int azx_probe(struct pci_dev *pci, goto out_free_power; } - if (pci_dev_run_wake(pci)) + if (chip-driver_caps AZX_DCAPS_PM_RUNTIME) pm_runtime_put_noidle(pci-dev); dev++; @@ -3834,7 +3834,7 @@ static void azx_remove(struct pci_dev *pci) struct snd_card *card = pci_get_drvdata(pci); struct azx *chip = card-private_data; - if (pci_dev_run_wake(pci)) + if (chip-driver_caps AZX_DCAPS_PM_RUNTIME) pm_runtime_get_noresume(pci-dev); if (card) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4 V2] ALSA: hda - Continue probe in work context to avoid request_module deadlock
Hi Takashi,
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Thursday, May 23, 2013 2:49 PM
To: Wang Xingchao
Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org;
david.hennings...@canonical.com; Girdwood, Liam R; Li, Jocelyn; Wang,
Xingchao; Lin, Mengdong
Subject: Re: [PATCH 4/4 V2] ALSA: hda - Continue probe in work context to
avoid
request_module deadlock
At Thu, 23 May 2013 09:51:07 +0800,
Wang Xingchao wrote:
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) - azx_probe - module_request (or
symbol_request) - modprobe (userspace) - i915 init - drm_pci_init
- pci_register_driver - bus_add_driver - driver_attach - which in
turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.
This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c | 13 -- sound/pci/hda/hda_intel.c |
105 +++---
2 files changed, 71 insertions(+), 47 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c index
76c13d5..7547b20 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -42,13 +42,18 @@ int hda_i915_init(void) {
int err = 0;
- get_power = symbol_request(i915_request_power_well);
+ get_power = symbol_get(i915_request_power_well);
if (!get_power) {
- snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
- return -ENODEV;
+ request_module(i915);
+ get_power = symbol_get(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
+ return -ENODEV;
+ }
+ snd_printdd(hda-i915: get_power symbol get successful\n);
Why do you need this change?
symbol_request() should be the better API in such case but in my test it
doesnot really load i915 module, that's why
I call request_module(i915) directly here.
Please note there's parameter difference:
request_module(i915)
symbol_request(i915_reauest_power_well)--request_module(symbol:i915_request_power_well)
I donot know why the second one did not really load the module.
Thanks
--xingchao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] ALSA: hda - Fix runtime PM check
-Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Thursday, May 23, 2013 4:10 PM To: Wang, Xingchao Cc: dan...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; david.hennings...@canonical.com; Girdwood, Liam R; Li, Jocelyn; Wang Xingchao Subject: Re: [PATCH 3/4] ALSA: hda - Fix runtime PM check At Thu, 23 May 2013 07:53:00 +, Wang, Xingchao wrote: Hi Takashi, -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Thursday, May 23, 2013 2:03 PM To: Wang Xingchao Cc: dan...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; david.hennings...@canonical.com; Girdwood, Liam R; Li, Jocelyn; Wang, Xingchao Subject: Re: [PATCH 3/4] ALSA: hda - Fix runtime PM check At Thu, 23 May 2013 01:04:15 +0800, Wang Xingchao wrote: The device can support runtime PM no matter whether it support signal wakeup or not. For some chips like Haswell which doesnot support PME by default, this patch let haswell Display HD-A controller enter runtime suspend, and bring more power saving whith power-well feature enabled. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com This change has nothing to do with the power well fix, thus no reason to put in the series. But power-well feature depends on HD-A controller's power-save enabling, without this patch, Power-well would not be shutdown automatically, thus cause more power. Then the fix order is wrong. Fix this first, then the rest. Okay, I see. thanks --xingchao Takashi So I thought it should be part of the patchset. Anyway it's a more general fix not only for Haswell, so better to leave it alone. I will split it from the patchset in next version. Thanks --xingchao Takashi --- sound/pci/hda/hda_intel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 54c7c22..f20a88c 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -3755,7 +3755,7 @@ static int azx_probe(struct pci_dev *pci, goto out_free_power; } - if (pci_dev_run_wake(pci)) + if (chip-driver_caps AZX_DCAPS_PM_RUNTIME) pm_runtime_put_noidle(pci-dev); dev++; @@ -3834,7 +3834,7 @@ static void azx_remove(struct pci_dev *pci) struct snd_card *card = pci_get_drvdata(pci); struct azx *chip = card-private_data; - if (pci_dev_run_wake(pci)) + if (chip-driver_caps AZX_DCAPS_PM_RUNTIME) pm_runtime_get_noresume(pci-dev); if (card) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4 V2] ALSA: hda - Continue probe in work context to avoid request_module deadlock
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Thursday, May 23, 2013 6:27 PM
To: Wang, Xingchao
Cc: Wang Xingchao; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; david.hennings...@canonical.com; Girdwood,
Liam R; Li, Jocelyn; Lin, Mengdong
Subject: Re: [PATCH 4/4 V2] ALSA: hda - Continue probe in work context to
avoid
request_module deadlock
At Thu, 23 May 2013 10:19:27 +,
Wang, Xingchao wrote:
Hi Takashi,
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Thursday, May 23, 2013 2:49 PM
To: Wang Xingchao
Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org;
david.hennings...@canonical.com; Girdwood, Liam R; Li, Jocelyn;
Wang, Xingchao; Lin, Mengdong
Subject: Re: [PATCH 4/4 V2] ALSA: hda - Continue probe in work
context to avoid request_module deadlock
At Thu, 23 May 2013 09:51:07 +0800,
Wang Xingchao wrote:
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) - azx_probe - module_request (or
symbol_request) - modprobe (userspace) - i915 init -
drm_pci_init
- pci_register_driver - bus_add_driver - driver_attach - which
- in
turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.
This patch introduce a work to store remaining probe stuff, and
let request_module run in safe work context.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c | 13 -- sound/pci/hda/hda_intel.c
|
105 +++---
2 files changed, 71 insertions(+), 47 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index
76c13d5..7547b20 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -42,13 +42,18 @@ int hda_i915_init(void) {
int err = 0;
- get_power = symbol_request(i915_request_power_well);
+ get_power = symbol_get(i915_request_power_well);
if (!get_power) {
- snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
- return -ENODEV;
+ request_module(i915);
+ get_power = symbol_get(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power
symbol
get
fail\n);
+ return -ENODEV;
+ }
+ snd_printdd(hda-i915: get_power symbol get
successful\n);
Why do you need this change?
symbol_request() should be the better API in such case but in my test
it doesnot really load i915 module, that's why I call request_module(i915)
directly here.
Please note there's parameter difference:
request_module(i915)
symbol_request(i915_reauest_power_well)--request_module(symbol:i915_
request_power_well)
I donot know why the second one did not really load the module.
Well, something is really fishy. The patch can't be accepted only because it
just works by moon phase...
I will continue to figure out the reason it doesnot work. :(
--xingchao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4 V5] Power-well API implementation for Haswell
Hi all, This is V5 and here're some changes notes: change from V4--V5: - fix reference count bug - new patch on general runtime pm support for audio pci device - new patch to avoid request_module() deadlock change between V3--V4: - add new structure i915_power_well - initialize drm_device pointer at module init time - change function name change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Wang Xingchao (4): i915/drm: Add private api for power well usage ALSA: hda - Add power-welll support for haswell HDA ALSA: hda - Fix runtime PM check ALSA: hda - Continue probe in work context to avoid request_module deadlock drivers/gpu/drm/i915/i915_dma.c | 6 ++ drivers/gpu/drm/i915/i915_drv.h | 12 drivers/gpu/drm/i915/intel_drv.h | 4 ++ drivers/gpu/drm/i915/intel_pm.c | 92 --- include/drm/i915_powerwell.h | 36 +++ sound/pci/hda/Kconfig| 10 +++ sound/pci/hda/Makefile | 3 + sound/pci/hda/hda_i915.c | 75 ++ sound/pci/hda/hda_i915.h | 35 +++ sound/pci/hda/hda_intel.c| 132 --- 10 files changed, 360 insertions(+), 45 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] ALSA: hda - Fix runtime PM check
The device can support runtime PM no matter whether it support signal wakeup or not. For some chips like Haswell which doesnot support PME by default, this patch let haswell Display HD-A controller enter runtime suspend, and bring more power saving whith power-well feature enabled. Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com --- sound/pci/hda/hda_intel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 54c7c22..f20a88c 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -3755,7 +3755,7 @@ static int azx_probe(struct pci_dev *pci, goto out_free_power; } - if (pci_dev_run_wake(pci)) + if (chip-driver_caps AZX_DCAPS_PM_RUNTIME) pm_runtime_put_noidle(pci-dev); dev++; @@ -3834,7 +3834,7 @@ static void azx_remove(struct pci_dev *pci) struct snd_card *card = pci_get_drvdata(pci); struct azx *chip = card-private_data; - if (pci_dev_run_wake(pci)) + if (chip-driver_caps AZX_DCAPS_PM_RUNTIME) pm_runtime_get_noresume(pci-dev); if (card) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] ALSA: hda - Continue probe in work context to avoid request_module deadlock
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) - azx_probe - module_request
(or symbol_request) - modprobe (userspace) - i915 init -
drm_pci_init - pci_register_driver - bus_add_driver - driver_attach -
which in turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.
This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_intel.c | 105 +++---
1 file changed, 62 insertions(+), 43 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index f20a88c..1bc7c3b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -76,6 +76,7 @@ static int probe_only[SNDRV_CARDS];
static int jackpoll_ms[SNDRV_CARDS];
static bool single_cmd;
static int enable_msi = -1;
+static int dev;
#ifdef CONFIG_SND_HDA_PATCH_LOADER
static char *patch[SNDRV_CARDS];
#endif
@@ -542,6 +543,8 @@ struct azx {
/* for pending irqs */
struct work_struct irq_pending_work;
+ struct delayed_work probe_work;
+
/* reboot notifier (for mysterious hangup problem at power-down) */
struct notifier_block reboot_notifier;
@@ -3670,58 +3673,22 @@ static void azx_firmware_cb(const struct firmware *fw,
void *context)
}
#endif
-static int azx_probe(struct pci_dev *pci,
-const struct pci_device_id *pci_id)
+static void azx_probe_work(struct work_struct *work)
{
- static int dev;
- struct snd_card *card;
- struct azx *chip;
+ struct azx *chip =
+ container_of(work, struct azx, probe_work.work);
+ struct snd_card *card = chip-card;
+ struct pci_dev *pci = chip-pci;
bool probe_now;
int err;
- if (dev = SNDRV_CARDS)
- return -ENODEV;
- if (!enable[dev]) {
- dev++;
- return -ENOENT;
- }
-
- err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, card);
- if (err 0) {
- snd_printk(KERN_ERR hda-intel: Error creating card!\n);
- return err;
- }
-
- snd_card_set_dev(card, pci-dev);
-
- err = azx_create(card, pci, dev, pci_id-driver_data, chip);
- if (err 0)
- goto out_free;
- card-private_data = chip;
-
- pci_set_drvdata(pci, card);
-
- err = register_vga_switcheroo(chip);
- if (err 0) {
- snd_printk(KERN_ERR SFX
- %s: Error registering VGA-switcheroo client\n,
pci_name(pci));
- goto out_free;
- }
-
- if (check_hdmi_disabled(pci)) {
- snd_printk(KERN_INFO SFX %s: VGA controller is disabled\n,
- pci_name(pci));
- snd_printk(KERN_INFO SFX %s: Delaying initialization\n,
pci_name(pci));
- chip-disabled = true;
- }
-
/* Request power well for Haswell HDA controller and codec */
if (chip-driver_caps AZX_DCAPS_I915_POWERWELL) {
#ifdef CONFIG_SND_HDA_I915
err = hda_i915_init();
if (err 0) {
snd_printk(KERN_ERR SFX Error request power-well from
i915\n);
- return err;
+ goto out_free;
}
hda_display_power(true);
#else
@@ -3760,7 +3727,7 @@ static int azx_probe(struct pci_dev *pci,
dev++;
complete_all(chip-probe_wait);
- return 0;
+ return;
out_free_power:
if (chip-driver_caps AZX_DCAPS_I915_POWERWELL) {
hda_display_power(false);
@@ -3769,6 +3736,58 @@ out_free_power:
out_free:
snd_card_free(card);
pci_set_drvdata(pci, NULL);
+}
+
+static int azx_probe(struct pci_dev *pci,
+const struct pci_device_id *pci_id)
+{
+ struct snd_card *card;
+ struct azx *chip;
+ int err;
+
+ if (dev = SNDRV_CARDS)
+ return -ENODEV;
+ if (!enable[dev]) {
+ dev++;
+ return -ENOENT;
+ }
+
+ err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, card);
+ if (err 0) {
+ snd_printk(KERN_ERR hda-intel: Error creating card!\n);
+ return err;
+ }
+
+ snd_card_set_dev(card, pci-dev);
+
+ err = azx_create(card, pci, dev, pci_id-driver_data, chip);
+ if (err 0)
+ goto out_free;
+ card-private_data = chip;
+
+ pci_set_drvdata(pci, card);
+
+ err = register_vga_switcheroo(chip);
+ if (err 0) {
+ snd_printk(KERN_ERR SFX
+ %s: Error registering VGA-switcheroo client\n,
pci_name(pci));
+ goto out_free;
+ }
+
+ if (check_hdmi_disabled(pci)) {
+ snd_printk(KERN_INFO
[Intel-gfx] [PATCH 4/4 V2] ALSA: hda - Continue probe in work context to avoid request_module deadlock
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) - azx_probe - module_request
(or symbol_request) - modprobe (userspace) - i915 init -
drm_pci_init - pci_register_driver - bus_add_driver - driver_attach -
which in turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.
This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c | 13 --
sound/pci/hda/hda_intel.c | 105 +++---
2 files changed, 71 insertions(+), 47 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index 76c13d5..7547b20 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -42,13 +42,18 @@ int hda_i915_init(void)
{
int err = 0;
- get_power = symbol_request(i915_request_power_well);
+ get_power = symbol_get(i915_request_power_well);
if (!get_power) {
- snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
- return -ENODEV;
+ request_module(i915);
+ get_power = symbol_get(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
+ return -ENODEV;
+ }
+ snd_printdd(hda-i915: get_power symbol get successful\n);
}
- put_power = symbol_request(i915_release_power_well);
+ put_power = symbol_get(i915_release_power_well);
if (!put_power) {
symbol_put(i915_request_power_well);
get_power = NULL;
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index f20a88c..1bc7c3b 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -76,6 +76,7 @@ static int probe_only[SNDRV_CARDS];
static int jackpoll_ms[SNDRV_CARDS];
static bool single_cmd;
static int enable_msi = -1;
+static int dev;
#ifdef CONFIG_SND_HDA_PATCH_LOADER
static char *patch[SNDRV_CARDS];
#endif
@@ -542,6 +543,8 @@ struct azx {
/* for pending irqs */
struct work_struct irq_pending_work;
+ struct delayed_work probe_work;
+
/* reboot notifier (for mysterious hangup problem at power-down) */
struct notifier_block reboot_notifier;
@@ -3670,58 +3673,22 @@ static void azx_firmware_cb(const struct firmware *fw,
void *context)
}
#endif
-static int azx_probe(struct pci_dev *pci,
-const struct pci_device_id *pci_id)
+static void azx_probe_work(struct work_struct *work)
{
- static int dev;
- struct snd_card *card;
- struct azx *chip;
+ struct azx *chip =
+ container_of(work, struct azx, probe_work.work);
+ struct snd_card *card = chip-card;
+ struct pci_dev *pci = chip-pci;
bool probe_now;
int err;
- if (dev = SNDRV_CARDS)
- return -ENODEV;
- if (!enable[dev]) {
- dev++;
- return -ENOENT;
- }
-
- err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, card);
- if (err 0) {
- snd_printk(KERN_ERR hda-intel: Error creating card!\n);
- return err;
- }
-
- snd_card_set_dev(card, pci-dev);
-
- err = azx_create(card, pci, dev, pci_id-driver_data, chip);
- if (err 0)
- goto out_free;
- card-private_data = chip;
-
- pci_set_drvdata(pci, card);
-
- err = register_vga_switcheroo(chip);
- if (err 0) {
- snd_printk(KERN_ERR SFX
- %s: Error registering VGA-switcheroo client\n,
pci_name(pci));
- goto out_free;
- }
-
- if (check_hdmi_disabled(pci)) {
- snd_printk(KERN_INFO SFX %s: VGA controller is disabled\n,
- pci_name(pci));
- snd_printk(KERN_INFO SFX %s: Delaying initialization\n,
pci_name(pci));
- chip-disabled = true;
- }
-
/* Request power well for Haswell HDA controller and codec */
if (chip-driver_caps AZX_DCAPS_I915_POWERWELL) {
#ifdef CONFIG_SND_HDA_I915
err = hda_i915_init();
if (err 0) {
snd_printk(KERN_ERR SFX Error request power-well from
i915\n);
- return err;
+ goto out_free;
}
hda_display_power(true);
#else
@@ -3760,7 +3727,7 @@ static int azx_probe(struct pci_dev *pci,
dev++;
complete_all(chip-probe_wait);
- return 0;
+ return;
out_free_power:
if (chip-driver_caps AZX_DCAPS_I915_POWERWELL) {
hda_display_power(false);
@@ -3769,6 +3736,58 @@ out_free_power:
out_free:
snd_card_free(card
Re: [Intel-gfx] [PATCH 2/2 V4] ALSA: hda - Add power-welll support for haswell HDA
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 21, 2013 3:19 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; david.hennings...@canonical.com; Lin,
Mengdong; Li, Jocelyn; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Barnes, Jesse; Zanoni, Paulo R; Wang,
Xingchao
Subject: Re: [PATCH 2/2 V4] ALSA: hda - Add power-welll support for haswell
HDA
At Mon, 20 May 2013 19:26:58 +0800,
Wang Xingchao wrote:
For Intel Haswell chip, HDA controller and codec have power well
dependency from GPU side. This patch added support to request/release
power well in audio driver. Power save feature should be enabled to
get runtime power saving.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/Kconfig | 10 ++
sound/pci/hda/Makefile|3 ++
sound/pci/hda/hda_i915.c | 75
+
sound/pci/hda/hda_i915.h | 35 +
sound/pci/hda/hda_intel.c | 41 +++--
5 files changed, 161 insertions(+), 3 deletions(-) create mode
100644 sound/pci/hda/hda_i915.c create mode 100644
sound/pci/hda/hda_i915.h
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig index
80a7d44..c5a872c 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -152,6 +152,16 @@ config SND_HDA_CODEC_HDMI
snd-hda-codec-hdmi.
This module is automatically loaded at probing.
+config SND_HDA_I915
+ bool Build Display HD-audio controller/codec power well support for
i915
cards
+ depends on DRM_I915
+ help
+ Say Y here to include full HDMI and DisplayPort HD-audio
controller/codec
+ power-well support for Intel Haswell graphics cards based on the i915
driver.
+
+ Note that this option must be enabled for Intel Haswell C+ stepping
machines, otherwise
+ the GPU audio controller/codecs will not be initialized or damaged
when
exit from S3 mode.
+
config SND_HDA_CODEC_CIRRUS
bool Build Cirrus Logic codec support
default y
diff --git a/sound/pci/hda/Makefile b/sound/pci/hda/Makefile index
24a2514..4b0a4bc 100644
--- a/sound/pci/hda/Makefile
+++ b/sound/pci/hda/Makefile
@@ -6,6 +6,9 @@ snd-hda-codec-$(CONFIG_PROC_FS) += hda_proc.o
snd-hda-codec-$(CONFIG_SND_HDA_HWDEP) += hda_hwdep.o
snd-hda-codec-$(CONFIG_SND_HDA_INPUT_BEEP) += hda_beep.o
+# for haswell power well
+snd-hda-intel-$(CONFIG_SND_HDA_I915) +=hda_i915.o
+
# for trace-points
CFLAGS_hda_codec.o := -I$(src)
CFLAGS_hda_intel.o := -I$(src)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c new
file mode 100644 index 000..76c13d5
--- /dev/null
+++ b/sound/pci/hda/hda_i915.c
@@ -0,0 +1,75 @@
+/*
+ * hda_i915.c - routines for Haswell HDA controller power well
+support
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as published by
+the Free
+ * Software Foundation; either version 2 of the License, or (at your
+option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include sound/core.h
+#include drm/i915_powerwell.h
+#include hda_i915.h
+
+static void (*get_power)(void);
+static void (*put_power)(void);
+
+void hda_display_power(bool enable)
+{
+ if (!get_power || !put_power)
+ return;
+
+ snd_printdd(HDA display power %s \n,
+ enable ? Enable : Disable);
+ if (enable)
+ get_power();
+ else
+ put_power();
+}
+
+int hda_i915_init(void)
+{
+ int err = 0;
+
+ get_power = symbol_request(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
+ return -ENODEV;
+ }
+
+ put_power = symbol_request(i915_release_power_well);
+ if (!put_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ return -ENODEV;
+ }
+
+ snd_printd(HDA driver get symbol successfully from i915 module\n);
+
+ return err;
+}
+
+int hda_i915_exit(void)
+{
+ if (get_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ }
+ if (put_power) {
+ symbol_put
Re: [Intel-gfx] [PATCH 1/2 V4] i915/drm: Add private api for power well usage
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 21, 2013 3:18 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; david.hennings...@canonical.com; Lin,
Mengdong; Li, Jocelyn; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Barnes, Jesse; Zanoni, Paulo R; Wang,
Xingchao
Subject: Re: [PATCH 1/2 V4] i915/drm: Add private api for power well usage
At Mon, 20 May 2013 19:26:57 +0800,
Wang Xingchao wrote:
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c |6 +++
drivers/gpu/drm/i915/i915_drv.h | 12 +
drivers/gpu/drm/i915/intel_drv.h |4 ++
drivers/gpu/drm/i915/intel_pm.c | 98
+++---
include/drm/i915_powerwell.h | 36 ++
5 files changed, 149 insertions(+), 7 deletions(-) create mode
100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index a1648eb..2b9010a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1652,6 +1652,9 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
/* Start out suspended */
dev_priv-mm.suspended = 1;
+ if (IS_HASWELL(dev))
+ i915_init_power_well(dev);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = i915_load_modeset_init(dev);
if (ret 0) {
@@ -1708,6 +1711,9 @@ int i915_driver_unload(struct drm_device *dev)
intel_gpu_ips_teardown();
+ if (IS_HASWELL(dev))
+ i915_remove_power_well(dev);
+
i915_teardown_sysfs(dev);
if (dev_priv-mm.inactive_shrinker.shrink)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 3ac71db..a0f1a6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -702,6 +702,15 @@ struct intel_ilk_power_mgmt {
struct drm_i915_gem_object *renderctx; };
+/* Power well structure for haswell */ struct i915_power_well {
+ struct drm_device *device;
+ spinlock_t lock;
+ /* power well enable/disable usage count */
+ int count;
+ int i915_request;
+};
+
struct i915_dri1_state {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
@@ -1048,6 +1057,9 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /* Haswell power well */
+ struct i915_power_well *hsw_pwr;
+
enum no_fbc_reason no_fbc_reason;
struct drm_mm_node *compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index dfcf546..efcccab 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -759,6 +759,10 @@ extern void intel_update_fbc(struct drm_device
*dev); extern void intel_gpu_ips_init(struct drm_i915_private
*dev_priv); extern void intel_gpu_ips_teardown(void);
+/* Power well */
+extern int i915_init_power_well(struct drm_device *dev); extern void
+i915_remove_power_well(struct drm_device *dev);
+
extern bool intel_using_power_well(struct drm_device *dev); extern
void intel_init_power_well(struct drm_device *dev); extern void
intel_set_power_well(struct drm_device *dev, bool enable); diff --git
a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f4b46e..eec7aa8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4344,18 +4344,12 @@ bool intel_using_power_well(struct drm_device
*dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void __intel_set_power_well(struct drm_device *dev, bool
+enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE; @@ -4378,6
+4372,96 @@
void intel_set_power_well(struct drm_device *dev, bool enable)
}
}
+static struct i915_power_well *hsw_pwr;
+
+/* Display audio driver power well request */ void
+i915_request_power_well(void) {
+ if (hsw_pwr == NULL)
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+ if (!hsw_pwr-count++
+ !hsw_pwr-i915_request)
+ __intel_set_power_well(hsw_pwr
[Intel-gfx] [PATCH 1/2 V4] i915/drm: Add private api for power well usage
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c |6 +++
drivers/gpu/drm/i915/i915_drv.h | 12 +
drivers/gpu/drm/i915/intel_drv.h |4 ++
drivers/gpu/drm/i915/intel_pm.c | 98 +++---
include/drm/i915_powerwell.h | 36 ++
5 files changed, 149 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a1648eb..2b9010a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1652,6 +1652,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
/* Start out suspended */
dev_priv-mm.suspended = 1;
+ if (IS_HASWELL(dev))
+ i915_init_power_well(dev);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = i915_load_modeset_init(dev);
if (ret 0) {
@@ -1708,6 +1711,9 @@ int i915_driver_unload(struct drm_device *dev)
intel_gpu_ips_teardown();
+ if (IS_HASWELL(dev))
+ i915_remove_power_well(dev);
+
i915_teardown_sysfs(dev);
if (dev_priv-mm.inactive_shrinker.shrink)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3ac71db..a0f1a6d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -702,6 +702,15 @@ struct intel_ilk_power_mgmt {
struct drm_i915_gem_object *renderctx;
};
+/* Power well structure for haswell */
+struct i915_power_well {
+ struct drm_device *device;
+ spinlock_t lock;
+ /* power well enable/disable usage count */
+ int count;
+ int i915_request;
+};
+
struct i915_dri1_state {
unsigned allow_batchbuffer : 1;
u32 __iomem *gfx_hws_cpu_addr;
@@ -1048,6 +1057,9 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /* Haswell power well */
+ struct i915_power_well *hsw_pwr;
+
enum no_fbc_reason no_fbc_reason;
struct drm_mm_node *compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dfcf546..efcccab 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -759,6 +759,10 @@ extern void intel_update_fbc(struct drm_device *dev);
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+/* Power well */
+extern int i915_init_power_well(struct drm_device *dev);
+extern void i915_remove_power_well(struct drm_device *dev);
+
extern bool intel_using_power_well(struct drm_device *dev);
extern void intel_init_power_well(struct drm_device *dev);
extern void intel_set_power_well(struct drm_device *dev, bool enable);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f4b46e..eec7aa8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4344,18 +4344,12 @@ bool intel_using_power_well(struct drm_device *dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void __intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE;
@@ -4378,6 +4372,96 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
}
}
+static struct i915_power_well *hsw_pwr;
+
+/* Display audio driver power well request */
+void i915_request_power_well(void)
+{
+ if (hsw_pwr == NULL)
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+ if (!hsw_pwr-count++
+ !hsw_pwr-i915_request)
+ __intel_set_power_well(hsw_pwr-device, true);
+ spin_unlock_irq(hsw_pwr-lock);
+}
+EXPORT_SYMBOL_GPL(i915_request_power_well);
+
+/* Display audio driver power well release */
+void i915_release_power_well(void)
+{
+ if (hsw_pwr == NULL)
+ return;
+
+ spin_lock_irq(hsw_pwr-lock);
+
+ /* i915 using power well */
+ if (hsw_pwr-i915_request) {
+ spin_unlock_irq(hsw_pwr-lock);
+ return;
+ }
+
+ WARN_ON(!hsw_pwr-count);
+ if (!--hsw_pwr-count
Re: [Intel-gfx] [PATCH 1/2 V3] drm/915: Add private api for power well usage
Hi Jesse,
-Original Message-
From: Barnes, Jesse
Sent: Friday, May 17, 2013 11:44 PM
To: Wang Xingchao
Cc: ti...@suse.de; dan...@ffwll.ch; Girdwood, Liam R;
david.hennings...@canonical.com; Lin, Mengdong; Li, Jocelyn;
alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Zanoni, Paulo R;
Wang, Xingchao
Subject: Re: [PATCH 1/2 V3] drm/915: Add private api for power well usage
A few comments and questions below.
On Thu, 16 May 2013 15:52:36 +0800
Wang Xingchao xingchao.w...@linux.intel.com wrote:
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 75
+++
include/drm/i915_powerwell.h| 36 +++
2 files changed, 104 insertions(+), 7 deletions(-) create mode
100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c index 0f4b46e..88820e1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4344,18 +4344,12 @@ bool intel_using_power_well(struct drm_device
*dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void enable_power_well(struct drm_device *dev, bool enable)
We can leave the name of this function alone; even for static stuff we tend to
use the intel_ prefix. Plus it's a set function, not an enable function...
so
maybe just put a __ in front of it to indicate it's for internal use only.
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
+/* Global drm_device for display audio drvier usage */ static struct
+drm_device *power_well_device;
+/* Lock protecting power well setting */ static
+DEFINE_SPINLOCK(powerwell_lock); static bool i915_power_well_using;
What does this mean? If it's just for making sure we don't use bogus
power_well_device, it seems like we can just use a NULL check against
power_well_device for that instead.
+static int hsw_power_count;
+
+void i915_request_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ if (!hsw_power_count++ !i915_power_well_using)
+ enable_power_well(power_well_device, true);
+ spin_unlock_irq(powerwell_lock);
+}
+EXPORT_SYMBOL_GPL(i915_request_power_well);
+
+void i915_release_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ WARN_ON(!hsw_power_count);
+ if (!--hsw_power_count
+!i915_power_well_using)
+ enable_power_well(power_well_device, false);
+ spin_unlock_irq(powerwell_lock);
+}
+EXPORT_SYMBOL_GPL(i915_release_power_well);
+
+/* TODO: Call this when i915 module unload */ void
+i915_remove_power_well(void) {
+ i915_power_well_using = false;
+ power_well_device = NULL;
+}
+
+void intel_set_power_well(struct drm_device *dev, bool enable) {
+ if (!HAS_POWER_WELL(dev))
+ return;
+
+ power_well_device = dev;
+ spin_lock_irq(powerwell_lock);
+ i915_power_well_using = enable;
+ if (!enable hsw_power_count) {
+ DRM_DEBUG_KMS(Display audio power well busy using now\n);
+ goto out;
+ }
+
+ if (!i915_disable_power_well !enable)
+ goto out;
+
+ enable_power_well(dev, enable);
+out:
+ spin_unlock_irq(powerwell_lock);
+}
I think we should just set the power_well_device at module init time, then ou
wouldn't need to check/set it here.
Also, the existing i915 code could just use the request/release functions too
(internal versions taking a drm_device *), then you wouldn't need this special
case.
It's not a good idea to use the same reference count to track power-well
calling for both audio and i915 driver.
For audio driver the calling request/release are symmetrical, but for i915
driver it's not.
In my test, i915 request power-well 3 times, but release power-well 5 times.
That obviously caused conflicts.
+/* For use by hda_i915 driver */
+extern void i915_request_power_well(void); extern void
+i915_release_power_well(void);
For future proofing, it might be good if these took an enum for the power well
being requested. Then we could track an array of refcounts later when we
need the additional controls.
But I suppose that could be added later when we have a better idea of what
[Intel-gfx] [PATCH 0/2 V3] Power-well API implementation for Haswell
Hi all, This is V3 and some fixes after Takashi's review. change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Wang Xingchao (2): drm/915: Add private api for power well usage ALSA: hda - Add power-welll support for haswell HDA drivers/gpu/drm/i915/intel_pm.c | 76 +++ include/drm/i915_powerwell.h| 36 +++ sound/pci/hda/Kconfig | 10 ++ sound/pci/hda/Makefile |3 ++ sound/pci/hda/hda_i915.c| 75 ++ sound/pci/hda/hda_i915.h| 35 ++ sound/pci/hda/hda_intel.c | 41 +++-- 7 files changed, 262 insertions(+), 10 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2 V3] drm/915: Add private api for power well usage
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 75 +++
include/drm/i915_powerwell.h| 36 +++
2 files changed, 104 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f4b46e..88820e1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4344,18 +4344,12 @@ bool intel_using_power_well(struct drm_device *dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void enable_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE;
@@ -4378,6 +4372,73 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
}
}
+/* Global drm_device for display audio drvier usage */
+static struct drm_device *power_well_device;
+/* Lock protecting power well setting */
+static DEFINE_SPINLOCK(powerwell_lock);
+static bool i915_power_well_using;
+static int hsw_power_count;
+
+void i915_request_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ if (!hsw_power_count++ !i915_power_well_using)
+ enable_power_well(power_well_device, true);
+ spin_unlock_irq(powerwell_lock);
+}
+EXPORT_SYMBOL_GPL(i915_request_power_well);
+
+void i915_release_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ WARN_ON(!hsw_power_count);
+ if (!--hsw_power_count
+!i915_power_well_using)
+ enable_power_well(power_well_device, false);
+ spin_unlock_irq(powerwell_lock);
+}
+EXPORT_SYMBOL_GPL(i915_release_power_well);
+
+/* TODO: Call this when i915 module unload */
+void i915_remove_power_well(void)
+{
+ i915_power_well_using = false;
+ power_well_device = NULL;
+}
+
+void intel_set_power_well(struct drm_device *dev, bool enable)
+{
+ if (!HAS_POWER_WELL(dev))
+ return;
+
+ power_well_device = dev;
+ spin_lock_irq(powerwell_lock);
+ i915_power_well_using = enable;
+ if (!enable hsw_power_count) {
+ DRM_DEBUG_KMS(Display audio power well busy using now\n);
+ goto out;
+ }
+
+ if (!i915_disable_power_well !enable)
+ goto out;
+
+ enable_power_well(dev, enable);
+out:
+ spin_unlock_irq(powerwell_lock);
+}
+
/*
* Starting with Haswell, we have a Power Down Well that can be turned off
* when not needed anymore. We have 4 registers that can request the power well
diff --git a/include/drm/i915_powerwell.h b/include/drm/i915_powerwell.h
new file mode 100644
index 000..cfdc884
--- /dev/null
+++ b/include/drm/i915_powerwell.h
@@ -0,0 +1,36 @@
+/**
+ *
+ * Copyright 2013 Intel Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS
[Intel-gfx] [PATCH 2/2 V3] ALSA: hda - Add power-welll support for haswell HDA
For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/Kconfig | 10 ++
sound/pci/hda/Makefile|3 ++
sound/pci/hda/hda_i915.c | 75 +
sound/pci/hda/hda_i915.h | 35 +
sound/pci/hda/hda_intel.c | 41 +++--
5 files changed, 161 insertions(+), 3 deletions(-)
create mode 100644 sound/pci/hda/hda_i915.c
create mode 100644 sound/pci/hda/hda_i915.h
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index 80a7d44..c5a872c 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -152,6 +152,16 @@ config SND_HDA_CODEC_HDMI
snd-hda-codec-hdmi.
This module is automatically loaded at probing.
+config SND_HDA_I915
+ bool Build Display HD-audio controller/codec power well support for
i915 cards
+ depends on DRM_I915
+ help
+ Say Y here to include full HDMI and DisplayPort HD-audio
controller/codec
+ power-well support for Intel Haswell graphics cards based on the i915
driver.
+
+ Note that this option must be enabled for Intel Haswell C+ stepping
machines, otherwise
+ the GPU audio controller/codecs will not be initialized or damaged
when exit from S3 mode.
+
config SND_HDA_CODEC_CIRRUS
bool Build Cirrus Logic codec support
default y
diff --git a/sound/pci/hda/Makefile b/sound/pci/hda/Makefile
index 24a2514..4b0a4bc 100644
--- a/sound/pci/hda/Makefile
+++ b/sound/pci/hda/Makefile
@@ -6,6 +6,9 @@ snd-hda-codec-$(CONFIG_PROC_FS) += hda_proc.o
snd-hda-codec-$(CONFIG_SND_HDA_HWDEP) += hda_hwdep.o
snd-hda-codec-$(CONFIG_SND_HDA_INPUT_BEEP) += hda_beep.o
+# for haswell power well
+snd-hda-intel-$(CONFIG_SND_HDA_I915) +=hda_i915.o
+
# for trace-points
CFLAGS_hda_codec.o := -I$(src)
CFLAGS_hda_intel.o := -I$(src)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
new file mode 100644
index 000..76c13d5
--- /dev/null
+++ b/sound/pci/hda/hda_i915.c
@@ -0,0 +1,75 @@
+/*
+ * hda_i915.c - routines for Haswell HDA controller power well support
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include sound/core.h
+#include drm/i915_powerwell.h
+#include hda_i915.h
+
+static void (*get_power)(void);
+static void (*put_power)(void);
+
+void hda_display_power(bool enable)
+{
+ if (!get_power || !put_power)
+ return;
+
+ snd_printdd(HDA display power %s \n,
+ enable ? Enable : Disable);
+ if (enable)
+ get_power();
+ else
+ put_power();
+}
+
+int hda_i915_init(void)
+{
+ int err = 0;
+
+ get_power = symbol_request(i915_request_power_well);
+ if (!get_power) {
+ snd_printk(KERN_WARNING hda-i915: get_power symbol get
fail\n);
+ return -ENODEV;
+ }
+
+ put_power = symbol_request(i915_release_power_well);
+ if (!put_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ return -ENODEV;
+ }
+
+ snd_printd(HDA driver get symbol successfully from i915 module\n);
+
+ return err;
+}
+
+int hda_i915_exit(void)
+{
+ if (get_power) {
+ symbol_put(i915_request_power_well);
+ get_power = NULL;
+ }
+ if (put_power) {
+ symbol_put(i915_release_power_well);
+ put_power = NULL;
+ }
+
+ return 0;
+}
diff --git a/sound/pci/hda/hda_i915.h b/sound/pci/hda/hda_i915.h
new file mode 100644
index 000..4b89dfc
--- /dev/null
+++ b/sound/pci/hda/hda_i915.h
@@ -0,0 +1,35 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
Re: [Intel-gfx] [PATCH 0/2 V3] Power-well API implementation for Haswell
Hi Daniel, Do you have further comments on this patchset? thanks --xingchao -Original Message- From: Wang Xingchao [mailto:xingchao.w...@linux.intel.com] Sent: Thursday, May 16, 2013 3:53 PM To: ti...@suse.de; dan...@ffwll.ch; Girdwood, Liam R Cc: david.hennings...@canonical.com; Lin, Mengdong; Li, Jocelyn; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Barnes, Jesse; Zanoni, Paulo R; Wang, Xingchao; Wang Xingchao Subject: [PATCH 0/2 V3] Power-well API implementation for Haswell Hi all, This is V3 and some fixes after Takashi's review. change between V2--V3: - make SND_HDA_I915 selectable - use snd_printdd to output message - add return error code check - use symbol_request to replace symbol_get - release power_well at azx_free - some typo fixes changes between V1--V2: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Wang Xingchao (2): drm/915: Add private api for power well usage ALSA: hda - Add power-welll support for haswell HDA drivers/gpu/drm/i915/intel_pm.c | 76 +++ include/drm/i915_powerwell.h| 36 +++ sound/pci/hda/Kconfig | 10 ++ sound/pci/hda/Makefile |3 ++ sound/pci/hda/hda_i915.c| 75 ++ sound/pci/hda/hda_i915.h| 35 ++ sound/pci/hda/hda_intel.c | 41 +++-- 7 files changed, 262 insertions(+), 10 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 1/2] drm/915: Add private api for power well usage
Hi Takashi,
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 14, 2013 8:32 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; alsa-de...@alsa-project.org; Zanoni,
Paulo R; Li, Jocelyn; Lin, Mengdong; intel-gfx@lists.freedesktop.org; Wang,
Xingchao; Barnes, Jesse; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [PATCH 1/2] drm/915: Add private api for power well
usage
At Tue, 14 May 2013 19:44:18 +0800,
Wang Xingchao wrote:
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell mobile
C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 76
+++
include/drm/i915_powerwell.h| 36 +++
2 files changed, 105 insertions(+), 7 deletions(-) create mode
100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c index 0f4b46e..cf7e352 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4344,18 +4344,12 @@ bool intel_using_power_well(struct drm_device
*dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void enable_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE; @@ -4378,6
+4372,74 @@
void intel_set_power_well(struct drm_device *dev, bool enable)
}
}
+/* Global drm_device for display audio drvier usage */ static struct
+drm_device *power_well_device;
+/* Lock protecting power well setting */ static
+DEFINE_SPINLOCK(powerwell_lock); static bool i915_power_well_using;
+static int hsw_power_count;
+
+void i915_request_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ if (!hsw_power_count++) {
+ enable_power_well(power_well_device, true);
+ }
Should be
if (!hsw_power_count++ !i915_power_well_using)
enable_power_well(power_well_device, true);
Fixed.
Thanks
--xingchao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] ALSA: hda - Add power-welll support for haswell HDA
Hi Takashi,
Thanks your quick feedback, please see my comments below.
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Tuesday, May 14, 2013 8:15 PM
To: Wang Xingchao
Cc: dan...@ffwll.ch; Girdwood, Liam R; david.hennings...@canonical.com; Lin,
Mengdong; Li, Jocelyn; alsa-de...@alsa-project.org;
intel-gfx@lists.freedesktop.org; Barnes, Jesse; Zanoni, Paulo R; Wang,
Xingchao
Subject: Re: [PATCH 2/2] ALSA: hda - Add power-welll support for haswell HDA
At Tue, 14 May 2013 19:44:19 +0800,
Wang Xingchao wrote:
For Intel Haswell chip, HDA controller and codec have power well
dependency from GPU side. This patch added support to request/release
power well in audio driver. Power save feature should be enabled to
get runtime power saving.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/Kconfig |8
sound/pci/hda/Makefile|3 ++
sound/pci/hda/hda_i915.c | 92
+
sound/pci/hda/hda_i915.h | 35 +
sound/pci/hda/hda_intel.c | 33 ++--
5 files changed, 168 insertions(+), 3 deletions(-) create mode
100644 sound/pci/hda/hda_i915.c create mode 100644
sound/pci/hda/hda_i915.h
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig index
80a7d44..d9e71e4 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -152,6 +152,14 @@ config SND_HDA_CODEC_HDMI
snd-hda-codec-hdmi.
This module is automatically loaded at probing.
+config SND_HDA_I915
+ bool Build Display HD-audio controller/codec power well support for
i915
cards
+ depends on DRM_I915
+ default y
+ help
+ Say Y here to include full HDMI and DisplayPort HD-audio
controller/codec
+ support for Intel Haswell graphics cards based on the i915 driver.
Do we need to make this selectable?
If you have i915 driver, this can be always set.
Well, for Non-Haswell chips with SND_HDA_I915 compiled in, it do nothing as it
has no AZX_DCAPS_I915_POWERWELL set, so no power-well API called.
For Haswell chips, SND_HDA_I915 must be enabled otherwise display audio would
fail. Anyway I added a note message in the choice to let
user know this option is a *must* one for Haswell chips.
config SND_HDA_CODEC_CIRRUS
bool Build Cirrus Logic codec support
default y
diff --git a/sound/pci/hda/Makefile b/sound/pci/hda/Makefile index
24a2514..4b0a4bc 100644
--- a/sound/pci/hda/Makefile
+++ b/sound/pci/hda/Makefile
@@ -6,6 +6,9 @@ snd-hda-codec-$(CONFIG_PROC_FS) += hda_proc.o
snd-hda-codec-$(CONFIG_SND_HDA_HWDEP) += hda_hwdep.o
snd-hda-codec-$(CONFIG_SND_HDA_INPUT_BEEP) += hda_beep.o
+# for haswell power well
+snd-hda-intel-$(CONFIG_SND_HDA_I915) +=hda_i915.o
+
# for trace-points
CFLAGS_hda_codec.o := -I$(src)
CFLAGS_hda_intel.o := -I$(src)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c new
file mode 100644 index 000..96ca9e7
--- /dev/null
+++ b/sound/pci/hda/hda_i915.c
@@ -0,0 +1,92 @@
+/*
+ * hda_i915.c - routines for Haswell HDA controller power well
+support
+ *
+ * This program is free software; you can redistribute it and/or
+modify it
+ * under the terms of the GNU General Public License as published by
+the Free
+ * Software Foundation; either version 2 of the License, or (at your
+option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include sound/core.h
+#include drm/i915_powerwell.h
+#include hda_i915.h
+
+static const char *module_name = i915; static struct module *i915;
+static void (*get_power)(void); static void (*put_power)(void);
+
+void hda_display_power(bool enable)
+{
+ if (!get_power || !put_power)
+ return;
+
+ snd_printk(KERN_DEBUG HDA display power %s \n,
+ enable ? Enable : Disable);
Use snd_printdd() for such a frequent debug message.
We don't want to see this message at each time you open/close the audio
stream.
Fixed.
+ if (enable)
+ get_power();
+ else
+ put_power();
+}
+
+/* in case i915 not loaded, try load i915 first */ static int
+load_i915(void) {
+ int err;
+ mutex_lock(module_mutex);
+ i915 = find_module(module_name);
+ mutex_unlock(module_mutex);
+
+ if (!i915) {
+ err = request_module
[Intel-gfx] [PATCH 0/2 V2] Power-well API implementation for Haswell
Hi all, This is V2 and some fixes after first round review: - use reference count to track power-well usage - remove external module, compiled into snd-hda-intel instead - manage symbols and module loading properly - remove IS_HSW macro, use flag instead - remove audio callback for gfx driver to avoid dependency - split whole patch into two pieces for easy review - more typo fixes Wang Xingchao (2): drm/915: Add private api for power well usage ALSA: hda - Add power-welll support for haswell HDA drivers/gpu/drm/i915/intel_pm.c | 76 +--- include/drm/i915_powerwell.h| 36 +++ sound/pci/hda/Kconfig |8 sound/pci/hda/Makefile |3 ++ sound/pci/hda/hda_i915.c| 92 +++ sound/pci/hda/hda_i915.h| 35 +++ sound/pci/hda/hda_intel.c | 33 -- 7 files changed, 273 insertions(+), 10 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/915: Add private api for power well usage
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell mobile
C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 76 +++
include/drm/i915_powerwell.h| 36 +++
2 files changed, 105 insertions(+), 7 deletions(-)
create mode 100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f4b46e..cf7e352 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4344,18 +4344,12 @@ bool intel_using_power_well(struct drm_device *dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+static void enable_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE;
@@ -4378,6 +4372,74 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
}
}
+/* Global drm_device for display audio drvier usage */
+static struct drm_device *power_well_device;
+/* Lock protecting power well setting */
+static DEFINE_SPINLOCK(powerwell_lock);
+static bool i915_power_well_using;
+static int hsw_power_count;
+
+void i915_request_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ if (!hsw_power_count++) {
+ enable_power_well(power_well_device, true);
+ }
+ spin_unlock_irq(powerwell_lock);
+}
+EXPORT_SYMBOL_GPL(i915_request_power_well);
+
+void i915_release_power_well(void)
+{
+ if (!power_well_device)
+ return;
+
+ if (!IS_HASWELL(power_well_device))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ WARN_ON(!hsw_power_count);
+ if (!--hsw_power_count
+!i915_power_well_using)
+ enable_power_well(power_well_device, false);
+ spin_unlock_irq(powerwell_lock);
+}
+EXPORT_SYMBOL_GPL(i915_release_power_well);
+
+/* TODO: Call this when i915 module unload */
+void i915_remove_power_well(void)
+{
+ i915_power_well_using = false;
+ power_well_device = NULL;
+}
+
+void intel_set_power_well(struct drm_device *dev, bool enable)
+{
+ if (!HAS_POWER_WELL(dev))
+ return;
+
+ power_well_device = dev;
+ spin_lock_irq(powerwell_lock);
+ i915_power_well_using = enable;
+ if (!enable hsw_power_count) {
+ DRM_DEBUG_KMS(Display audio power well busy using now\n);
+ goto out;
+ }
+
+ if (!i915_disable_power_well !enable)
+ goto out;
+
+ enable_power_well(dev, enable);
+out:
+ spin_unlock_irq(powerwell_lock);
+}
+
/*
* Starting with Haswell, we have a Power Down Well that can be turned off
* when not needed anymore. We have 4 registers that can request the power well
diff --git a/include/drm/i915_powerwell.h b/include/drm/i915_powerwell.h
new file mode 100644
index 000..cfdc884
--- /dev/null
+++ b/include/drm/i915_powerwell.h
@@ -0,0 +1,36 @@
+/**
+ *
+ * Copyright 2013 Intel Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS
[Intel-gfx] [PATCH 3/5] ALSA: hda - Power well request/release for hda controller
Display HDA need reqeust power well in case it's shut down by gfx.
Currently hda is the only user in audio side, even though the codecs
depends on same power well too, it's safe to share the same power well
with hda controller. If gfx power well could shut down only for codecs,
it can be added as another new user hdmi-codec.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c |2 +-
sound/pci/hda/hda_intel.c | 18 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index 7e8ddaa..00def82 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -25,7 +25,7 @@
/* Power well has impact on Haswell controller and codecs */
void hda_display_power(bool enable)
{
- snd_printk(KERN_INFO HDA display power %d \n, enable);
+ snd_printk(KERN_INFO HDA display power %s \n, enable ? Enable :
Disable);
if (enable)
i915_request_power_well(hda);
else
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 418bfc0..8bb6075 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -62,6 +62,7 @@
#include linux/vga_switcheroo.h
#include linux/firmware.h
#include hda_codec.h
+#include hda_i915.h
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
@@ -675,6 +676,10 @@ static char *driver_short_names[] = {
#define azx_sd_readb(dev,reg) \
readb((dev)-sd_addr + ICH6_REG_##reg)
+#define IS_HSW(pci)((pci)-device == 0x0a0c || \
+(pci)-device == 0x0c0c || \
+(pci)-device == 0x0d0c)
+
/* for pcm support */
#define get_azx_dev(substream) (substream-runtime-private_data)
@@ -2869,6 +2874,8 @@ static int azx_suspend(struct device *dev)
pci_disable_device(pci);
pci_save_state(pci);
pci_set_power_state(pci, PCI_D3hot);
+ if (IS_HSW(pci))
+ hda_display_power(false);
return 0;
}
@@ -2881,6 +2888,8 @@ static int azx_resume(struct device *dev)
if (chip-disabled)
return 0;
+ if (IS_HSW(pci))
+ hda_display_power(true);
pci_set_power_state(pci, PCI_D0);
pci_restore_state(pci);
if (pci_enable_device(pci) 0) {
@@ -2913,6 +2922,8 @@ static int azx_runtime_suspend(struct device *dev)
azx_stop_chip(chip);
azx_clear_irq_pending(chip);
+ if (IS_HSW(to_pci_dev(dev)))
+ hda_display_power(false);
return 0;
}
@@ -2921,6 +2932,8 @@ static int azx_runtime_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card-private_data;
+ if (IS_HSW(to_pci_dev(dev)))
+ hda_display_power(true);
azx_init_pci(chip);
azx_init_chip(chip, 1);
return 0;
@@ -3671,6 +3684,9 @@ static int azx_probe(struct pci_dev *pci,
return -ENOENT;
}
+ if (IS_HSW(pci))
+ hda_display_power(true);
+
err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, card);
if (err 0) {
snd_printk(KERN_ERR hda-intel: Error creating card!\n);
@@ -3806,6 +3822,8 @@ static void azx_remove(struct pci_dev *pci)
if (card)
snd_card_free(card);
pci_set_drvdata(pci, NULL);
+ if (IS_HSW(pci))
+ hda_display_power(false);
}
/* PCI IDs */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] ALSA: hda - Fix module dependency with gfx i915
hda_i915 has dependency on i915 module, this patch check whether
symbol exist before calling API there. If i915 module not loaded it
will try to load before use.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
sound/pci/hda/hda_i915.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index 00def82..edf1a08 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -22,16 +22,54 @@
#include drm/i915_powerwell.h
#include hda_i915.h
+const char *name = i915;
+static void (*get_power)(const char *name);
+static void (*put_power)(const char *name);
+
/* Power well has impact on Haswell controller and codecs */
void hda_display_power(bool enable)
{
snd_printk(KERN_INFO HDA display power %s \n, enable ? Enable :
Disable);
+
+ if (!get_power || !put_power)
+ return;
+
if (enable)
- i915_request_power_well(hda);
+ get_power(hda);
else
- i915_release_power_well(hda);
+ put_power(hda);
}
EXPORT_SYMBOL(hda_display_power);
+static int __init hda_i915_init(void)
+{
+ struct module *i915;
+ mutex_lock(module_mutex);
+ i915 = find_module(name);
+ mutex_unlock(module_mutex);
+
+ if (!i915)
+ request_module_nowait(name);
+
+ if (!try_module_get(i915))
+ return -EFAULT;
+
+ get_power = symbol_get(i915_request_power_well);
+ put_power = symbol_get(i915_release_power_well);
+
+ module_put(i915);
+ return 0;
+}
+
+#if 0
+static void __exit hda_i915_exit(void)
+{
+ drm_pci_exit(driver, i915_pci_driver);
+}
+
+module_init(hda_i915_init);
+module_exit(hda_i915_exit);
+#endif
+module_init(hda_i915_init);
MODULE_DESCRIPTION(HDA power well);
MODULE_LICENSE(GPL);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] ALSA/i915: Check power well API existense before calling
I915 module maybe loaded after snd_hda_intel, the power-well
API doesnot exist in such case. This patch intended to avoid
loading dependency between snd-hda-intel and i915 module.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c |3 ++
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 12 +++
include/drm/i915_powerwell.h |1 +
sound/pci/hda/hda_i915.c | 69 --
sound/pci/hda/hda_i915.h |5 +++
sound/pci/hda/hda_intel.c|8 +++--
7 files changed, 72 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a1648eb..307ca4b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1671,6 +1671,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (IS_GEN5(dev))
intel_gpu_ips_init(dev_priv);
+ if (IS_HASWELL(dev))
+ intel_gpu_audio_init();
+
return 0;
out_gem_unload:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dfcf546..f159f12 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -758,6 +758,8 @@ extern void intel_update_fbc(struct drm_device *dev);
/* IPS */
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+/* Display audio */
+extern void intel_gpu_audio_init(void);
extern bool intel_using_power_well(struct drm_device *dev);
extern void intel_init_power_well(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 642c4b6..8c1df21 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -29,6 +29,7 @@
#include i915_drv.h
#include intel_drv.h
#include ../../../platform/x86/intel_ips.h
+#include ../../../../sound/pci/hda/hda_i915.h
#include linux/module.h
#define FORCEWAKE_ACK_TIMEOUT_MS 2
@@ -4393,6 +4394,17 @@ struct i915_power_well_user {
struct list_head list;
};
+void intel_gpu_audio_init(void)
+{
+ void (*link)(void);
+
+ link = symbol_get(audio_link_to_i915_driver);
+ if (link) {
+ link();
+ symbol_put(audio_link_to_i915_driver);
+ }
+}
+
void i915_request_power_well(const char *name)
{
struct i915_power_well_user *user;
diff --git a/include/drm/i915_powerwell.h b/include/drm/i915_powerwell.h
index 87e0a2e..de03dc8 100644
--- a/include/drm/i915_powerwell.h
+++ b/include/drm/i915_powerwell.h
@@ -33,6 +33,7 @@
#ifndef _I915_POWERWELL_H_
#define _I915_POWERWELL_H_
+/* For use by hda_i915 driver */
extern void i915_request_power_well(const char *name);
extern void i915_release_power_well(const char *name);
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index edf1a08..d11f255 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -22,54 +22,71 @@
#include drm/i915_powerwell.h
#include hda_i915.h
-const char *name = i915;
-static void (*get_power)(const char *name);
-static void (*put_power)(const char *name);
+char *module_name = i915;
+void (*get_power)(const char *);
+void (*put_power)(const char *);
+static bool hsw_i915_load;
+
+void audio_link_to_i915_driver(void)
+{
+ /* it's time to try getting the symbols again.*/
+ hsw_i915_load = true;
+}
+EXPORT_SYMBOL_GPL(audio_link_to_i915_driver);
/* Power well has impact on Haswell controller and codecs */
void hda_display_power(bool enable)
{
- snd_printk(KERN_INFO HDA display power %s \n, enable ? Enable :
Disable);
-
- if (!get_power || !put_power)
- return;
+ if (!get_power || !put_power) {
+ if (hsw_i915_load) {
+ get_power = i915_request_power_well;
+ put_power = i915_release_power_well;
+ } else
+ return;
+ }
+ snd_printk(KERN_DEBUG HDA display power %s \n,
+ enable ? Enable : Disable);
if (enable)
get_power(hda);
else
put_power(hda);
}
-EXPORT_SYMBOL(hda_display_power);
+EXPORT_SYMBOL_GPL(hda_display_power);
-static int __init hda_i915_init(void)
+/* In case i915 module loaded first, the APIs are there.
+ * Otherwise wait until i915 module notify us. */
+int hda_i915_init(void)
{
- struct module *i915;
- mutex_lock(module_mutex);
- i915 = find_module(name);
- mutex_unlock(module_mutex);
+ struct module *i915;
- if (!i915)
- request_module_nowait(name);
+ mutex_lock(module_mutex);
+ i915 = find_module(module_name);
+ mutex_unlock(module_mutex);
- if (!try_module_get(i915))
- return -EFAULT;
+ if (!i915)
+ request_module_nowait(module_name
Re: [Intel-gfx] [alsa-devel] [PATCH 5/5] ALSA/i915: Check power well API existense before calling
Hi David,
-Original Message-
From: alsa-devel-boun...@alsa-project.org
[mailto:alsa-devel-boun...@alsa-project.org] On Behalf Of David Henningsson
Sent: Monday, May 13, 2013 4:29 PM
To: Wang Xingchao
Cc: alsa-de...@alsa-project.org; dan...@ffwll.ch; ti...@suse.de; Lin,
Mengdong; intel-gfx@lists.freedesktop.org; Li, Jocelyn; Barnes, Jesse;
Girdwood, Liam R; Zanoni, Paulo R
Subject: Re: [alsa-devel] [PATCH 5/5] ALSA/i915: Check power well API
existense before calling
On 05/13/2013 09:37 AM, Wang Xingchao wrote:
I915 module maybe loaded after snd_hda_intel, the power-well API
doesnot exist in such case. This patch intended to avoid loading
dependency between snd-hda-intel and i915 module.
Hi Xingchao and thanks for working on this.
This patch seems to re-do some of the work done in other patches (a lot of
lines
removed), so it's a little hard to follow. But I'll try to write some overall
comments on how I have envisioned things...
1. I don't think there's any need to create an additional kernel module, we
can
just let hda_i915.c be in the snd-hda-intel.ko module, and only compile it if
DRM_I915 is defined.
2. We don't need an IS_HSW macro on the audio side. Instead declare a new
AZX_DCAPS_NEED_I915_POWER (or similar) driver quirk.
3. Somewhere in the beginning of the probing in hda_intel.c, we'll need
something like:
if (driver_caps AZX_DCAPS_NEED_I915_POWER)
hda_i915_init(chip);
4. The hda_i915_init does not need to be exported (they're now both in the
same module). hda_i915.h could have something like:
#ifdef DRM_I915
void hda_i915_init(chip);
#else
#define hda_i915_init(chip) do {} while(0) #endif
Thanks your suggestions. Will change them in next version.
5. You're saying this patch is about avoid loading dependency between
snd-hda-intel and i915 module. That does not make sense to me, since the
powerwell API is in the i915 module, snd-hda-intel must load it when it wants
to
enable power on haswell, right? Thus there is a loading dependency. If the
i915
module is not loaded at that point, we must wait for it to load, so we can
have
proper power, instead of continuing probing without the power well?
If i915 module not loaded, snd-had-intel will load it in current code.
The question is the tolerant delay of waiting for i915 loading.
Continuing probing would immediately fail.
Thanks
--xingchao
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c |3 ++
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 12 +++
include/drm/i915_powerwell.h |1 +
sound/pci/hda/hda_i915.c | 69
--
sound/pci/hda/hda_i915.h |5 +++
sound/pci/hda/hda_intel.c|8 +++--
7 files changed, 72 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index a1648eb..307ca4b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1671,6 +1671,9 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
if (IS_GEN5(dev))
intel_gpu_ips_init(dev_priv);
+ if (IS_HASWELL(dev))
+ intel_gpu_audio_init();
+
return 0;
out_gem_unload:
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index dfcf546..f159f12 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -758,6 +758,8 @@ extern void intel_update_fbc(struct drm_device
*dev);
/* IPS */
extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
extern void intel_gpu_ips_teardown(void);
+/* Display audio */
+extern void intel_gpu_audio_init(void);
extern bool intel_using_power_well(struct drm_device *dev);
extern void intel_init_power_well(struct drm_device *dev); diff
--git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c index 642c4b6..8c1df21 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -29,6 +29,7 @@
#include i915_drv.h
#include intel_drv.h
#include ../../../platform/x86/intel_ips.h
+#include ../../../../sound/pci/hda/hda_i915.h
#include linux/module.h
#define FORCEWAKE_ACK_TIMEOUT_MS 2
@@ -4393,6 +4394,17 @@ struct i915_power_well_user {
struct list_head list;
};
+void intel_gpu_audio_init(void)
+{
+ void (*link)(void);
+
+ link = symbol_get(audio_link_to_i915_driver);
+ if (link) {
+ link();
+ symbol_put(audio_link_to_i915_driver);
+ }
+}
+
void i915_request_power_well(const char *name)
{
struct i915_power_well_user *user;
diff --git a/include/drm/i915_powerwell.h
b/include/drm/i915_powerwell.h index 87e0a2e..de03dc8 100644
--- a/include/drm/i915_powerwell.h
+++ b
Re: [Intel-gfx] [alsa-devel] [PATCH 5/5] ALSA/i915: Check power well API existense before calling
Hi Jaroslav,
-Original Message-
From: alsa-devel-boun...@alsa-project.org
[mailto:alsa-devel-boun...@alsa-project.org] On Behalf Of Jaroslav Kysela
Sent: Monday, May 13, 2013 4:56 PM
To: David Henningsson
Cc: alsa-de...@alsa-project.org; Girdwood, Liam R; ti...@suse.de; Lin,
Mengdong; intel-gfx@lists.freedesktop.org; Wang Xingchao; Li, Jocelyn;
Barnes, Jesse; dan...@ffwll.ch; Zanoni, Paulo R
Subject: Re: [alsa-devel] [PATCH 5/5] ALSA/i915: Check power well API
existense before calling
Date 13.5.2013 10:28, David Henningsson wrote:
On 05/13/2013 09:37 AM, Wang Xingchao wrote:
I915 module maybe loaded after snd_hda_intel, the power-well API
doesnot exist in such case. This patch intended to avoid loading
dependency between snd-hda-intel and i915 module.
Hi Xingchao and thanks for working on this.
This patch seems to re-do some of the work done in other patches (a
lot of lines removed), so it's a little hard to follow. But I'll try
to write some overall comments on how I have envisioned things...
1. I don't think there's any need to create an additional kernel
module, we can just let hda_i915.c be in the snd-hda-intel.ko module,
and only compile it if DRM_I915 is defined.
2. We don't need an IS_HSW macro on the audio side. Instead declare a
new AZX_DCAPS_NEED_I915_POWER (or similar) driver quirk.
3. Somewhere in the beginning of the probing in hda_intel.c, we'll
need something like:
if (driver_caps AZX_DCAPS_NEED_I915_POWER)
hda_i915_init(chip);
4. The hda_i915_init does not need to be exported (they're now both in
the same module). hda_i915.h could have something like:
#ifdef DRM_I915
void hda_i915_init(chip);
#else
#define hda_i915_init(chip) do {} while(0) #endif
5. You're saying this patch is about avoid loading dependency between
snd-hda-intel and i915 module. That does not make sense to me, since
the powerwell API is in the i915 module, snd-hda-intel must load it
when it wants to enable power on haswell, right? Thus there is a
loading dependency. If the i915 module is not loaded at that point, we
must wait for it to load, so we can have proper power, instead of
continuing probing without the power well?
Looking to the code, if the drm code requires a callback to the audio code, I
would just register it in the audio driver init phase and unregister it when
snd-hda-intel is unloaded. This cross module loading dependency looks really
bad. Or it is not allowed to load the audio driver later than DRM one?
I think the dependency here is not real. In case the i915 loaded first, the
callback
doesnot exist and do nothing, it's safe. In case snd-hda-intel loaded first,
and need
pause there to wait i915 module loading, this callback is helpful to notify
snd-hda-intel
the proper time to check symbol again.
Thanks
--xingchao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/3] drm/915: Add private api for power well usage
Hi Takashi, -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Friday, May 10, 2013 1:18 AM To: Daniel Vetter Cc: Wang, Xingchao; david.hennings...@canonical.com; Girdwood, Liam R; Barnes, Jesse; Li, Jocelyn; Lin, Mengdong; Zanoni, Paulo R; Wang Xingchao; intel-gfx; alsa-de...@alsa-project.org Subject: Re: [RFC PATCH 1/3] drm/915: Add private api for power well usage At Thu, 9 May 2013 11:23:21 +0200, Daniel Vetter wrote: 2. On a quick read of the hda driver stuff I don't think the power well enable/disable places are at the right spot: We force the power well on whenever the hda codec is used, but we must only do that when we want to output audio to external screens. And since that state transition can only really happen due to a modeset change on the gfx side I don't think we need any autosuspend delays either. The use-case I'm thinking of is media playback with just the panel enabled: In that case we can switch off the power well on the display side, and I don't think the power well is required for audio play back on the integrated speakerrs/headphone-jack either. Well, in the case of Haswell, the audio controller/codec is dedicated to only HDMI audio, and in the audio driver level, the power saving of each codec/controller chip is managed individually. So, it's not that bad to handle power well on/off at that point. A sane power-conscious OS would open/close the audio device file in a fine grained way. 3. The moduel depencies seem to still not work out dynamically, at least I think we still have a hard chain between hda-intel and i915.ko (just with one thing in between now). True. The question is in which level we need power_well_*() controls. If the initialization of HD-audio controller (e.g. PCI registers) requires the power well on, hda_intel.c requires the calls, as this patch does. OTOH, if it's only about the HD-audio verbs, basically we can push the power well calls into the codec driver, i.e. patch_hdmi.c. In the latter case, as David once suggested, we can split the Haswell codec driver from patch_hdmi.c so that only the new driver depends on i915. The power well has impact on both HD-Audio controller and hdmi codec, they share the same power well. In the initial version patch, both controller and codecs would request power-well, but for hdmi-codec is unnecessary as HD-audio controller must have power already, otherwise it's crashed, so I removed that, only HD-audio controller request power-well on demand. That's why there's some changes based on David's patch. Thanks --xingchao thanks, Takashi Cheers, Daniel On Thu, May 9, 2013 at 9:23 AM, Wang, Xingchao xingchao.w...@intel.com wrote: Hi All, This is a newer version patchset for power well feature implementation. I will send out a document later to describe the design, especially for David and Takashi as they could not see Bspec so it maybe a bit confuse. Meanwhile Liam will send out a meeting request for discussion, welcome Daniel, Paulo, Jesse to join us. Basically, here's the latest working status on my side: I tested the power well feature on Haswell ULT board, there's only one eDP port used. Without this patch and we enabled power well feature, gfx driver will shutdown power well, audio driver will crash. Applied this patch, display audio driver will request power well on before initialize the card. In gfx side, it will enable power well. Also power_save feature in audio side should be enabled, I set 5 second to let codec enter suspend when free for 5s long. Audio controller driver detects all codecs are suspended it will release power well and suspend too. Gfx driver will receive the request and shut down power well. If user trigger some audio operations(cat codec# info), audio controller driver will request power well again... If gfx side decided to disable power well now, while audio is in use, power well would be kept on. Generally audio drvier will request power well on need and release it immediately after suspend. Gfx should make decision at his side. The new introduced module hda-i915 has dependency on i915, only built in when i915 enabled. So it's safe for call. This module was based on David's original patch, which added pm_suspend/resume callback for hdmi codec. As the codecs and controller are both depending on powerwell, and codec *must* already on power so I moved the power well request/release to controller side and changed the module name to hda-i915. David, would you like me to add you as author for the second patch? :) For non-Haswell platform, power well is no need atm. If the module is built in and gfx will reject power well request at its side, so it's safe too. thanks --xingchao -Original Message- From: Wang Xingchao [mailto:xingchao.w
Re: [Intel-gfx] [RFC PATCH 1/3] drm/915: Add private api for power well usage
Hi Jesse, -Original Message- From: Barnes, Jesse Sent: Friday, May 10, 2013 2:30 AM To: Takashi Iwai Cc: Daniel Vetter; Wang, Xingchao; david.hennings...@canonical.com; Girdwood, Liam R; Li, Jocelyn; Lin, Mengdong; Zanoni, Paulo R; Wang Xingchao; intel-gfx; alsa-de...@alsa-project.org Subject: Re: [RFC PATCH 1/3] drm/915: Add private api for power well usage On Thu, 9 May 2013 19:17:36 +0200 Takashi Iwai ti...@suse.de wrote: At Thu, 9 May 2013 11:23:21 +0200, Daniel Vetter wrote: 2. On a quick read of the hda driver stuff I don't think the power well enable/disable places are at the right spot: We force the power well on whenever the hda codec is used, but we must only do that when we want to output audio to external screens. And since that state transition can only really happen due to a modeset change on the gfx side I don't think we need any autosuspend delays either. The use-case I'm thinking of is media playback with just the panel enabled: In that case we can switch off the power well on the display side, and I don't think the power well is required for audio play back on the integrated speakerrs/headphone-jack either. Well, in the case of Haswell, the audio controller/codec is dedicated to only HDMI audio, and in the audio driver level, the power saving of each codec/controller chip is managed individually. So, it's not that bad to handle power well on/off at that point. A sane power-conscious OS would open/close the audio device file in a fine grained way. So hda_intel and the azx_suspend/resume functions will only be called for HDMI audio on HSW? If so, then I guess this patch has the calls in the right places. Well not, hda_intel and azx_suspend/resume is more generic call. But it has no impact for non-HSW platform. Since power-well requirement must be done at very early stage for HD-audio controller, so it happened at very high level. For non-HSW platform, the external module should no built in at first. Given it could call into gfx side, no power-well change happen there. If it's going to force the power well on for non-HDMI audio, then I think we'll need some additional changes. For non-HDMI audio, it's in non HSW HD-Audio controller, so it should be safe. So the patchset intend to work only for Haswell HD-audio controller and codecs. 3. The moduel depencies seem to still not work out dynamically, at least I think we still have a hard chain between hda-intel and i915.ko (just with one thing in between now). True. The question is in which level we need power_well_*() controls. If the initialization of HD-audio controller (e.g. PCI registers) requires the power well on, hda_intel.c requires the calls, as this patch does. OTOH, if it's only about the HD-audio verbs, basically we can push the power well calls into the codec driver, i.e. patch_hdmi.c. In the latter case, as David once suggested, we can split the Haswell codec driver from patch_hdmi.c so that only the new driver depends on i915. I think it's needed for the HDMI related MMIO regs as well, but I don't have a platform to test and make sure. That's true. The probing sound card would fail if there's no power-well enabled, we say in such case: Boot up with no hdmi cable connected -- gfx disable power-well -- haswell audio probe fail. Thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/3] drm/915: Add private api for power well usage
Hi Daniel, -Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, May 09, 2013 5:23 PM To: Wang, Xingchao Cc: david.hennings...@canonical.com; Girdwood, Liam R; ti...@suse.de; Barnes, Jesse; Li, Jocelyn; Lin, Mengdong; Zanoni, Paulo R; Wang Xingchao; intel-gfx; alsa-de...@alsa-project.org Subject: Re: [RFC PATCH 1/3] drm/915: Add private api for power well usage Hi all, Three things: 1. Any reason public mailing lists (intel-gfx, alsa-devel) aren't cc'ed? Afaics no secret stuff is being discussed here ... Please resend the patches with mailings lists cc'ed. Sorry the document has some confidential info from Bspec, but e patch itself is okay for public review. I will resend the patchset at first. thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
Hi David, Thank you very much for your draft patch. I have some more work on a new patchset, some ideas are from your patch. Here's a brief introduction of attached patchset: 1. a new bus type in /sound/had_bus.c, used to bind the single module and codec device It looks like ac97_bus.c 2. add a new device node in struct hda_codec, it's used to register for new bus type. 3. a new single module hdmi_i915, which compiled in only when DRM_I915 and CODEC_HDMI enabled. It stores the private API for gfx part. There's no support to probe haswell hdmi codec only yet. Power well will be used only for haswell display audio. 4. power well API implementation in gfx side. Please feel free to add your idea and I will help test your patch too. Thanks --xingchao -Original Message- From: David Henningsson [mailto:david.hennings...@canonical.com] Sent: Thursday, May 02, 2013 10:49 PM To: Liam Girdwood Cc: Barnes, Jesse; alsa-de...@alsa-project.org; Zanoni, Paulo R; Takashi Iwai; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wysocki, Rafael J; Wang Xingchao; Wang, Xingchao; Li, Jocelyn; Hindman, Gavin; Daniel Vetter; Lin, Mengdong; ville.syrj...@linux.intel.com Subject: Re: [alsa-devel] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team On 04/30/2013 04:41 PM, Liam Girdwood wrote: On Tue, 2013-04-30 at 12:29 +0200, David Henningsson wrote: On 04/29/2013 05:02 PM, Jesse Barnes wrote: On Sat, 27 Apr 2013 13:35:29 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sat, Apr 27, 2013 at 09:20:39AM +, Wang, Xingchao wrote: Let me throw a basic proposal on Audio driver side, please give your comments freely. it contains the power well control usage points: #1: audio request power well at boot up. I915 may shut down power well after bootup initialization, as there's no monitor connected outside or only eDP on pipe A. #2: audio request power on resume After exit from D3 mode, audio driver quest power on. This may happen at normal resume or runtime resume. #3: audio release power well control at suspend Audio driver will let i915 know it doensot need power well anymore as it's going to suspend. This may happened at normal suspend or runtime suspend point. #4: audio release power well when module unload Audio release power well at remove callback to let i915 know. I miss the power well grab/dropping at runtime from the audio side. If the audio driver forces the power well to be on the entire time it's loaded, that's not good, since the power well stuff is very much for runtime PM. We _must_ be able to switch off the power well whenever possible. Xingchao, I'm not an audio developer so I'm probably way off. But what we really need is a very small and targeted set of calls into the i915 driver from say the HDMI driver in HDA. It looks like the prepare/cleanup pair in the pcm_ops structure might be the right place to put things? If that's too fine grained, you could do it at open/close time I guess, but the danger there is that some app will keep the device open even while it's not playing. If that won't work, maybe calling i915 from hda_power_work in the higher level code would be better? For detecting whether to call i915 at all, you can filter on the PCI IDs (just look for an Intel graphics device and if present, try to get the i915 symbols for the power functions). --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3860,6 +3860,8 @@ static unsigned int hda_call_codec_suspend(struct hda_code codec-patch_ops.suspend(codec); hda_cleanup_all_streams(codec); state = hda_set_power_state(codec, AC_PWRST_D3); + if (i915_shared_power_well) + i915_put_power_well(codec-i915_data); /* Cancel delayed work if we aren't currently running from it. */ if (!in_wq) cancel_delayed_work_sync(codec-power_work); @@ -4807,6 +4809,9 @@ static void __snd_hda_power_up(struct hda_codec *codec, bo return; spin_unlock(codec-power_lock); + if (i915_shared_power_well) + i915_get_power_well(codec-i915_data); Is it wise that a _get function actually has side effects? Perhaps _push and _pop or something else would be better semantics. I think the intention here is to model on the PM runtime subsystem where we can get/put the reference count on a PM resource. I'd expect with this API that i915_get_power_well() will increment the count and prevent the shared PM resource from being powered OFF. Ok, I stand corrected. + cancel_delayed_work_sync(codec-power_work); spin_lock(codec-power_lock); With some code at init time to get the i915 symbols you need to call and whether or not the shared power well is present... Takashi, any other ideas
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
Hi Takashi, -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Friday, May 03, 2013 10:27 PM To: Barnes, Jesse Cc: Daniel Vetter; Wang, Xingchao; Li, Jocelyn; Daniel Vetter; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team At Mon, 29 Apr 2013 08:02:19 -0700, Jesse Barnes wrote: On Sat, 27 Apr 2013 13:35:29 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sat, Apr 27, 2013 at 09:20:39AM +, Wang, Xingchao wrote: Let me throw a basic proposal on Audio driver side, please give your comments freely. it contains the power well control usage points: #1: audio request power well at boot up. I915 may shut down power well after bootup initialization, as there's no monitor connected outside or only eDP on pipe A. #2: audio request power on resume After exit from D3 mode, audio driver quest power on. This may happen at normal resume or runtime resume. #3: audio release power well control at suspend Audio driver will let i915 know it doensot need power well anymore as it's going to suspend. This may happened at normal suspend or runtime suspend point. #4: audio release power well when module unload Audio release power well at remove callback to let i915 know. I miss the power well grab/dropping at runtime from the audio side. If the audio driver forces the power well to be on the entire time it's loaded, that's not good, since the power well stuff is very much for runtime PM. We _must_ be able to switch off the power well whenever possible. Xingchao, I'm not an audio developer so I'm probably way off. But what we really need is a very small and targeted set of calls into the i915 driver from say the HDMI driver in HDA. It looks like the prepare/cleanup pair in the pcm_ops structure might be the right place to put things? If that's too fine grained, you could do it at open/close time I guess, but the danger there is that some app will keep the device open even while it's not playing. Well, the question is what impact the power well on/off has against the audio. Do we need to resume the HD-audio controller / codec fully from the scratch? I guess not, but I have no certain idea. Both the display H-DA controller and codec are under control by power well. When the power well is off, for H-DA controller, the MMIO space is off, the PCI Registers are in on well. The codec could not access anymore. If the impact of the change (i.e. the procedure needed to resume) is small, somehow limited to the targeted converter/pin, it can be implemented in the prepare/cleanup callback of the codec driver, yes. Though, the easiest path would be to add i915_get/put_power_well() in the codec probe, suspend, resume, and free callbacks, as you pointed out below. Yes, and Jesse should get the background that, even power well is requested at probe, It will not take long time to waste power. The controller/codec will enter power save mode If runtime pm enabled. Thanks --xingchao If that won't work, maybe calling i915 from hda_power_work in the higher level code would be better? For detecting whether to call i915 at all, you can filter on the PCI IDs (just look for an Intel graphics device and if present, try to get the i915 symbols for the power functions). --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3860,6 +3860,8 @@ static unsigned int hda_call_codec_suspend(struct hda_code codec-patch_ops.suspend(codec); hda_cleanup_all_streams(codec); state = hda_set_power_state(codec, AC_PWRST_D3); + if (i915_shared_power_well) + i915_put_power_well(codec-i915_data); /* Cancel delayed work if we aren't currently running from it. */ if (!in_wq) cancel_delayed_work_sync(codec-power_work); @@ -4807,6 +4809,9 @@ static void __snd_hda_power_up(struct hda_codec *codec, bo return; spin_unlock(codec-power_lock); + if (i915_shared_power_well) + i915_get_power_well(codec-i915_data); + cancel_delayed_work_sync(codec-power_work); spin_lock(codec-power_lock); With some code at init time to get the i915 symbols you need to call and whether or not the shared power well is present... Takashi, any other ideas? The high level goal here should be for the audio driver to call into i915 with get/put power well around the sequences where it needs the power to be up (reading/writing registers, playing audio), but not across the whole time the driver is loaded, just like you already do with the powersave work functions
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
Hi Jesse, -Original Message- From: Barnes, Jesse Sent: Monday, April 29, 2013 11:02 PM To: Daniel Vetter Cc: Wang, Xingchao; Takashi Iwai; Li, Jocelyn; Daniel Vetter; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team On Sat, 27 Apr 2013 13:35:29 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sat, Apr 27, 2013 at 09:20:39AM +, Wang, Xingchao wrote: Let me throw a basic proposal on Audio driver side, please give your comments freely. it contains the power well control usage points: #1: audio request power well at boot up. I915 may shut down power well after bootup initialization, as there's no monitor connected outside or only eDP on pipe A. #2: audio request power on resume After exit from D3 mode, audio driver quest power on. This may happen at normal resume or runtime resume. #3: audio release power well control at suspend Audio driver will let i915 know it doensot need power well anymore as it's going to suspend. This may happened at normal suspend or runtime suspend point. #4: audio release power well when module unload Audio release power well at remove callback to let i915 know. I miss the power well grab/dropping at runtime from the audio side. If the audio driver forces the power well to be on the entire time it's loaded, that's not good, since the power well stuff is very much for runtime PM. We _must_ be able to switch off the power well whenever possible. Xingchao, I'm not an audio developer so I'm probably way off. But what we really need is a very small and targeted set of calls into the i915 driver from say the HDMI driver in HDA. It looks like the prepare/cleanup pair in the pcm_ops structure might be the right place to put things? If that's too fine grained, you could do it at open/close time I guess, but the danger there is that some app will keep the device open even while it's not playing. If that won't work, maybe calling i915 from hda_power_work in the higher level code would be better? For detecting whether to call i915 at all, you can filter on the PCI IDs (just look for an Intel graphics device and if present, try to get the i915 symbols for the power functions). --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3860,6 +3860,8 @@ static unsigned int hda_call_codec_suspend(struct hda_code codec-patch_ops.suspend(codec); hda_cleanup_all_streams(codec); state = hda_set_power_state(codec, AC_PWRST_D3); + if (i915_shared_power_well) + i915_put_power_well(codec-i915_data); /* Cancel delayed work if we aren't currently running from it. */ if (!in_wq) cancel_delayed_work_sync(codec-power_work); @@ -4807,6 +4809,9 @@ static void __snd_hda_power_up(struct hda_codec *codec, bo return; spin_unlock(codec-power_lock); + if (i915_shared_power_well) + i915_get_power_well(codec-i915_data); + cancel_delayed_work_sync(codec-power_work); spin_lock(codec-power_lock); With some code at init time to get the i915 symbols you need to call and whether or not the shared power well is present... Takashi, any other ideas? The high level goal here should be for the audio driver to call into i915 with get/put power well around the sequences where it needs the power to be up (reading/writing registers, playing audio), but not across the whole time the driver is loaded, just like you already do with the powersave work functions, e.g. hda_call_codec_suspend. That's the point. I missed the background about power well it's part of runtime power feature. Audio driver should not always keep power well on even it's not active, I guess you were misunderstood by the power well request point at azx_probe(). azx_probe() is very initial point for power well request, and it will switch to runtime pm soon(please check Mengdong's reply in another email), so the power well will be release if the codec is inactive, that match the initial idea of power well. Thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
Hi Daniel, -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Friday, April 26, 2013 10:57 PM To: Li, Jocelyn Cc: Daniel Vetter; Wang, Xingchao; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Takashi Iwai; Barnes, Jesse; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team On Fri, Apr 26, 2013 at 07:53:41AM +, Li, Jocelyn wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Sent: Friday, April 26, 2013 3:25 PM To: Li, Jocelyn Cc: Wang, Xingchao; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Takashi Iwai; Barnes, Jesse; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team Once we've figured out what needs to be changed in the audio driver we can look at the entire patch series and the interface to i915.ko. That's also why I didn't comment on Xingchao's patch right away, but only once he specifically asked for feedback, since doing a real review of the interface doesn't make sense until we have all the pieces (and a working audio driver). [Jocelyn] I think you have made constructive comments on Xingchao's patch yesterday. Next, shall we have Xingchao improve his patch? Or we just have Xingchao wait till you have completed your pieces. Sorry, I am a little confused :) I think the next step is to use Xinchao's patch as-is and get the audio side going. If you mean the audio working with this patch while power well feature enabled, I say yes. Please see my reply after sending this patch: http://lists.freedesktop.org/archives/intel-gfx/2013-April/027157.html The patch could prevent power well losing, thus audio driver could keep its power on. Without this patch, audio codec info will become unavailable if the power well is shut down by graphic side. Once we have that fixed up, we can revisit the interface and make it solid. But for now trying to polish this relatively simple part seems like wasted time. Also, reviewing an interface is much easier if we have both the i915 pieces (already here) and the audio pieces (which I haven't seen yet) avaialble. It's good idea to list audio driver's usage pieces, I will prepare for that in another email later. Thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
Hi Takashi, -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Friday, April 26, 2013 11:13 PM To: Daniel Vetter Cc: Li, Jocelyn; Daniel Vetter; Wang, Xingchao; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Barnes, Jesse; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team At Fri, 26 Apr 2013 16:57:08 +0200, Daniel Vetter wrote: On Fri, Apr 26, 2013 at 07:53:41AM +, Li, Jocelyn wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Sent: Friday, April 26, 2013 3:25 PM To: Li, Jocelyn Cc: Wang, Xingchao; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Takashi Iwai; Barnes, Jesse; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team Once we've figured out what needs to be changed in the audio driver we can look at the entire patch series and the interface to i915.ko. That's also why I didn't comment on Xingchao's patch right away, but only once he specifically asked for feedback, since doing a real review of the interface doesn't make sense until we have all the pieces (and a working audio driver). [Jocelyn] I think you have made constructive comments on Xingchao's patch yesterday. Next, shall we have Xingchao improve his patch? Or we just have Xingchao wait till you have completed your pieces. Sorry, I am a little confused :) I think the next step is to use Xinchao's patch as-is and get the audio side going. Once we have that fixed up, we can revisit the interface and make it solid. But for now trying to polish this relatively simple part seems like wasted time. Also, reviewing an interface is much easier if we have both the i915 pieces (already here) and the audio pieces (which I haven't seen yet) avaialble. I haven't checked the patch properly yet, but the patch pasted in the post looks like i915 driver exports the functions to control power well, and let audio driver calling them. If so, the big mess in such a case is the dependency between driver modules. A simple workaround would be to split this function and the relevant instance out of i915 and snd-hda-intel and put into an individual module (e.g. i915-powerwell-ctl). I agree this a single independent module could solve the dependency issue. I tested the patch without i915 module loaded, there's symbol error in audio drvier side. Also, it would be feasible to implement some PM governor over both graphics and audio, that is, it gives the proper serialization of power up for audio controller, for example. This could avoid more private APIs between gfx and audio driver as there're really some dependencies on that now. Besides that could the governor help serialize the resume sequence for gfx and audio? We have some good cases to start for the implementations now. i.e. audio driver resume too early while gfx doesnot enable relative transcoders which cause codec pin issues. If you have more guide on this, that would be appreciated. Thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team
Hi Daniel/Takashi, -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Saturday, April 27, 2013 1:18 AM To: Takashi Iwai Cc: Daniel Vetter; Li, Jocelyn; Daniel Vetter; Wang, Xingchao; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Barnes, Jesse; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team On Fri, Apr 26, 2013 at 05:45:15PM +0200, Takashi Iwai wrote: At Fri, 26 Apr 2013 17:42:07 +0200, Daniel Vetter wrote: On Fri, Apr 26, 2013 at 05:12:34PM +0200, Takashi Iwai wrote: At Fri, 26 Apr 2013 16:57:08 +0200, Daniel Vetter wrote: On Fri, Apr 26, 2013 at 07:53:41AM +, Li, Jocelyn wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Sent: Friday, April 26, 2013 3:25 PM To: Li, Jocelyn Cc: Wang, Xingchao; Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Takashi Iwai; Barnes, Jesse; Wysocki, Rafael J; Hindman, Gavin Subject: Re: [PATCH] drm/i915: Add private api for power well usage -- alignment between graphic team and audio team Once we've figured out what needs to be changed in the audio driver we can look at the entire patch series and the interface to i915.ko. That's also why I didn't comment on Xingchao's patch right away, but only once he specifically asked for feedback, since doing a real review of the interface doesn't make sense until we have all the pieces (and a working audio driver). [Jocelyn] I think you have made constructive comments on Xingchao's patch yesterday. Next, shall we have Xingchao improve his patch? Or we just have Xingchao wait till you have completed your pieces. Sorry, I am a little confused :) I think the next step is to use Xinchao's patch as-is and get the audio side going. Once we have that fixed up, we can revisit the interface and make it solid. But for now trying to polish this relatively simple part seems like wasted time. Also, reviewing an interface is much easier if we have both the i915 pieces (already here) and the audio pieces (which I haven't seen yet) avaialble. I haven't checked the patch properly yet, but the patch pasted in the post looks like i915 driver exports the functions to control power well, and let audio driver calling them. If so, the big mess in such a case is the dependency between driver modules. A simple workaround would be to split this function and the relevant instance out of i915 and snd-hda-intel and put into an individual module (e.g. i915-powerwell-ctl). Yeah, the current patch doesn't work for loading i915/snd-hda-intel in any order. But it should be good enough to fix the hw interactions. Well, my current concern is that the call is built into snd-hda-intel module and this will lead to load i915 module no matter whether it's used or not. snd-hda-intel is used for any HD-audio controllers (despite its name). Loading i915 on a pure AMD system will annoy some non-Intel people :) Even if we built the code via ifdef CONFIG_DRM_I915 or such, it's still hardcoded, thus the problem above will occur with distro kernels. Sure, the current patch won't cut it for upstreaming. But it should be good enough to figure out what exactly we need (which to still be a bit unclear). Or at least where exactly we need it and what kind of other changes in snd-hda-intel are required to get things going. Let me throw a basic proposal on Audio driver side, please give your comments freely. it contains the power well control usage points: #1: audio request power well at boot up. I915 may shut down power well after bootup initialization, as there's no monitor connected outside or only eDP on pipe A. #2: audio request power on resume After exit from D3 mode, audio driver quest power on. This may happen at normal resume or runtime resume. #3: audio release power well control at suspend Audio driver will let i915 know it doensot need power well anymore as it's going to suspend. This may happened at normal suspend or runtime suspend point. #4: audio release power well when module unload Audio release power well at remove callback to let i915 know. 1/2 should have API like i915_request_power_well(). 3/4 should be i915_release_power_well(). Also there're some dependencies: #1: I915 driver not loaded yet, it will be loaded soon. This may happen at bootup, the audio driver module was initialized at first. We may follow Takashi's suggestion to move things into single
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage
Hi Daniel, -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Sent: Thursday, April 25, 2013 3:52 PM To: Wang, Xingchao Cc: Zanoni, Paulo R; ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; Li, Jocelyn; intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; Wang Xingchao; Takashi Iwai; Barnes, Jesse; Wysocki, Rafael J Subject: Re: [PATCH] drm/i915: Add private api for power well usage On Thu, Apr 25, 2013 at 4:36 AM, Wang, Xingchao xingchao.w...@intel.com wrote: Hi Daniel/Paulo, Any comments on this? Add Jesse and Rafael in loop. Well I've figured we want to get the power well integration working before we waste time reviewing an interface which might or might not quite work. Well it's good news you have plan to add power well API support in graphic side, then it's easy for audio driver to use. I donot know much background about your idea and current status of the power well integration status there so it's better to avoid duplicated work. But if you want, I can drop two quick comments: - I think the functions needs some prefix like i915_ - Imo the power well should just be reference counted (the current interface name suggests it's generally useable, but actually can only cope with one request from the audio driver). Indeed it was my initial idea to use reference counter to track power well users. A second thinking is It become complex as i915 did not call intel_set_power_well(enable/disable) symmetrically. It may enable Power well several times but disable it only once. That's why I just use a basic logic to track the power well usage. - Is the spin_lock (irq-disabling even) really required for the audio driver to work? power well enabling can take up to 20ms, so this won't work as-is. Can't we just use a mutex? - I'd need to see the audio driver side of this to check how this works for coping with arbitrary module load ordering. Thanks your review, i will change it in next versioin patch. Thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add private api for power well usage
Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell mobile
C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 73 +++
include/drm/audio_drm.h | 39 +
sound/pci/hda/hda_intel.c |8 +
3 files changed, 113 insertions(+), 7 deletions(-)
create mode 100644 include/drm/audio_drm.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2557926..9983f56 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4298,18 +4298,12 @@ bool intel_using_power_well(struct drm_device *dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+void set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE;
@@ -4332,6 +4326,71 @@ void intel_set_power_well(struct drm_device *dev, bool
enable)
}
}
+/* Global drm_device for display audio drvier usage */
+static struct drm_device *power_well_device;
+static bool audio_power_well_using, i915_power_well_using;
+/* Lock protecting power well setting */
+DEFINE_SPINLOCK(powerwell_lock);
+
+void request_power_well(void)
+{
+ DRM_DEBUG_KMS(Display audio requesting power well\n);
+ spin_lock_irq(powerwell_lock);
+ if (!power_well_device)
+ goto out;
+ if (i915_power_well_using == false)
+ set_power_well(power_well_device, true);
+ audio_power_well_using = true;
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+EXPORT_SYMBOL_GPL(request_power_well);
+
+void release_power_well(void)
+{
+ DRM_DEBUG_KMS(Display audio releasing power well\n);
+ spin_lock_irq(powerwell_lock);
+ if (!power_well_device)
+ goto out;
+ if (i915_power_well_using == false)
+ set_power_well(power_well_device, false);
+ audio_power_well_using = false;
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+EXPORT_SYMBOL_GPL(release_power_well);
+
+/* TODO: Call this when i915 module unload */
+void remove_power_well(void)
+{
+ spin_lock_irq(powerwell_lock);
+ audio_power_well_using = false;
+ i915_power_well_using = false;
+ power_well_device = NULL;
+ spin_unlock_irq(powerwell_lock);
+}
+
+void intel_set_power_well(struct drm_device *dev, bool enable)
+{
+ if (!HAS_POWER_WELL(dev))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ power_well_device = dev;
+ i915_power_well_using = enable;
+ if (!enable audio_power_well_using)
+ goto out;
+
+ if (!i915_disable_power_well !enable)
+ goto out;
+ set_power_well(dev, enable);
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+
/*
* Starting with Haswell, we have a Power Down Well that can be turned off
* when not needed anymore. We have 4 registers that can request the power well
diff --git a/include/drm/audio_drm.h b/include/drm/audio_drm.h
new file mode 100644
index 000..4412b36
--- /dev/null
+++ b/include/drm/audio_drm.h
@@ -0,0 +1,39 @@
+/**
+ *
+ * Copyright 2013 Intel Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage
Hi Guys,
Sorry I should Add Takashi and alsa maillist in loop.
I tested this patch against Daniel's drm-intel-next-queued Branch, on Haswell
Mobile C3 stepping machines.
Test steps:
1. only connect one monitor through HDMI cable
2. echo 1 /sys/module/i915/parameters/disable_power_well == I think this
could be set as 1 by default if applied my patch.
3. plug out HDMI cable
4. cat /proc/asound/card0/codec#0
At step 3, i915 will try to disable power well but rejected as display audio
is using power well.
Without the patch, display audio would crash at step 4.
I did not list suspend/resume test here, as during suspend sequence, i915 will
_ENABLE_ power well, that's a BUG?
For me above test case is the only one to reproduce the issue, if you have more
ideas and need more test, please let me know.
I'm afraid there's some risk because the dependency between alsa driver and drm
driver. For example, if i915 module was not loaded, display audio
Will call request_power_well() and meet symbol error. Even if i915 module
loaded after snd-hda-intel module, there's such risk too. Any comment on this?
Another risk is the pointer power_well_device, it should be set NULL when
i915 module unloaded, I added the caller but have no idea where to call it, if
anyone has suggestion, that would be fine.
thanks
--xingchao
-Original Message-
From: Wang Xingchao [mailto:xingchao.w...@linux.intel.com]
Sent: Thursday, April 24, 2014 10:20 PM
To: daniel.vet...@ffwll.ch; Zanoni, Paulo R
Cc: ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; Li,
Jocelyn;
intel-gfx@lists.freedesktop.org; Wang, Xingchao; Wang Xingchao
Subject: [PATCH] drm/i915: Add private api for power well usage
Display audio depends on power well in graphic side, it should request power
well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell mobile
C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 73
+++
include/drm/audio_drm.h | 39 +
sound/pci/hda/hda_intel.c |8 +
3 files changed, 113 insertions(+), 7 deletions(-) create mode 100644
include/drm/audio_drm.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2557926..9983f56 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4298,18 +4298,12 @@ bool intel_using_power_well(struct drm_device
*dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+void set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE; @@ -4332,6
+4326,71 @@ void intel_set_power_well(struct drm_device *dev, bool enable)
}
}
+/* Global drm_device for display audio drvier usage */ static struct
+drm_device *power_well_device; static bool audio_power_well_using,
+i915_power_well_using;
+/* Lock protecting power well setting */
+DEFINE_SPINLOCK(powerwell_lock);
+
+void request_power_well(void)
+{
+ DRM_DEBUG_KMS(Display audio requesting power well\n);
+ spin_lock_irq(powerwell_lock);
+ if (!power_well_device)
+ goto out;
+ if (i915_power_well_using == false)
+ set_power_well(power_well_device, true);
+ audio_power_well_using = true;
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+EXPORT_SYMBOL_GPL(request_power_well);
+
+void release_power_well(void)
+{
+ DRM_DEBUG_KMS(Display audio releasing power well\n);
+ spin_lock_irq(powerwell_lock);
+ if (!power_well_device)
+ goto out;
+ if (i915_power_well_using == false)
+ set_power_well(power_well_device, false);
+ audio_power_well_using = false;
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+EXPORT_SYMBOL_GPL(release_power_well);
+
+/* TODO: Call this when i915 module unload */ void
+remove_power_well(void) {
+ spin_lock_irq(powerwell_lock);
+ audio_power_well_using = false;
+ i915_power_well_using = false;
+ power_well_device = NULL;
+ spin_unlock_irq(powerwell_lock);
+}
+
+void intel_set_power_well(struct drm_device *dev, bool enable) {
+ if (!HAS_POWER_WELL(dev))
+ return;
+
+ spin_lock_irq(powerwell_lock);
+ power_well_device = dev;
+ i915_power_well_using = enable;
+ if (!enable audio_power_well_using)
+ goto
Re: [Intel-gfx] [PATCH] drm/i915: Add private api for power well usage
Hi Daniel/Paulo,
Any comments on this?
Add Jesse and Rafael in loop.
thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Wednesday, April 24, 2013 3:29 PM
To: daniel.vet...@ffwll.ch; Zanoni, Paulo R; 'Takashi Iwai'
Cc: ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R; Li,
Jocelyn;
intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; 'Wang Xingchao'
Subject: RE: [PATCH] drm/i915: Add private api for power well usage
Hi Guys,
Sorry I should Add Takashi and alsa maillist in loop.
I tested this patch against Daniel's drm-intel-next-queued Branch, on
Haswell Mobile C3 stepping machines.
Test steps:
1. only connect one monitor through HDMI cable 2. echo 1
/sys/module/i915/parameters/disable_power_well == I think this could be set
as 1 by default if applied my patch.
3. plug out HDMI cable
4. cat /proc/asound/card0/codec#0
At step 3, i915 will try to disable power well but rejected as display audio
is
using power well.
Without the patch, display audio would crash at step 4.
I did not list suspend/resume test here, as during suspend sequence, i915 will
_ENABLE_ power well, that's a BUG?
For me above test case is the only one to reproduce the issue, if you have
more
ideas and need more test, please let me know.
I'm afraid there's some risk because the dependency between alsa driver and
drm driver. For example, if i915 module was not loaded, display audio Will
call
request_power_well() and meet symbol error. Even if i915 module loaded after
snd-hda-intel module, there's such risk too. Any comment on this?
Another risk is the pointer power_well_device, it should be set NULL when
i915 module unloaded, I added the caller but have no idea where to call it, if
anyone has suggestion, that would be fine.
thanks
--xingchao
-Original Message-
From: Wang Xingchao [mailto:xingchao.w...@linux.intel.com]
Sent: Thursday, April 24, 2014 10:20 PM
To: daniel.vet...@ffwll.ch; Zanoni, Paulo R
Cc: ville.syrj...@linux.intel.com; Lin, Mengdong; Girdwood, Liam R;
Li, Jocelyn; intel-gfx@lists.freedesktop.org; Wang, Xingchao; Wang
Xingchao
Subject: [PATCH] drm/i915: Add private api for power well usage
Display audio depends on power well in graphic side, it should request
power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell mobile
C3 stepping board.
Signed-off-by: Wang Xingchao xingchao.w...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 73
+++
include/drm/audio_drm.h | 39 +
sound/pci/hda/hda_intel.c |8 +
3 files changed, 113 insertions(+), 7 deletions(-) create mode
100644 include/drm/audio_drm.h
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c index 2557926..9983f56 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4298,18 +4298,12 @@ bool intel_using_power_well(struct drm_device
*dev)
return true;
}
-void intel_set_power_well(struct drm_device *dev, bool enable)
+void set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
bool is_enabled, enable_requested;
uint32_t tmp;
- if (!HAS_POWER_WELL(dev))
- return;
-
- if (!i915_disable_power_well !enable)
- return;
-
tmp = I915_READ(HSW_PWR_WELL_DRIVER);
is_enabled = tmp HSW_PWR_WELL_STATE;
enable_requested = tmp HSW_PWR_WELL_ENABLE; @@ -4332,6
+4326,71 @@ void intel_set_power_well(struct drm_device *dev, bool
+enable)
}
}
+/* Global drm_device for display audio drvier usage */ static struct
+drm_device *power_well_device; static bool audio_power_well_using,
+i915_power_well_using;
+/* Lock protecting power well setting */
+DEFINE_SPINLOCK(powerwell_lock);
+
+void request_power_well(void)
+{
+ DRM_DEBUG_KMS(Display audio requesting power well\n);
+ spin_lock_irq(powerwell_lock);
+ if (!power_well_device)
+ goto out;
+ if (i915_power_well_using == false)
+ set_power_well(power_well_device, true);
+ audio_power_well_using = true;
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+EXPORT_SYMBOL_GPL(request_power_well);
+
+void release_power_well(void)
+{
+ DRM_DEBUG_KMS(Display audio releasing power well\n);
+ spin_lock_irq(powerwell_lock);
+ if (!power_well_device)
+ goto out;
+ if (i915_power_well_using == false)
+ set_power_well(power_well_device, false);
+ audio_power_well_using = false;
+out:
+ spin_unlock_irq(powerwell_lock);
+ return;
+}
+EXPORT_SYMBOL_GPL(release_power_well);
+
+/* TODO: Call this when i915 module
[Intel-gfx] Power well issue could not be reproduced with drm-intel-next branch
Hi Daniel/Paulo, In order to verify an RFC patch to fix the power well issue, I'm trying to reproduce it on my Haswell ULT C stepping board, with drm-intel-next branch, the last commit is: commit 80ad9206c0d863832bc5f6008c4d1868d1df8e70 Author: Ville Syrjälä ville.syrj...@linux.intel.com Date: Fri Apr 19 14:36:51 2013 +0300 The test step is: 1) echo 1 /sys/module/i915/parameters/disable_power_well 2) echo mem /sys/power/state 3) press any key or power button to resume system 4) check Haswell hdmi codec status At step 2), I cannot suspend the whole system successfully on Haswell ULT C stepping board, the CPU fan is always running. At step 3), I could see resume message for i915 module, but there's one warning as below: [ 172.755762] [drm:intel_ddi_put_crtc_pll], Disabling WRPLL 1 [ 172.755764] [ cut here ] [ 172.755805] WARNING: at drivers/gpu/drm/i915/intel_ddi.c:781 intel_ddi_put_crtc_pll+0x293/0x2a0 [i915]() [ 172.755807] Hardware name: Shark Bay Client platform [ 172.755853] Modules linked in: rfcomm bnep bluetooth parport_pc ppdev snd_hda_codec_hdmi coretemp kvm_intel kvm i915 snd_hda_intel snd_hda_codec ghash_clmulni_intel aesni_intel snd_hwdep ablk_helper cryptd snd_pcm lrw aes_x86_64 drm_kms_helper xts gf128mul snd_seq_midi drm snd_rawmidi snd_seq_midi_event hid_generic snd_seq usbhid microcode e1000e asix snd_timer i2c_algo_bit hid snd_seq_device usbnet video snd serio_raw mac_hid lpc_ich ptp soundcore snd_page_alloc pps_core lp parport [ 172.755857] Pid: 2431, comm: kworker/u:13 Tainted: GW 3.9.0-rc5-daniel-force-pin+ #195 [ 172.755859] Call Trace: [ 172.755873] [81058faf] warn_slowpath_common+0x7f/0xc0 [ 172.755881] [8105900a] warn_slowpath_null+0x1a/0x20 [ 172.755907] [a0274c03] intel_ddi_put_crtc_pll+0x293/0x2a0 [i915] [ 172.755930] [a0274c5e] intel_ddi_pll_mode_set+0x4e/0x3c0 [i915] [ 172.755947] [a023ec9c] ? ivybridge_enable_vblank+0x2c/0x80 [i915] [ 172.755971] [a026ae88] haswell_crtc_mode_set+0x138/0x540 [i915] [ 172.755994] [a0264d9b] __intel_set_mode+0x68b/0xd50 [i915] [ 172.756017] [a026f181] intel_modeset_setup_hw_state+0x6f1/0xa30 [i915] [ 172.756031] [a0237287] __i915_drm_thaw+0x127/0x1c0 [i915] [ 172.756045] [a02377ac] i915_resume+0x7c/0xd0 [i915] [ 172.756059] [a0237816] i915_pm_resume+0x16/0x20 [i915] [ 172.756069] [8136613e] pci_pm_resume+0x7e/0xe0 [ 172.756074] [813660c0] ? pci_pm_thaw+0x80/0x80 [ 172.756083] [81443bdb] dpm_run_callback.isra.4+0x3b/0x80 [ 172.756089] [81443ed4] device_resume+0xd4/0x1b0 [ 172.756095] [81443fd1] async_resume+0x21/0x50 [ 172.756102] [8108476b] async_run_entry_fn+0x3b/0x140 [ 172.756108] [8107792b] process_one_work+0x16b/0x400 [ 172.756113] [810785b8] worker_thread+0x118/0x360 [ 172.756118] [810784a0] ? manage_workers+0x350/0x350 [ 172.756124] [8107db00] kthread+0xc0/0xd0 [ 172.756131] [8107da40] ? flush_kthread_worker+0xb0/0xb0 [ 172.756137] [816b60ec] ret_from_fork+0x7c/0xb0 [ 172.756143] [8107da40] ? flush_kthread_worker+0xb0/0xb0 [ 172.756146] ---[ end trace e203505bded24940 ]--- [ 172.756150] [drm:intel_ddi_pll_mode_set], Using WRPLL 1 on pipe A Did you notice the same warning there? Does it has impact on the power well feature? At step 4), the codec info still exist, means the power well issue could not reproduced. It seems power for display audio was not removed during suspend. Could someone clarify me which commit do that? If I revert commits back to Paulo's below commit: commit 2124b72e6283c4e84a55e71077fee91793f4c801 Author: Paulo Zanoni paulo.r.zan...@intel.com Date: Fri Mar 22 14:07:23 2013 -0300 Repeat same steps, at step 4), the codec info crashed and there're many spurious irq in audio part, that means the display audio power was removed during suspend. thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support for Haswell
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 21 +
drivers/gpu/drm/i915/intel_display.c |4
drivers/gpu/drm/i915/intel_drv.h |1 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..821316c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -650,6 +650,7 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
DRM_DEBUG_KMS(Preparing DDI mode for Haswell on port %c, pipe %c\n,
port_name(port), pipe_name(pipe));
+ intel_crtc-eld_vld = false;
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -1274,10 +1275,14 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
static void intel_enable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ uint32_t tmp;
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and swing/emphasis values
@@ -1290,18 +1295,34 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
ironlake_edp_backlight_on(intel_dp);
}
+
+ if (intel_crtc-eld_vld) {
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe *
4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
+ }
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t tmp;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
}
+
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1464e47..11fbe04 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3745,10 +3745,12 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc-dev;
struct drm_connector *connector;
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
/* crtc should still be enabled when we disable it. */
WARN_ON(!crtc-enabled);
+ intel_crtc-eld_vld = false;
dev_priv-display.crtc_disable(crtc);
intel_crtc_update_sarea(crtc, false);
dev_priv-display.off(crtc);
@@ -5622,6 +5624,7 @@ static void haswell_write_eld(struct drm_connector
*connector,
struct drm_i915_private *dev_priv = connector-dev-dev_private;
uint8_t *eld = connector-eld;
struct drm_device *dev = crtc-dev;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t eldv;
uint32_t i;
int len;
@@ -5663,6 +5666,7 @@ static void haswell_write_eld(struct drm_connector
*connector,
DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
eldv = AUDIO_ELD_VALID_A (pipe * 4);
+ intel_crtc-eld_vld = true;
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 116580b..be588da 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -206,6 +206,7 @@ struct intel_crtc {
* some outputs connected to this crtc.
*/
bool active;
+ bool eld_vld;
bool primary_disabled; /* is the crtc obscured by a plane
[Intel-gfx] [PATCH v3] drm/i915: HDMI/DP - ELD info refresh support for Haswell
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 22 ++
drivers/gpu/drm/i915/intel_display.c |2 ++
drivers/gpu/drm/i915/intel_drv.h |1 +
3 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..c23dd63 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1274,10 +1274,14 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
static void intel_enable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ int tmp;
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and swing/emphasis values
@@ -1290,18 +1294,36 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
ironlake_edp_backlight_on(intel_dp);
}
+
+ if (!intel_crtc-eld_vld) {
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe *
4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
+ intel_crtc-eld_vld = true;
+ }
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int tmp;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
}
+
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
+ intel_crtc-eld_vld = false;
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1464e47..4e56abe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5622,6 +5622,7 @@ static void haswell_write_eld(struct drm_connector
*connector,
struct drm_i915_private *dev_priv = connector-dev-dev_private;
uint8_t *eld = connector-eld;
struct drm_device *dev = crtc-dev;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t eldv;
uint32_t i;
int len;
@@ -5663,6 +5664,7 @@ static void haswell_write_eld(struct drm_connector
*connector,
DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
eldv = AUDIO_ELD_VALID_A (pipe * 4);
+ intel_crtc-eld_vld = true;
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 116580b..be588da 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -206,6 +206,7 @@ struct intel_crtc {
* some outputs connected to this crtc.
*/
bool active;
+ bool eld_vld;
bool primary_disabled; /* is the crtc obscured by a plane? */
bool lowfreq_avail;
struct intel_overlay *overlay;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh support for Haswell
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Monday, January 21, 2013 9:11 PM
To: Wang, Xingchao
Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zanoni, Paulo R
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh
support for Haswell
On Mon, Jan 21, 2013 at 05:40:23AM +, Wang, Xingchao wrote:
Hi Ville Syrjälä,
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, January 18, 2013 9:14 PM
To: Wang, Xingchao
Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zanoni,
Paulo R
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info
refresh support for Haswell
On Fri, Jan 18, 2013 at 12:00:10PM +, Wang, Xingchao wrote:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, January 18, 2013 6:46 PM
To: Wang, Xingchao
Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
Zanoni, Paulo R
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info
refresh support for Haswell
On Fri, Jan 18, 2013 at 10:51:55AM +0800, Wang Xingchao wrote:
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output
enable bit from callback intel_disable/eanble_ddi().
Hmm. Is it OK to set the ELD valid bit if the ELD hasn't
actually been
written?
This triggers an unsolicited event to ALSA driver which continue
to read ELD
info.
I take it we don't want that to happen?
And besides these bits are already set by haswell_write_eld().
Intel_disable/enable_ddi() was called even after
haswell_write_eld(), so we
need set the bits again.
For the mode set sequence only intel_enable_ddi() is called after
haswell_write_eld().
This is how the sequence should end up looking with the current
code:
intel_set_mode()
- haswell_crtc_disable()
- intel_disable_ddi()
- intel_crtc_mode_set()
- haswell_crtc_mode_set()
- intel_ddi_mode_set()
- intel_write_eld()
- haswell_write_eld()
- haswell_crtc_enable()
- intel_enable_ddi()
But for DPMS on-off-on there would be calls to
haswell_crtc_disable() and
haswell_crtc_enable() w/o calls to haswell_write_eld(). I suppose
this is the problem you want to fix?
Exactly. Intel_disable_ddi() was called after haswell_write_eld() only once
during system bootup.
I added a flag to monitor ELD valid status. It will be set in
haswell_write_eld()
and cleared in intel_disable_ddi().
In intel_enable_ddi() , will check this flag and set the ELD valid bit
again only if
the flag was cleared before.
But that would make the code behave almost the same as the old patch, no?
As there's DPMS state change during bootup, the ELD valid bit was cleared in
intel_disable_ddi(),
So we have to set that bit again in intel_enable_ddi(), otherwise there's no
eld info after system bootup.
I changed the logic based on your suggestion below, didot clear
intel_crtc-eld_vld in intel_disable_ddi().
It would make intel_enable_ddi() set the ELD valid bit, even if ELD wasn't
written.
So the basic rule is to ONLY set ELD valid bit when ELD was really written in
haswell_write_eld().
My idea was that intel_disable_ddi() would not clear the flag, and
intel_enable_ddi() would only write the ELD valid bit if the flag is set.
That way we never write the ELD valid bit to the register when there is no
valid
ELD.
So something likes this perhaps:
intel_ddi_mode_set()
{
Should it be intel_set_mode()?
...
+ intel_encoder-eld_valid = false;
...
intel_write_eld();
...
}
haswell_write_eld()
{
...
+ intel_encoder-eld_valid = true;
}
intel_enable_ddi()
{
...
+ if (intel_encoder-eld_valid)
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD);
}
intel_disable_ddi()
{
...
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD)
}
One extra idea would be to have something like 'uint32_t eld_reg'
instead of 'bool eld_valid'. That was you could just do
'I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, intel_encoder-eld_reg);' in
intel_eanble_ddi() without having to recompute the register value.
And intel_encodr-eld_reg would be updated with the new value in
haswell_write_eld().
I think using eld_vld is better as in intel_enable_ddi() we need this flag to
decide whether
to update the ELD valid bit. And the register value may change based on
different pipe setting,
it's more efficient to just read out the register value.
I had tested the new patch and it works well. I will send out the updated
patch later.
So, perhaps there should be a flag somewhere that would be cleared
at the beginning of the mode_set
Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh support for Haswell
Hi Ville Syrjälä, -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Friday, January 18, 2013 9:14 PM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zanoni, Paulo R Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh support for Haswell On Fri, Jan 18, 2013 at 12:00:10PM +, Wang, Xingchao wrote: -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Friday, January 18, 2013 6:46 PM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zanoni, Paulo R Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh support for Haswell On Fri, Jan 18, 2013 at 10:51:55AM +0800, Wang Xingchao wrote: ELD info should be updated dynamically according to hot plug event. For haswell chip, clear/set the eld valid bit and output enable bit from callback intel_disable/eanble_ddi(). Hmm. Is it OK to set the ELD valid bit if the ELD hasn't actually been written? This triggers an unsolicited event to ALSA driver which continue to read ELD info. I take it we don't want that to happen? And besides these bits are already set by haswell_write_eld(). Intel_disable/enable_ddi() was called even after haswell_write_eld(), so we need set the bits again. For the mode set sequence only intel_enable_ddi() is called after haswell_write_eld(). This is how the sequence should end up looking with the current code: intel_set_mode() - haswell_crtc_disable() - intel_disable_ddi() - intel_crtc_mode_set() - haswell_crtc_mode_set() - intel_ddi_mode_set() - intel_write_eld() - haswell_write_eld() - haswell_crtc_enable() - intel_enable_ddi() But for DPMS on-off-on there would be calls to haswell_crtc_disable() and haswell_crtc_enable() w/o calls to haswell_write_eld(). I suppose this is the problem you want to fix? Exactly. Intel_disable_ddi() was called after haswell_write_eld() only once during system bootup. I added a flag to monitor ELD valid status. It will be set in haswell_write_eld() and cleared in intel_disable_ddi(). In intel_enable_ddi() , will check this flag and set the ELD valid bit again only if the flag was cleared before. I had tested the new patch and it works well. I will send out the updated patch later. So, perhaps there should be a flag somewhere that would be cleared at the beginning of the mode_set operation, and then intel_write_eld() should set the flag when the ELD was written succesfully. intel_enable_ddi() could check the flag and only set the ELD valid bit when the flag is set. Should non-ddi platforms do something similar as well? Would you share more ideas on this? I have not noticed the potential issues here. Thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh support for Haswell
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, January 18, 2013 6:46 PM
To: Wang, Xingchao
Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zanoni, Paulo R
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh
support for Haswell
On Fri, Jan 18, 2013 at 10:51:55AM +0800, Wang Xingchao wrote:
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Hmm. Is it OK to set the ELD valid bit if the ELD hasn't actually been
written?
This triggers an unsolicited event to ALSA driver which continue to read ELD
info.
And besides these bits are already set by haswell_write_eld().
Intel_disable/enable_ddi() was called even after haswell_write_eld(), so we
need set the bits again.
Thanks
--xingchao
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..7ce4728 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1274,10 +1274,14 @@ static void intel_ddi_post_disable(struct
intel_encoder *intel_encoder) static void intel_enable_ddi(struct
intel_encoder *intel_encoder) {
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ int tmp;
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and swing/emphasis values
@@
-1290,18 +1294,32 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
ironlake_edp_backlight_on(intel_dp);
}
+
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe *
4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder) {
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int tmp;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
}
+
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe *
4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support for Haswell
Hi Vivi,
-Original Message-
From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com]
Sent: Tuesday, January 15, 2013 1:00 AM
To: Wang, Xingchao
Cc: Daniel Vetter; intel-gfx; Zanoni, Paulo R
Subject: Re: [Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support
for Haswell
Hi Wang,
I would prefer to use defined HSW_AUD_PIN_ELD_CP_VLD directly at
read/write macros instead of creating an variable aud_cntrl_st2.
Okay, will modify that in second version patch.
But this is minor, the other question I have here, why are you doing this
only for
pipe A instead of pipe in use?
No, the patch is making fix for the current using pipe, not only for pipe A.
please note below line:
tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
Thanks
--xingchao
On Mon, Jan 7, 2013 at 3:20 AM, Wang Xingchao xingchao.w...@intel.com
wrote:
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..a80125f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1274,10 +1274,15 @@ static void intel_ddi_post_disable(struct
intel_encoder *intel_encoder) static void intel_enable_ddi(struct
intel_encoder *intel_encoder) {
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+ int tmp;
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and
swing/emphasis values @@ -1290,18 +1295,33 @@ static void
intel_enable_ddi(struct intel_encoder *intel_encoder)
ironlake_edp_backlight_on(intel_dp);
}
+
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A)
(pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder) {
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int tmp;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
}
+
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A)
(pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info refresh support for Haswell
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..7ce4728 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1274,10 +1274,14 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
static void intel_enable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ int tmp;
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and swing/emphasis values
@@ -1290,18 +1294,32 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
ironlake_edp_backlight_on(intel_dp);
}
+
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int tmp;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
}
+
+ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
+ I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp);
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: HDMI/DP - ELD info refresh support for Haswell
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f02b3fe..a80125f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1274,10 +1274,15 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
static void intel_enable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+ int tmp;
if (type == INTEL_OUTPUT_HDMI) {
/* In HDMI/DVI mode, the port width, and swing/emphasis values
@@ -1290,18 +1295,33 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
ironlake_edp_backlight_on(intel_dp);
}
+
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= ((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
}
static void intel_disable_ddi(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
int type = intel_encoder-type;
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int tmp;
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_backlight_off(intel_dp);
}
+
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp = ~((AUDIO_OUTPUT_ENABLE_A | AUDIO_ELD_VALID_A) (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
}
int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
-Original Message- From: Wu, Fengguang Sent: Thursday, September 13, 2012 11:14 AM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; daniel.vet...@ffwll.ch; ti...@suse.de; Zhao, Yakui; Fu, Michael Subject: Re: [PATCH] drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally u32 enable_bits = SDVO_ENABLE; - if (intel_hdmi-has_audio) - enable_bits |= SDVO_AUDIO_ENABLE; + enable_bits |= SDVO_AUDIO_ENABLE; The two lines can be combined: u32 enable_bits = SDVO_ENABLE | SDVO_AUDIO_ENABLE; Looks better, I send out V2 patch for Daniel. -- Xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH v2] drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
Hi Takashi, 2012/9/13 Takashi Iwai ti...@suse.de: At Thu, 13 Sep 2012 11:19:00 +0800, Wang Xingchao wrote: Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_enable_hdmi(), if intel_hdmi-has_audio been true, the Audio enable bit will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi-has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_disable_hdmi(), the Audio enable bit will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao xingchao.w...@intel.com We need the same fix for stable kernels, too, but unfortunately this can't be applied to 3.6 or earlier. I had another patch against 3.6 kernel, I send it out at first. This v2 version is based on Daniel's drm-intel-next branch. so i will resend that seperate patch to Greg. The patch for 3.6 kernel: http://lists.freedesktop.org/archives/intel-gfx/2012-September/020413.html thanks --xingchao Greg prefers still having a Cc to stable even in such a case, and then send a separate patch applicable to the existing kernels. http://lwn.net/Articles/515528/ So better to have a Cc to stable in the patch. thanks, Takashi --- drivers/gpu/drm/i915/intel_hdmi.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 5d02aad..229897f 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -674,10 +674,7 @@ static void intel_disable_hdmi(struct intel_encoder *encoder) struct drm_i915_private *dev_priv = dev-dev_private; struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder-base); u32 temp; - u32 enable_bits = SDVO_ENABLE; - - if (intel_hdmi-has_audio) - enable_bits |= SDVO_AUDIO_ENABLE; + u32 enable_bits = SDVO_ENABLE | SDVO_AUDIO_ENABLE; temp = I915_READ(intel_hdmi-sdvox_reg); -- 1.7.9.5 ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: ELD info update during HDMI hot plug
-Original Message- From: Wu, Fengguang Sent: Wednesday, September 05, 2012 1:30 PM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zhao, Yakui Subject: Re: [PATCH] drm/i915: ELD info update during HDMI hot plug Xingchao, We have the drm_i915_display_funcs.write_eld() for such functionalities. I have another simple patch to replace this one, will send it out later. thanks --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_hdmi_dpms(), if intel_hdmi-has_audio been true, the Audio enable bit will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi-has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_hdmi_dpms(), the Audio enable bit will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao xingchao.w...@intel.com --- drivers/gpu/drm/i915/intel_hdmi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 98f6024..12dc330 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -609,7 +609,7 @@ static void intel_hdmi_dpms(struct drm_encoder *encoder, int mode) u32 temp; u32 enable_bits = SDVO_ENABLE; - if (intel_hdmi-has_audio) + if (intel_hdmi-has_audio || mode != DRM_MODE_DPMS_ON) enable_bits |= SDVO_AUDIO_ENABLE; temp = I915_READ(intel_hdmi-sdvox_reg); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_enable_hdmi(), if intel_hdmi-has_audio been true, the Audio enable bit will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi-has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_disable_hdmi(), the Audio enable bit will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao xingchao.w...@intel.com --- drivers/gpu/drm/i915/intel_hdmi.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 5d02aad..d39ed58 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -676,8 +676,7 @@ static void intel_disable_hdmi(struct intel_encoder *encoder) u32 temp; u32 enable_bits = SDVO_ENABLE; - if (intel_hdmi-has_audio) - enable_bits |= SDVO_AUDIO_ENABLE; + enable_bits |= SDVO_AUDIO_ENABLE; temp = I915_READ(intel_hdmi-sdvox_reg); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally
Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_enable_hdmi(), if intel_hdmi-has_audio been true, the Audio enable bit will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi-has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_disable_hdmi(), the Audio enable bit will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao xingchao.w...@intel.com --- drivers/gpu/drm/i915/intel_hdmi.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 5d02aad..229897f 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -674,10 +674,7 @@ static void intel_disable_hdmi(struct intel_encoder *encoder) struct drm_i915_private *dev_priv = dev-dev_private; struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder-base); u32 temp; - u32 enable_bits = SDVO_ENABLE; - - if (intel_hdmi-has_audio) - enable_bits |= SDVO_AUDIO_ENABLE; + u32 enable_bits = SDVO_ENABLE | SDVO_AUDIO_ENABLE; temp = I915_READ(intel_hdmi-sdvox_reg); -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: ELD info update during HDMI hot plug
ELD infomation should update immediately when detected HDMI hot plug event.
The related ELD_VALID bit should be set/clear to generate unsolicited event
to notify Alsa driver this change.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e4c37bb..1d9aaa9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -719,6 +719,10 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
struct drm_i915_private *dev_priv = connector-dev-dev_private;
struct edid *edid;
enum drm_connector_status status = connector_status_disconnected;
+ enum drm_connector_status old_status = connector-status;
+ int aud_cntrl_st2;
+ uint32_t eldv;
+ int i;
if (IS_G4X(connector-dev) !g4x_hdmi_connected(intel_hdmi))
return status;
@@ -747,6 +751,30 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
(intel_hdmi-force_audio == HDMI_AUDIO_ON);
}
+ if (status != old_status) {
+ if (HAS_PCH_IBX(connector-dev))
+ aud_cntrl_st2 = IBX_AUD_CNTL_ST2;
+ else if (IS_HASWELL(connector-dev))
+ aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+ else
+ aud_cntrl_st2 = CPT_AUD_CNTRL_ST2;
+
+ eldv = (AUDIO_ELD_VALID_A |
+ AUDIO_ELD_VALID_B |
+ AUDIO_ELD_VALID_C) ;
+ if (status == connector_status_connected) {
+ DRM_DEBUG_KMS([CONNECTOR:%d:%s] Pluged In\n,
connector-base.id,
+ drm_get_connector_name(connector));
+ I915_WRITE(aud_cntrl_st2, eldv);
+ } else {
+ i = I915_READ(aud_cntrl_st2);
+ i = ~eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+ DRM_DEBUG_KMS([CONNECTOR:%d:%s] Pluged Out\n,
connector-base.id,
+ drm_get_connector_name(connector));
+ }
+ }
+
return status;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 3/4] drm/i915: Haswell HDMI audio initialization
Added new haswell_write_eld() to initialize Haswell HDMI audio registers
to generate an unsolicited response to the audio controller driver to
indicate that the controller sequence should start.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 98 +-
2 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55aa10e..08f8b65 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4294,6 +4294,7 @@
#define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
HSW_AUD_DIG_CNVT_1, \
HSW_AUD_DIG_CNVT_2)
+#define DIP_PORT_SEL_MASK0x3
#define HSW_AUD_EDID_DATA_A 0x65050
#define HSW_AUD_EDID_DATA_B 0x65150
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 70d30fc..3b70777 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5067,6 +5067,102 @@ static void g4x_write_eld(struct drm_connector
*connector,
I915_WRITE(G4X_AUD_CNTL_ST, i);
}
+static void haswell_write_eld(struct drm_connector *connector,
+struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ struct drm_device *dev = crtc-dev;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int pipe = to_intel_crtc(crtc)-pipe;
+ int tmp;
+
+ int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
+ int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
+ int aud_config = HSW_AUD_CFG(pipe);
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+
+
+ DRM_DEBUG_DRIVER(HDMI: Haswell Audio initialize\n);
+
+ /* Audio output enable */
+ DRM_DEBUG_DRIVER(HDMI audio: enable codec\n);
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= (AUDIO_OUTPUT_ENABLE_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n, tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n, tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX | AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ i = I915_READ(aud_cntl_st);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
= PortB */
+ if (!i) {
+ DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
+ /* operate blindly on all ports */
+ eldv = AUDIO_ELD_VALID_A;
+ eldv |= AUDIO_ELD_VALID_B;
+ eldv |= AUDIO_ELD_VALID_C;
+ } else {
+ DRM_DEBUG_DRIVER(ELD on port %c\n, 'A' + i);
+ eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
+ }
+
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
+ eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
+ I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
+ } else
+ I915_WRITE(aud_config, 0);
+
+ if (intel_eld_uptodate(connector,
+ aud_cntrl_st2, eldv,
+ aud_cntl_st, IBX_ELD_ADDRESS,
+ hdmiw_hdmiedid))
+ return;
+
+ i = I915_READ(aud_cntrl_st2);
+ i = ~eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+ if (!eld[0])
+ return;
+
+ i = I915_READ(aud_cntl_st);
+ i = ~IBX_ELD_ADDRESS;
+ I915_WRITE(aud_cntl_st, i);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
= PortB */
+ DRM_DEBUG_DRIVER(port num:%d\n, i);
+
+ len = min_t(uint8_t, eld[2], 21); /* 84 bytes of hw ELD buffer */
+ DRM_DEBUG_DRIVER(ELD size %d\n, len);
+ for (i = 0; i len; i++)
+ I915_WRITE(hdmiw_hdmiedid, *((uint32_t *)eld + i));
+
+ i = I915_READ(aud_cntrl_st2);
+ i |= eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+}
+
static void ironlake_write_eld(struct drm_connector *connector,
struct drm_crtc *crtc)
{
@@ -7041,7 +7137,7 @@ static void intel_init_display(struct drm_device *dev
Re: [Intel-gfx] [PATCH v8 3/4] drm/i915: Haswell HDMI audio initialization
Hi Daniel/Imre,
Changelog for v8:
- enabled proper output port based on current pipe
This version patch works well on my sharkbay machine.
This revised version changelog (v7):
- add Wait for 1 vertical blank after enable audio output port
- configure pipe related transcoder instead of operate all transcoders blindly
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Thursday, August 16, 2012 2:15 PM
To: imre.d...@gmail.com; dan...@ffwll.ch
Cc: intel-gfx@lists.freedesktop.org; Wang, Xingchao
Subject: [PATCH v8 3/4] drm/i915: Haswell HDMI audio initialization
Added new haswell_write_eld() to initialize Haswell HDMI audio registers to
generate an unsolicited response to the audio controller driver to indicate
that
the controller sequence should start.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 98
+-
2 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h index 55aa10e..08f8b65 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4294,6 +4294,7 @@
#define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
HSW_AUD_DIG_CNVT_1, \
HSW_AUD_DIG_CNVT_2)
+#define DIP_PORT_SEL_MASK 0x3
#define HSW_AUD_EDID_DATA_A0x65050
#define HSW_AUD_EDID_DATA_B0x65150
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 70d30fc..3b70777 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5067,6 +5067,102 @@ static void g4x_write_eld(struct drm_connector
*connector,
I915_WRITE(G4X_AUD_CNTL_ST, i);
}
+static void haswell_write_eld(struct drm_connector *connector,
+ struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ struct drm_device *dev = crtc-dev;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int pipe = to_intel_crtc(crtc)-pipe;
+ int tmp;
+
+ int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
+ int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
+ int aud_config = HSW_AUD_CFG(pipe);
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+
+
+ DRM_DEBUG_DRIVER(HDMI: Haswell Audio initialize\n);
+
+ /* Audio output enable */
+ DRM_DEBUG_DRIVER(HDMI audio: enable codec\n);
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= (AUDIO_OUTPUT_ENABLE_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n, tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n, tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX |
AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ i = I915_READ(aud_cntl_st);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
=
PortB */
+ if (!i) {
+ DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
+ /* operate blindly on all ports */
+ eldv = AUDIO_ELD_VALID_A;
+ eldv |= AUDIO_ELD_VALID_B;
+ eldv |= AUDIO_ELD_VALID_C;
+ } else {
+ DRM_DEBUG_DRIVER(ELD on port %c\n, 'A' + i);
+ eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
+ }
+
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
+ eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
+ I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 =
DP */
+ } else
+ I915_WRITE(aud_config, 0);
+
+ if (intel_eld_uptodate(connector,
+aud_cntrl_st2, eldv,
+aud_cntl_st, IBX_ELD_ADDRESS,
+hdmiw_hdmiedid))
+ return;
+
+ i = I915_READ(aud_cntrl_st2);
+ i = ~eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+ if (!eld[0])
+ return;
+
+ i = I915_READ(aud_cntl_st);
+ i = ~IBX_ELD_ADDRESS;
+ I915_WRITE(aud_cntl_st, i);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
Re: [Intel-gfx] [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization
-Original Message-
From: Imre Deak [mailto:imre.d...@gmail.com]
Sent: Thursday, August 16, 2012 6:54 PM
To: Wang, Xingchao
Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org; przan...@gmail.com
Subject: Re: [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization
On Thu, Aug 16, 2012 at 6:45 AM, Wang Xingchao xingchao.w...@intel.com
wrote:
On Wed, Aug 15, 2012 at 08:05:14PM +0300, Imre Deak wrote:
On Wed, Aug 15, 2012 at 6:27 AM, Wang, Xingchao
xingchao.w...@intel.com wrote:
[...]
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n,
tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n,
tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX |
AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ i = I915_READ(aud_cntl_st);
+ i = (i 29) DIP_PORT_SEL_MASK; /*
DIP_Port_Select, 0x1 =
PortB */
+ if (!i) {
+ DRM_DEBUG_DRIVER(Audio directed to unknown
port\n);
+ /* operate blindly on all ports */
+ eldv = AUDIO_ELD_VALID_A;
+ eldv |= AUDIO_ELD_VALID_B;
+ eldv |= AUDIO_ELD_VALID_C;
+ } else {
+ DRM_DEBUG_DRIVER(ELD on port %c\n, 'A' + i);
+ eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
+ }
Again, if we handle the ELD_VALID bits on a transcoder basis, as
above when enabling and disabling it, why are we doing it here
differently, on a port basis?
A bit different. These bits[30:29] reflects which port is used to
transmit DIP data. It's configured in other register, see
PIPE_DDI_FUNC_CTL, that determines which DDI port would be combined
with current pipe. I think it's also transcoder basis. please note
aud_cntl_st is
also pipe based.
On new HW it shouldn't matter which port is used to transmit the DIP data for
the ELD configuration. Earlier in the code you have picked the ELD_VALID_X bit
based on the pipe:
tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
and written this to the AUD_PIN_ELD_CP_VLD register . Here you pick the
same bit based on the port:
eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
and write this to the same AUD_PIN_ELD_CP_VLD register. The definition from
the spec for this register is the same though in both cases: the ELD valid bit
should be picked based on the transcoder, no matter what port is used to
transfer the data.
Thanks for clarification. As it's pipe/transcoder basis for ELD bits on
Haswell, I agree just set the specific active transcoder,
For older hardware, we just left the code there, is that okay for you?
I cannot test this right now, since I don't have an HSW machine set up here.
Could you Wang give a try to the following diff on top of your patch?
I tested your patch and it just works well as before. It's more clear now.
I will add your change to patch and send it to Daniel, is that okay?
Thanks a lot, Imre. :)
--xingchao
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a3339a..0776f71 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5113,18 +5113,7 @@ static void haswell_write_eld(struct
drm_connector *connector,
DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
- i = I915_READ(aud_cntl_st);
- i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
=
PortB */
- if (!i) {
- DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
- /* operate blindly on all ports */
- eldv = AUDIO_ELD_VALID_A;
- eldv |= AUDIO_ELD_VALID_B;
- eldv |= AUDIO_ELD_VALID_C;
- } else {
- DRM_DEBUG_DRIVER(ELD on port %c\n, 'A' + i);
- eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
- }
+ eldv = AUDIO_ELD_VALID_A (pipe * 4);
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
Thanks,
Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 3/4] drm/i915: Haswell HDMI audio initialization
Added new haswell_write_eld() to initialize Haswell HDMI audio registers
to generate an unsolicited response to the audio controller driver to
indicate that the controller sequence should start.
Reviewed-by: Imre Deak imre.d...@intel.com
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 87 +-
2 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55aa10e..08f8b65 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4294,6 +4294,7 @@
#define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
HSW_AUD_DIG_CNVT_1, \
HSW_AUD_DIG_CNVT_2)
+#define DIP_PORT_SEL_MASK0x3
#define HSW_AUD_EDID_DATA_A 0x65050
#define HSW_AUD_EDID_DATA_B 0x65150
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 70d30fc..8df8c30 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5067,6 +5067,91 @@ static void g4x_write_eld(struct drm_connector
*connector,
I915_WRITE(G4X_AUD_CNTL_ST, i);
}
+static void haswell_write_eld(struct drm_connector *connector,
+struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ struct drm_device *dev = crtc-dev;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int pipe = to_intel_crtc(crtc)-pipe;
+ int tmp;
+
+ int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
+ int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
+ int aud_config = HSW_AUD_CFG(pipe);
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+
+
+ DRM_DEBUG_DRIVER(HDMI: Haswell Audio initialize\n);
+
+ /* Audio output enable */
+ DRM_DEBUG_DRIVER(HDMI audio: enable codec\n);
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= (AUDIO_OUTPUT_ENABLE_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n, tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n, tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX | AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ eldv = AUDIO_ELD_VALID_A (pipe * 4);
+
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
+ eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
+ I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
+ } else
+ I915_WRITE(aud_config, 0);
+
+ if (intel_eld_uptodate(connector,
+ aud_cntrl_st2, eldv,
+ aud_cntl_st, IBX_ELD_ADDRESS,
+ hdmiw_hdmiedid))
+ return;
+
+ i = I915_READ(aud_cntrl_st2);
+ i = ~eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+ if (!eld[0])
+ return;
+
+ i = I915_READ(aud_cntl_st);
+ i = ~IBX_ELD_ADDRESS;
+ I915_WRITE(aud_cntl_st, i);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
= PortB */
+ DRM_DEBUG_DRIVER(port num:%d\n, i);
+
+ len = min_t(uint8_t, eld[2], 21); /* 84 bytes of hw ELD buffer */
+ DRM_DEBUG_DRIVER(ELD size %d\n, len);
+ for (i = 0; i len; i++)
+ I915_WRITE(hdmiw_hdmiedid, *((uint32_t *)eld + i));
+
+ i = I915_READ(aud_cntrl_st2);
+ i |= eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+}
+
static void ironlake_write_eld(struct drm_connector *connector,
struct drm_crtc *crtc)
{
@@ -7041,7 +7126,7 @@ static void intel_init_display(struct drm_device *dev)
dev_priv-display.write_eld = ironlake_write_eld;
} else if (IS_HASWELL(dev)) {
dev_priv-display.fdi_link_train = hsw_fdi_link_train;
- dev_priv-display.write_eld = ironlake_write_eld;
+ dev_priv-display.write_eld = haswell_write_eld;
} else
dev_priv-display.update_wm = NULL;
} else if (IS_G4X
Re: [Intel-gfx] [PATCH v9 3/4] drm/i915: Haswell HDMI audio initialization
Hi Daniel,
This is the last version of patch 3/4, reviewd by Imre, tested on my sharkbay
machine, HDMI audio works well.
You can apply it now. :)
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Thursday, August 16, 2012 10:44 PM
To: imre.d...@gmail.com; dan...@ffwll.ch
Cc: intel-gfx@lists.freedesktop.org; Wang, Xingchao
Subject: [PATCH v9 3/4] drm/i915: Haswell HDMI audio initialization
Added new haswell_write_eld() to initialize Haswell HDMI audio registers to
generate an unsolicited response to the audio controller driver to indicate
that
the controller sequence should start.
Reviewed-by: Imre Deak imre.d...@intel.com
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 87
+-
2 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h index 55aa10e..08f8b65 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4294,6 +4294,7 @@
#define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
HSW_AUD_DIG_CNVT_1, \
HSW_AUD_DIG_CNVT_2)
+#define DIP_PORT_SEL_MASK 0x3
#define HSW_AUD_EDID_DATA_A0x65050
#define HSW_AUD_EDID_DATA_B0x65150
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 70d30fc..8df8c30 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5067,6 +5067,91 @@ static void g4x_write_eld(struct drm_connector
*connector,
I915_WRITE(G4X_AUD_CNTL_ST, i);
}
+static void haswell_write_eld(struct drm_connector *connector,
+ struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ struct drm_device *dev = crtc-dev;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int pipe = to_intel_crtc(crtc)-pipe;
+ int tmp;
+
+ int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
+ int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
+ int aud_config = HSW_AUD_CFG(pipe);
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+
+
+ DRM_DEBUG_DRIVER(HDMI: Haswell Audio initialize\n);
+
+ /* Audio output enable */
+ DRM_DEBUG_DRIVER(HDMI audio: enable codec\n);
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= (AUDIO_OUTPUT_ENABLE_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n, tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n, tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX |
AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ eldv = AUDIO_ELD_VALID_A (pipe * 4);
+
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+ DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
+ eld[5] |= (1 2); /* Conn_Type, 0x1 = DisplayPort */
+ I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 =
DP */
+ } else
+ I915_WRITE(aud_config, 0);
+
+ if (intel_eld_uptodate(connector,
+aud_cntrl_st2, eldv,
+aud_cntl_st, IBX_ELD_ADDRESS,
+hdmiw_hdmiedid))
+ return;
+
+ i = I915_READ(aud_cntrl_st2);
+ i = ~eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+ if (!eld[0])
+ return;
+
+ i = I915_READ(aud_cntl_st);
+ i = ~IBX_ELD_ADDRESS;
+ I915_WRITE(aud_cntl_st, i);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
=
PortB */
+ DRM_DEBUG_DRIVER(port num:%d\n, i);
+
+ len = min_t(uint8_t, eld[2], 21); /* 84 bytes of hw ELD buffer */
+ DRM_DEBUG_DRIVER(ELD size %d\n, len);
+ for (i = 0; i len; i++)
+ I915_WRITE(hdmiw_hdmiedid, *((uint32_t *)eld + i));
+
+ i = I915_READ(aud_cntrl_st2);
+ i |= eldv;
+ I915_WRITE(aud_cntrl_st2, i);
+
+}
+
static void ironlake_write_eld(struct drm_connector *connector,
struct drm_crtc *crtc)
{
@@ -7041,7 +7126,7 @@ static void intel_init_display(struct drm_device
*dev
