[alsa-devel] [PATCH - ice1724 1/4] ALSA: ice1724 - Create capture pcm only for ADC-enabled configurations

From: Pavel Hofman pavel.hofman@ivitera.com
Add the capture pcm only if there is at least one ADC configured in the SYSCONF register.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 4353e76..2a0be2c 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -1117,14 +1117,18 @@ static struct snd_pcm_ops snd_vt1724_capture_pro_ops = { static int __devinit snd_vt1724_pcm_profi(struct snd_ice1712 *ice, int device) { struct snd_pcm *pcm; - int err; + int capt, err;
- err = snd_pcm_new(ice->card, "ICE1724", device, 1, 1, &pcm); + capt = (~ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) ? + 1 : 0; + err = snd_pcm_new(ice->card, "ICE1724", device, 1, capt, &pcm); if (err < 0) return err;
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_vt1724_playback_pro_ops); - snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_vt1724_capture_pro_ops); + if (capt) + snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, + &snd_vt1724_capture_pro_ops);
pcm->private_data = ice; pcm->info_flags = 0;

From: Pavel Hofman pavel.hofman@ivitera.com
Append the external clock item to the clock list only if the SPDIF_IN capability is defined in the SPDIF register.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 2a0be2c..a671377 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -1829,7 +1829,12 @@ static int snd_vt1724_pro_internal_clock_info(struct snd_kcontrol *kcontrol, uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED; uinfo->count = 1;
- uinfo->value.enumerated.items = hw_rates_count + ice->ext_clock_count; + /* internal clocks */ + uinfo->value.enumerated.items = hw_rates_count; + /* external clocks */ + if (ice->force_rdma1 || + (ice->eeprom.data[ICE_EEP2_SPDIF] & VT1724_CFG_SPDIF_IN)) + uinfo->value.enumerated.items += ice->ext_clock_count; /* upper limit - keep at top */ if (uinfo->value.enumerated.item >= uinfo->value.enumerated.items) uinfo->value.enumerated.item = uinfo->value.enumerated.items - 1;

At Thu, 5 Jan 2012 22:01:56 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
Append the external clock item to the clock list only if the SPDIF_IN capability is defined in the SPDIF register.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
Applied this one now. Thanks.
Takashi
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 2a0be2c..a671377 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -1829,7 +1829,12 @@ static int snd_vt1724_pro_internal_clock_info(struct snd_kcontrol *kcontrol, uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED; uinfo->count = 1;
- uinfo->value.enumerated.items = hw_rates_count + ice->ext_clock_count;
- /* internal clocks */
- uinfo->value.enumerated.items = hw_rates_count;
- /* external clocks */
- if (ice->force_rdma1 ||
(ice->eeprom.data[ICE_EEP2_SPDIF] & VT1724_CFG_SPDIF_IN))
/* upper limit - keep at top */ if (uinfo->value.enumerated.item >= uinfo->value.enumerated.items) uinfo->value.enumerated.item = uinfo->value.enumerated.items - 1;uinfo->value.enumerated.items += ice->ext_clock_count;
-- 1.7.0.4

From: Pavel Hofman pavel.hofman@ivitera.com
When two different cards share the same PCI vendor/subvendor identification, allow card info based on model only. Do not require subvendor ID.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index a671377..8c473b1 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -2279,7 +2279,7 @@ static int __devinit snd_vt1724_read_eeprom(struct snd_ice1712 *ice, } } for (tbl = card_tables; *tbl; tbl++) { - for (c = *tbl; c->subvendor; c++) { + for (c = *tbl; c->model; c++) { if (modelname && c->model && !strcmp(modelname, c->model)) { printk(KERN_INFO "ice1724: Using board model %s\n", @@ -2588,8 +2588,10 @@ static int __devinit snd_vt1724_probe(struct pci_dev *pci, ice->ext_clock_count = 0;
for (tbl = card_tables; *tbl; tbl++) { - for (c = *tbl; c->subvendor; c++) { - if (c->subvendor == ice->eeprom.subvendor) { + for (c = *tbl; c->name; c++) { + if ((model[dev] && c->model && + !strcmp(model[dev], c->model)) || + (c->subvendor == ice->eeprom.subvendor)) { strcpy(card->shortname, c->name); if (c->driver) /* specific driver? */ strcpy(card->driver, c->driver);

At Thu, 5 Jan 2012 22:01:57 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
When two different cards share the same PCI vendor/subvendor identification, allow card info based on model only. Do not require subvendor ID.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index a671377..8c473b1 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -2279,7 +2279,7 @@ static int __devinit snd_vt1724_read_eeprom(struct snd_ice1712 *ice, } } for (tbl = card_tables; *tbl; tbl++) {
for (c = *tbl; c->subvendor; c++) {
for (c = *tbl; c->model; c++) {
This should be also
for (c = *tbl; c->name; c++) {
like below. It's a loop for all entries after all.
if (modelname && c->model && !strcmp(modelname, c->model)) { printk(KERN_INFO "ice1724: Using board model %s\n",
@@ -2588,8 +2588,10 @@ static int __devinit snd_vt1724_probe(struct pci_dev *pci, ice->ext_clock_count = 0;
for (tbl = card_tables; *tbl; tbl++) {
for (c = *tbl; c->subvendor; c++) {
if (c->subvendor == ice->eeprom.subvendor) {
for (c = *tbl; c->name; c++) {
if ((model[dev] && c->model &&
!strcmp(model[dev], c->model)) ||
(c->subvendor == ice->eeprom.subvendor)) {
If possible, try to indent like indent or Emacs do, i.e. aligning with parentheses level. It'll make a bit easier to read in this case.
thanks,
Takashi
strcpy(card->shortname, c->name); if (c->driver) /* specific driver? */ strcpy(card->driver, c->driver);
-- 1.7.0.4

From: Pavel Hofman pavel.hofman@ivitera.com
This card shares PCI ids with Chaintec AV710. Therefore, it will not be detected automatically, it can only be activated by the module parameter model=sq210a.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 8c473b1..248ad31 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -2182,6 +2182,40 @@ static struct snd_kcontrol_new snd_vt1724_mixer_pro_peak __devinitdata = {
static struct snd_ice1712_card_info no_matched __devinitdata;
+ +/* + ooAoo cards with no controls +*/ +static unsigned char ooaoo_sq210_eeprom[] __devinitdata = { + [ICE_EEP2_SYSCONF] = 0x4c, /* 49MHz crystal, no mpu401, no ADC, + 1xDACs */ + [ICE_EEP2_ACLINK] = 0x80, /* I2S */ + [ICE_EEP2_I2S] = 0x78, /* no volume, 96k, 24bit, 192k */ + [ICE_EEP2_SPDIF] = 0xc1, /* out-en, out-int, out-ext */ + [ICE_EEP2_GPIO_DIR] = 0x00, /* no GPIOs are used */ + [ICE_EEP2_GPIO_DIR1] = 0x00, + [ICE_EEP2_GPIO_DIR2] = 0x00, + [ICE_EEP2_GPIO_MASK] = 0xff, + [ICE_EEP2_GPIO_MASK1] = 0xff, + [ICE_EEP2_GPIO_MASK2] = 0xff, + + [ICE_EEP2_GPIO_STATE] = 0x00, /* inputs */ + [ICE_EEP2_GPIO_STATE1] = 0x00, /* all 1, but GPIO_CPLD_RW + and GPIO15 always zero */ + [ICE_EEP2_GPIO_STATE2] = 0x00, /* inputs */ +}; + + +struct snd_ice1712_card_info snd_vt1724_ooaoo_cards[] __devinitdata = { + { + .name = "ooAoo SQ210a", + .model = "sq210a", + .eeprom_size = sizeof(ooaoo_sq210_eeprom), + .eeprom_data = ooaoo_sq210_eeprom, + }, + { } /* terminator */ +}; + static struct snd_ice1712_card_info *card_tables[] __devinitdata = { snd_vt1724_revo_cards, snd_vt1724_amp_cards, @@ -2196,6 +2230,7 @@ static struct snd_ice1712_card_info *card_tables[] __devinitdata = { snd_vt1724_wtm_cards, snd_vt1724_se_cards, snd_vt1724_qtet_cards, + snd_vt1724_ooaoo_cards, NULL, };

At Thu, 5 Jan 2012 22:01:58 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
This card shares PCI ids with Chaintec AV710. Therefore, it will not be detected automatically, it can only be activated by the module parameter model=sq210a.
Hrm, that's bad. Do you know any other way to identify the device?
Takashi
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 8c473b1..248ad31 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -2182,6 +2182,40 @@ static struct snd_kcontrol_new snd_vt1724_mixer_pro_peak __devinitdata = {
static struct snd_ice1712_card_info no_matched __devinitdata;
+/*
- ooAoo cards with no controls
+*/ +static unsigned char ooaoo_sq210_eeprom[] __devinitdata = {
- [ICE_EEP2_SYSCONF] = 0x4c, /* 49MHz crystal, no mpu401, no ADC,
1xDACs */
- [ICE_EEP2_ACLINK] = 0x80, /* I2S */
- [ICE_EEP2_I2S] = 0x78, /* no volume, 96k, 24bit, 192k */
- [ICE_EEP2_SPDIF] = 0xc1, /* out-en, out-int, out-ext */
- [ICE_EEP2_GPIO_DIR] = 0x00, /* no GPIOs are used */
- [ICE_EEP2_GPIO_DIR1] = 0x00,
- [ICE_EEP2_GPIO_DIR2] = 0x00,
- [ICE_EEP2_GPIO_MASK] = 0xff,
- [ICE_EEP2_GPIO_MASK1] = 0xff,
- [ICE_EEP2_GPIO_MASK2] = 0xff,
- [ICE_EEP2_GPIO_STATE] = 0x00, /* inputs */
- [ICE_EEP2_GPIO_STATE1] = 0x00, /* all 1, but GPIO_CPLD_RW
and GPIO15 always zero */
- [ICE_EEP2_GPIO_STATE2] = 0x00, /* inputs */
+};
+struct snd_ice1712_card_info snd_vt1724_ooaoo_cards[] __devinitdata = {
- {
.name = "ooAoo SQ210a",
.model = "sq210a",
.eeprom_size = sizeof(ooaoo_sq210_eeprom),
.eeprom_data = ooaoo_sq210_eeprom,
- },
- { } /* terminator */
+};
static struct snd_ice1712_card_info *card_tables[] __devinitdata = { snd_vt1724_revo_cards, snd_vt1724_amp_cards, @@ -2196,6 +2230,7 @@ static struct snd_ice1712_card_info *card_tables[] __devinitdata = { snd_vt1724_wtm_cards, snd_vt1724_se_cards, snd_vt1724_qtet_cards,
- snd_vt1724_ooaoo_cards, NULL,
};
-- 1.7.0.4

Dne 8.1.2012 10:13, Takashi Iwai napsal(a):
At Thu, 5 Jan 2012 22:01:58 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
This card shares PCI ids with Chaintec AV710. Therefore, it will not be detected automatically, it can only be activated by the module parameter model=sq210a.
Hrm, that's bad. Do you know any other way to identify the device?
I am afraid I do not. There is no string ID in EEPROM contents (unlike in some other cards). Perhaps the Chaintec EEPROM would offer a hint, but I do not have the card on hand.
It is a very low-cost generic card, not many people know about it. Since you applied the patch preventing kernel oops when the AV710 code was run for this card, the autodetection just chooses a wrong card and it is simple to reload the module with the model parameter. Plus I would not be surprised if the other cards with different accessories produced by that company shared all the same PCI ids and differed just in EEPROM configs (most likely incorrect too :-) )
Thanks,
Pavel.

Pavel Hofman wrote:
Dne 8.1.2012 10:13, Takashi Iwai napsal(a):
pavel.hofman@ivitera.com wrote:
This card shares PCI ids with Chaintec AV710. Therefore, it will not be detected automatically, it can only be activated by the module parameter model=sq210a.
Hrm, that's bad. Do you know any other way to identify the device?
I am afraid I do not.
There is already a conflict with the AV710; it appears all three vendors use some default ID.
Plus I would not be surprised if the other cards with different accessories produced by that company shared all the same PCI ids and differed just in EEPROM configs (most likely incorrect too :-) )
Their CMI8788-based cards implement only features that are a subset of those supported by the generic Windows driver. (I guess they ship an .ini file that disables things like 7.1 output on a stereo card (thus breaking other models with the same ID), but it's possible that they just don't bother.)
Pavel, please don't forget to update the sound card matrix: http://www.alsa-project.org/main/index.php/Matrix:Vendor-%E5%82%B2%E7%8E%8B
Regards, Clemens

Dne 9.1.2012 10:24, Clemens Ladisch napsal(a):
Pavel Hofman wrote:
Dne 8.1.2012 10:13, Takashi Iwai napsal(a):
pavel.hofman@ivitera.com wrote:
This card shares PCI ids with Chaintec AV710. Therefore, it will not be detected automatically, it can only be activated by the module parameter model=sq210a.
Hrm, that's bad. Do you know any other way to identify the device?
I am afraid I do not.
There is already a conflict with the AV710; it appears all three vendors use some default ID.
Plus I would not be surprised if the other cards with different accessories produced by that company shared all the same PCI ids and differed just in EEPROM configs (most likely incorrect too :-) )
Their CMI8788-based cards implement only features that are a subset of those supported by the generic Windows driver. (I guess they ship an .ini file that disables things like 7.1 output on a stereo card (thus breaking other models with the same ID), but it's possible that they just don't bother.)
They do seem not to bother much, they do not supply windows drivers for this one at all, people should just use generic Envy24 drivers by VIA :-) But the price is right.
Pavel, please don't forget to update the sound card matrix: http://www.alsa-project.org/main/index.php/Matrix:Vendor-%E5%82%B2%E7%8E%8B
Thanks for pointing out. I will add the latin "ooAoo" to the chinese name, I had no idea the company was already listed in the matrix :)
Pavel.

At Thu, 5 Jan 2012 22:01:55 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
Add the capture pcm only if there is at least one ADC configured in the SYSCONF register.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 4353e76..2a0be2c 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -1117,14 +1117,18 @@ static struct snd_pcm_ops snd_vt1724_capture_pro_ops = { static int __devinit snd_vt1724_pcm_profi(struct snd_ice1712 *ice, int device) { struct snd_pcm *pcm;
- int err;
- int capt, err;
- err = snd_pcm_new(ice->card, "ICE1724", device, 1, 1, &pcm);
- capt = (~ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) ?
1 : 0;
Are you sure that this is correct? I thought the value 0 means 1 ADC, 1 is two ADCS, etc.
thanks,
Takashi

Dne 8.1.2012 10:12, Takashi Iwai napsal(a):
At Thu, 5 Jan 2012 22:01:55 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
Add the capture pcm only if there is at least one ADC configured in the SYSCONF register.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 4353e76..2a0be2c 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -1117,14 +1117,18 @@ static struct snd_pcm_ops snd_vt1724_capture_pro_ops = { static int __devinit snd_vt1724_pcm_profi(struct snd_ice1712 *ice, int device) { struct snd_pcm *pcm;
- int err;
- int capt, err;
- err = snd_pcm_new(ice->card, "ICE1724", device, 1, 1, &pcm);
- capt = (~ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) ?
1 : 0;
Are you sure that this is correct? I thought the value 0 means 1 ADC, 1 is two ADCS, etc.
I think it is correct. This is what the datasheet says:
CCS04: System Configuration Register
bits 3:2
00: one stereo ADC connected 01: two stereo ADCs connected 10: one stereo ADC and a S/PDIF receiver connected 11: No physical inputs
I have two soundcards, one with 10 (ADC + SPDIF in), another with 11 (no ADC), the code seems to work fine.
Thanks,
Pavel.

At Mon, 09 Jan 2012 08:36:54 +0100, Pavel Hofman wrote:
Dne 8.1.2012 10:12, Takashi Iwai napsal(a):
At Thu, 5 Jan 2012 22:01:55 +0100, pavel.hofman@ivitera.com wrote:
From: Pavel Hofman pavel.hofman@ivitera.com
Add the capture pcm only if there is at least one ADC configured in the SYSCONF register.
Signed-off-by: Pavel Hofman pavel.hofman@ivitera.com
diff --git a/pci/ice1712/ice1724.c b/pci/ice1712/ice1724.c index 4353e76..2a0be2c 100644 --- a/pci/ice1712/ice1724.c +++ b/pci/ice1712/ice1724.c @@ -1117,14 +1117,18 @@ static struct snd_pcm_ops snd_vt1724_capture_pro_ops = { static int __devinit snd_vt1724_pcm_profi(struct snd_ice1712 *ice, int device) { struct snd_pcm *pcm;
- int err;
- int capt, err;
- err = snd_pcm_new(ice->card, "ICE1724", device, 1, 1, &pcm);
- capt = (~ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) ?
1 : 0;
Are you sure that this is correct? I thought the value 0 means 1 ADC, 1 is two ADCS, etc.
I think it is correct. This is what the datasheet says:
CCS04: System Configuration Register
bits 3:2
00: one stereo ADC connected 01: two stereo ADCs connected 10: one stereo ADC and a S/PDIF receiver connected 11: No physical inputs
I have two soundcards, one with 10 (ADC + SPDIF in), another with 11 (no ADC), the code seems to work fine.
Ah, then I misunderstood your code. The bit-wise operation is confusing for such a case.
It should be rather more easy-readable like:
if ((ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) == VT1724_CFG_ADC_NONE) capt = 0; else capt = 1;
Could you revise the patch?
thanks,
Takashi

Dne 9.1.2012 10:27, Takashi Iwai napsal(a):
At Mon, 09 Jan 2012 08:36:54 +0100, Pavel Hofman wrote:
Ah, then I misunderstood your code. The bit-wise operation is confusing for such a case.
It should be rather more easy-readable like:
if ((ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) == VT1724_CFG_ADC_NONE) capt = 0; else capt = 1;
Could you revise the patch?
Absolutely, happy to do so. Just please is there a way for me to "migrate" from git.alsa-project.org to your repozitory at kernel.org where the other patches were committed? I mean without compiling the whole kernel, just the drivers as with alsa-project.org? I followed the description at http://alsa-project.org/main/index.php/GIT_Server#Occasional_Developers . The kmirror at git.alsa-project.org seems to be a bit behind.
Thanks a lot for help,
Pavel.

At Mon, 09 Jan 2012 10:48:11 +0100, Pavel Hofman wrote:
Dne 9.1.2012 10:27, Takashi Iwai napsal(a):
At Mon, 09 Jan 2012 08:36:54 +0100, Pavel Hofman wrote:
Ah, then I misunderstood your code. The bit-wise operation is confusing for such a case.
It should be rather more easy-readable like:
if ((ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) == VT1724_CFG_ADC_NONE) capt = 0; else capt = 1;
Could you revise the patch?
Absolutely, happy to do so. Just please is there a way for me to "migrate" from git.alsa-project.org to your repozitory at kernel.org where the other patches were committed? I mean without compiling the whole kernel, just the drivers as with alsa-project.org? I followed the description at http://alsa-project.org/main/index.php/GIT_Server#Occasional_Developers . The kmirror at git.alsa-project.org seems to be a bit behind.
You can build locally with alsa-driver-build.git. This tree contains only the build stub.
% git clone git://..../sound.git % git clone git://..../alsa-driver-build.git % cd alsa-driver-build % utils/setup-alsa-kernel ../sound % ./gitcompile --enable-dynamic-minors ....
Takashi

Dne 9.1.2012 10:51, Takashi Iwai napsal(a):
At Mon, 09 Jan 2012 10:48:11 +0100, Pavel Hofman wrote:
Dne 9.1.2012 10:27, Takashi Iwai napsal(a):
At Mon, 09 Jan 2012 08:36:54 +0100, Pavel Hofman wrote:
Ah, then I misunderstood your code. The bit-wise operation is confusing for such a case.
It should be rather more easy-readable like:
if ((ice->eeprom.data[ICE_EEP2_SYSCONF] & VT1724_CFG_ADC_MASK) == VT1724_CFG_ADC_NONE) capt = 0; else capt = 1;
Could you revise the patch?
Absolutely, happy to do so. Just please is there a way for me to "migrate" from git.alsa-project.org to your repozitory at kernel.org where the other patches were committed? I mean without compiling the whole kernel, just the drivers as with alsa-project.org? I followed the description at http://alsa-project.org/main/index.php/GIT_Server#Occasional_Developers . The kmirror at git.alsa-project.org seems to be a bit behind.
You can build locally with alsa-driver-build.git. This tree contains only the build stub.
% git clone git://..../sound.git % git clone git://..../alsa-driver-build.git % cd alsa-driver-build % utils/setup-alsa-kernel ../sound % ./gitcompile --enable-dynamic-minors ....
That helps a lot, thanks you.
participants (4)
-
Clemens Ladisch
-
Pavel Hofman
-
pavel.hofman@ivitera.com
-
Takashi Iwai