Bug 730215
| Summary: | [HP Feat6.x]: Enable LSI modem driver support on RHEL 6.x | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | YS Chen <ys.chen> |
| Component: | kernel | Assignee: | Jaroslav Kysela <jkysela> |
| Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | arozansk, bzeranski, dwa, ichute, karen.skweres, michael.lee, quoc.pham, suresh.gupta, tcamuso, trinh.dao, xin.mei |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | 6.2 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-08-24 13:28:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 698821 | ||
| Attachments: | |||
Created attachment 517980 [details]
Need to modify one line of the hda_intel.c file of Linux kernel to share HDA for Modem
Need to modify one line of the hda_intel.c file of Linux kernel in orfer to share the HDA interrupt to modem.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. LSI HDA Modem will not work unless HDA interrupts will be shared. As our Codec is also attached to same HDA bus and for its proper working, modem driver need to request same interrupt line which was acquired by ALSA. The changes are shown in attached hda_intel.c under “LSI CHANGE START”. Making this change will disable Message Signaled Interrupts feature. According to me, disabling Message Signaled Interrupts and sharing interrupt should not affect other things. We are also facing CAPTURE stream issue after sharing interrupts. We found that the HDA 1st capture stream (position 0) is not working fine. When I hardcoded our driver to open capture stream 2, it works and even passes all basic tests. I believe something corrupts the 1st capture stream after boot up. Also I hear some noise when our modem is running using any one of the other capture streams (2nd, 3rd and 4th). So I removed alsa.conf from /usr/share/alsa which means that no other application will be able to open PLAYBACK and CAPTURE stream (no audio can be played). With this change after reboot, our modem driver works without any noise and even works with capture stream 0 also. This clearly shows that some other application is corrupting the Capture Stream, which needs to be fixed by RedHat. Our modem driver will not work without these changes and should be taken at higher priority by RedHat. You may use 'disable_msi' module option for the hda_intel module to disable msi interrupts - so no changes are needed for the HDA driver.
A better way is to use the codec->patch_ops.unsol_event() callback than registering same interrupt and share the HDA bus communication which may introduce some clashes - it means to create your driver on top of the ALSA HDA driver.
Please, provide unified diffs ('diff -up') to show your proposed changes.
The above method I proposed because I want to indicate that the problem is with sharing interrupts not with MSI. There are many ways to disable MSI for had_intel. The best I know is to provide parameter enable_msi=0 at load time and for RHEL this can be done by writing “options snd-hda-intel enable_msi=0” in“/etc/modprobe.d/dist-alsa.conf”. We want RedHat to choose the best possible way to share interrupts. If you want I will provide the unified diffs for dist-alsa.conf. I do not agree so much to avoid using MSI where possible (at least major users of the HDA drivers do not require sharing of interrupts - loading of a proprietary driver). I think that a note in the documentation for the modem driver may be enough to describe the behaviour. Eventually, the modem driver package can change the modprobe configuration with a "reboot wanted" mark. Could you answer my question why you require to communicate with the codec directly? If you use the HDA PCI bridge simultaneously with the HDA audio driver to communicate with the modem codec, there may be some i/o access clashes. I assume that the modem driver uses same HDA PCI bridge registers to access to the modem codec as ALSA HDA audio driver does, if not - please - describe the modem driver behaviour / structure. I found some LSI codec drivers at http://linmodems.technion.ac.il/packages/ltmodem/11c11040 where some drivers uses the ALSA HDA driver for the communication with the modem codec (a way to go) and others use probably a direct hardware access (it is bad in my eyes). Created attachment 519001 [details] Latest Modem Driver There is no difference in architecture between driver mentioned in "http://linmodems.technion.ac.il/packages/ltmodem/11c11040" and the current driver. The basic architecture is same. Our driver architecture has not changed and it has worked with previous versions of RH. The Current issue we faced is only with new RedHat release. We request you to Share HDA Interrupts (with best possible way according to you) so that our driver request and use it too. I attached the latest driver Steps to install our modem driver 1. untar mdc-modem-1021-2.6.32.tar 2. move to mdc-modem-1021-2.6.32 dir 3. Run “make clean module” 4. Run “make uninstall install” The ALSA code is from upstream, so you will have problem with any newer Linux kernel sources. Please, put a note to your driver that it requires to disable msi for the ALSA hda driver. No changes in RHEL are required. Again, what is the reason to not use the unsol_event() codec callback in HDA.c and do the unsolicited event handling job in your driver? You already patched the resume/suspend callbacks there (setSuspendCallBack and setResumeCallBack). If you use this callback, you do not require to allocate/request the same interrupt. I will check with my team members and come back to you. Can you please concentrate and suggest about the other issue we are facing after Disabling MSI. You can reproduce it by below steps. 1.Install Modem and run Minicom. This time minicom does not respond. Close Minicom. Then start capturing audio (arecord -d 100 -f cd -t wav ~/test.wav). This will acquire stream 0. Now start Minicom. Minicom will work but you will hear some noise. 2.Remove /usr/share/alsa.conf and reboot. Run Minicom and see it will respond. I found that whenever Modem try to acquire the stream which was get freed by some other utility, Modem will not work. And If Modem acquire some fresh stream which was not touch by any utility its work properly and even pass basic tests. You may compare HDA codec state in /proc/asound/card*/codec* files for both working and non-working case (diff -u). Created attachment 519609 [details]
/proc/asound/card0/codec#0 with/with out alsa.conf
There are some limitations due to which we cannot use unsol_event. These are already known issue. So we decide to put “options snd-hda-intel enable_msi=0” while installing our driver. I will make changes in init scripts of modem.
Meanwhile, I look into 2nd issue and did not get much understanding while seeing diff of /proc/asound/card0/card#0 for working and not working case. I attached below two file when alsa.conf is present and alsa.conf is not present. Can you please evaluate your thoughts????
> Created attachment 519609 [details] > /proc/asound/card0/codec#0 with/with out alsa.conf > > There are some limitations due to which we cannot use unsol_event. These are > already known issue. So we decide to put “options snd-hda-intel enable_msi=0” > while installing our driver. I will make changes in init scripts of modem. It looks like a bad software design. If you use the HDA interrupt for a maintenance/polling work, you may use the system timer for this job, too. > Meanwhile, I look into 2nd issue and did not get much understanding while > seeing diff of /proc/asound/card0/card#0 for working and not working case. I > attached below two file when alsa.conf is present and alsa.conf is not present. > Can you please evaluate your thoughts???? It might be a stream number clash (over HDA link) in the converter or so. The codec#* files shows the actual audio modem status/configuration. Unfortunately, I do not know what you share with the ALSA HDA driver exactly and how you set the modem codec. Anyway, further discussions might go to the alsa-devel mailing list (http://www.alsa-project.org). There are more ALSA HDA developers. I am closing this bug, because the original request was solved without the requirement of the RHEL kernel modification. Our driver is working with SUSE new release which have same ALSA version (1.0.21). Did RH change something or ALSA changed?? Can you please provide the ALSA package so that I don’t need kernel compilation to debug our modem and ALSA together. RHEL 6.2 contains the ALSA HDA driver snapshot 2011/07/11. Use the recent ALSA HDA code/snapshots to check your issue. I did not find RHEL 6.2 anywhere. Can you please tell from where I get this? Thanks in advance. Suresh, 6.2 has not been released yet, but there are nightly builds of the proto-6.2 kernel. I think we can provide that for you, if you have an NDA with RH and there are no embargoes on the current 6.2 kernel. Linda, Aris, correct me if I am wrong about that. We checked with legal department. We do not seem to have an NDA currently. Please provide a copy of the NDA for us to review and sign. Thanks Beth, Can you help steer Suresh <suresh.gupta> to someone who can provide an NDA so we can provide an early 6.2 kernel for him to test? Hi, This is Quoc Pham from HP. I am the manager the Business NB R&D Linux OS development group. We are asking LSI to deliver the modem driver for the modem HW shipping on our 2011 HP Business NB. We are close to wrapping up the RHEL 6.1 cert for our 14", 15", and 17" W series platforms. While the modem device doesn't gate us from completing the cert, it's important for our customers who are running RHEL to have this device working. Can we use HP's NDA since LSI is working on our behalf? Is the alternative option is for LSI to wait for the formal alpha release? Quoc, Be advised that this would be a 6.2 kernel, not a 6.1 kernel. Your customers would not have access to it until the release of RHEL6.2. If you want to do some testing, I believe I can provide you a kernel binary for that, but you cannot relay it to a 3rd party. HP is the NDA holder and only HP can be given such a kernel. I will check to be certain, though. Tony, Yes, thanks for working to add modem driver support into the RHEL 6.2 release. We missed the opportunity when we were doing RHEL 6.1 cert and I would like to see if we can knock this out with RHEL 6.2 release. Can you confirm if and when the alpha release is made available to HP, can LSI test with that release instead of the proto 6.2 kernel? Without an NDA, I cannot give the kernel to LSI. I will ask if you could install it on an HP-owned system at an HP site and allow LSI to run their tests remotely. I'll try to get back to you in an hour or so. Quoc, I haven't forgotten you. :) I'm working on getting a 6.2 test kernel for you, and perhaps even for Suresh. I learned that LSI does indeed have an NDA with Red Hat, but I am just awaiting confirmation whether I can provide a kernel. Suresh, LSI already has an NDA with Red Hat, but I think its a different group than yours. You should have access through LSI to RHEL6.2 alpha when it is released. We checked with LSI legal department and came to know there is Master Service Agreement between LSI and Red Hat. Please let me know, is this sufficient to get alpha release. Tony, We checked with LSI legal department and came to know there is Master Service Agreement between LSI and Red Hat. Please let me know, is this sufficient to get alpha 6.2 new release. If this MSA is not suitable then I request you to send NDA document for us to sign. This will also helps in future. Thanks Created attachment 524032 [details] Latest Modem driver for RedHat 6.1 - 32bit. Modem receive unwanted data on stream 0 even current stream is not open by any device. Stream 0 was acquired by IDC 7605 and this codec keep sending something even after closing the stream. On further investigation I found ALSA ver 1.0.24 have new fix “Make converter setups sticky” which changes the semantics of snd_hda_codec_cleanup_stream() not to clean up the stream at that moment but delay the action. This is the reason why Modem getting some unwanted data and stop working. To resolve this issue we need to enable “no_sticky_stream” for these IDT codec. The fix is like putting one line of code “codec->no_sticky_stream =1;” at the end of function “patch_stac92hd83xxx” in file ”/sound/pci/hda/patch_sigmatel.c”. As I am not much aware of the fix “Make converter setups sticky” and also not know the side effects of above mention my fix, I already report a bug in ALSA bug tracking system.” https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5447”. Please test this fix at your end with attached driver and update the IDT vendor to look into the issue and fix it properly. |
Created attachment 517979 [details] Feature Request form to fix the issue found with LSI Modem Description of problem: Redhat Linux kernel does not share the HDA interrupt for modem device and result in the modem device does not function. Request Redhat to fix the kernel issue by sharing the interrupt for HDA modem device. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: