[alsa-devel] [PATCH v3 2/6] ASoC: hdac-hdmi: Add hdmi driver

[Takashi Iwai]

On Mon, 09 Nov 2015 05:39:20 +0100,
Vinod Koul wrote:
> 
> On Wed, Nov 04, 2015 at 02:48:45PM +0000, Mark Brown wrote:
> > > > > +	/*
> > > > > +	 * Currently on board only 1 pin and 1 converter enabled for
> > > > > +	 * simplification, more will be added eventually
> > > > > +	 * So using fixed map for dai_id:pin:cvt
> > > > > +	 */
> > > > > +	return hdac_hdmi_init_dai_map(edev, &hdmi->dai_map[0], hdmi->pin_nid[0],
> > > > > +			hdmi->cvt_nid[0], 0);
> > 
> > > > I'm not entirely sure I understand what this is all doing.  It looks
> > > > like it's trying to translate the HDA widget map into a DAPM map which
> > > > seems sensible but it appears it's making some simplifying assumptions
> > > > about the device it's dealing with?
> > 
> > > The device is actually quite simple and yes we simplified even further by
> > > ignoring multiple pins for now. We will keep adding more features and adding
> > > stuff to map as we go along..
> > 
> > That's not giving me a clear picture of what the code is doing or how
> > we're working with the device - we've got some code parsing the HDA
> > graph, some code hard coding things and I don't really know why or how
> > anything fits together so I'm a bit nonplussed about what I'm reviewing
> > here.
> 
> Sorry for late reply, somehow seemed to miss this earlier..
> 
> Here is the complete picture let me know if things are not clear
> 
> This code has below structure (from the specs).
> 
> 			Root Node (0)
> 			     |
> 			   AFG  (1)
> 			     |
> 	Converter (2) ----------------	Pin Widget (5)
> 			     |
> 	Converter (3) ----------------	Pin Widget (6)
> 			     |
> 	Converter (4) ----------------	Pin Widget (7)
> 			     |
> 			Vendor Widget (8)
> 
> Numbers in braces indicated NID values for these nodes
> 
> Currently we are using only one pin which is used on our ref board and seems
> to be default config.
> After the base driver is done we will add code to enumerate all the nodes.
> Based on node capability we will parse and add widgets for all the queried
> nodes. So for this case will be 3 nodes and 3 widgets created
> 
> Since coding for each widget would not make sense so we created a generic
> function hdac_hdmi_init_dai_map() based on the node passed which we will use
> later for all the queried pins

Note that the mapping between converters and pins are arbitrary on
many HDMI/DP codecs.  Although it's implicitly implemented as 1:1 on a
few Intel codecs (in GPU), with the extension of MST, the routing will
be again dynamic, too.  Also, many codecs have amp on converter or pin
in addition.

Since it's targeted only for ASoC skylake and upward, it's fine to
start from the simplest assumption.  But you need to make clear how
generic your driver will support in feature, as the code complexity
will depend on it.


Takashi