Download the binary here.

audiohd.tar.gz

What is new in this audioHD driver?

1) Parser was added to replace the hard coding for building output path,
   input path and monitor path.
2) You can monitor the recording process and get "what you hear is what you get".
3) SPDIF output was enabled.

Tested platforms:

1) Ultra 40 M2,  Codec10ec, 0885
2) Ultra 24, Codec10ec, 0888
3) Ultra 20, Code10ec, 0883
4) Toshiba M8  Codec10ec,0268

Platforms not working:

1) Toshiba M9 

The steps to try the driver:

  1. backup old audiohd driver

     cp /kernel/drv/audiohd /kernel/drv/audiohd.bak

     cp /kernel/drv/amd64/audiohd /kernel/drv/amd64/audiohd.bak

  2. untar the file,

      audiohd.tar.gz

  3. cp debug32/audiohd 

     cp debug64/auduiohd /kernel/drv/amd64/

  4. If you don't want to reboot your system, do the 

     following steps in CDE or console mode (not in gnome):

     4.1 uncomment this line:  reset-configuration=1;  in

       /kernel/drv/audiohd.conf

     4.2 rem_drv audiohd

     4.3 add_drv -i '"pciclass,0403"' audiohd

  5. Or, you reboot system after overriding audiohd binary 

     in step 3.

After I added some code to reinitialize the GTT(Graphics Translation Table) table in agptarget driver resume interface,  Solaris could resume properly from the suspend state.   Finally,  there are four components affecting Intel graphics S3 process, ie, i915 driver, vgatext driver, agptarget driver and DDX driver.  
Tips in suspend debugging. 

1)Now days, most of the laptops do not get serial ports in them.  We can only wake up kmdb in console which depends on framebuffer driver.  How can we debug the suspend process with KMDB after the framebuffer suspend?  Let me explain a bit,  each device like framebuffer in Solaris will be set to poweoff by post suspend call which can not be controlled by device driver.  So the graphics device will power off after it say "suspend success" to upper layer, then console and kmdb prompt will go away for the poweroff.   We should hack the power off code in post supsend if we need further kmdb support.

2) I should have more, let me think a while.

  I have one file to be formatted for special use, here are my original file and target file.
Original file:

__glXDisp_CreateContext             0x7a        ../../../GL/glx/.libs/libglx.a(glxcmdsswap.o)
__glXDisp_CreateNewContext          0x116       ../../../GL/glx/.libs/libglx.a(glxcmdsswap.o)

Target file:
        __glXDisp_CreateContext
        __glXDisp_CreateNewContext

Following pattern was used to get my work done. 

 

%s/^\(\S\+\).*$/^I^I^I\1/g

 Notes: \S stands for white space character. ^I stands for tab character. \(, \) stands for the first matched pair that was referenced by "\1".

     

  A developer from ISV asked me when the probe(9E) must be implemented.  Let's look at the fragment from Solaris's manpage below first.

---

probe – determine if a non-self-identifying device is present

For a self-identifying device, this entry point is not necessary.  However, if a device exists in both self-identifying and  non-self-identifying forms,   a probe() routine can be provided to simplify the driver

  However, as to a non self-identified device like ISA device, a configuration file must be created to tell where the device possibly is located.  Probe entry will be called to test if the device is actually there. I t is the responsibility of the developer to know which IO ports are probed for ISA devices.  In morden society, there is no need for 99 percent of the devices to implement probe entry.  Because, non self-identified device is gone.
 

Our internal Xorg SUN  is a patched soruce tree from open source community. So it is better to debug it with GNU tool, ie., gdb. As the usual, we should compile the source files with debug information first. Some kind of trick is used here. Let's give a example as the following, we like to know what is going on with the Intel video driver. The driver may have some dependency on other modules, so we build the full Xorg tree first. As a result, we get a compiled Xorg source tree without debug information. Under the directory "open-src/driver/xf86-video-intel", "make clean & make debug" command will give you a Intel driver with debug information.  Let's have a look why you can do this. There is a "Makefile" "open-src/driver/xf86-video-intel which depends on "../Makefile.inc", and "../Makefile.inc" itself depends on "../../common/Makefile". A debug target is defined in "../../common/Makefile".

  After install the new object file into target system, we can start our adventure now. If you do not tell it, GDB does not know where the source files are located. I prefer to write the source path in ".gdbinit" just as the B-shell search in path "bashrc". 

  -bash /usr/X11/bin/Xorg

  (gdb) file /usr/X11/bin/Xorg

  (gdb) file /usr/X11/bin/Xorg

Load new symbol table from "/usr/X11/bin/Xorg"? (y or n)
Reading symbols from /usr/X11/bin/Xorg...done.

(gdb) break i830_dri.c:I830DRIScreenInit

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (i830_dri.c:I830DRIScreenInit) pending.

(gdb)

Fourtunately, "defered breakpoints" is supported by gdb, so we can set the breakpoint on the share library which haven't been loaded yet.
 

 

Currently, the video card is left randomly after it resume from the power suspend.
Neither BIOS nor video card driver restore all the device context.
Here video card driver refers to both DDX driver and DRM driver.

The context of the video cards is composed from three parts:
   1. 2D context including register status and device memory content
      Xserver charge these.
   2. 3D context including register status and device memory content
      DRI and DRM driver charge these.
   3. PCI config space.
      In Solaris, it is the responsibility of Nexus driver to save and restore all the PCI
     config space.

    Xserver and DRM driver may save and restore part of the device's register. It is highly
 possible that we will create a boundary and hand shake for Xserver and DRM driver.

    How linux does?

    In open source world, some guys use some hack method to the graphics suspend and resume.

    1). Save the configuration space of the device manually by some tools.
    2). Suspend the device, then bios will leave the device in random state
    3). Post the device and restore the configuration of the device manually by some tools.
     

   By this way, linux sometimes can work with or without Xorg. But it is very unstable.

 
 

 

In order to get more information, I used two workstation for analysis. One is the Ultra 20, the other is

IBM ThinkCenter A50P. The Solaris trial version of X86 PM can work well on Ultral 20, ie, the system can do suspend and resume properly.

Let's take a look on How ultra 20 works.
1)Setup the kmdb through serial line
2)active kmdb and set the breakpoint at AcpiEnterSleepState
3)Run command "uadmin 3 20"

the system stop at following stack:

acpica`AcpiEnterSleepState(ffffff00024a4b78)

acpippm`appm_ioctl+0x8f(de00000000, 4101, ffffff00024a4b78, 80200002,fffffffec2f0de18, 0)

cdev_ioctl+0x48(de00000000, 4101, ffffff00024a4b78, 80200002, fffffffec2f0de18, 0)

ldi_ioctl+0xac(fffffffec41e5f60, 4101, ffffff00024a4b78, 80000002, fffffffec2f0de18, 0)

ppm`ppm_manage_sx+0x88(ffffff00024a4b78, 1)

ppm`ppm_ctlops+0x121(fffffffec27eb458, fffffffec27fec78, 15, ffffff00024a4c88, ffffff00024a4cc4)

pm_ctlops+0x70(fffffffec27eb458, fffffffec27fec78, 15, ffffff00024a4c88, ffffff00024a4cc4)

cpr`i_cpr_power_down+0x2ff(3)

cpr`cpr_main+0x1aa(3)

cpr`cpr+0xdb(14)

stubs_common_code+0x51()

kadmin+0x179(3, 14, 0, fffffffed99f2d60)

uadmin+0xb1(3, 14, 0) 

4) However, when I set the defering breakpoint, ie, "::bp cpr`cpr_main" or "::bp AcpiEnterSleepState" The system can stop.
On the other hand, when I did the same thing on the IBM A50P,  It can only stop at "::bp cpr`cpr_main".

 

As we have known, Solaris does not export MTRR interfaces to user level applications. So PAT is used for write combing support for Xorg. Let's verified it by mdb.

1). Start solaris and Xorg.

2). Make sure solaris dumps all the pages beside kernel pages. dumpadm -c all

3). Reboot the solaris and get the dump core files reboot -d

4). mdb -k 0. Suppose your core files are "unix.0" and "vmcore.0".

5). find the pid of Xorg ::ps ! grep Xorg

     Here I got "100777".

6). get the HAT table of the Xorg 0t100777 ::pid2proc |::print proc_t p_as->a_hat

    Here I got "0xceb7d140".

7). dump the all the page table entries 0xceb7d140::htables | ::print struct htable ht_pfn |::ptable

8). From the Xorg log, we can get the physical range of frame buffer. ... Linear framebuffer at 0xF0000000 ...

9). Search "0xF0000000" in the page table entries. Got these.

...

[722] va=b4800000 pte=f00004f7: pfn=0xf0000 noconsist largepage mod ref user write uncached

[723] va=b4c00000 pte=f04004f7: pfn=0xf0400 noconsist largepage mod ref user write uncached

[724] va=b5000000 pte=f08004f7: pfn=0xf0800 noconsist largepage mod ref user write uncached

[725] va=b5400000 pte=f0c004f7: pfn=0xf0c00 noconsist largepage mod ref user write uncached

[745] va=ba400000 pte=f5c004f7: pfn=0xf5c00 noconsist largepage mod ref user write uncached

...

10).In solairs the PAT/PWT/PCD values are setup so that:

PAT & PWT -> Write Protected

PAT & PCD -> Write Combining PAT by itself (PWT == 0 && PCD ==0) fields uncac0hables (same as PCD == 1) 0x04f7 = 0x0000010011110111
               ^      ^^ 

               |      ||_____________________________________________PAT 0 should be 1??

               |      |____________________________PCD 1

               |________________PWT 0

   for large pages Bit 12: PAT Bit 4: PCD Bit 3: PWT Any thing wrong here?

8.3.3. D3 State Restoring a function from D3 requires the operating system to reinitialize the function, beginning with, for the case of D3cold , restoring power to the device and initiating a PCI Bus Segment Reset. This is accomplished by either programming the hosting bus’s Originating Device to D0 or by other ACPI-type control methods. Full context must be restored to the function before it is capable of resuming normal operation. For example, reinitialization includes, but is not necessarily limited to, restoring the Base Address registers, re-enabling the I/O and memory spaces, re-enabling bus master capabilities, and unmasking any IRQs or PCI Interrupts as well as restoring the INT Line register. Furthermore, if the function has the DSI bit set, the operating system is required to execute whatever initialization code is necessary, either via the device driver’s initialization code or by executing POST.

a PMCS(Power Management Control/Status is defined in the PCI spec. Offset D4~D5 in PCI configuration space. There is a PCI tool in Solaris which is un-disclosed yet to read and write PCI registers. dump the register in Offset D4~D5: pcitool /pci\@0\,0 -d bdf=0.2.0,config -o d4 -s 1 -b 0x1
0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00
-----------------------------------------------
0x00000000000000d0: -- -- -- -- -- -- -- -- -- -- -- 00 -- -- -- --
the Xorg crashed:
Set the register to 0x3(D3):
pcitool /pci\@0\,0 -d bdf=0.2.0,config -w 0x3 -o d4 -s 1
Backtrace:
1: 0xc4b3d39f: /lib/libc.so.1:__sighndlr+0xf
2: 0xc4b3288b: /lib/libc.so.1:call_user_handler+0x2b8
** Signal 11 (SEGV)
3: 0xc47ab1f2: /usr/X11/lib/modules/drivers/i810_drv.so:PreInitCleanup+0x162
4: 0xc47ac721: /usr/X11/lib/modules/drivers/i810_drv.so:I830BIOSPreInit+0x13d1
5: 0x80d0f3a: /usr/X11/bin/i386/Xorg:InitOutput+0xd6a
6: 0x80abb0a: /usr/X11/bin/i386/Xorg:main+0x29a
7: 0x8085ab0: /usr/X11/bin/i386/Xorg:_start+0x80
Fatal server error:
Caught signal 11. Server aborting
The screen is freezing. Mouse can not move around and the screen have no change whatever I hit.
Set the register back to 0x(D0):
pcitool /pci\@0\,0 -d bdf=0.2.0,config -w 0 -o d4 -s 1
pkill -HUP dtlogin
the Xserver can start again.
From the test above, Xorg need some extra work to handle the situation when the graphics card is set to D3 state. Otherwise, it will crash immediately. And the graphics card can be re-initialized successfully by only the PMCS.

Yesterday, We attended a VT conference hosted by Novell In Beijing. "Virtualization" is a hot topic nowadays. However, it really surprise me when I found there was no vacant seat in the hall. As the usual, after the boring opening remarks, Intel, IBM, Dell boast their solutions for Virtualization. They listed below as the advantage of Virtualization. ie., 1. Server consolidation. 2. Service migration and scalability. 3. Security. Unlike other companys, The engineer from AMD gave us a technical presentation. They showed their roadmap to support full Virtualiztion. Currently, Intel and AMD only support CPU Virtualization, and IO virtulization is not supported yet. The good news is Intel's VTD is on the way. And AMD promises to deliver virtulizated IO chipsets in 2009, nested MMU in 2007. Furthrer, muti-core and virtualization are like a inherent pal. They also demonstrated their desirable muti-core plan. Maybe, several years later, "everything is virtualized" is not only a advertisement, but also a must requirement by our customers.