On Mon, Nov 09, 2015 at 08:51:11AM +0100, Takashi Iwai wrote: > 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. Yes that is why we didn't say converter pin pair although by looking at diagram one can assume that and in many case it is true but we should not rely on this in our code > 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. So right now we are going to use 1:1 mapping as simple design but the thinking from us is that we should add DAPM widgets for converters and pins and routing to pin should be decided by DAPM map. The converter to pin configuration should be derived by the user settings. -- ~Vinod _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
