Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Yes, link - http://lkml.org/lkml/2007/10/8/93 add the AHCI legacy support to sata_nv when IDE/RAID mode been set in SBIOS and Device IDs are not in ahci.c at this moment. To do so, when a new chipset come out and DIDs haven't been submited to LKML,user still can use ahci driver to handle it when setting AHCI mode in BIOS, using sata_nv when setting RAID/IDE in BIOS. For example, ahci driver in Fedora 7 doesn't include the DIDs of MCP78, so if you set the IDE/RAID mode in BIOS, os installation onto SATA drive will fail. But if Fedora 7 include this patch, installation will be successful. 2007/10/19, Jeff Garzik [EMAIL PROTECTED]: peer chen wrote: Ok,I agree to use AHCI driver for our AHCI controllers no matter their class codes are IDE/RAID/AHCI. But for those new or upcoming AHCI controller which DIDs are not included in ahci.c and also IDE/RAID mode being set in BIOS, no driver will be loaded currently, so I hope the first patch http://lkml.org/lkml/2007/10/8/93 can be appied for this case. Any comments? hmmm is that the correct URL? That one updates sata_nv to support AHCI controllers?. I would think you would want to add the RAID class code to ahci.c instead? And just some regular PCI IDs? Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Ok,I agree to use AHCI driver for our AHCI controllers no matter their class codes are IDE/RAID/AHCI. But for those new or upcoming AHCI controller which DIDs are not included in ahci.c and also IDE/RAID mode being set in BIOS, no driver will be loaded currently, so I hope the first patch http://lkml.org/lkml/2007/10/8/93 can be appied for this case. Any comments? 2007/10/19, Jeff Garzik [EMAIL PROTECTED]: peer chen wrote: I hope one of the following patches can be merged to 2.6.24. == http://lkml.org/lkml/2007/10/8/93 http://lkml.org/lkml/2007/9/25/20 Unfortunately I do not feel like this is the right course of action. Experience from Intel platforms tells us that our users get very unhappy when their silicon supports AHCI mode, but they are forced into using a less-performant mode. A popular example is an unnamed OEM whose BIOS had no method whatsoever for enabling AHCI -- didn't even program the PCI BAR -- even though tests showed the AHCI mode worked just fine when manually programmed. AHCI is more likely to provide a /stable/ Serial ATA experience, because the silicon deals primarily with sending and receiving FIS's, and not much else. In constrast, experience has shown the legacy IDE interface to be a less reliable method of SATA support. And certainly AHCI is much, much faster with less per-command overhead. Given that AHCI is both faster and more stable, I feel it is the best policy to enable AHCI when the hardware supports it, regardless of PCI class code (IDE, SATA, or RAID). Yes, I agree to set the 'swncq' as default for 2.6.24, after all, for our server customers, stability is far more important than the new feature no matter the problem is caused by drive or controller. Agreed. Done! Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
I hope one of the following patches can be merged to 2.6.24. == http://lkml.org/lkml/2007/10/8/93 http://lkml.org/lkml/2007/9/25/20 Yes, I agree to set the 'swncq' as default for 2.6.24, after all, for our server customers, stability is far more important than the new feature no matter the problem is caused by drive or controller. 2007/10/13, Jeff Garzik [EMAIL PROTECTED]: Peer Chen wrote: Add the ahci controller legacy mode support to sata_nv. Move the DIDs of legacy mode from ahci.c to sata_nv.c The patch base on kernel 2.6.23-rc8 Signed-off-by: Peer Chen [EMAIL PROTECTED] Would you mind checking libata-dev.git#upstream, and make sure it has all the NV patches? I'm thinking I should go ahead and push the 'nv-swncq' branch, which contains the sata_nv updates for swncq. They have been in -mm for a while. I am leaning towards leaving the default to 'off' for 2.6.24 though. Comments welcome... Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Jeff, Is it possible this patch appear in mainline kernel 2.6.24? BRs Peer Chen -Original Message- From: Kuan Luo Sent: Thursday, September 27, 2007 4:55 PM To: 'Jeff Garzik' Cc: Zoltan Boszormenyi; [EMAIL PROTECTED]; Peer Chen; Robert Hancock; linux-ide@vger.kernel.org Subject: RE: [patch 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61 Jeff Garzik wrote: Kuan Luo wrote: Jeff Garzik wrote: Kuan Luo wrote: hi, i saw the below changes from http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.g it;a=commi tdiff;h=5a5a9e1890b8260686218a68862d880daee1a817 [libata] sata_nv: Clean up ATA_FLAG_NCQ usage; bit test micro-opt @@ -622,7 +622,9 @@ static const struct ata_port_info nv_port_info[] = { /* SWNCQ */ { .sht= nv_swncq_sht, - .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY, + .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY | + ATA_FLAG_NCQ, + .link_flags = ATA_LFLAG_HRST_TO_RESUME, .pio_mask = NV_PIO_MASK, .mwdma_mask = NV_MWDMA_MASK, .udma_mask = NV_UDMA_MASK, If swncq_enabled is set zero by user, nv_swncq_host_init would not be called . Then ncq should be disabled and the libata shouldn't send ncq cmd. I am not sure whether the ATA_FLAG_NCQ flag which is in default set makes libata send ncq cmd even when swncq_enable is 0? nv_init_one } else if (type == SWNCQ swncq_enabled) { dev_printk(KERN_NOTICE, pdev-dev, Using SWNCQ mode\n); nv_swncq_host_init(host); Thanks for watching! Yes, that looks like a problem. I still feel the flags usage I removed was problematic. A better solution, I think, would be to do follow the ADMA example of switching the port_info type during early initialization: if (type = CK804 adma_enabled) { type = ADMA; which in our case would result in if (type == SWNCQ !swncq_enabled) type = GENERIC; Or, if you prefer, we could take the opposite route, _not_ set SWNCQ in the pci_device_id table, and instead do something like if (type = MCP65 swncq_enabled) type = SWNCQ; (MCP65 is just a pulled-out-of-thin-air example) Regards, Jeff 1.The former method type =GENERIC cann't support hotplug in mcp51-55-61. 'GENERIC' just an example; my apologies for the confusion. 2.As to the latter mehthod, do you mean we may set MCP65 in pci_device_id table and add the extra variable static const struct ata_port_operations nv_MCP65_ops ={...}. Correct. The main point was to fall back from SWNCQ to something else, if !swncq_enabled, to avoid changing the ap-flags value after the port has been allocated and initialized internally. And that switch must occur prior to ata_pci_prepare_sff_host() call in nv_init_one(). Regards, Jeff One idea, only simply adding if (!swncq_enabled) nv_port_info[SWNCQ].flags = ~ATA_FLAG_NCQ; ppi[0] = nv_port_info[type]; rc = ata_pci_prepare_sff_host(pdev, ppi, host); I don't know if this is appropriate --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI being selected, which will verify if our legacy mode work well and have additional option if there is any bug for the ahci mode. Peer Chen 2007-09-25 - ·¢¼þÈË£ºJeff Garzik ·¢ËÍÈÕÆÚ£º2007-09-25 15:08:45 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºlinux-kernel; linux-ide; akpm Ö÷Ì⣺Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv Peer Chen wrote: Add the ahci controller legacy mode support to sata_nv. Move the DIDs of legacy mode from ahci.c to sata_nv.c The patch base on kernel 2.6.23-rc8 Signed-off-by: Peer Chen [EMAIL PROTECTED] I don't understand why these are being moved? If an interface can be driven via the AHCI driver, that is greatly preferred over the sata_nv driver. Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Yes,I hear what you are saying but user should know what they are setting in BIOS,there are lots of ways to change the BIOS setting result in unbootable system not only change AHCI/IDE mode. If they encounter booting failure after changing the BIOS setting,they should restore it. Using legacy driver for legacy mode won't affect user to enjoy the feature of AHCI,just select AHCI/RAID mode will ok. As I know, Intel did it in the same way,and I think it's reasonable. -- Peer Chen 2007-09-25 - ·¢¼þÈË£ºJeff Garzik ·¢ËÍÈÕÆÚ£º2007-09-25 16:13:52 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºlinux-kernel; linux-ide; akpm Ö÷Ì⣺Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv Peer Chen wrote: We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI being selected, which will verify if our legacy mode work well and have additional option if there is any bug for the ahci mode. I understand that logic, but look at what happens in practice: 1) User installs new OS in AHCI mode. Distro updates initramfs (loaded at kernel boot time, with boot drivers) to include ahci driver. 2) User reboots into BIOS setup, and switches from AHCI mode to IDE mode. 3) BIOS setup reboots computer. 4) OS kernel and initramfs image are loaded. ahci driver load fails. 5) User is left without a bootable system. The same situation happens in reverse, if you install in IDE mode (sata_nv in initramfs), and then switch to AHCI/RAID mode. Additionally, AHCI provides better performance and more direct exposure to the SATA frames. This is key for supporting many modern SATA features that cannot be accessed via IDE legacy mode. AHCI lacks in-silicon simulation of an IDE interface, which time has shown is a less stable, edge-case-prone approach to SATA. I do not find the verify nvidia's legacy mode works argument compelling; that is not the kernel's job, nor the user's. And if there is an AHCI silicon bug, let us deal with that when such a bug appears. Overall, AFAICS this patch -introduces- new ways for the user to easily render their systems unbootable. Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] ahci: Add MCP79 support to AHCI driver
Yes,they all belong to AHCI controllers, 4 of them use ahci class code and others use RAID class code. -- Peer Chen 2007-09-25 - ·¢¼þÈË£ºSergei Shtylyov ·¢ËÍÈÕÆÚ£º2007-09-24 20:53:44 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºAlan Cox; linux-kernel; linux-ide; akpm; jeff Ö÷Ì⣺Re: [PATCH] ahci: Add MCP79 support to AHCI driver Hello. Peer Chen wrote: Code change, remove some Device IDs. Signed-off-by: Peer Chen [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig 2007-09-20 11:01:55.0 -0400 +++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-24 10:08:03.0 -0400 @@ -472,6 +472,14 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */ + { PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },/* MCP79 */ I wonder whether all of those 8 IDs belong to AHCI controllers... MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Add the ahci controller legacy mode support to sata_nv. Move the DIDs of legacy mode from ahci.c to sata_nv.c The patch base on kernel 2.6.23-rc8 Signed-off-by: Peer Chen [EMAIL PROTECTED] --- diff -uprN -X linux-2.6.23-rc8-vanilla/Documentation/dontdiff linux-2.6.23-rc8-vanilla/drivers/ata/ahci.c linux-2.6.23-rc8/drivers/ata/ahci.c --- linux-2.6.23-rc8-vanilla/drivers/ata/ahci.c 2007-09-25 11:53:40.0 -0400 +++ linux-2.6.23-rc8/drivers/ata/ahci.c 2007-09-25 11:53:25.0 -0400 @@ -434,14 +434,6 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(NVIDIA, 0x044d), board_ahci },/* MCP65 */ { PCI_VDEVICE(NVIDIA, 0x044e), board_ahci },/* MCP65 */ { PCI_VDEVICE(NVIDIA, 0x044f), board_ahci },/* MCP65 */ - { PCI_VDEVICE(NVIDIA, 0x045c), board_ahci },/* MCP65 */ - { PCI_VDEVICE(NVIDIA, 0x045d), board_ahci },/* MCP65 */ - { PCI_VDEVICE(NVIDIA, 0x045e), board_ahci },/* MCP65 */ - { PCI_VDEVICE(NVIDIA, 0x045f), board_ahci },/* MCP65 */ - { PCI_VDEVICE(NVIDIA, 0x0550), board_ahci },/* MCP67 */ - { PCI_VDEVICE(NVIDIA, 0x0551), board_ahci },/* MCP67 */ - { PCI_VDEVICE(NVIDIA, 0x0552), board_ahci },/* MCP67 */ - { PCI_VDEVICE(NVIDIA, 0x0553), board_ahci },/* MCP67 */ { PCI_VDEVICE(NVIDIA, 0x0554), board_ahci },/* MCP67 */ { PCI_VDEVICE(NVIDIA, 0x0555), board_ahci },/* MCP67 */ { PCI_VDEVICE(NVIDIA, 0x0556), board_ahci },/* MCP67 */ @@ -450,10 +442,6 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(NVIDIA, 0x0559), board_ahci },/* MCP67 */ { PCI_VDEVICE(NVIDIA, 0x055a), board_ahci },/* MCP67 */ { PCI_VDEVICE(NVIDIA, 0x055b), board_ahci },/* MCP67 */ - { PCI_VDEVICE(NVIDIA, 0x07f0), board_ahci },/* MCP73 */ - { PCI_VDEVICE(NVIDIA, 0x07f1), board_ahci },/* MCP73 */ - { PCI_VDEVICE(NVIDIA, 0x07f2), board_ahci },/* MCP73 */ - { PCI_VDEVICE(NVIDIA, 0x07f3), board_ahci },/* MCP73 */ { PCI_VDEVICE(NVIDIA, 0x07f4), board_ahci },/* MCP73 */ { PCI_VDEVICE(NVIDIA, 0x07f5), board_ahci },/* MCP73 */ { PCI_VDEVICE(NVIDIA, 0x07f6), board_ahci },/* MCP73 */ @@ -462,10 +450,6 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(NVIDIA, 0x07f9), board_ahci },/* MCP73 */ { PCI_VDEVICE(NVIDIA, 0x07fa), board_ahci },/* MCP73 */ { PCI_VDEVICE(NVIDIA, 0x07fb), board_ahci },/* MCP73 */ - { PCI_VDEVICE(NVIDIA, 0x0ad0), board_ahci },/* MCP77 */ - { PCI_VDEVICE(NVIDIA, 0x0ad1), board_ahci },/* MCP77 */ - { PCI_VDEVICE(NVIDIA, 0x0ad2), board_ahci },/* MCP77 */ - { PCI_VDEVICE(NVIDIA, 0x0ad3), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0ad4), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0ad5), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0ad6), board_ahci },/* MCP77 */ diff -uprN -X linux-2.6.23-rc8-vanilla/Documentation/dontdiff linux-2.6.23-rc8-vanilla/drivers/ata/sata_nv.c linux-2.6.23-rc8/drivers/ata/sata_nv.c --- linux-2.6.23-rc8-vanilla/drivers/ata/sata_nv.c 2007-09-25 11:31:03.0 -0400 +++ linux-2.6.23-rc8/drivers/ata/sata_nv.c 2007-09-25 11:19:48.0 -0400 @@ -266,6 +266,7 @@ static void nv_adma_tf_read(struct ata_p enum nv_host_type { GENERIC, + AHCI_LEG, NFORCE2, NFORCE3 = NFORCE2, /* NF2 == NF3 as far as sata_nv is concerned */ CK804, @@ -287,6 +288,29 @@ static const struct pci_device_id nv_pci { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), GENERIC }, { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2), GENERIC }, { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3), GENERIC }, + { PCI_VDEVICE(NVIDIA, 0x45c), AHCI_LEG }, /* MCP65 */ + { PCI_VDEVICE(NVIDIA, 0x45d), AHCI_LEG }, /* MCP65 */ + { PCI_VDEVICE(NVIDIA, 0x45e), AHCI_LEG }, /* MCP65 */ + { PCI_VDEVICE(NVIDIA, 0x45f), AHCI_LEG }, /* MCP65 */ + { PCI_VDEVICE(NVIDIA, 0x550), AHCI_LEG }, /* MCP67 */ + { PCI_VDEVICE(NVIDIA, 0x551), AHCI_LEG }, /* MCP67 */ + { PCI_VDEVICE(NVIDIA, 0x552), AHCI_LEG }, /* MCP67 */ + { PCI_VDEVICE(NVIDIA, 0x553), AHCI_LEG }, /* MCP67 */ + { PCI_VDEVICE(NVIDIA, 0x7f0), AHCI_LEG }, /* MCP73 */ + { PCI_VDEVICE(NVIDIA, 0x7f1), AHCI_LEG }, /* MCP73 */ + { PCI_VDEVICE(NVIDIA, 0x7f2), AHCI_LEG }, /* MCP73 */ + { PCI_VDEVICE(NVIDIA, 0x7f3), AHCI_LEG }, /* MCP73 */ + { PCI_VDEVICE(NVIDIA, 0xad0
Re: Re: [PATCH] ahci: Add MCP79 support to AHCI driver
Yes,it's necessary because our RAID controller also use the ahci driver. -- Peer Chen 2007-09-24 - ·¢¼þÈË£ºAlan Cox ·¢ËÍÈÕÆÚ£º2007-09-21 18:32:09 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºlinux-kernel; linux-ide; akpm; jeff Ö÷Ì⣺Re: [PATCH] ahci: Add MCP79 support to AHCI driver On Fri, 21 Sep 2007 14:06:10 +0800 Peer Chen [EMAIL PROTECTED] wrote: Add the MCP79 support to ahci driver. The patch base on kernel 2.6.23-rc7 Is this actually needed or as they are standard ahci devices will the class match get them anyway ? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH] ahci: Add MCP79 support to AHCI driver
Code change, remove some Device IDs. Signed-off-by: Peer Chen [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0 -0400 +++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-24 10:08:03.0 -0400 @@ -472,6 +472,14 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */ + { PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },/* MCP79 */ /* SiS */ { PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */ - -- Peer Chen 2007-09-24 - ·¢¼þÈË£ºAlan Cox ·¢ËÍÈÕÆÚ£º2007-09-21 18:32:09 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºlinux-kernel; linux-ide; akpm; jeff Ö÷Ì⣺Re: [PATCH] ahci: Add MCP79 support to AHCI driver On Fri, 21 Sep 2007 14:06:10 +0800 Peer Chen [EMAIL PROTECTED] wrote: Add the MCP79 support to ahci driver. The patch base on kernel 2.6.23-rc7 Is this actually needed or as they are standard ahci devices will the class match get them anyway ? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ahci: Add MCP79 support to AHCI driver
Add the MCP79 support to ahci driver. The patch base on kernel 2.6.23-rc7 Signed-off-by: Peer Chen [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0 -0400 +++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-21 13:54:58.0 -0400 @@ -472,6 +472,18 @@ static const struct pci_device_id ahci_p { PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */ { PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */ + { PCI_VDEVICE(NVIDIA, 0x0ab4), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab5), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab6), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab7), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },/* MCP79 */ + { PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },/* MCP79 */ /* SiS */ { PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */ - - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ahci: enable GHC.AE bit before set GHC.HR
According to the description of section 5.2.2.1 and 10.1.2 of AHCI specification rev1_1/rev1_2, GHC.HR shall only be set to ¡®1¡¯ by software when GHC.AE is set to ¡®1¡¯. Signed-off-by: Peer Chen [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0 -0400 +++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-20 11:07:31.0 -0400 @@ -834,6 +834,10 @@ static int ahci_reset_controller(struct void __iomem *mmio = host-iomap[AHCI_PCI_BAR]; u32 tmp; +/* turn on AHCI mode before controller reset*/ +writel(HOST_AHCI_EN, mmio + HOST_CTL); +(void) readl(mmio + HOST_CTL); /* flush */ + /* global controller reset */ tmp = readl(mmio + HOST_CTL); if ((tmp HOST_RESET) == 0) { - -- Peer Chen 2007-09-21 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] drivers/ata: correct a wrong free function for sata_nv driver
Sorry for posting a fault patch,following is the right one. Signed-off-by: Peer Chen [EMAIL PROTECTED] === --- linux-2.6.22-rc1/drivers/ata/sata_nv.c.orig +++ linux-2.6.22-rc1/drivers/ata/sata_nv.c @@ -1619,7 +1619,7 @@ static void nv_remove_one (struct pci_de struct nv_host_priv *hpriv = host-private_data; ata_pci_remove_one(pdev); - kfree(hpriv); + devm_kfree(pdev-dev, hpriv); } #ifdef CONFIG_PM = BRs Peer Chen -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 1:21 PM To: Peer Chen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; IDE/ATA development list Subject: Re: [PATCH] drivers/ata: correct a wrong free function for sata_nv driver Peer Chen wrote: For sata_nv driver in kernel 2.6.21 onward, Inside nv_init_one(),use 'hpriv = devm_kzalloc(pdev-dev, sizeof(*hpriv), GFP_KERNEL);' but using the kfree(hpriv) to free that data struction in nv_remove_one(), which will cause system hang when removing the sata_nv module. Change the 'kfree()' function to 'devm_kfree' will fix this bug. The patch base on kernel 2.6.22-rc1. Signed-off-by: Peer Chen [EMAIL PROTECTED] = --- linux-2.6.22-rc1/drivers/ata/sata_nv.c.orig +++ linux-2.6.22-rc1/drivers/ata/sata_nv.c @@ -1619,7 +1619,7 @@ static void nv_remove_one (struct pci_de struct nv_host_priv *hpriv = host-private_data; ata_pci_remove_one(pdev); - kfree(hpriv); + devm_kfree(pci_dev-dev, hpriv); This patch is complete crap. It doesn't even compile. There is no variable pci_dev in this function at all. It is highly discouraging that you cannot even bother to compile your own submissions to the second (or third) most popular operating system in the world. Jeff --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 08/20] drivers/ata: remove the wildcard from sata_nv driver
Tejun, The future nvidia chips are all base on AHCI and also they can support compatible mode,but current sata_nv have the bug with compatible mode for AHCI controller,we need to modify the sata_nv driver then submit the patch. Before that,if users load the sata_nv driver for our AHCI controllers,they will encounter that bug. BRs Peer Chen -Original Message- From: Tejun Heo [mailto:[EMAIL PROTECTED] Sent: Friday, May 11, 2007 7:49 PM To: [EMAIL PROTECTED]; Peer Chen Cc: [EMAIL PROTECTED]; linux-ide@vger.kernel.org Subject: Re: [patch 08/20] drivers/ata: remove the wildcard from sata_nv driver [EMAIL PROTECTED] wrote: From: Peer Chen [EMAIL PROTECTED] Because nvidia SATA controllers onward base on AHCI, so wildcard in sata_nv driver is unnecessary. Also the wildcard sometimes cause sata_nv driver to be loaded for AHCI controllers,which is not as expected. Signed-off-by: Peer Chen [EMAIL PROTECTED] Cc: Tejun Heo [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Peer Chen, are you sure we don't miss any existing devices by doing this? Also, what would future nvidia chips look like? AHCI only or dual mode similar ICHs? If compatible mode is going to be supported there is no switch we can mangle from PCI quirks to put it into AHCI mode, we might wanna keep PCI_CLASS_STORAGE_IDE assuming compatible mode interface remains similar. Thanks. -- tejun --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 08/20] drivers/ata: remove the wildcard from sata_nv driver
As following, the scr registers' offset in sata_nv driver is 0x0 0x40, but offset 0x0 in BAR5 memory map of AHCI controller is 'HBA Capabilities register', the value of this register make the driver believe there is always a HD drive being connected to port0,so error happen. == NV_PORT0_SCR_REG_OFFSET = 0x00, NV_PORT1_SCR_REG_OFFSET = 0x40, BRs Peer Chen -Original Message- From: Tejun Heo [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 5:29 PM To: Peer Chen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-ide@vger.kernel.org Subject: Re: [patch 08/20] drivers/ata: remove the wildcard from sata_nv driver Hello, Peer Chen wrote: Tejun, The future nvidia chips are all base on AHCI and also they can support compatible mode,but current sata_nv have the bug with compatible mode for AHCI controller,we need to modify the sata_nv driver then submit the patch. Yes, please do that. Before that,if users load the sata_nv driver for our AHCI controllers,they will encounter that bug. What kind of bug are we talking about? Thanks. -- tejun --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] sata_nv ahci: Move some IDs from sata_nv.c to ahci.c
Thanks. BRs Peer Chen -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 3:20 AM To: Peer Chen Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org; Andrew Morton Subject: Re: [PATCH 1/2] sata_nv ahci: Move some IDs from sata_nv.c to ahci.c Peer Chen wrote: Resend the patch. The content of memory map io of BAR5 have been change from MCP65 then sata_nv can't work fine on the platform based on MCP65 and MCP67,so move their IDs from sata_nv.c to ahci.c. Please check attachment for new patch,thanks. Signed-off-by: Peer Chen [EMAIL PROTECTED] Patch applied, manually. For future patches, 1) Please do not quote the original message 2) Please include patches inline, rather than as an attachment. Jeff --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] sata_nv ahci: Move some IDs from sata_nv.c to ahci.c
Resend the patch. The content of memory map io of BAR5 have been change from MCP65 then sata_nv can't work fine on the platform based on MCP65 and MCP67,so move their IDs from sata_nv.c to ahci.c. Please check attachment for new patch,thanks. Signed-off-by: Peer Chen [EMAIL PROTECTED] -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Thursday, November 30, 2006 6:43 PM To: Peer Chen Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org; Andrew Morton Subject: Re: [PATCH 1/2] sata_nv ahci: Move some IDs from sata_nv.c to ahci.c Peer Chen wrote: Move the device IDs of MCP65/MCP67 from sata_nv.c to ahci.c. The patch will be applied to kernel 2.6.19. Please check attachment for the patch. Signed-off-by: Peer Chen [EMAIL PROTECTED] Please update as follows: 1) Provide a detailed explanation as to /why/ this is needed. I certainly encourage use of ahci over legacy mode, but the patch description tells us nothing. 2) Combine the two patches into one. Think of a patch as an atomic operation. If you apply your patches as submitted, then a 'git bisect' may reach a state where the PCI IDs exist in _neither_ sata_nv or ahci. Any time you /move/ code or data, it should be in the same patch. 3) Your patches are completely unreviewable in a standard Internet mailer, because they were sent with your email base64-encoded. For many mailers, base64 encoding means the patch is not shown nor able to be commented upon. Indeed, some mailers make it difficult to response -at all- to data contained in a MIME attachment. The change itself seems OK, once suitable justification is provided. Jeff --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- patch.sata_nv-ahci Description: patch.sata_nv-ahci
[PATCH 2/2] sata_nv ahci: Move some IDs from sata_nv.c to ahci.c
Move the device IDs of MCP65/MCP67 from sata_nv.c to ahci.c. The patch will be applied to kernel 2.6.19. Please check attachment for the patch. Signed-off-by: Peer Chen [EMAIL PROTECTED] BRs Peer Chen --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- patch.ahci Description: patch.ahci
RE: [PATCH] SCSI: Add the SGPIO support for sata_nv.c
I didn't get any comment from you guys for new patch, does someone take care this patch, do we still need some modification upon it? Or do we need re-submit it in other thread? BRs Peer Chen -Original Message- From: Peer Chen Sent: Tuesday, November 07, 2006 5:55 PM To: 'Christoph Hellwig' Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; linux-ide@vger.kernel.org; Kuan Luo Subject: RE: [PATCH] SCSI: Add the SGPIO support for sata_nv.c Modified and resent out the patch as attachment. Description about the patch: Add SGPIO support in sata_nv.c. SGPIO (Serial General Purpose Input Output) is a sideband serial 4-wire interface that a storage controller uses to communicate with a storage enclosure management controller, primarily to control activity and status LEDs that are located within drive bays or on a storage backplane. SGPIO is defined by [SFF8485]. In this patch,we drive the LEDs to blink when read/write operation happen on SATA drives connect the corresponding ports on MCP55 board. == The patch will be applied to kernel 2.6.19-rc4-git9. Singed-off-by: Kuan Luo [EMAIL PROTECTED] Singed-off-by: Peer Chen [EMAIL PROTECTED] BRs Peer Chen -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 6:41 PM To: Peer Chen Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; linux-ide@vger.kernel.org; Kuan Luo Subject: Re: [PATCH] SCSI: Add the SGPIO support for sata_nv.c On Tue, Oct 31, 2006 at 04:43:19PM +0800, Peer Chen wrote: The following SGPIO patch for sata_nv.c is based on 2.6.18 kernel. Signed-off by: Kuan Luo [EMAIL PROTECTED] First I'd like to say the patch subject isn't very informative. For a sata_nv patch it should read: [PATCH] sata_nv: foooblah and then the SGPIO in both the subject and description doesn't say anything at all, what functionality or improvement does this patch actually add. And in general send patches against latest git or -mm tree. I don't know how much the sata_nv driver changed since 2.6.18 but in general sending patches against old kernel means they often can't be applied anymore. +//sgpio +// Sgpio defines +// SGPIO state defines please use /* */ style comments. Also these aren't exactly useful +#define NV_ON 1 +#define NV_OFF 0 +#ifndef bool +#define bool u8 +#endif please don't use your own bool types. +#define BF_EXTRACT(v, off, bc) \ + u8)(v)) (off)) ((1 (bc)) - 1)) + +#define BF_INS(v, ins, off, bc) \ + (((v) ~1 (bc)) - 1)) (off))) | \ + (((u8)(ins)) (off))) + +#define BF_EXTRACT_U32(v, off, bc) \ + u32)(v)) (off)) ((1 (bc)) - 1)) + +#define BF_INS_U32(v, ins, off, bc) \ + (((v) ~1 (bc)) - 1)) (off))) | \ + (((u32)(ins)) (off))) please make such things inline functions. Also they could have more descriptive names. +union nv_sgpio_nvcr +{ + struct { + u8 init_cnt; + u8 cb_size; + u8 cbver; + u8 rsvd; + } bit; + u32 all; +}; + +union nv_sgpio_tx +{ + u8 tx_port[4]; + u32 all; +}; + +struct nv_sgpio_cb +{ + u64 scratch_space; + union nv_sgpio_nvcr nvcr; + u32 cr0; + u32 rsvd[4]; + union nv_sgpio_tx tx[2]; +}; + +struct nv_sgpio_host_share +{ + spinlock_t *plock; + unsigned long *ptstamp; +}; + +struct nv_sgpio_host_flags +{ + u8 sgpio_enabled:1; + u8 need_update:1; + u8 rsvd:6; +}; + +struct nv_host_sgpio +{ + struct nv_sgpio_host_flags flags; + u8 *pcsr; + struct nv_sgpio_cb *pcb; + struct nv_sgpio_host_share share; + struct timer_list sgpio_timer; +}; + +struct nv_sgpio_port_flags +{ + u8 last_state:1; + u8 recent_activity:1; + u8 rsvd:6; +}; + +struct nv_sgpio_led +{ + struct nv_sgpio_port_flags flags; + u8 force_off; + u8 last_cons_active; +}; + +struct nv_port_sgpio +{ + struct nv_sgpio_led activity; +}; + +static spinlock_tnv_sgpio_lock; please use DEFINE_SPINLOCK to initialize the lock statically. +static unsigned long nv_sgpio_tstamp; +static inline void nv_sgpio_set_csr(u8 csr, unsigned long pcsr) +{ + outb(csr, pcsr); +} + +static inline u8 nv_sgpio_get_csr(unsigned long pcsr) +{ + return inb(pcsr); +} these helpers aren't useful at all, please remove them. +static inline u8 nv_sgpio_get_func(struct ata_host_set *host_set) +{ + u8 devfn = (to_pci_dev(host_set-dev))-devfn; + return (PCI_FUNC(devfn)); +} + +static inline u8 nv_sgpio_tx_host_offset(struct ata_host_set *host_set