Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

2007-10-21 Thread peer chen
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

2007-10-19 Thread peer chen
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

2007-10-16 Thread peer chen
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

2007-10-04 Thread Peer Chen
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

2007-09-25 Thread Peer Chen
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

2007-09-25 Thread Peer Chen
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

2007-09-24 Thread Peer Chen
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

2007-09-24 Thread Peer Chen
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

2007-09-23 Thread Peer Chen
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

2007-09-23 Thread Peer Chen
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

2007-09-21 Thread Peer Chen
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

2007-09-20 Thread Peer Chen
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

2007-05-15 Thread Peer Chen
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

2007-05-14 Thread Peer Chen
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

2007-05-14 Thread Peer Chen
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

2006-12-20 Thread Peer Chen
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

2006-12-04 Thread Peer Chen
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

2006-11-30 Thread Peer Chen
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

2006-11-17 Thread Peer Chen
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