| Message ID | 1449523469-4395-14-git-send-email-subhransu.s.prusty@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 07 Dec 2015 22:24:28 +0100, Subhransu S. Prusty wrote: > > User space also need be notified of HDMI hotplug notification so > that it can select the appropriate device to route audio. > > Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> > Signed-off-by: Vinod Koul <vinod.koul@intel.com> > --- > sound/soc/codecs/hdac_hdmi.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c > index 008a29f..cce2af0 100644 > --- a/sound/soc/codecs/hdac_hdmi.c > +++ b/sound/soc/codecs/hdac_hdmi.c > @@ -24,6 +24,7 @@ > #include <linux/hdmi.h> > #include <drm/drm_edid.h> > #include <sound/pcm_params.h> > +#include <sound/jack.h> > #include <sound/soc.h> > #include <sound/hdaudio_ext.h> > #include <sound/hda_i915.h> > @@ -73,6 +74,7 @@ struct hdac_hdmi_pin { > struct hdac_ext_device *edev; > int repoll_count; > struct delayed_work work; > + struct snd_jack *jack; > }; > > struct hdac_hdmi_dai_pin_map { > @@ -905,6 +907,7 @@ static void hdac_hdmi_present_sense(struct hdac_hdmi_pin *pin, int repoll) > pin->eld.eld_valid = !!(val & AC_PINSENSE_ELDV); > > if (!pin->eld.monitor_present || !pin->eld.eld_valid) { > + snd_jack_report(pin->jack, 0); > dev_info(&edev->hdac.dev, "%s: disconnect or eld_invalid\n", > __func__); > goto put_hdac_device; > @@ -915,6 +918,7 @@ static void hdac_hdmi_present_sense(struct hdac_hdmi_pin *pin, int repoll) > if (hdac_hdmi_get_eld(&edev->hdac, pin->nid, > pin->eld.eld_buffer, > &pin->eld.eld_size) == 0) { > + snd_jack_report(pin->jack, SND_JACK_AVOUT); > print_hex_dump_bytes("Eld: ", DUMP_PREFIX_OFFSET, > pin->eld.eld_buffer, pin->eld.eld_size); > } else { > @@ -1173,6 +1177,7 @@ static int hdmi_codec_probe(struct snd_soc_codec *codec) > struct snd_soc_dapm_context *dapm = > snd_soc_component_get_dapm(&codec->component); > struct hdac_hdmi_pin *pin; > + char jack_name[NAME_SIZE]; > int ret; > > edev->scodec = codec; > @@ -1189,8 +1194,12 @@ static int hdmi_codec_probe(struct snd_soc_codec *codec) > return ret; > } > > - list_for_each_entry(pin, &hdmi->pin_list, head) > + list_for_each_entry(pin, &hdmi->pin_list, head) { > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); Such a name makes sense only to be compatible for PA, and then this string isn't compatible. Note that it's not about pin but for PCM stream. You may wonder why it matters -- see the whole discussion on MST support. Takashi
On Mon, Dec 07, 2015 at 05:18:06PM +0100, Takashi Iwai wrote: > On Mon, 07 Dec 2015 22:24:28 +0100, > > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); > > Such a name makes sense only to be compatible for PA, and then this > string isn't compatible. Note that it's not about pin but for PCM > stream. You may wonder why it matters -- see the whole discussion on > MST support. So in our case we have added only one PCM Backend in DSP. In codec we have one DAI supported, thus creating a DAIlink The Codec DAI is mapped to a stream which we fix to a CVT. Future we will add two more streams which are mapped to other two CVTs. We use MUX controls to allow user to specfiy how CVT and PINs are connected togther, this way we can route stream to any pin. Extending this concept, behind a pin for MST there may be different 'ports', right? Shouldn't that be another mux configuration :) So we can treat three streams coming to codec to be routed to any pin and then any port. Since we have only 3 CVTs we will have only 3 streams... Back on present :), what do you recommend for us for jack name. Thanks
On Tue, 08 Dec 2015 07:31:36 +0100, Vinod Koul wrote: > > On Mon, Dec 07, 2015 at 05:18:06PM +0100, Takashi Iwai wrote: > > On Mon, 07 Dec 2015 22:24:28 +0100, > > > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); > > > > Such a name makes sense only to be compatible for PA, and then this > > string isn't compatible. Note that it's not about pin but for PCM > > stream. You may wonder why it matters -- see the whole discussion on > > MST support. > > So in our case we have added only one PCM Backend in DSP. In codec we have > one DAI supported, thus creating a DAIlink > > The Codec DAI is mapped to a stream which we fix to a CVT. Future we > will add two more streams which are mapped to other two CVTs. > > We use MUX controls to allow user to specfiy how CVT and PINs are connected > togther, this way we can route stream to any pin. > > Extending this concept, behind a pin for MST there may be different 'ports', > right? Shouldn't that be another mux configuration :) So we can treat three > streams coming to codec to be routed to any pin and then any port. Since we > have only 3 CVTs we will have only 3 streams... You can't do that easily. Remember that you may connect up to 64 different devices at the same time per pin, and this can switch on the fly. How would you implement a MUX? Though, the max number of converters is limited, thus what you can actually use is defined by this constraint. Due to this, we'll likely manage MST for the legacy HDA by assigning MST devs dynamically to pins in a certain procedure to make things compatible. > Back on present :), what do you recommend for us for jack name. Depends on your purpose. If you want to keep it compatible, then use the compatible string. HTH, Takashi
On Tue, Dec 08, 2015 at 07:38:46AM +0100, Takashi Iwai wrote: > On Tue, 08 Dec 2015 07:31:36 +0100, > Vinod Koul wrote: > > > > On Mon, Dec 07, 2015 at 05:18:06PM +0100, Takashi Iwai wrote: > > > On Mon, 07 Dec 2015 22:24:28 +0100, > > > > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); > > > > > > Such a name makes sense only to be compatible for PA, and then this > > > string isn't compatible. Note that it's not about pin but for PCM > > > stream. You may wonder why it matters -- see the whole discussion on > > > MST support. > > > > So in our case we have added only one PCM Backend in DSP. In codec we have > > one DAI supported, thus creating a DAIlink > > > > The Codec DAI is mapped to a stream which we fix to a CVT. Future we > > will add two more streams which are mapped to other two CVTs. > > > > We use MUX controls to allow user to specfiy how CVT and PINs are connected > > togther, this way we can route stream to any pin. > > > > Extending this concept, behind a pin for MST there may be different 'ports', > > right? Shouldn't that be another mux configuration :) So we can treat three > > streams coming to codec to be routed to any pin and then any port. Since we > > have only 3 CVTs we will have only 3 streams... > > You can't do that easily. Remember that you may connect up to 64 > different devices at the same time per pin, and this can switch on the > fly. How would you implement a MUX? somehow I was under impression that it is 3.. Btw even if 64 devices can be connected how many can we render to? > Though, the max number of converters is limited, thus what you can > actually use is defined by this constraint. Due to this, we'll likely > manage MST for the legacy HDA by assigning MST devs dynamically to > pins in a certain procedure to make things compatible. but how many MST devs are you going to create? > > Back on present :), what do you recommend for us for jack name. > > Depends on your purpose. If you want to keep it compatible, then use > the compatible string. Since compatible string would mean specfying PCM, which we don;t know and is per machine driver dailink defination, we would go ahead with logical "HDMI/DP, Pin=%d Jack" names. Thanks
On Tue, 08 Dec 2015 08:42:16 +0100, Vinod Koul wrote: > > On Tue, Dec 08, 2015 at 07:38:46AM +0100, Takashi Iwai wrote: > > On Tue, 08 Dec 2015 07:31:36 +0100, > > Vinod Koul wrote: > > > > > > On Mon, Dec 07, 2015 at 05:18:06PM +0100, Takashi Iwai wrote: > > > > On Mon, 07 Dec 2015 22:24:28 +0100, > > > > > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); > > > > > > > > Such a name makes sense only to be compatible for PA, and then this > > > > string isn't compatible. Note that it's not about pin but for PCM > > > > stream. You may wonder why it matters -- see the whole discussion on > > > > MST support. > > > > > > So in our case we have added only one PCM Backend in DSP. In codec we have > > > one DAI supported, thus creating a DAIlink > > > > > > The Codec DAI is mapped to a stream which we fix to a CVT. Future we > > > will add two more streams which are mapped to other two CVTs. > > > > > > We use MUX controls to allow user to specfiy how CVT and PINs are connected > > > togther, this way we can route stream to any pin. > > > > > > Extending this concept, behind a pin for MST there may be different 'ports', > > > right? Shouldn't that be another mux configuration :) So we can treat three > > > streams coming to codec to be routed to any pin and then any port. Since we > > > have only 3 CVTs we will have only 3 streams... > > > > You can't do that easily. Remember that you may connect up to 64 > > different devices at the same time per pin, and this can switch on the > > fly. How would you implement a MUX? > > somehow I was under impression that it is 3.. Btw even if 64 devices can be > connected how many can we render to? That's what I meant below. Although you can may connect quite a lot of devices, the number of devices that can be actually output at the same time is limited, actually equal with the number of converters. > > Though, the max number of converters is limited, thus what you can > > actually use is defined by this constraint. Due to this, we'll likely > > manage MST for the legacy HDA by assigning MST devs dynamically to > > pins in a certain procedure to make things compatible. > > but how many MST devs are you going to create? This is exactly the point: for the legacy HDA, instead of creating the entry for each MST devices, they are assigned dynamically to PCM at activation. So the number of devices exposed to user-space is limited -- or better to say, user-space won't notice the difference. > > > Back on present :), what do you recommend for us for jack name. > > > > Depends on your purpose. If you want to keep it compatible, then use > > the compatible string. > > Since compatible string would mean specfying PCM, which we don;t know and is > per machine driver dailink defination, we would go ahead with logical > "HDMI/DP, Pin=%d Jack" names. But then it makes little sense. Multiple MST devices can be on the same pin. Takashi
On Tue, Dec 08, 2015 at 08:52:10AM +0100, Takashi Iwai wrote: > On Tue, 08 Dec 2015 08:42:16 +0100, > Vinod Koul wrote: > > > > On Tue, Dec 08, 2015 at 07:38:46AM +0100, Takashi Iwai wrote: > > > On Tue, 08 Dec 2015 07:31:36 +0100, > > > Vinod Koul wrote: > > > > > > > > On Mon, Dec 07, 2015 at 05:18:06PM +0100, Takashi Iwai wrote: > > > > > On Mon, 07 Dec 2015 22:24:28 +0100, > > > > > > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); > > > > > > > > > > Such a name makes sense only to be compatible for PA, and then this > > > > > string isn't compatible. Note that it's not about pin but for PCM > > > > > stream. You may wonder why it matters -- see the whole discussion on > > > > > MST support. > > > > > > > > So in our case we have added only one PCM Backend in DSP. In codec we have > > > > one DAI supported, thus creating a DAIlink > > > > > > > > The Codec DAI is mapped to a stream which we fix to a CVT. Future we > > > > will add two more streams which are mapped to other two CVTs. > > > > > > > > We use MUX controls to allow user to specfiy how CVT and PINs are connected > > > > togther, this way we can route stream to any pin. > > > > > > > > Extending this concept, behind a pin for MST there may be different 'ports', > > > > right? Shouldn't that be another mux configuration :) So we can treat three > > > > streams coming to codec to be routed to any pin and then any port. Since we > > > > have only 3 CVTs we will have only 3 streams... > > > > > > You can't do that easily. Remember that you may connect up to 64 > > > different devices at the same time per pin, and this can switch on the > > > fly. How would you implement a MUX? > > > > somehow I was under impression that it is 3.. Btw even if 64 devices can be > > connected how many can we render to? > > That's what I meant below. Although you can may connect quite a lot > of devices, the number of devices that can be actually output at the > same time is limited, actually equal with the number of converters. Okay got it now, that is how my 3 limit for MST is coming from as we have 3 CVTs so we can actually stream to only 3 devices per port although someone may theoretically connect 64! > > > Though, the max number of converters is limited, thus what you can > > > actually use is defined by this constraint. Due to this, we'll likely > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > pins in a certain procedure to make things compatible. > > > > but how many MST devs are you going to create? > > This is exactly the point: for the legacy HDA, instead of creating the > entry for each MST devices, they are assigned dynamically to PCM at > activation. So the number of devices exposed to user-space is > limited -- or better to say, user-space won't notice the difference. And how many PCMs are you proposing for MST? > > > > Back on present :), what do you recommend for us for jack name. > > > > > > Depends on your purpose. If you want to keep it compatible, then use > > > the compatible string. > > > > Since compatible string would mean specfying PCM, which we don;t know and is > > per machine driver dailink defination, we would go ahead with logical > > "HDMI/DP, Pin=%d Jack" names. > > But then it makes little sense. Multiple MST devices can be on the > same pin. Well am not supporting MST at the moment. How is legacy handling this, how do you report jack for 64 X 3 devices :) Or, are you reporting jack for PCMs based on connection to pin/device, I think latter. But then you would hit limit of PCMs, I assume you maybe doing 9 PCMs for this, so if someone connects 10th device we won't report it's jack?
On Tue, 08 Dec 2015 09:38:31 +0100, Vinod Koul wrote: > > On Tue, Dec 08, 2015 at 08:52:10AM +0100, Takashi Iwai wrote: > > On Tue, 08 Dec 2015 08:42:16 +0100, > > Vinod Koul wrote: > > > > > > On Tue, Dec 08, 2015 at 07:38:46AM +0100, Takashi Iwai wrote: > > > > On Tue, 08 Dec 2015 07:31:36 +0100, > > > > Vinod Koul wrote: > > > > > > > > > > On Mon, Dec 07, 2015 at 05:18:06PM +0100, Takashi Iwai wrote: > > > > > > On Mon, 07 Dec 2015 22:24:28 +0100, > > > > > > > + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); > > > > > > > > > > > > Such a name makes sense only to be compatible for PA, and then this > > > > > > string isn't compatible. Note that it's not about pin but for PCM > > > > > > stream. You may wonder why it matters -- see the whole discussion on > > > > > > MST support. > > > > > > > > > > So in our case we have added only one PCM Backend in DSP. In codec we have > > > > > one DAI supported, thus creating a DAIlink > > > > > > > > > > The Codec DAI is mapped to a stream which we fix to a CVT. Future we > > > > > will add two more streams which are mapped to other two CVTs. > > > > > > > > > > We use MUX controls to allow user to specfiy how CVT and PINs are connected > > > > > togther, this way we can route stream to any pin. > > > > > > > > > > Extending this concept, behind a pin for MST there may be different 'ports', > > > > > right? Shouldn't that be another mux configuration :) So we can treat three > > > > > streams coming to codec to be routed to any pin and then any port. Since we > > > > > have only 3 CVTs we will have only 3 streams... > > > > > > > > You can't do that easily. Remember that you may connect up to 64 > > > > different devices at the same time per pin, and this can switch on the > > > > fly. How would you implement a MUX? > > > > > > somehow I was under impression that it is 3.. Btw even if 64 devices can be > > > connected how many can we render to? > > > > That's what I meant below. Although you can may connect quite a lot > > of devices, the number of devices that can be actually output at the > > same time is limited, actually equal with the number of converters. > > Okay got it now, that is how my 3 limit for MST is coming from as we > have 3 CVTs so we can actually stream to only 3 devices per port > although someone may theoretically connect 64! > > > > > Though, the max number of converters is limited, thus what you can > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > pins in a certain procedure to make things compatible. > > > > > > but how many MST devs are you going to create? > > > > This is exactly the point: for the legacy HDA, instead of creating the > > entry for each MST devices, they are assigned dynamically to PCM at > > activation. So the number of devices exposed to user-space is > > limited -- or better to say, user-space won't notice the difference. > > And how many PCMs are you proposing for MST? 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we provide the reserved slots just for the compatible behavior that assumes the static pin/slot assignment. > > > > > Back on present :), what do you recommend for us for jack name. > > > > > > > > Depends on your purpose. If you want to keep it compatible, then use > > > > the compatible string. > > > > > > Since compatible string would mean specfying PCM, which we don;t know and is > > > per machine driver dailink defination, we would go ahead with logical > > > "HDMI/DP, Pin=%d Jack" names. > > > > But then it makes little sense. Multiple MST devices can be on the > > same pin. > > Well am not supporting MST at the moment. How is legacy handling this, > how do you report jack for 64 X 3 devices :) > > Or, are you reporting jack for PCMs based on connection to pin/device, I > think latter. Yes, the jack reporting is for PCM in this case, which is I mentioned in the first reply: it's not about pin but PCM. > But then you would hit limit of PCMs, I assume you maybe doing 9 PCMs for > this, so if someone connects 10th device we won't report it's jack? The jack reporting is done actually at the time the audio is enabled/disabled. And at this moment, the PCM assignment is assured as well. So, to user-space, only the actually usable devices are exposed no matter how many devices are plugged. Takashi
On Tue, Dec 08, 2015 at 09:42:09AM +0100, Takashi Iwai wrote: > > Okay got it now, that is how my 3 limit for MST is coming from as we > > have 3 CVTs so we can actually stream to only 3 devices per port > > although someone may theoretically connect 64! > > > > > > > Though, the max number of converters is limited, thus what you can > > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > > pins in a certain procedure to make things compatible. > > > > > > > > but how many MST devs are you going to create? > > > > > > This is exactly the point: for the legacy HDA, instead of creating the > > > entry for each MST devices, they are assigned dynamically to PCM at > > > activation. So the number of devices exposed to user-space is > > > limited -- or better to say, user-space won't notice the difference. > > > > And how many PCMs are you proposing for MST? > > 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we > provide the reserved slots just for the compatible behavior that > assumes the static pin/slot assignment. > > > > > > > Back on present :), what do you recommend for us for jack name. > > > > > > > > > > Depends on your purpose. If you want to keep it compatible, then use > > > > > the compatible string. > > > > > > > > Since compatible string would mean specfying PCM, which we don;t know and is > > > > per machine driver dailink defination, we would go ahead with logical > > > > "HDMI/DP, Pin=%d Jack" names. > > > > > > But then it makes little sense. Multiple MST devices can be on the > > > same pin. > > > > Well am not supporting MST at the moment. How is legacy handling this, > > how do you report jack for 64 X 3 devices :) > > > > Or, are you reporting jack for PCMs based on connection to pin/device, I > > think latter. > > Yes, the jack reporting is for PCM in this case, which is I mentioned > in the first reply: it's not about pin but PCM. > > > But then you would hit limit of PCMs, I assume you maybe doing 9 PCMs for > > this, so if someone connects 10th device we won't report it's jack? > > The jack reporting is done actually at the time the audio is > enabled/disabled. And at this moment, the PCM assignment is assured > as well. So, to user-space, only the actually usable devices are > exposed no matter how many devices are plugged. Yes that was my thinking based on discussion and patches posted by Libin. But one more question who does PCM assignment, looking at patches it seems driver and no way to change that.. For example I have 10 devices connected and we have 5 PCMs. I would like to route to 7th device, how would that be done? Thanks
On Tue, 08 Dec 2015 11:20:59 +0100, Vinod Koul wrote: > > On Tue, Dec 08, 2015 at 09:42:09AM +0100, Takashi Iwai wrote: > > > Okay got it now, that is how my 3 limit for MST is coming from as we > > > have 3 CVTs so we can actually stream to only 3 devices per port > > > although someone may theoretically connect 64! > > > > > > > > > Though, the max number of converters is limited, thus what you can > > > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > > > pins in a certain procedure to make things compatible. > > > > > > > > > > but how many MST devs are you going to create? > > > > > > > > This is exactly the point: for the legacy HDA, instead of creating the > > > > entry for each MST devices, they are assigned dynamically to PCM at > > > > activation. So the number of devices exposed to user-space is > > > > limited -- or better to say, user-space won't notice the difference. > > > > > > And how many PCMs are you proposing for MST? > > > > 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we > > provide the reserved slots just for the compatible behavior that > > assumes the static pin/slot assignment. > > > > > > > > > Back on present :), what do you recommend for us for jack name. > > > > > > > > > > > > Depends on your purpose. If you want to keep it compatible, then use > > > > > > the compatible string. > > > > > > > > > > Since compatible string would mean specfying PCM, which we don;t know and is > > > > > per machine driver dailink defination, we would go ahead with logical > > > > > "HDMI/DP, Pin=%d Jack" names. > > > > > > > > But then it makes little sense. Multiple MST devices can be on the > > > > same pin. > > > > > > Well am not supporting MST at the moment. How is legacy handling this, > > > how do you report jack for 64 X 3 devices :) > > > > > > Or, are you reporting jack for PCMs based on connection to pin/device, I > > > think latter. > > > > Yes, the jack reporting is for PCM in this case, which is I mentioned > > in the first reply: it's not about pin but PCM. > > > > > But then you would hit limit of PCMs, I assume you maybe doing 9 PCMs for > > > this, so if someone connects 10th device we won't report it's jack? > > > > The jack reporting is done actually at the time the audio is > > enabled/disabled. And at this moment, the PCM assignment is assured > > as well. So, to user-space, only the actually usable devices are > > exposed no matter how many devices are plugged. > > Yes that was my thinking based on discussion and patches posted by Libin. > But one more question who does PCM assignment, looking at patches it seems > driver and no way to change that.. > > For example I have 10 devices connected and we have 5 PCMs. > I would like to route to 7th device, how would that be done? Manage xrandr to enable the target monitor. Then one PCM stream will be switched to the corresponding audio, and it'll be notified to user-space. Takashi
On Tue, Dec 08, 2015 at 11:28:16AM +0100, Takashi Iwai wrote: > > Yes that was my thinking based on discussion and patches posted by Libin. > > But one more question who does PCM assignment, looking at patches it seems > > driver and no way to change that.. > > > > For example I have 10 devices connected and we have 5 PCMs. > > I would like to route to 7th device, how would that be done? > > Manage xrandr to enable the target monitor. Then one PCM stream will > be switched to the corresponding audio, and it'll be notified to > user-space. Thanks, that helps.. Looking at RFC patches I do not see that implemented, so maybe Libin and you will add that eventually The question here is how will the switch be handled, can you please elaborate on that. From xrandr selection how will audio driver be notified and how will change be done?
On Tue, 08 Dec 2015 11:42:57 +0100, Vinod Koul wrote: > > On Tue, Dec 08, 2015 at 11:28:16AM +0100, Takashi Iwai wrote: > > > Yes that was my thinking based on discussion and patches posted by Libin. > > > But one more question who does PCM assignment, looking at patches it seems > > > driver and no way to change that.. > > > > > > For example I have 10 devices connected and we have 5 PCMs. > > > I would like to route to 7th device, how would that be done? > > > > Manage xrandr to enable the target monitor. Then one PCM stream will > > be switched to the corresponding audio, and it'll be notified to > > user-space. > > Thanks, that helps.. > > Looking at RFC patches I do not see that implemented, so maybe Libin > and you will add that eventually > > The question here is how will the switch be handled, can you please > elaborate on that. From xrandr selection how will audio driver be > notified and how will change be done? The switch itself has to be done voluntarily by user-space, unfortunately, as in the current form. We thought of the preemptive disconnection. It works for aplay, but screws up PulseAudio, so no-go. Takashi
On Tue, 08 Dec 2015 11:51:40 +0100, Takashi Iwai wrote: > > On Tue, 08 Dec 2015 11:42:57 +0100, > Vinod Koul wrote: > > > > On Tue, Dec 08, 2015 at 11:28:16AM +0100, Takashi Iwai wrote: > > > > Yes that was my thinking based on discussion and patches posted by Libin. > > > > But one more question who does PCM assignment, looking at patches it seems > > > > driver and no way to change that.. > > > > > > > > For example I have 10 devices connected and we have 5 PCMs. > > > > I would like to route to 7th device, how would that be done? > > > > > > Manage xrandr to enable the target monitor. Then one PCM stream will > > > be switched to the corresponding audio, and it'll be notified to > > > user-space. > > > > Thanks, that helps.. > > > > Looking at RFC patches I do not see that implemented, so maybe Libin > > and you will add that eventually > > > > The question here is how will the switch be handled, can you please > > elaborate on that. From xrandr selection how will audio driver be > > notified and how will change be done? > > The switch itself has to be done voluntarily by user-space, > unfortunately, as in the current form. We thought of the preemptive > disconnection. It works for aplay, but screws up PulseAudio, so > no-go. Maybe the above wasn't clear enough. Put in that way: the assignment of PCM stream and the switching of PCM stream are different things. The former is done at the time the HDA driver gets notified by i915 (actually happens twice, one for disabling and one for enabling). The audio driver notifies this to user-space. Then user-space closes / reopens a stream accordingly, which is equivalent as switching a PCM stream. We've tested the PCM switching in the driver side, but it broke the compatibility with PA. So the switching itself is voluntarily done by user-space. Takashi
On Tue, Dec 08, 2015 at 11:59:41AM +0100, Takashi Iwai wrote: > On Tue, 08 Dec 2015 11:51:40 +0100, > Takashi Iwai wrote: > > > > On Tue, 08 Dec 2015 11:42:57 +0100, > > Vinod Koul wrote: > > > > > > On Tue, Dec 08, 2015 at 11:28:16AM +0100, Takashi Iwai wrote: > > > > > Yes that was my thinking based on discussion and patches posted by Libin. > > > > > But one more question who does PCM assignment, looking at patches it seems > > > > > driver and no way to change that.. > > > > > > > > > > For example I have 10 devices connected and we have 5 PCMs. > > > > > I would like to route to 7th device, how would that be done? > > > > > > > > Manage xrandr to enable the target monitor. Then one PCM stream will > > > > be switched to the corresponding audio, and it'll be notified to > > > > user-space. > > > > > > Thanks, that helps.. > > > > > > Looking at RFC patches I do not see that implemented, so maybe Libin > > > and you will add that eventually > > > > > > The question here is how will the switch be handled, can you please > > > elaborate on that. From xrandr selection how will audio driver be > > > notified and how will change be done? > > > > The switch itself has to be done voluntarily by user-space, > > unfortunately, as in the current form. We thought of the preemptive > > disconnection. It works for aplay, but screws up PulseAudio, so > > no-go. > > Maybe the above wasn't clear enough. Put in that way: the assignment > of PCM stream and the switching of PCM stream are different things. > The former is done at the time the HDA driver gets notified by i915 > (actually happens twice, one for disabling and one for enabling). The > audio driver notifies this to user-space. Then user-space closes / > reopens a stream accordingly, which is equivalent as switching a PCM > stream. Thanks for the explanation :) SO how do you notify, thru alsa jack control. In that case if we had assigned PCM to pin 5, device 62 and change to pin 5 device 35, how would userspace view this > We've tested the PCM switching in the driver side, but it broke the > compatibility with PA. So the switching itself is voluntarily done by > user-space.
Hi Takashi, > > > > > > > Though, the max number of converters is limited, thus what you can > > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > > pins in a certain procedure to make things compatible. > > > > > > > > but how many MST devs are you going to create? > > > > > > This is exactly the point: for the legacy HDA, instead of creating the > > > entry for each MST devices, they are assigned dynamically to PCM at > > > activation. So the number of devices exposed to user-space is > > > limited -- or better to say, user-space won't notice the difference. > > > > And how many PCMs are you proposing for MST? > > 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we > provide the reserved slots just for the compatible behavior that > assumes the static pin/slot assignment. > How is Nconv * 2 - 1 PCMs are derived? Lets assume, there are 3 cvts and 4pins, I think it will not work.
On Wed, 09 Dec 2015 09:03:38 +0100, Subhransu S. Prusty wrote: > > Hi Takashi, > > > > > > > > > > Though, the max number of converters is limited, thus what you can > > > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > > > pins in a certain procedure to make things compatible. > > > > > > > > > > but how many MST devs are you going to create? > > > > > > > > This is exactly the point: for the legacy HDA, instead of creating the > > > > entry for each MST devices, they are assigned dynamically to PCM at > > > > activation. So the number of devices exposed to user-space is > > > > limited -- or better to say, user-space won't notice the difference. > > > > > > And how many PCMs are you proposing for MST? > > > > 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we > > provide the reserved slots just for the compatible behavior that > > assumes the static pin/slot assignment. > > > > How is Nconv * 2 - 1 PCMs are derived? Lets assume, there are 3 cvts and 4pins, > I think it will not work. We're talking about Intel case, right? Then both numbers are same. Takashi
On Wed, Dec 09, 2015 at 09:13:56AM +0100, Takashi Iwai wrote: > On Wed, 09 Dec 2015 09:03:38 +0100, > Subhransu S. Prusty wrote: > > > > Hi Takashi, > > > > > > > > > > > > > Though, the max number of converters is limited, thus what you can > > > > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > > > > pins in a certain procedure to make things compatible. > > > > > > > > > > > > but how many MST devs are you going to create? > > > > > > > > > > This is exactly the point: for the legacy HDA, instead of creating the > > > > > entry for each MST devices, they are assigned dynamically to PCM at > > > > > activation. So the number of devices exposed to user-space is > > > > > limited -- or better to say, user-space won't notice the difference. > > > > > > > > And how many PCMs are you proposing for MST? > > > > > > 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we > > > provide the reserved slots just for the compatible behavior that > > > assumes the static pin/slot assignment. > > > > > > > How is Nconv * 2 - 1 PCMs are derived? Lets assume, there are 3 cvts and 4pins, > > I think it will not work. > > We're talking about Intel case, right? Then both numbers are same. Yes that's true. But was wondering what if it changes in future. Regards, Subhransu > > > Takashi
On Wed, 09 Dec 2015 12:14:55 +0100, Subhransu S. Prusty wrote: > > On Wed, Dec 09, 2015 at 09:13:56AM +0100, Takashi Iwai wrote: > > On Wed, 09 Dec 2015 09:03:38 +0100, > > Subhransu S. Prusty wrote: > > > > > > Hi Takashi, > > > > > > > > > > > > > > > > Though, the max number of converters is limited, thus what you can > > > > > > > > actually use is defined by this constraint. Due to this, we'll likely > > > > > > > > manage MST for the legacy HDA by assigning MST devs dynamically to > > > > > > > > pins in a certain procedure to make things compatible. > > > > > > > > > > > > > > but how many MST devs are you going to create? > > > > > > > > > > > > This is exactly the point: for the legacy HDA, instead of creating the > > > > > > entry for each MST devices, they are assigned dynamically to PCM at > > > > > > activation. So the number of devices exposed to user-space is > > > > > > limited -- or better to say, user-space won't notice the difference. > > > > > > > > > > And how many PCMs are you proposing for MST? > > > > > > > > 5 for Intel, i.e. Nconv * 2 - 1. This could be even Nconv, but we > > > > provide the reserved slots just for the compatible behavior that > > > > assumes the static pin/slot assignment. > > > > > > > > > > How is Nconv * 2 - 1 PCMs are derived? Lets assume, there are 3 cvts and 4pins, > > > I think it will not work. > > > > We're talking about Intel case, right? Then both numbers are same. > > Yes that's true. But was wondering what if it changes in future. Well, then the formula will be changed, too :) As mentioned, the number of PCMs doesn't have to be changed in theory. The point is only to map the active connection to the available PCM slot dynamically, then this is notified to user-space. We reserve a few more PCM slots than of now, but it's just for subtle compatibility reason. Takashi
diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 008a29f..cce2af0 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -24,6 +24,7 @@ #include <linux/hdmi.h> #include <drm/drm_edid.h> #include <sound/pcm_params.h> +#include <sound/jack.h> #include <sound/soc.h> #include <sound/hdaudio_ext.h> #include <sound/hda_i915.h> @@ -73,6 +74,7 @@ struct hdac_hdmi_pin { struct hdac_ext_device *edev; int repoll_count; struct delayed_work work; + struct snd_jack *jack; }; struct hdac_hdmi_dai_pin_map { @@ -905,6 +907,7 @@ static void hdac_hdmi_present_sense(struct hdac_hdmi_pin *pin, int repoll) pin->eld.eld_valid = !!(val & AC_PINSENSE_ELDV); if (!pin->eld.monitor_present || !pin->eld.eld_valid) { + snd_jack_report(pin->jack, 0); dev_info(&edev->hdac.dev, "%s: disconnect or eld_invalid\n", __func__); goto put_hdac_device; @@ -915,6 +918,7 @@ static void hdac_hdmi_present_sense(struct hdac_hdmi_pin *pin, int repoll) if (hdac_hdmi_get_eld(&edev->hdac, pin->nid, pin->eld.eld_buffer, &pin->eld.eld_size) == 0) { + snd_jack_report(pin->jack, SND_JACK_AVOUT); print_hex_dump_bytes("Eld: ", DUMP_PREFIX_OFFSET, pin->eld.eld_buffer, pin->eld.eld_size); } else { @@ -1173,6 +1177,7 @@ static int hdmi_codec_probe(struct snd_soc_codec *codec) struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(&codec->component); struct hdac_hdmi_pin *pin; + char jack_name[NAME_SIZE]; int ret; edev->scodec = codec; @@ -1189,8 +1194,12 @@ static int hdmi_codec_probe(struct snd_soc_codec *codec) return ret; } - list_for_each_entry(pin, &hdmi->pin_list, head) + list_for_each_entry(pin, &hdmi->pin_list, head) { + sprintf(jack_name, "HDMI/DP, Pin=%d Jack", pin->nid); + snd_jack_new(dapm->card->snd_card, jack_name, SND_JACK_AVOUT, + &pin->jack, true, false); hdac_hdmi_present_sense(pin, 1); + } /* Imp: Store the card pointer in hda_codec */ edev->card = dapm->card->snd_card;