From owner-freebsd-multimedia@FreeBSD.ORG Fri May 12 21:02:28 2006 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DA5A16AF88 for ; Fri, 12 May 2006 21:02:28 +0000 (UTC) (envelope-from feature.id@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 351A843D62 for ; Fri, 12 May 2006 21:02:16 +0000 (GMT) (envelope-from feature.id@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so137167uge for ; Fri, 12 May 2006 14:02:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=XjSAmvD6IuX7ekyQl1xx9fcT7jDNY6Ec7yStRnQlRM8p4+aaZxPngHXmsgastBPApA2X9HEKWFNQ5hcICeTMJD893U41Qt+oUpIIo98rc6bHaExz/ABJEdot0dyULKDopcJ26XlwsW0AqlA5CCDiDLsSOu4d+NbZrikxpzVqMtc= Received: by 10.67.87.10 with SMTP id p10mr106667ugl; Fri, 12 May 2006 14:02:15 -0700 (PDT) Received: from xeon.local ( [83.237.38.178]) by mx.gmail.com with ESMTP id y7sm1216427ugc.2006.05.12.14.02.12; Fri, 12 May 2006 14:02:15 -0700 (PDT) Date: Sat, 13 May 2006 01:02:17 +0400 From: feature To: freebsd-multimedia@freebsd.org Message-Id: <20060513010217.2f0cd472.feature.id@gmail.com> X-Mailer: Sylpheed version 2.2.3 (GTK+ 2.8.17; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: High Definition Audio driver X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 21:02:28 -0000 Hi, Steph. Having the same `audio problem'. Tried your driver . (got it to compile only after commenting everything related to hdac_probe(), because of the following: hdac.c: In function `hdac_probe': hdac.c:866: error: `PCIS_MULTIMEDIA_HDA' undeclared (first use in this function) hdac.c:866: error: (Each undeclared identifier is reported only once hdac.c:866: error: for each function it appears in.) *** Error code 1) kldload went ok, but without any noticable effect to the system (still no sound, nothing in dmesg, etc). uname: 6.1-STABLE On 4/3/06, Stephane E. Potvin wrote: > > A few weeks ago I upgraded my laptop only to discover that the sound > system > on it was unsupported by FreeBSD, being an High Definition Audio > controller / codec. I started at that time to write a driver specific to > FreeBSD. Given that it seems that I'm not the only one stuck with this > problem, I decided after some gentle prodding by Alexander to share what > I'm trying to achieve. > > I first had a look at the NetBSD driver but soon decided not to start from > it. They chose to use a monolithic driver that controls both the HDA > controller and the audio codec. The HDA architecture calls for a single > HDA > controller to have many codecs connected via a shared bus. Each codec can > have multiple functions. These functions could be Audio, Modems, etc. > > So I decided to take another approach for the driver I'm writing. I've > decided to split it into a driver for the HDA controller itself, one for > the HDA bus and one (or many) for the actual functions. The bus driver > will > be used to enumerate the different functions that are on the different > codecs to find matching drivers. > > This will enable us, in the long run, to be able to support other drivers > than Audio ones (like modems). It will also enable to have more than one > Audio function active on a single controller (in the case of an external > codec in a docking station for example). It will also enable the support > of > different controllers on other architectures in case this standard catches > up without having to rewrite the audio functions. > > Here are the major steps that I currently plan to do for this driver. They > are not in any relevant order: > > - Implement the CORB and RIRB engines to send verbs and receive responses > from the codecs (mostly done). > > - Implement a bus driver (hda) that will enumerate the functions on the > codecs and try to attach matching drivers. I'm not sure yet if I'll use > the > bus_space subsystem to handle reading and writing the function registers > (via the CORB/RIRB). If anyone has any thoughts about that I'll be glad to > hear about them. (started but progressing slowly) > > - Add support for the Stream Resources on the HDA controller. These are > the > DMA engines that transfer the actual audio data to and from the codecs to > physical memory. > > - Write the actual audio driver to control the audio function. This will > be > the driver that will actually attach to the pcm subsystem. > > - Add unsolicited response support to handle asynchronous events from the > functions. This will enable, for example, to send a devd events (or via > any > other mechanism required) to userspace applications to indicate that a > jack > was inserted or removed. > > - Add hot insertion/removal of codecs to handle the case where a docking > station that sports a codec is added. > > - Support for low power states on the HDA controller and on the codecs. > > - Suspend / Resume support for laptop. I guess that I'll somewhat need to > fix basic suspend/resume on my laptop before I can tackle that :( > > - Any other things I might need to add along the way...( > > Now, the bad news. I'm working on this when I have the time but it's > usually not nearly enough as I would like it to be. I'll get there someday > unless somebody else beat me to it. If anybody would like this to go > faster, I'll be very happy to get any help that I might get. > > In case it might be of interest to anybody, there's a version of the > driver > (about 2 weeks ago) available at: (Thanks again Alexander) > http://www.leidinger.net/FreeBSD/hdac-20060313.tbz > > Usual disclaimers, use this at your own risk. It may eat your computer, > make your cats sick, yaya. Some parts were added in a hurry just to make > this work (the interrupt handler for example), so they are kind of really > ugly. I plan to refine them with time. > > I'm currently working on the bus driver itself. Once I get it working to > my > liking, I'll update the driver and post a message here.. > > I would appreciate any feedback I can get about my plans, what I have done > so far, etc. Please don't hesitate to drop me an email in that case. > > Regards, > > Steph