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