Diff was being silly and I wanted to get the patch posted before I left work for the day. I've cleaned up the patch and included it.
I wasn't able to find where INTA was used so I used what the RPR lists as default. INTG. After looking at the mptable, I agree INTA is the correct answer. I've corrected it. I used dev_find_slot because I copied from the SATA driver. I've added the comment just like the SATA driver has. I don't know what the difference is, or why the SATA driver did this.
The reordering was based on what order things happen in the BIOS Developers guide, RPR, and SATA driver. I fixed the order of the devices that didn't matter to clean up the change log. 1. Enable the Chip 2. Setup the SMBus registers 3. Setup the Device Registers 4. Look for Codec 5. Init Codec
The codec init was changed to match the description in the RRG pg 235. Mem Reg: Base + 08h Bit 0. There were unneeded things happening.
So here is the second try.
Thanks, Dan Lykowski
Signed-off-by: Dan Lykowski lykowdk@gmail.com
On Tue, Jan 27, 2009 at 11:07 AM, Dan Lykowski engineerguy3737@yahoo.com wrote:
Diff was being silly and I wanted to get the patch posted before I left work for the day. I've cleaned up the patch and included it.
I wasn't able to find where INTA was used so I used what the RPR lists as default. INTG. After looking at the mptable, I agree INTA is the correct answer. I've corrected it. I used dev_find_slot because I copied from the SATA driver. I've added the comment just like the SATA driver has. I don't know what the difference is, or why the SATA driver did this.
The reordering was based on what order things happen in the BIOS Developers guide, RPR, and SATA driver. I fixed the order of the devices that didn't matter to clean up the change log.
- Enable the Chip
- Setup the SMBus registers
- Setup the Device Registers
- Look for Codec
- Init Codec
The codec init was changed to match the description in the RRG pg 235. Mem Reg: Base + 08h Bit 0. There were unneeded things happening. So here is the second try.
Thanks, Dan Lykowski
Signed-off-by: Dan Lykowski lykowdk@gmail.com
This looks good to me. The hda_init looks like it was writing to the wrong device for the interrupt line setup. It would be good if the the AMD guys or Carl-Daniel can test and ack it.
Marc
Hi, Dan
I have tested your patch on my dbm690t (ALC882) and pistachio (ALC885) board. It really works. However, I have a suggestion for you.
/* Read in Codec location (BAR + 0xe)[2..0]*/ dword = readl(base + 0xe); dword &= 7; if (!dword) goto no_codec; The above phrase is not correct all the time, at lease to my pistachio board. It will give me the wrong msg "No codec!".
I would appreciate and ack the patch if you can modify it.
BTW, pci_locate_device is only used in early setup stage. So, you can remove it.
Best regards Maggie li
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Marc Jones Sent: Thursday, January 29, 2009 1:10 PM To: Dan Lykowski Cc: Carl-Daniel Hailfinger; coreboot@coreboot.org Subject: Re: [coreboot] SB600 HDA can't find codec fix
On Tue, Jan 27, 2009 at 11:07 AM, Dan Lykowski engineerguy3737@yahoo.com wrote:
Diff was being silly and I wanted to get the patch posted before I left work for the day. I've cleaned up the patch and included it.
I wasn't able to find where INTA was used so I used what the RPR lists as default. INTG. After looking at the mptable, I agree INTA is the correct answer. I've corrected it. I used dev_find_slot because I copied from the SATA driver. I've added the comment just like the SATA driver has. I don't know what the difference is, or why the SATA driver did this.
The reordering was based on what order things happen in the BIOS Developers guide, RPR, and SATA driver. I fixed the order of the devices that didn't matter to clean up the change log.
- Enable the Chip
- Setup the SMBus registers
- Setup the Device Registers
- Look for Codec
- Init Codec
The codec init was changed to match the description in the RRG pg 235. Mem Reg: Base + 08h Bit 0. There were unneeded things happening. So here is the second try.
Thanks, Dan Lykowski
Signed-off-by: Dan Lykowski lykowdk@gmail.com
This looks good to me. The hda_init looks like it was writing to the wrong device for the interrupt line setup. It would be good if the the AMD guys or Carl-Daniel can test and ack it.
Marc
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot