Hi Takashi, > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@xxxxxxx] > Sent: Wednesday, September 28, 2016 3:57 PM > To: Yang, Libin <libin.yang@xxxxxxxxx> > Cc: libin.yang@xxxxxxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; Lin, Mengdong > <mengdong.lin@xxxxxxxxx> > Subject: Re: [RFC PATCH 0/3] support DP MST audio > > On Wed, 28 Sep 2016 04:50:53 +0200, > Yang, Libin wrote: > > > > Hi Takashi, > > > > > > > If so, now my question again: for devid!=0, which connections > > > > > are given statically? In other words, how many devid would be > passed? > > > > > > > > For the connection list, it is static. It will be initialized at bootup. > > > > > > So this is only about devid=0, right? For devid!=0, there wouldn't > > > be anything else than pin/cvt connections, correct? > > > > Devid != 0 is the same as devid = 0. And there is only pin/cvt connections. > > > > My basic idea is: > > 1. Every device entry use a virtual pin > > OK. > > > 2. Each device entry will be initialized at bootup even it is not in MST mode. > > Here starts unclearness. How "*each* device entry" will be enumerated at > boot up time? The device id can be arbitrary numbers, per spec. This is a good question. We really met such issue. We currently is to judge whether it is support MST or not (if it is haswell_plus, then it supports MST). We didn't use snd_hda_get_num_devices() to get the device number. And if it is MST, then everything works well, each per_pin represents a device entry. If it is NON-MST, the device id means nothing, and snd_hda_set_dev_select() does nothing. So we will use the first device entry (dev_id = 0) to represent the pin. > > And "even it is not in MST" means the devices that aren't capable MST (like > SandyBridge HDMI/DP)? Or it's meant "even when no monitor is connected > via MST"? I mean " even when no monitor is connected via MST". Actually, when initialization, driver will judge the platform supports MST or not (for intel, only haswell_plus support MST). > > > This means after bootup, mode change will not add/remove the per_pin. > > What here "mode" means exactly? Mode means MST mode or NON_MST mode. > > > 3. All device entries under the same pin will use the same connection list. > > And the connection list is initialized at bootup. It will be saved in > > per_pin->mux_nids. This will never be changed after bootup. > > (However the pin-cvt connection is dynamically assigned when > > necessary.) > > > > > > > > > For the pin and cvt actual connection, it is dynamically assigned. > > > > > > ... but you still want to cache this to an (ever-growing) array for > > > the standard connection lists. That's what I was concerned. > > > > Do you mean codec->conn_list? If we don't use the dev_id and all the > > device entries under the same pin use the same one, it will be exactly > > the same as before. > > But you touch the whole codes doing the connection list caching even by > adding the dev_id field. Why this is needed if you don't use the dev_id...? > > Again, try not to mess up the core code as a start. The virtual pin concept is > OK as long as it's self-contained in the HDMI codec driver. And adding some > basic calls to handle the device id is fine. > But the way to change as in patch 1 can't be included without the enough > justification. Yes, I understand and I will refine the patch and not touch the connection list core code in next patchset. In the new patch, dev_id will not be used in connection list. I will totally remove the patch 1. Regards, Libin > > > thanks, > > Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
