lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hefmvpgwe.wl-tiwai@suse.de>
Date:   Fri, 12 Jan 2018 10:26:09 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     " Kumar, Abhijeet " <abhijeet.kumar@...el.com>
Cc:     "Vinod Koul" <vinod.koul@...el.com>, <alsa-devel@...a-project.org>,
        "Liam Girdwood" <lgirdwood@...il.com>,
        "Guneshwor Singh" <guneshwor.o.singh@...el.com>,
        "Jeeja KP" <jeeja.kp@...el.com>,
        "Sandeep Tayal" <sandeepx.tayal@...el.com>,
        "Subhransu S. Prusty" <subhransu.s.prusty@...el.com>,
        "Mark Brown" <broonie@...nel.org>,
        "Jaroslav Kysela" <perex@...ex.cz>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: hdac_hdmi: Ensuring proper setting of output widget power state

On Fri, 12 Jan 2018 09:25:54 +0100,
 Kumar, Abhijeet  wrote:
> 
> 
> 
> On 1/12/2018 11:16 AM, Vinod Koul wrote:
> > On Thu, Jan 11, 2018 at 05:04:27PM +0530, abhijeet.kumar@...el.com wrote:
> >> From: Abhijeet Kumar <abhijeet.kumar@...el.com>
> >>
> >> When we change the resolution of DP pannel or hot plug-unplug it while
> >> playing an audio clip,sometimes we observe a silent playback(no audio).
> > can you rephrase this please
> done please review v2!
> >> During no audio condition, we have noticed that the power state of the
> >> pin or the connector is D3. Optimzing the way we set the power could
> >> mitigate the issue.With this changes the verb is sent to set the power
> > space after .
> >
> >> state and response is received. Thus ensuring power state is set.
> > am not sure I fully understood the problem here
> 
> This appears to be an timing issue, while performing a stress test, we
> found out that sometimes either pin or converters are not powered
> up. Thus ensuring it that the power state is set correctly.
> 
> >
> >> Signed-off-by: Abhijeet Kumar <abhijeet.kumar@...el.com>
> >> ---
> >>   sound/soc/codecs/hdac_hdmi.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c
> >> index f3b4f4dfae6a..e24caecf0a4f 100644
> >> --- a/sound/soc/codecs/hdac_hdmi.c
> >> +++ b/sound/soc/codecs/hdac_hdmi.c
> >> @@ -718,7 +718,7 @@ static void hdac_hdmi_set_power_state(struct hdac_ext_device *edev,
> >>   {
> >>   	if (get_wcaps(&edev->hdac, nid) & AC_WCAP_POWER) {
> >>   		if (!snd_hdac_check_power_state(&edev->hdac, nid, pwr_state))
> >> -			snd_hdac_codec_write(&edev->hdac, nid, 0,
> >> +			snd_hdac_codec_read(&edev->hdac, nid, 0,
> > how does read help instead of write?
> 
> Indeed i'm making use of read instead of write to send the set command.
> 
> But unlike codec_write, codec_read send the verb synchronously. Maybe
> if you read the comment while powering up and down in
> hdmi_codec_prepare and hdmi_codec_complete you would understand
> better.
> 
> "codec_read is preferred over codec_write to set the power state.
> 
> This way verb is send to set the power state and response is
> received. So setting power state is ensured without using loop to read
> the state."

It's better, but doesn't guarantee that the node reached the given
power state.  codec_read assures that the verb is sent and the codec
gives the response.  But it means only the target state gets updated,
and doesn't mean that the actual state reached.


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ