High Definition Audio driver
feature.id at gmail.com
Fri May 12 21:02:28 UTC 2006
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).
On 4/3/06, Stephane E. Potvin <sepotvin at videotron.ca> wrote:
> A few weeks ago I upgraded my laptop only to discover that the sound
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> other mechanism required) to userspace applications to indicate that a
> 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
> (about 2 weeks ago) available at: (Thanks again Alexander)
> 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
> 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.
More information about the freebsd-multimedia