[alsa-devel] [RFC]Connection list of hda widget

[Takashi Iwai]

At Fri, 8 Feb 2013 06:33:46 +0800,
Raymond Yau wrote:
> 
> > > >
> > > > Treat vendor defined widget different from audio selector/audio input
> > > > widget since hda_proc.c query the connection list of vendor defined
> widget
> > > >
> > > > ADI codecs  have vendor defined widgets ( BIAS Power-Down and VREF
> > > > Power-Down) which have connection list
> > > >
> > > > static void print_conn_list(struct snd_info_buffer *buffer,
> > > >      struct hda_codec *codec, hda_nid_t nid,
> > > >      unsigned int wid_type, hda_nid_t *conn,
> > > >      int conn_len)
> > > > {
> > > > int c, curr = -1;
> > > >
> > > > if (conn_len > 1 &&
> > > >      wid_type != AC_WID_AUD_MIX &&
> > > >      wid_type != AC_WID_VOL_KNB &&
> > > > +     wide_type != AC_WID_VENDOR &&
> > > >      wid_type != AC_WID_POWER)
> > > > curr = snd_hda_codec_read(codec, nid, 0,
> > > >    AC_VERB_GET_CONNECT_SEL, 0);
> > > > snd_iprintf(buffer, "  Connection: %d\n", conn_len);
> > > >
> > >
> > > I think there are some Sigmatel/IDT (or was it Analog Devices?) codecs
> > > that actually have sensible connections for their vendor specific nodes,
> > > so I would prefer not to change this.
> 
> Do you mean other codecs  have vendor defined widgets which support
> AC_VERB_GET_CONNECT_SEL ?

Possibly, who knows.  It's a vendor-specific widget, after all.

> 
> 7.1.2 Node Addressing
> 
> Each entry in the connection list is one NID; it may be an independent NID,
> indicating a single node, or may be part of a 2-tuple of NIDs delineating a
> continuous range of nodes.  The high order bit of each entry indicates how
> it is to be interpreted (see Figure 51).  If the range indicator is set,
> that list entry forms a range with the previous list entry; i.e., if the
> range bit were set on the third list entry, then the second and third
> entries form a range, and the first entry is an independent NID.  The range
> indicator may not be set in the first entry of a connection list nor may it
> be set on any two sequential list entries.  The connection list thus
> provides a set of optional inputs to the node.  A connection selector
> (control) allows run-time control over which input is used
> 
> >
> > Right.  The widget connection longer than 32 itself is OK. It's just
> > ugly.  That being said, it's basically a bug that we restrict the max
> > connection size in the core code.
> 
> Node 0x23 [Vendor Defined Widget] wcaps 0xf00100: Mono
>    Connection: 18
>       0x11* 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x24 0x25 0x38 0x39 0x3a
> 0x3b 0x3c 0x3d 0x20 0x21
> 
> The length  is 8 and the number of  nodes  in the connection list is 18

Do you mean NID 0x23 returns AC_PAR_CONNLIST_LEN = 8, but contains
more nodes because of range definitions?  Or what do you mean exactly?

> Node 0x2f [Vendor Defined Widget] wcaps 0xf00100: Mono
>     Connection: 6
> 0x11* 0x12 0x14 0x15 0x16 0x17
> 
> My proposed patch just remove "*" from the connection list since there is
> no way to know the vendor defined widget support the verb GET_CONNECT_SELECT

You should have written _this_ text at the first place!
The biggest problem is that your description doesn't match with what
you write in your patch.

But still, it's still an open question.  In the specification, the use
of selector isn't prohibited for vendor-spec widgets.  So, some crazy
h/w designer may think of it.


thanks,

Takashi
> 
> 
> Node 0x19 [Power Widget] wcaps 0x500500: Mono
>   Power: 0x0
>     Connection: 2
>       0x20* 0x21