From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Compiling the newest code for testing? Date: Fri, 07 Jan 2005 12:16:11 +0100 Message-ID: References: <200501070525.45603.mr@ramendik.ru> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Fri_Jan__7_12:16:11_2005-1" Return-path: In-Reply-To: <200501070525.45603.mr@ramendik.ru> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Mikhail Ramendik Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org --Multipart_Fri_Jan__7_12:16:11_2005-1 Content-Type: text/plain; charset=US-ASCII At Fri, 7 Jan 2005 05:25:45 +0300, Mikhail Ramendik wrote: > > Hello, > > I would like to do some extensive testing of alsa on my Intel 865PE hardware > (notably the analog vs. SPDIF issues). I have done some bug reporting and > tested some fixes (thanks go to Takashi) in the past, but then fell out of > sync on kernel versions because of other kernel-related issues on my hardware > (now finally resolved). > > I would like to test the latest code, in order for this testing to be most > useful. > > But I really got lost in what is that newest code that I should test, and in > how I should get it to run. So I have some questions: > > - Which alsa code version is in the 2.6.10 kernel release? > (include/sound/version.h says 1.0.6, but there seem to be changelog entries > and factual changes even from 2.6.10-rc3...) It's nearly 1.0.7, 1.0.6 plus fixes. > - Which alsa kernel code should I run for testing? The 2.6.10-kernel version? > 1.0.8rc2? CVS? 1.0.8rc2 plus some files from CVS [those related to i8x0]? For testing purpse, I recommend ALSA CVS version. ATM, 1.0.8rc2 is very new, so it should be fine in most cases, too. > - Is it OK to compile this kernel code by merely copying the relevant > directories (sound [except for sound/oss] and include/sound) from the alsa > tree into the kernel tree? I run an RPM-based system, and would like to keep > the existing approach to kernel building (full RPM rebuild) alive; it's slow > but reliable. Not always. The ALSA cvs may contain the codes for the very latest kernel (rc or mm). Copying the files to kernel might not work when the kernel function / API is changed. The difference is usually absorbed by patches in alsa-driver tree. > - Which alsa-lib and alsa-utils code should I be running? (I know how to > compile it using RPM, I just need to understand the version). It should match with the ALSA driver version. The library itself has backward compatibility, but the configurations included in alsa-lib package may not match with the old drivers. > And an i8x0-specific question: in the above-mentioned current code, should > output to hw:0,0 go only to analog, or to both analog and spdif? Analog only. Basically, you should avoid to access "hw:0,0". If you want to output to analog front, you can use "front", instead. Similarly, for spdif, use "spdif" (or "iec958"). Regarding the dubbed output to analog and spdif - I once had a patch for testing but the tester couldn't apply it. The latest patch is attached below (to 1.0.8rc2 or CVS). If you're interested in it, please give it a try. Takashi --Multipart_Fri_Jan__7_12:16:11_2005-1 Content-Type: text/plain; charset=US-ASCII Index: alsa-kernel/pci/intel8x0.c =================================================================== RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/intel8x0.c,v retrieving revision 1.184 diff -u -r1.184 intel8x0.c --- alsa-kernel/pci/intel8x0.c 5 Jan 2005 18:37:30 -0000 1.184 +++ alsa-kernel/pci/intel8x0.c 7 Jan 2005 11:13:43 -0000 @@ -355,7 +355,7 @@ #define get_ichdev(substream) (ichdev_t *)(substream->runtime->private_data) -typedef struct { +typedef struct ichdev { unsigned int ichd; /* ich device number */ unsigned long reg_offset; /* offset to bmaddr */ u32 *bdbar; /* CPU address (32bit) */ @@ -380,6 +380,9 @@ unsigned int ali_slot; /* ALI DMA slot */ struct ac97_pcm *pcm; int pcm_open_flag; + struct ichdev *spdif_dev; + int slave_mode: 1; + int spdif_ok: 1; unsigned int page_attr_changed: 1; } ichdev_t; @@ -800,7 +803,8 @@ } spin_unlock(&chip->reg_lock); if (ack && ichdev->substream) { - snd_pcm_period_elapsed(ichdev->substream); + if (! ichdev->slave_mode) + snd_pcm_period_elapsed(ichdev->substream); } iputbyte(chip, port + ichdev->roff_sr, status & (ICH_FIFOE | ICH_BCIS | ICH_LVBCI)); @@ -843,10 +847,8 @@ * PCM part */ -static int snd_intel8x0_pcm_trigger(snd_pcm_substream_t *substream, int cmd) +static int _snd_intel8x0_pcm_trigger(intel8x0_t *chip, ichdev_t *ichdev, int cmd) { - intel8x0_t *chip = snd_pcm_substream_chip(substream); - ichdev_t *ichdev = get_ichdev(substream); unsigned char val = 0; unsigned long port = ichdev->reg_offset; @@ -878,6 +880,19 @@ return 0; } +static int snd_intel8x0_pcm_trigger(snd_pcm_substream_t *substream, int cmd) +{ + intel8x0_t *chip = snd_pcm_substream_chip(substream); + ichdev_t *ichdev = get_ichdev(substream); + int err; + err = _snd_intel8x0_pcm_trigger(chip, ichdev, cmd); + if (err < 0) + return err; + if (ichdev->spdif_dev && ichdev->spdif_ok) + return _snd_intel8x0_pcm_trigger(chip, ichdev->spdif_dev, cmd); + return 0; +} + static int snd_intel8x0_ali_trigger(snd_pcm_substream_t *substream, int cmd) { intel8x0_t *chip = snd_pcm_substream_chip(substream); @@ -956,8 +971,14 @@ if (err >= 0) { ichdev->pcm_open_flag = 1; /* Force SPDIF setting */ - if (ichdev->ichd == ICHD_PCMOUT && chip->spdif_idx < 0) - snd_ac97_set_rate(ichdev->pcm->r[0].codec[0], AC97_SPDIF, params_rate(hw_params)); + if (ichdev->ichd == ICHD_PCMOUT) { + if (chip->spdif_idx < 0) + snd_ac97_set_rate(ichdev->pcm->r[0].codec[0], + AC97_SPDIF, params_rate(hw_params)); + else if (ichdev->spdif_dev) + ichdev->spdif_ok = ! snd_ac97_set_rate(ichdev->spdif_dev->pcm->r[0].codec[0], + AC97_SPDIF, params_rate(hw_params)); + } } return err; } @@ -1045,6 +1066,19 @@ } } snd_intel8x0_setup_periods(chip, ichdev); + if (ichdev->spdif_dev && ichdev->spdif_ok) { + /* slave SPDIF DMA */ + if (runtime->format != SNDRV_PCM_FORMAT_S16_LE || + runtime->channels != 2) + ichdev->spdif_ok = 0; + else { + ichdev_t *sdev = ichdev->spdif_dev; + sdev->physbuf = runtime->dma_addr; + sdev->size = snd_pcm_lib_buffer_bytes(substream); + sdev->fragsize = snd_pcm_lib_period_bytes(substream); + snd_intel8x0_setup_periods(chip, sdev); + } + } spin_unlock_irq(&chip->reg_lock); return 0; } @@ -1162,6 +1196,13 @@ runtime->hw.formats |= SNDRV_PCM_FMTBIT_S32_LE; snd_pcm_hw_constraint_msbits(runtime, 0, 32, 20); } + if (chip->spdif_idx >= 0 && chip->device_type != DEVICE_ALI) { + if (! chip->ichd[chip->spdif_idx].substream) { + chip->ichd[chip->spdif_idx].slave_mode = 1; + chip->ichd[ICHD_PCMOUT].spdif_dev = &chip->ichd[chip->spdif_idx]; + chip->ichd[ICHD_PCMOUT].spdif_ok = 0; + } + } return 0; } @@ -1169,6 +1210,10 @@ { intel8x0_t *chip = snd_pcm_substream_chip(substream); + if (chip->ichd[ICHD_PCMOUT].spdif_dev) { + chip->ichd[ICHD_PCMOUT].spdif_dev->slave_mode = 0; + chip->ichd[ICHD_PCMOUT].spdif_dev = NULL; + } chip->ichd[ICHD_PCMOUT].substream = NULL; return 0; } @@ -1238,6 +1283,8 @@ intel8x0_t *chip = snd_pcm_substream_chip(substream); int idx = chip->device_type == DEVICE_NFORCE ? NVD_SPBAR : ICHD_SPBAR; + if (chip->ichd[idx].slave_mode) + return -EBUSY; return snd_intel8x0_pcm_open(substream, &chip->ichd[idx]); } --Multipart_Fri_Jan__7_12:16:11_2005-1-- ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt