On Wed, 11 Jul 2018 12:56:03 +0200, Sriram Periyasamy wrote:
On Wed, Jul 11, 2018 at 12:03:14PM +0200, Takashi Iwai wrote:
On Wed, 11 Jul 2018 11:25:46 +0200, Sriram Periyasamy wrote:
On Wed, Jul 11, 2018 at 08:45:05AM +0200, Takashi Iwai wrote:
On Wed, 11 Jul 2018 08:30:43 +0200, Sriram Periyasamy wrote:
if (port->pin->conn_index > 0)snd_hdac_codec_write(&edev->hdev, port->pin->nid,0, AC_VERB_SET_CONNECT_SEL,port->pin->conn_index - 1);And, here checks conn_index > 0 while...
@@ -903,6 +931,9 @@ static int hdac_hdmi_set_pin_port_mux(struct snd_kcontrol *kcontrol, } }
- if (ucontrol->value.enumerated.item[0] > 0)
port->pin->conn_index = ucontrol->value.enumerated.item[0];... conn_index is set only non-zero here.
That is, once after a non-zero is passed, conn_index can't any longer back to zero. I guess it's not intentional?
No, it is intentional. For example, two ports are connected to the display and user land set mux only for one port. Hence other port's conn_index is set to default 0. When jack report happens for that port, we would be writing invalid connection select index which will lead to undefined hardware behaviour as per the HDA spec.
Though it is userland's mistake, it is better to take care in the driver.
Then wouldn't it be better to remember the last set value in hdac_hdmi_pin_mux_widget_event()? The purpose of the patch is to restore the previous state.
Since hdac_hdmi_pin_mux_widget_event() invoked only for current playback pin-port-mux path, we wouldn't restore other port's indices. So hdac_hdmi_jack_report() chosen which will restore other ports also in all use cases.
Hm, it sounds like really more black magic behind the scene. Please give more descriptions to the patch and/or codes.
Takashi