RE: no sound with CS4281 card
I Can not reproduce the problem with 2.4.5-ac5 driver or with latest rev of the driver that I have been working on, or with any of the previous 4 internal releases back to early april. although I do not have a Toshiba laptop to test on and don't doubt that there might be a problem on your system. I have not tested a 1755 model. Another user indicated that the Toshiba 1620 CDS works with the latest driver. I'll wait for your input concerning the latest driver that I sent to you via email. Fyi, I have USB disabled, SMP enabled, and all *PM enabled. If you can boot with max debugging /sbin/insmod cs4281.o cs_debuglevel=9 cs_debugmask=0x and then run mpg123 on a very small mp3 file or very small wave file (<16k). It'll be a lot of output, but if you could send it all, especially the boot info, that'd help me to debug the problem. Thanks tom -Original Message- From: Rik van Riel [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject:no sound with CS4281 card Hi, my notebook (Toshiba 1755) comes with CS4281 built-in, with all 2.4 kernels I tried this sound card doesn't generate any sound, or interrupts for that matter. The driver detects the card fine, but doesn't seem to be able to do anything with it, on 2.4.5-ac2: /proc/pci Bus 0, device 8, function 0: Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 1). IRQ 5. Master Capable. Latency=64. Min Gnt=4.Max Lat=24. Non-prefetchable 32 bit memory at 0xfc01 [0xfc010fff]. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. dmesg cs4281: version v1.13.32 time 15:54:07 May 29 2001 PCI: Enabling device 00:08.0 ( -> 0002) PCI: Found IRQ 5 for device 00:08.0 /proc/interrupts 5: 0 XT-PIC Crystal CS4281 (after trying to play music with mpg123 about 20 times) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: no sound with CS4281 card
I'll send the latest driver that I have via separate email. Toshiba refuses to supply equipment, and there are some design issues with Toshiba laptops. I recently sent a driver to another Toshiba owner and he had good luck with the latest driver. I have never seen any Toshiba laptop not generate sound with any cs4281 driver at any time ( :) ), but that certainly doesn't rule out the 2.4.5-ac2 not working on a Toshiba 1755. I am pulling the 2.4.5-ac6 source now and will try on a 4281 ref card. mpg123 the only app not working? Thanks for the input tom -Original Message- From: Rik van Riel [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:15 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject:no sound with CS4281 card Hi, my notebook (Toshiba 1755) comes with CS4281 built-in, with all 2.4 kernels I tried this sound card doesn't generate any sound, or interrupts for that matter. The driver detects the card fine, but doesn't seem to be able to do anything with it, on 2.4.5-ac2: /proc/pci Bus 0, device 8, function 0: Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 1). IRQ 5. Master Capable. Latency=64. Min Gnt=4.Max Lat=24. Non-prefetchable 32 bit memory at 0xfc01 [0xfc010fff]. Non-prefetchable 32 bit memory at 0xfc00 [0xfc00]. dmesg cs4281: version v1.13.32 time 15:54:07 May 29 2001 PCI: Enabling device 00:08.0 ( -> 0002) PCI: Found IRQ 5 for device 00:08.0 /proc/interrupts 5: 0 XT-PIC Crystal CS4281 (after trying to play music with mpg123 about 20 times) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.3+ sound distortion
David, your report sounds like a problem that we have seen in the test lab, but no one has reported in the field... yet. :) if the problem is the same as we have seen... unloading the driver and reloading the driver should also clear up the problem. but typically the problem only occurs after playing for several hours without a break in the audio stream. we think that we understand the problem (theoretically), in that we believe that we need to manipulate a static DSP image location periodically that gets too far out of value. the issue is that internal variables for the static DSP image are not reinitialized on a task restart (e.g. restarting up an audio stream). reloading the static image (i.e. suspend/resume or reloading the driver) clears up the tinny sound here. it hadn't been reported, so I haven't taken the time to plough through the static image map to try to figure out where all the locations are for all the task images that need manipulation. might take a while, but since we now have a problem report, i'll try to find some time to start negotiating the DSP map. i'll send the fix to you for testing when/if... i can get the problem resolved. thanks tom [EMAIL PROTECTED] > -Original Message- > From: David [SMTP:[EMAIL PROTECTED]] > Sent: Sunday, April 22, 2001 10:08 PM > To: [EMAIL PROTECTED] > Subject: Re: 2.4.3+ sound distortion > > I have noticed a problem with sound lately. I have a cs46xx card and > it randomly gets distorted. Normally I just reboot but on this last > occurence I simply left it as it was. The distortion sounds someone > punched the speaker core, it's tinny and mangled. Today it fixed itself > out of the blue in the middle of playing a sound. All sound programs are > equally affected. > > It's only done this in the 2.4 series, I haven't had the desire to look > into it. > > David > > Mike Castle wrote: > > >On Sat, Apr 21, 2001 at 06:04:47PM +0200, Victor Julien wrote: > > > >>I have a problem with kernels higher than 2.4.2, the sound distorts when > > >>playing a song with xmms while the seti@home client runs. 2.4.2 did not > have > >> > > > >Would this be the same issue as describe in these threads: > > > >http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.0/0233.html > >http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.1/0231.html > > > >That is, the change in how nice is recalculated. > > > >mrc > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Incorrect mdelay() results on Power Managed Machines x86
i talked with Keith Frechette at IBM, he is in charge of Linux for IBM. he indicated that they are working issues with INTEL speedstep and Linux for their newer laptops, albeit not at a swift pace. he will probably contact the linux community at some point to help solve issues with SpeedStep, but he affirms that INTEL treats this information as proprietary, so not sure how much work can be done for linux. he also indicated that some of the older IBM models did some non-standard manipulation with the CPU speed at runtime, e.g. what I am seeing with mdelay failing if booting on a 600X on battery power. most likely, no event notification would be available for any of these CPU speed manipulations. I am going to send some info on the issue to Keith, and he is going to forward to the technical IBM folks somewhere at IBM, but any solution would most likely be specific to IBM for the cs46xx audio driver. It does sound like the PM timer is the best idea so far. Tom [EMAIL PROTECTED] > -Original Message- > From: Alan Cox [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, March 28, 2001 10:11 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Incorrect mdelay() results on Power Managed Machines x86 > > > I know on ACPI systems you are guaranteed a PM timer running at ~3.57 > Mhz. > > Could udelay use that, or are there other timers that are better (maybe > > without the ACPI dependency)? > > We could use that if ACPI was present. It might be worth exploring. Is > this > PM timer well defined for accesses ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Incorrect mdelay() results on Power Managed Machines x86
ok, results of additional testing are a little different than i anticipated.
here is some recent information using the IBM Thinkpad 600X. for testing
purposes I used an mdelay of 1 (10 seconds) in the driver in the resume
code. the results are the same with or without booting with the "notsc"
boot option. ("linux notsc" used as command line to disable tsc). system
was suspended and then resumed, and the delay time noted. AC power was
removed/applied for both before APM action, as well as between suspend and
resume, no difference in the results below.
1) Boot on AC Power - BogoMips is ~992, cpu_khz is ~500
mdelay() functions as expected (10 sec delay) on AC power.
remove AC and go to battery, mdelay() ALSO functions as expected (10 sec
delay). this is good.
2) Boot on Battery - BogoMips is ~280, cpu_khz is ~132
Battery Power - mdelay() fails to delay properly (~2-3 second delay for
mdelay(1))
apply AC Power - mdelay() fails to delay properly (~2-3 second delay for
mdelay(1))
Note that apmd() detects a power status change. and indicates via message
that "Now using AC Power", or "Now using Battery Power". so as Pavel
mentioned there is an APM event that occurs if a recal wants to happen.
for now, I'll just look at why the mdelay() actual wait time is never
correct, if booted up on Battery. This fix might be all that is needed.
i'll also look into the archives and see if i can find Pavel's patch, but
until mdelay is working when booted up on battery the patch may not be
needed.
> -Original Message-
> From: Pavel Machek [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 5:29 PM
> To: Woller, Thomas; '[EMAIL PROTECTED]'
> Subject: Re: Incorrect mdelay() results on Power Managed Machines x86
>
> Hi!
>
> > Problem: Certain Laptops (IBM Thinkpads is where i see the issue) reduce
> the
> > CPU frequency based upon whether the unit is on battery power or direct
> > power. When the Linux kernel boots up, then the cpu_khz (time.c)
>
> This is issue with my toshiba sattelite, too. I even had a patch to
> detect that speed changed and recalibrate (see archives), but
> recalibrate may come too late.
> Pavel
> --
> I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
> Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Incorrect mdelay() results on Power Managed Machines x86
> > I wonder if there is a way to modify mdelay to use a kernel timer if > > interval > 10msec? I am not familiar with this section of the kernel, > but I > > do know that Microsoft's similar function KeStallExecutionProcessor is > not > > recommended for more than 50 *micro*seconds. > >>Basically the same kind of recommendation applies. But as with all rules its >>sometimes appropriate to break it thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time I booted and kept the machine on battery power the ENTIRE time, i had not tried this before. the MHZ value Detected in time.c is 132Mhz (down from 500Mhz if not on battery power). but the interesting thing that i just noticed is that the mdelay() wait time, is STILL about 25% of what it should delay. i use 1 (for a 10 second delay) and get only about 2-3 seconds out of it. this smaller delay occurs with or without "notsc" on the boot line. now, i did not expect this behaviour if i did not plug in to get more CPU speed, with the calculated cpu rate when on battery power. i expected that mdelay() would function properly with the appropriate wait time if i booted and stayed on battery power, at the same reduced CPU frequency. Alan, you might have answered this in your first post but i don't under the INTEL speedstep logic to understand if this is expected behaviour. but the bottom line is that my delay of 700 milleseconds in the driver fails if i boot and stay on battery power exclusively. did anyone else expect this behaviour? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Incorrect mdelay() results on Power Managed Machines x86
Problem: Certain Laptops (IBM Thinkpads is where i see the issue) reduce the CPU frequency based upon whether the unit is on battery power or direct power. When the Linux kernel boots up, then the cpu_khz (time.c) value is determined based upon the current cpu speed. But if the unit's power source is subsequently changed (plugged into the power outlet from battery power; or unplugged and moved to battery power), then the delay resulting from mdelay() (i.e. udelay) is off by the same factor. cpu_khz is only calculated during init/boot time, and not on a change in the power source. This seems to be a serious problem since the result is off by a factor of 4 in some cases which impacts the mdelay() wait times in the same proportion (130 Mhz cpu speed on battery and 500 Mhz CPU speed direct power, on an IBM Thinkpad). During resume the IBM thinkpad with the cs46xx driver needs to delay 700 milleseconds, so if the machine is booted up on battery power, then to ensure that the delay is long enough, then a value of 3000 milleseconds is must be programmed into the driver (3 seconds!). all the mdelay and udelay wait times are incorrect by the same factor, resulting in some serious problems when attempting to wait specific delay times in other parts of the driver. this issue seems like it would be a problem for quite a few drivers that are used on laptops that need some fairly precise delays, but maybe this is only an IBM Thinkpad issue. I know that there have been some DMA timeout errors when resuming on IBM Thinkpads and maybe these errors that have been seen are due to the invalid delay times generated. solutions: using schedule() during resume is not an option, as it causes an oops under 2.2, and causes a second resume to be entered in the pci_driver resume table entry for some reason. also, schedule() is not fine enough granularity for some of the micro second delays needed. re-initing by reinvoking time_init() on each resume cycle doesn't seem to be an option that i can see. Appreciate any responses or thoughts on the subject, Tom Woller [EMAIL PROTECTED] Cirrus Logic/Crystal Semiconductor (512) 912-3920 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: cs46xx only works as a module still (post 2.4.0)
appreciate the info. i'll look at it. glad it works as a module :) tom > -Original Message- > From: David Ford [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, January 10, 2001 11:35 PM > To: LKML; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: cs46xx only works as a module still (post 2.4.0) > > Just a friendly reminder, the cs46xx driver only works if it's compiled > as a module. If it's static, it never gets activated on boot. > > -d > << File: Card for David Ford >> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
