from:"Peer Chen"

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2008-01-06 Thread Peer Chen

Eric,
Any decision for this patch, if not, currently we prefer to add all our
code to quirks.c.

BRs
Peer Chen

-Original Message-
From: Peer Chen 
Sent: Wednesday, January 02, 2008 5:58 PM
To: 'Eric W. Biederman'
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

I think it's more reasonable to only apply this rule onto AMD platform.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 24, 2007 7:49 PM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

"Peer Chen" <[EMAIL PROTECTED]> writes:

> I feel it's dangerous to set the En bit on Intel platform, If the HT
MSI
> En is set, the MSI should be expected to transform to HT INT message
> format. It may cause interrupt lost or hardware internal state machine
> failed depend on the hardware design.

Reasonable.  As long as what the quirk is to avoid errata and
chipset specific issues I don't have a problem with it.

I figure the quirk should be a separate patch though.

My concern is that the general rule that always enabling HT MSI
mapping capabilities is reasonable.  Even if there are some
specific exceptions where we don't want to do that.

I want code that requires the smallest list of chipset
exceptions that we can make. 

Eric
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2008-01-06 Thread Peer Chen

Eric,
Any decision for this patch, if not, currently we prefer to add all our
code to quirks.c.

BRs
Peer Chen

-Original Message-
From: Peer Chen 
Sent: Wednesday, January 02, 2008 5:58 PM
To: 'Eric W. Biederman'
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

I think it's more reasonable to only apply this rule onto AMD platform.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 24, 2007 7:49 PM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

Peer Chen [EMAIL PROTECTED] writes:

 I feel it's dangerous to set the En bit on Intel platform, If the HT
MSI
 En is set, the MSI should be expected to transform to HT INT message
 format. It may cause interrupt lost or hardware internal state machine
 failed depend on the hardware design.

Reasonable.  As long as what the quirk is to avoid errata and
chipset specific issues I don't have a problem with it.

I figure the quirk should be a separate patch though.

My concern is that the general rule that always enabling HT MSI
mapping capabilities is reasonable.  Even if there are some
specific exceptions where we don't want to do that.

I want code that requires the smallest list of chipset
exceptions that we can make. 

Eric
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2008-01-02 Thread Peer Chen

I think it's more reasonable to only apply this rule onto AMD platform.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 24, 2007 7:49 PM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

"Peer Chen" <[EMAIL PROTECTED]> writes:

> I feel it's dangerous to set the En bit on Intel platform, If the HT
MSI
> En is set, the MSI should be expected to transform to HT INT message
> format. It may cause interrupt lost or hardware internal state machine
> failed depend on the hardware design.

Reasonable.  As long as what the quirk is to avoid errata and
chipset specific issues I don't have a problem with it.

I figure the quirk should be a separate patch though.

My concern is that the general rule that always enabling HT MSI
mapping capabilities is reasonable.  Even if there are some
specific exceptions where we don't want to do that.

I want code that requires the smallest list of chipset
exceptions that we can make. 

Eric
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2008-01-02 Thread Peer Chen

I think it's more reasonable to only apply this rule onto AMD platform.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 24, 2007 7:49 PM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

Peer Chen [EMAIL PROTECTED] writes:

 I feel it's dangerous to set the En bit on Intel platform, If the HT
MSI
 En is set, the MSI should be expected to transform to HT INT message
 format. It may cause interrupt lost or hardware internal state machine
 failed depend on the hardware design.

Reasonable.  As long as what the quirk is to avoid errata and
chipset specific issues I don't have a problem with it.

I figure the quirk should be a separate patch though.

My concern is that the general rule that always enabling HT MSI
mapping capabilities is reasonable.  Even if there are some
specific exceptions where we don't want to do that.

I want code that requires the smallest list of chipset
exceptions that we can make. 

Eric
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2007-12-24 Thread Peer Chen

I feel it's dangerous to set the En bit on Intel platform, If the HT MSI
En is set, the MSI should be expected to transform to HT INT message
format. It may cause interrupt lost or hardware internal state machine
failed depend on the hardware design.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 21, 2007 6:48 AM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

"Peer Chen" <[EMAIL PROTECTED]> writes:

> The quirk is for our Intel platform, we don't want HT MSI mapping
> enabled in any of our devices.

Why is this a problem?  I seem to recall a real hypertransport bus
downstream of the Intel cpu.

If there is a real hypertransport bus in the middle then what happens
if someone puts a tunnel that uses hypertransport between the two chips?

I feel very dense right now.  I don't understand why enabling the
mapping on an Intel based system is a problem.  I am afraid there is
some important gap in my understanding in which case we may need to
rethink enabling the hypertransport capability by default.

If disabling the hypertransport bus is simply an optimization, or it
is to deal with an issue that appears exclusive to Nvidia chips
I have no problem with your quirk.

Eric
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2007-12-24 Thread Peer Chen

I feel it's dangerous to set the En bit on Intel platform, If the HT MSI
En is set, the MSI should be expected to transform to HT INT message
format. It may cause interrupt lost or hardware internal state machine
failed depend on the hardware design.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Friday, December 21, 2007 6:48 AM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

Peer Chen [EMAIL PROTECTED] writes:

 The quirk is for our Intel platform, we don't want HT MSI mapping
 enabled in any of our devices.

Why is this a problem?  I seem to recall a real hypertransport bus
downstream of the Intel cpu.

If there is a real hypertransport bus in the middle then what happens
if someone puts a tunnel that uses hypertransport between the two chips?

I feel very dense right now.  I don't understand why enabling the
mapping on an Intel based system is a problem.  I am afraid there is
some important gap in my understanding in which case we may need to
rethink enabling the hypertransport capability by default.

If disabling the hypertransport bus is simply an optimization, or it
is to deal with an issue that appears exclusive to Nvidia chips
I have no problem with your quirk.

Eric
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2007-12-20 Thread Peer Chen

The quirk is for our Intel platform, we don't want HT MSI mapping
enabled in any of our devices.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 19, 2007 5:59 AM
To: peerchen
Cc: linux-kernel; akpm; Andy Currid; Peer Chen
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

"peerchen" <[EMAIL PROTECTED]> writes:

> According to the HyperTransport spec, 'En' indicate if the MSI Mapping
is
> active.
> Set the 'En' bit when setup pci and add the quirk for some nvidia
devices. 
>
> The patch base on kernel 2.6.24-rc5

Ok.  This is starting to look good.

> Signed-off-by: Andy Currid <[EMAIL PROTECTED]>
> Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
>
> ---
> diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
> linux-2.6.24-rc5-vanilla/drivers/pci/probe.c
> linux-2.6.24-rc5/drivers/pci/probe.c
> --- linux-2.6.24-rc5-vanilla/drivers/pci/probe.c 2007-12-18
14:35:46.0
> -0500
> +++ linux-2.6.24-rc5/drivers/pci/probe.c 2007-12-18 16:28:29.0
-0500
> @@ -721,6 +721,9 @@ static int pci_setup_device(struct pci_d
>  
>   /* "Unknown power state" */
>   dev->current_state = PCI_UNKNOWN;
> + 
> + /* Enable HT MSI mapping */
> + ht_enable_msi_mapping(dev);
>  
>   /* Early fixups, before probing the BARs */
>   pci_fixup_device(pci_fixup_early, dev);
> diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
> linux-2.6.24-rc5-vanilla/drivers/pci/quirks.c
> linux-2.6.24-rc5/drivers/pci/quirks.c
> --- linux-2.6.24-rc5-vanilla/drivers/pci/quirks.c 2007-12-18
14:35:46.0
> -0500
> +++ linux-2.6.24-rc5/drivers/pci/quirks.c 2007-12-18
16:28:41.0 -0500
> @@ -1705,6 +1705,45 @@ static void __devinit quirk_nvidia_ck804
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
>   quirk_nvidia_ck804_msi_ht_cap);
>  
> +static void __devinit quirk_msi_ht_cap_disable(struct pci_dev *dev) {
> + struct pci_dev *host_bridge;
> + int pos, ttl = 48;
> +
> + /* HT MSI mapping should be disabled on devices that are below
> +  * a non-Hypertransport host bridge. Locate the host bridge...
> +  */
> +
> + if ((host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0,0))) ==
NULL) {
> + printk(KERN_WARNING
> + "PCI: quirk_msi_ht_cap_disable didn't locate host bridge\n");
> + return;
> + }
> +
> + if ((pos = pci_find_ht_capability(host_bridge, HT_CAPTYPE_SLAVE)) !=
0) {
> + /* Host bridge is to HT */
> + return;
> + }
> +
> + /* Host bridge is not to HT, disable HT MSI mapping on this
device */
> +
> + pos = pci_find_ht_capability(dev, HT_CAPTYPE_MSI_MAPPING);
> + while (pos && ttl--) {
> + u8 flags;
> +
> + if (pci_read_config_byte(dev, pos + HT_MSI_FLAGS, ) == 0) {
> + printk(KERN_INFO "PCI: Quirk disabling HT MSI mapping on %s\n",
> +pci_name(dev));
> +
> + pci_write_config_byte(dev, pos + HT_MSI_FLAGS,
> +   flags &
~HT_MSI_FLAGS_ENABLE);
> + }
> + pos = pci_find_next_ht_capability(dev, pos,
> +
HT_CAPTYPE_MSI_MAPPING);
> + }
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
> + quirk_msi_ht_cap_disable);

Could you explain the need for this quirk?

My expectation would be that if we turned an MSI interrupt into a
hypertransport interrupt then if we hit a non-hyptransport bridge
upstream it would just turn the hypertransport interrupts into
whatever makes sense for the upstream bridge.  I can see it being
excess work and adding some latency but I don't see it being a
correctness problem. 

Or are my expectations off and the NVIDIA chipsets do not handle
hypertransport interrupts the way I would expect.  Dropping them
instead of converting when going to a non-hypertransport host bridge.


>  static void __devinit quirk_msi_intx_disable_bug(struct pci_dev *dev)
>  {
>   dev->dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
> diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
> linux-2.6.24-rc5-vanilla/include/asm-generic/pci.h
> linux-2.6.24-rc5/include/asm-generic/pci.h
> --- linux-2.6.24-rc5-vanilla/include/asm-generic/pci.h 2007-12-18
> 14:35:52.0 -0500
> +++ linux-2.6.24-rc5/include/asm-generic/pci.h 2007-12-18
16:29:12.0
> -0500
> @@ -45,6 +45,10 @@ pcibios_select_root(struct pci_dev *pdev
>  
>  #define pcibios_scan_all_fns(a, b)   0
>  
> +#ifndef HAVE_ARCH_HT_ENABLE_MSI_MAPPING
> +#define ht_enable_msi_mapping(a) 0
> +#endif /* HAVE

RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

2007-12-20 Thread Peer Chen

The quirk is for our Intel platform, we don't want HT MSI mapping
enabled in any of our devices.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 19, 2007 5:59 AM
To: peerchen
Cc: linux-kernel; akpm; Andy Currid; Peer Chen
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

peerchen [EMAIL PROTECTED] writes:

 According to the HyperTransport spec, 'En' indicate if the MSI Mapping
is
 active.
 Set the 'En' bit when setup pci and add the quirk for some nvidia
devices. 

 The patch base on kernel 2.6.24-rc5

Ok.  This is starting to look good.

 Signed-off-by: Andy Currid [EMAIL PROTECTED]
 Signed-off-by: Peer Chen [EMAIL PROTECTED]

 ---
 diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
 linux-2.6.24-rc5-vanilla/drivers/pci/probe.c
 linux-2.6.24-rc5/drivers/pci/probe.c
 --- linux-2.6.24-rc5-vanilla/drivers/pci/probe.c 2007-12-18
14:35:46.0
 -0500
 +++ linux-2.6.24-rc5/drivers/pci/probe.c 2007-12-18 16:28:29.0
-0500
 @@ -721,6 +721,9 @@ static int pci_setup_device(struct pci_d
  
   /* Unknown power state */
   dev-current_state = PCI_UNKNOWN;
 + 
 + /* Enable HT MSI mapping */
 + ht_enable_msi_mapping(dev);
  
   /* Early fixups, before probing the BARs */
   pci_fixup_device(pci_fixup_early, dev);
 diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
 linux-2.6.24-rc5-vanilla/drivers/pci/quirks.c
 linux-2.6.24-rc5/drivers/pci/quirks.c
 --- linux-2.6.24-rc5-vanilla/drivers/pci/quirks.c 2007-12-18
14:35:46.0
 -0500
 +++ linux-2.6.24-rc5/drivers/pci/quirks.c 2007-12-18
16:28:41.0 -0500
 @@ -1705,6 +1705,45 @@ static void __devinit quirk_nvidia_ck804
  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
   quirk_nvidia_ck804_msi_ht_cap);
  
 +static void __devinit quirk_msi_ht_cap_disable(struct pci_dev *dev) {
 + struct pci_dev *host_bridge;
 + int pos, ttl = 48;
 +
 + /* HT MSI mapping should be disabled on devices that are below
 +  * a non-Hypertransport host bridge. Locate the host bridge...
 +  */
 +
 + if ((host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0,0))) ==
NULL) {
 + printk(KERN_WARNING
 + PCI: quirk_msi_ht_cap_disable didn't locate host bridge\n);
 + return;
 + }
 +
 + if ((pos = pci_find_ht_capability(host_bridge, HT_CAPTYPE_SLAVE)) !=
0) {
 + /* Host bridge is to HT */
 + return;
 + }
 +
 + /* Host bridge is not to HT, disable HT MSI mapping on this
device */
 +
 + pos = pci_find_ht_capability(dev, HT_CAPTYPE_MSI_MAPPING);
 + while (pos  ttl--) {
 + u8 flags;
 +
 + if (pci_read_config_byte(dev, pos + HT_MSI_FLAGS, flags) == 0) {
 + printk(KERN_INFO PCI: Quirk disabling HT MSI mapping on %s\n,
 +pci_name(dev));
 +
 + pci_write_config_byte(dev, pos + HT_MSI_FLAGS,
 +   flags 
~HT_MSI_FLAGS_ENABLE);
 + }
 + pos = pci_find_next_ht_capability(dev, pos,
 +
HT_CAPTYPE_MSI_MAPPING);
 + }
 +}
 +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
 + quirk_msi_ht_cap_disable);

Could you explain the need for this quirk?

My expectation would be that if we turned an MSI interrupt into a
hypertransport interrupt then if we hit a non-hyptransport bridge
upstream it would just turn the hypertransport interrupts into
whatever makes sense for the upstream bridge.  I can see it being
excess work and adding some latency but I don't see it being a
correctness problem. 

Or are my expectations off and the NVIDIA chipsets do not handle
hypertransport interrupts the way I would expect.  Dropping them
instead of converting when going to a non-hypertransport host bridge.


  static void __devinit quirk_msi_intx_disable_bug(struct pci_dev *dev)
  {
   dev-dev_flags |= PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG;
 diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
 linux-2.6.24-rc5-vanilla/include/asm-generic/pci.h
 linux-2.6.24-rc5/include/asm-generic/pci.h
 --- linux-2.6.24-rc5-vanilla/include/asm-generic/pci.h 2007-12-18
 14:35:52.0 -0500
 +++ linux-2.6.24-rc5/include/asm-generic/pci.h 2007-12-18
16:29:12.0
 -0500
 @@ -45,6 +45,10 @@ pcibios_select_root(struct pci_dev *pdev
  
  #define pcibios_scan_all_fns(a, b)   0
  
 +#ifndef HAVE_ARCH_HT_ENABLE_MSI_MAPPING
 +#define ht_enable_msi_mapping(a) 0
 +#endif /* HAVE_ARCH_HT_ENABLE_MSI_MAPPING */
 +
  #ifndef HAVE_ARCH_PCI_GET_LEGACY_IDE_IRQ
  static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int
channel)
  {
 diff -uprN -X linux-2.6.24-rc5-vanilla/Documentation/dontdiff
 linux-2.6.24-rc5-vanilla/include/asm-x86/pci.h
 linux-2.6.24-rc5/include/asm-x86/pci.h
 --- linux-2.6.24-rc5-vanilla/include/asm-x86/pci.h 2007-12-18
14:35:51.0
 -0500
 +++ linux-2.6.24-rc5/include/asm-x86/pci.h 2007-12-18

RE: [PATCH 1/2] msi: set 'En' bit of MSI Mapping Capability on HT platform

2007-11-25 Thread Peer Chen

I think the following lines are suitable for other bridges besides
nvidia's, :) :
===
+   if (pci_enable_msi_ht_cap(dev) != 0) {
+   return 0;
+   } else {
+   /* Get upstream bridge device handle */
+
+   bridge_dev = dev->bus->self;
+   while(bridge_dev != 0) {
+   if (pci_enable_msi_ht_cap(bridge_dev) !=
0) {
+   return 0;
+   } else
+   bridge_dev =
bridge_dev->bus->self;
+   }
+
+   return 1;
+   } 


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 26, 2007 2:34 AM
To: peerchen
Cc: linux-kernel; akpm; Peer Chen; Andy Currid
Subject: Re: [PATCH 1/2] msi: set 'En' bit of MSI Mapping Capability on
HT platform

peerchen wrote:
> According to the HyperTransport spec, 'En' indicate if the MSI Mapping
is active. So it should be set when enable the MSI.
> 
> The patch base on kernel 2.6.24-rc3
> 
> Signed-off-by: Andy Currid <[EMAIL PROTECTED]>
> Signed-off-by: Peer Chen <[EMAIL PROTECTED]>

Isn't there a way we can make this work for any upstream HT bridge,
rather than only for specific NVIDIA chipsets?

-- 
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED] Home Page:
http://www.roberthancock.com/

---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/2] msi: set 'En' bit of MSI Mapping Capability on HT platform

2007-11-25 Thread Peer Chen

I think the following lines are suitable for other bridges besides
nvidia's, :) :
===
+   if (pci_enable_msi_ht_cap(dev) != 0) {
+   return 0;
+   } else {
+   /* Get upstream bridge device handle */
+
+   bridge_dev = dev-bus-self;
+   while(bridge_dev != 0) {
+   if (pci_enable_msi_ht_cap(bridge_dev) !=
0) {
+   return 0;
+   } else
+   bridge_dev =
bridge_dev-bus-self;
+   }
+
+   return 1;
+   } 


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 26, 2007 2:34 AM
To: peerchen
Cc: linux-kernel; akpm; Peer Chen; Andy Currid
Subject: Re: [PATCH 1/2] msi: set 'En' bit of MSI Mapping Capability on
HT platform

peerchen wrote:
 According to the HyperTransport spec, 'En' indicate if the MSI Mapping
is active. So it should be set when enable the MSI.
 
 The patch base on kernel 2.6.24-rc3
 
 Signed-off-by: Andy Currid [EMAIL PROTECTED]
 Signed-off-by: Peer Chen [EMAIL PROTECTED]

Isn't there a way we can make this work for any upstream HT bridge,
rather than only for specific NVIDIA chipsets?

-- 
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED] Home Page:
http://www.roberthancock.com/

---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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,

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP79 support to hda_intel driver

2007-09-21 Thread Peer Chen

Resend the patch for description modification and send to correct alsa maillist.

Add the MCP79 support to hda driver.
The patch base on kernel 2.6.23-rc7
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc7/sound/pci/hda/hda_intel.c.orig 2007-09-20 
15:40:51.0 -0400
+++ linux-2.6.23-rc7/sound/pci/hda/hda_intel.c  2007-09-21 13:50:33.0 
-0400
@@ -1791,6 +1791,10 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0ac0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);
-

--
Peer Chen
2007-09-21

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP79 support to hda_intel driver

2007-09-21 Thread Peer Chen

Add the MCP73/MCP77 support to hda driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc7/sound/pci/hda/hda_intel.c.orig 2007-09-20 
15:40:51.0 -0400
+++ linux-2.6.23-rc7/sound/pci/hda/hda_intel.c  2007-09-21 13:50:33.0 
-0400
@@ -1791,6 +1791,10 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0ac0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);
-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP79 support to hda_intel driver

2007-09-21 Thread Peer Chen

Resend the patch for description modification and send to correct alsa maillist.

Add the MCP79 support to hda driver.
The patch base on kernel 2.6.23-rc7
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
--- linux-2.6.23-rc7/sound/pci/hda/hda_intel.c.orig 2007-09-20 
15:40:51.0 -0400
+++ linux-2.6.23-rc7/sound/pci/hda/hda_intel.c  2007-09-21 13:50:33.0 
-0400
@@ -1791,6 +1791,10 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0ac0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);
-

--
Peer Chen
2007-09-21

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP79 support to hda_intel driver

2007-09-21 Thread Peer Chen

Add the MCP73/MCP77 support to hda driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
--- linux-2.6.23-rc7/sound/pci/hda/hda_intel.c.orig 2007-09-20 
15:40:51.0 -0400
+++ linux-2.6.23-rc7/sound/pci/hda/hda_intel.c  2007-09-21 13:50:33.0 
-0400
@@ -1791,6 +1791,10 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0ac0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
+   { 0x10de, 0x0ac3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP79 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);
-

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

2007-07-08 Thread Peer Chen

It's a rule for all our drivers not just for linux, also if we put the Maxtor 
drive to the blacklist so that its NCQ function won't be enable for all 
controllers of other vendors,but we don't have the strong evidence that those 
Maxtor HDDs are also broken for other controllers.


BRs
Peer Chen

-Original Message-
From: Zoltan Boszormenyi [mailto:[EMAIL PROTECTED] 
Sent: Saturday, July 07, 2007 3:33 PM
To: kuan luo
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
PROTECTED]; [EMAIL PROTECTED]; Peer Chen; Kuan Luo
Subject: Re: [PATCH] ata: Add the SW NCQ support to sata_nv for 
MCP51/MCP55/MCP61

kuan luo írta:
> From: Kuan Luo <[EMAIL PROTECTED]>
>
> Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA 
> controller.  NCQ function is disable by default, you can enable it 
> with 'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51 
> or
> MCP55 rev 0xa2  platform.
>
> Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
> Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
> ---

Thanks, I am using it on 2.6.22-rc7-git5, have run a stress test yesterday 
night.
It seems to be as stable as the previous version. I guess it's safe to turn it 
on by default when it gets into Linus' kernels.

I have a question though. Why is the blanket needed for Maxtor drives?
Can't it be narrowed down to certain models? Maybe those models should be put 
into libata blacklist...
Not that my current machine is affected, I am just curious.

Best regards,
Zoltán Böszörményi


---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

2007-07-08 Thread Peer Chen

It's a rule for all our drivers not just for linux, also if we put the Maxtor 
drive to the blacklist so that its NCQ function won't be enable for all 
controllers of other vendors,but we don't have the strong evidence that those 
Maxtor HDDs are also broken for other controllers.


BRs
Peer Chen

-Original Message-
From: Zoltan Boszormenyi [mailto:[EMAIL PROTECTED] 
Sent: Saturday, July 07, 2007 3:33 PM
To: kuan luo
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL 
PROTECTED]; [EMAIL PROTECTED]; Peer Chen; Kuan Luo
Subject: Re: [PATCH] ata: Add the SW NCQ support to sata_nv for 
MCP51/MCP55/MCP61

kuan luo írta:
 From: Kuan Luo [EMAIL PROTECTED]

 Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA 
 controller.  NCQ function is disable by default, you can enable it 
 with 'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51 
 or
 MCP55 rev 0xa2  platform.

 Signed-off-by: Kuan Luo [EMAIL PROTECTED]
 Signed-off-by: Peer Chen [EMAIL PROTECTED]
 ---

Thanks, I am using it on 2.6.22-rc7-git5, have run a stress test yesterday 
night.
It seems to be as stable as the previous version. I guess it's safe to turn it 
on by default when it gets into Linus' kernels.

I have a question though. Why is the blanket needed for Maxtor drives?
Can't it be narrowed down to certain models? Maybe those models should be put 
into libata blacklist...
Not that my current machine is affected, I am just curious.

Best regards,
Zoltán Böszörményi


---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

2007-06-27 Thread Peer Chen

We did the many test with the new version driver and didn't encounter
that problem, but in certain cases, DMASETUP command packets from drive
to the controller are corrupted, and the controller issues an R_ERR to
the drive. Drives that comply with SATA spec will re-transmit the
corrupted packet and normal operation continues. However, some Maxtor
NCQ drives do not re-transmit the DMASETUP command packet, resulting in
software timeout for this command. So if you are using the Maxtor HD and
meet this problem,please don't enable the NCQ function.

BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 27, 2007 1:07 PM
To: kuan luo
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Peer Chen; Kuan Luo
Subject: Re: [PATCH] ata: Add the SW NCQ support to sata_nv for
MCP51/MCP55/MCP61

kuan luo wrote:
> Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA 
> controller.
> NCQ function is disable by default, you can enable it with 'swncq=1'
> 
> Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
> Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
> 

Haven't reviewed in detail, but does look cleaner than the previous
version. Some people reported seeing some unrecognized FIS, etc. errors
with the previous version, have those been looked into/fixed?

-- 
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED] Home Page:
http://www.roberthancock.com/

---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

2007-06-27 Thread Peer Chen

We did the many test with the new version driver and didn't encounter
that problem, but in certain cases, DMASETUP command packets from drive
to the controller are corrupted, and the controller issues an R_ERR to
the drive. Drives that comply with SATA spec will re-transmit the
corrupted packet and normal operation continues. However, some Maxtor
NCQ drives do not re-transmit the DMASETUP command packet, resulting in
software timeout for this command. So if you are using the Maxtor HD and
meet this problem,please don't enable the NCQ function.


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 27, 2007 1:07 PM
To: kuan luo
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Peer Chen; Kuan Luo
Subject: Re: [PATCH] ata: Add the SW NCQ support to sata_nv for
MCP51/MCP55/MCP61

kuan luo wrote:
 Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA 
 controller.
 NCQ function is disable by default, you can enable it with 'swncq=1'
 
 Signed-off-by: Kuan Luo [EMAIL PROTECTED]
 Signed-off-by: Peer Chen [EMAIL PROTECTED]
 

Haven't reviewed in detail, but does look cleaner than the previous
version. Some people reported seeing some unrecognized FIS, etc. errors
with the previous version, have those been looked into/fixed?

-- 
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED] Home Page:
http://www.roberthancock.com/

---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP73/77 support to hda_intel driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to hda driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc4/sound/pci/hda/hda_intel.c.orig
+++ linux-2.6.22-rc4/sound/pci/hda/hda_intel.c
@@ -1788,6 +1788,12 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x044b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP65 */
{ 0x10de, 0x055c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
{ 0x10de, 0x055d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
+   { 0x10de, 0x07fc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x07fd, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x0774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP73/77 support to hda_intel driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to hda driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
--
--- linux-2.6.22-rc4/sound/pci/hda/hda_intel.c.orig
+++ linux-2.6.22-rc4/sound/pci/hda/hda_intel.c
@@ -1788,6 +1788,12 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x044b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP65 */
{ 0x10de, 0x055c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
{ 0x10de, 0x055d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
+   { 0x10de, 0x07fc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x07fd, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x0774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] PATA: Add the MCP73/77 support to PATA driver

2007-06-07 Thread Peer Chen

Add the PATA controller device ID to pci_ids.h for MCP73/MCP77.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
--
--- linux-2.6.22-rc4/include/linux/pci_ids.h.orig
+++ linux-2.6.22-rc4/include/linux/pci_ids.h
@@ -1233,6 +1233,8 @@
 #define PCI_DEVICE_ID_NVIDIA_NVENET_26  0x054E
 #define PCI_DEVICE_ID_NVIDIA_NVENET_27  0x054F
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE   0x0560
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE   0x056C
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE   0x0759
 
 #define PCI_VENDOR_ID_IMS  0x10e0
 #define PCI_DEVICE_ID_IMS_TT1280x9128

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] PATA: Add the MCP73/77 support to PATA driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to PATA driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc4/drivers/ide/pci/amd74xx.c.orig
+++ linux-2.6.22-rc4/drivers/ide/pci/amd74xx.c
@@ -76,6 +76,8 @@ static struct amd_ide_chip {
{ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE,0x50, AMD_UDMA_133 },
{ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_IDE,0x50, AMD_UDMA_133 },
{ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE,0x50, AMD_UDMA_133 },
+   { PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE,0x50, AMD_UDMA_133 },
+   { PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE,0x50, AMD_UDMA_133 },
{ PCI_DEVICE_ID_AMD_CS5536_IDE, 0x40, AMD_UDMA_100 },
{ 0 }
 };

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] PATA: Add the MCP73/77 support to PATA driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to PATA driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc4/drivers/ata/pata_amd.c.orig
+++ linux-2.6.22-rc4/drivers/ata/pata_amd.c
@@ -693,6 +693,8 @@ static const struct pci_device_id amd[] 
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE), 8 },
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_IDE), 8 },
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE), 8 },
+   { PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE), 8 },
+   { PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE), 8 },
{ PCI_VDEVICE(AMD,  PCI_DEVICE_ID_AMD_CS5536_IDE),  9 },
 
{ },

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ahci: Add MCP73/MCP77 support to AHCI driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to ahci driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>

--- linux-2.6.22-rc4/drivers/ata/ahci.c.orig
+++ linux-2.6.22-rc4/drivers/ata/ahci.c
@@ -426,6 +426,30 @@ 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 */
+   { PCI_VDEVICE(NVIDIA, 0x07f7), board_ahci },/* MCP73 */
+   { PCI_VDEVICE(NVIDIA, 0x07f8), board_ahci },/* MCP73 */
+   { 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 */
+   { PCI_VDEVICE(NVIDIA, 0x0ad7), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ad8), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */
 
/* SiS */
{ PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ahci: Add MCP73/MCP77 support to AHCI driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to ahci driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]

--- linux-2.6.22-rc4/drivers/ata/ahci.c.orig
+++ linux-2.6.22-rc4/drivers/ata/ahci.c
@@ -426,6 +426,30 @@ 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 */
+   { PCI_VDEVICE(NVIDIA, 0x07f7), board_ahci },/* MCP73 */
+   { PCI_VDEVICE(NVIDIA, 0x07f8), board_ahci },/* MCP73 */
+   { 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 */
+   { PCI_VDEVICE(NVIDIA, 0x0ad7), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ad8), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */
+   { PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */
 
/* SiS */
{ PCI_VDEVICE(SI, 0x1184), board_ahci }, /* SiS 966 */

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] PATA: Add the MCP73/77 support to PATA driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to PATA driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
--- linux-2.6.22-rc4/drivers/ata/pata_amd.c.orig
+++ linux-2.6.22-rc4/drivers/ata/pata_amd.c
@@ -693,6 +693,8 @@ static const struct pci_device_id amd[] 
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE), 8 },
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_IDE), 8 },
{ PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE), 8 },
+   { PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE), 8 },
+   { PCI_VDEVICE(NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE), 8 },
{ PCI_VDEVICE(AMD,  PCI_DEVICE_ID_AMD_CS5536_IDE),  9 },
 
{ },

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] PATA: Add the MCP73/77 support to PATA driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to PATA driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
--- linux-2.6.22-rc4/drivers/ide/pci/amd74xx.c.orig
+++ linux-2.6.22-rc4/drivers/ide/pci/amd74xx.c
@@ -76,6 +76,8 @@ static struct amd_ide_chip {
{ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE,0x50, AMD_UDMA_133 },
{ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_IDE,0x50, AMD_UDMA_133 },
{ PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE,0x50, AMD_UDMA_133 },
+   { PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE,0x50, AMD_UDMA_133 },
+   { PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE,0x50, AMD_UDMA_133 },
{ PCI_DEVICE_ID_AMD_CS5536_IDE, 0x40, AMD_UDMA_100 },
{ 0 }
 };

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] PATA: Add the MCP73/77 support to PATA driver

2007-06-07 Thread Peer Chen

Add the PATA controller device ID to pci_ids.h for MCP73/MCP77.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
--
--- linux-2.6.22-rc4/include/linux/pci_ids.h.orig
+++ linux-2.6.22-rc4/include/linux/pci_ids.h
@@ -1233,6 +1233,8 @@
 #define PCI_DEVICE_ID_NVIDIA_NVENET_26  0x054E
 #define PCI_DEVICE_ID_NVIDIA_NVENET_27  0x054F
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE   0x0560
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE   0x056C
+#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE   0x0759
 
 #define PCI_VENDOR_ID_IMS  0x10e0
 #define PCI_DEVICE_ID_IMS_TT1280x9128

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP73/77 support to hda_intel driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to hda driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
--
--- linux-2.6.22-rc4/sound/pci/hda/hda_intel.c.orig
+++ linux-2.6.22-rc4/sound/pci/hda/hda_intel.c
@@ -1788,6 +1788,12 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x044b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP65 */
{ 0x10de, 0x055c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
{ 0x10de, 0x055d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
+   { 0x10de, 0x07fc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x07fd, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x0774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] alsa: Add the MCP73/77 support to hda_intel driver

2007-06-07 Thread Peer Chen

Add the MCP73/MCP77 support to hda driver.
The patch base on kernel 2.6.22-rc4
 
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
--- linux-2.6.22-rc4/sound/pci/hda/hda_intel.c.orig
+++ linux-2.6.22-rc4/sound/pci/hda/hda_intel.c
@@ -1788,6 +1788,12 @@ static struct pci_device_id azx_ids[] = 
{ 0x10de, 0x044b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP65 */
{ 0x10de, 0x055c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
{ 0x10de, 0x055d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP67 */
+   { 0x10de, 0x07fc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x07fd, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP73 */
+   { 0x10de, 0x0774, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0775, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0776, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
+   { 0x10de, 0x0777, PCI_ANY_ID, PCI_ANY_ID, 0, 0, AZX_DRIVER_NVIDIA }, /* 
NVIDIA MCP77 */
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: MCP55 NCQ problem?

2007-05-31 Thread Peer Chen

Zoltan,
What's your board's model number? Could you post the pci dump using 'lspci 
-xxx'? Thanks.


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 31, 2007 10:31 PM
To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?

CCing Peer Chen and Kuan Luo from NVIDIA..

Looks like there were some unrecognized FIS errors from the controller 
in there?

Zoltan Boszormenyi wrote:
> Hi,
> 
> I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:
> 
> ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
> ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
> 12288 out
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
> 12288 out
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata2: hard resetting port
> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
> ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
> ata2.00: configured for UDMA/133
> ata2: EH pending after completion, repeating EH (cnt=4)
> ata2: EH complete
> sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA
> 
> At the time I was creating a DVD ISO image (reads and writes went to the 
> disk
> that was resetted), browsing mail in thunderbird which also exercised 
> the same
> disk and I was downloading another ISO with about 400-450 kB/sec to
> another disk. Here are the disks in question:
> 
> scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 
> ANSI: 5
> scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 
> ANSI: 5
> 
> I got almost the same yesterday with 2.6.22-rc2-mm1:
> 
> May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
> SErr 0x0 action 0x2 frozen
> May 29 12:44:20 localhost kernel: ata2.00: cmd 
> 61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
> May 29 12:44:20 localhost kernel:  res 
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:44:20 localhost kernel: ata2.00: cmd 
> 61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
> May 29 12:44:20 localhost kernel:  res 
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:44:20 localhost kernel: ata2: hard resetting port
> May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
> 113 SControl 300)
> May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
> 625142448, hpa_sectors = 625142448
> May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
> 625142448, hpa_sectors = 625142448
> May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
> May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
> repeating EH (cnt=4)
> May 29 12:44:21 localhost kernel: ata2: EH complete
> May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
> hardware sectors (320073 MB)
> May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
> May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
> enabled, read cache: enabled, doesn't support DPO or FUA
> ..
> May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7 
> SErr 0x0 action 0x2 frozen
> May 29 12:47:46 localhost kernel: ata2.00: cmd 
> 61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
> May 29 12:47:46 localhost kernel:  res 
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:47:46 localhost kernel: ata2.00: cmd 
> 61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
> May 29 12:47:46 localhost kernel:  res 
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:47:46 localhost kernel: ata2.00: cmd 
> 61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
> May 29 12:47:46 localhost kernel:  res 
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
> May 29 12:47:46 localhost kernel: ata2: hard resetting port
> May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
> 113 SControl 300)
> May 29

RE: MCP55 NCQ problem?

2007-05-31 Thread Peer Chen

Zoltan,
What's your board's model number? Could you post the pci dump using 'lspci 
-xxx'? Thanks.


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 31, 2007 10:31 PM
To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?

CCing Peer Chen and Kuan Luo from NVIDIA..

Looks like there were some unrecognized FIS errors from the controller 
in there?

Zoltan Boszormenyi wrote:
 Hi,
 
 I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:
 
 ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
 ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
 12288 out
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
 12288 out
 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 ata2: hard resetting port
 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
 ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
 ata2.00: configured for UDMA/133
 ata2: EH pending after completion, repeating EH (cnt=4)
 ata2: EH complete
 sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
 sd 1:0:0:0: [sdb] Write Protect is off
 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
 support DPO or FUA
 
 At the time I was creating a DVD ISO image (reads and writes went to the 
 disk
 that was resetted), browsing mail in thunderbird which also exercised 
 the same
 disk and I was downloading another ISO with about 400-450 kB/sec to
 another disk. Here are the disks in question:
 
 scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 
 ANSI: 5
 scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 
 ANSI: 5
 
 I got almost the same yesterday with 2.6.22-rc2-mm1:
 
 May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
 SErr 0x0 action 0x2 frozen
 May 29 12:44:20 localhost kernel: ata2.00: cmd 
 61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
 May 29 12:44:20 localhost kernel:  res 
 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
 May 29 12:44:20 localhost kernel: ata2.00: cmd 
 61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
 May 29 12:44:20 localhost kernel:  res 
 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
 May 29 12:44:20 localhost kernel: ata2: hard resetting port
 May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
 113 SControl 300)
 May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
 625142448, hpa_sectors = 625142448
 May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
 625142448, hpa_sectors = 625142448
 May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
 May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
 repeating EH (cnt=4)
 May 29 12:44:21 localhost kernel: ata2: EH complete
 May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
 hardware sectors (320073 MB)
 May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
 May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
 enabled, read cache: enabled, doesn't support DPO or FUA
 ..
 May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7 
 SErr 0x0 action 0x2 frozen
 May 29 12:47:46 localhost kernel: ata2.00: cmd 
 61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
 May 29 12:47:46 localhost kernel:  res 
 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
 May 29 12:47:46 localhost kernel: ata2.00: cmd 
 61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
 May 29 12:47:46 localhost kernel:  res 
 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
 May 29 12:47:46 localhost kernel: ata2.00: cmd 
 61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
 May 29 12:47:46 localhost kernel:  res 
 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
 May 29 12:47:46 localhost kernel: ata2: hard resetting port
 May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
 113 SControl 300)
 May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
 625142448, hpa_sectors = 625142448
 May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
 625142448, hpa_sectors = 625142448
 May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
 May 29 12:47:47 localhost kernel: ata2: EH pending after completion

[PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

2007-05-17 Thread Peer Chen

 Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.

This patch base on sata_nv.c file from kernel 2.6.22-rc1

See attachment for the patch.

Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
==
See attached file.
==

---
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-swncq
Description: patch-sata_nv-swncq

[PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

2007-05-17 Thread Peer Chen

 Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.

This patch base on sata_nv.c file from kernel 2.6.22-rc1

See attachment for the patch.

Signed-off-by: Kuan Luo [EMAIL PROTECTED]
Signed-off-by: Peer Chen [EMAIL PROTECTED]
==
See attached file.
==

---
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-swncq
Description: patch-sata_nv-swncq

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(>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: linux-kernel@vger.kernel.org; [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(>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(_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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/ata: correct a wrong free function for sata_nv driver

2007-05-15 Thread Peer Chen

For sata_nv driver in kernel 2.6.21 onward, Inside nv_init_one(),use
'hpriv = devm_kzalloc(>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(_dev->dev, hpriv);
 }
 
 #ifdef CONFIG_PM
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/ata: correct a wrong free function for sata_nv driver

2007-05-15 Thread Peer Chen

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);
 }
 
 #ifdef CONFIG_PM
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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: linux-kernel@vger.kernel.org; [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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] drivers/net: move the nvidia forcedeth driver from 100M group to 1000M group

2007-04-26 Thread Peer Chen

You are right,both ways would cause confusion,but sooner or later we need to 
move it because our NICs onward are all Gigabit and 100M NICs will disappear 
gradually in the future. Probably H.Peter's suggestion that have a single list 
for 100M and 1000M is a better choice.

-Original Message-
From: Lennart Sorensen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 25, 2007 10:06 PM
To: Peer Chen
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH] drivers/net: move the nvidia forcedeth driver from 100M 
group to 1000M group

On Wed, Apr 25, 2007 at 01:30:04PM +0800, Peer Chen wrote:
> nForce ehternet is a Gigabit NIC not 100M, move it to 1000M group to 
> avoid the confusion.

The forcedeth on my nforce2 board is 100Mbit.  I think the driver handles both 
100Mbit and GBit type devices.  Makes for an interesting categorization 
problem.  Moving it would cause confusion.  Leaving it where it is could cause 
confusion.  Moving it may confuse existing users more though so I would 
recommend leaving it alone unless you can somehow make it appear in both.

--
Len Sorensen
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] drivers/net: move the nvidia forcedeth driver from 100M group to 1000M group

2007-04-26 Thread Peer Chen

You are right,both ways would cause confusion,but sooner or later we need to 
move it because our NICs onward are all Gigabit and 100M NICs will disappear 
gradually in the future. Probably H.Peter's suggestion that have a single list 
for 100M and 1000M is a better choice.

-Original Message-
From: Lennart Sorensen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 25, 2007 10:06 PM
To: Peer Chen
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH] drivers/net: move the nvidia forcedeth driver from 100M 
group to 1000M group

On Wed, Apr 25, 2007 at 01:30:04PM +0800, Peer Chen wrote:
 nForce ehternet is a Gigabit NIC not 100M, move it to 1000M group to 
 avoid the confusion.

The forcedeth on my nforce2 board is 100Mbit.  I think the driver handles both 
100Mbit and GBit type devices.  Makes for an interesting categorization 
problem.  Moving it would cause confusion.  Leaving it where it is could cause 
confusion.  Moving it may confuse existing users more though so I would 
recommend leaving it alone unless you can somehow make it appear in both.

--
Len Sorensen
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/net: move the nvidia forcedeth driver from 100M group to 1000M group

2007-04-24 Thread Peer Chen

nForce ehternet is a Gigabit NIC not 100M, move it to 1000M group to
avoid the confusion.

Signed-off-by: Peer Chen <[EMAIL PROTECTED]>



--- linux-2.6.21-rc7/drivers/net/Kconfig.orig
+++ linux-2.6.21-rc7/drivers/net/Kconfig
@@ -1399,35 +1399,6 @@ config B44
  .  The module
will be
  called b44.
 
-config FORCEDETH
-   tristate "nForce Ethernet support"
-   depends on NET_PCI && PCI
-   help
- If you have a network (Ethernet) controller of this type, say
Y and
- read the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here and read
- .  The module
will be
- called forcedeth.
-
-config FORCEDETH_NAPI
-   bool "Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)"
-   depends on FORCEDETH && EXPERIMENTAL
-   help
- NAPI is a new driver API designed to reduce CPU and interrupt
load
- when the driver is receiving lots of packets from the card. It
is
- still somewhat experimental and thus not yet enabled by
default.
-
- If your estimated Rx load is 10kpps or more, or if the card
will be
- deployed on potentially unfriendly networks (e.g. in a
firewall),
- then say Y here.
-
- See  for more
- information.
-
- If in doubt, say N.
-
 config CS89x0
tristate "CS89x0 support"
depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 ||
ARCH_PNX010X)
@@ -1999,6 +1970,35 @@ config MYRI_SBUS
  To compile this driver as a module, choose M here: the module
  will be called myri_sbus.  This is recommended.
 
+config FORCEDETH
+   tristate "nForce Ethernet support"
+   depends on NET_PCI && PCI
+   help
+ If you have a network (Ethernet) controller of this type, say
Y and
+ read the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ To compile this driver as a module, choose M here and read
+ .  The module
will be
+ called forcedeth.
+
+config FORCEDETH_NAPI
+   bool "Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)"
+   depends on FORCEDETH && EXPERIMENTAL
+   help
+ NAPI is a new driver API designed to reduce CPU and interrupt
load
+ when the driver is receiving lots of packets from the card. It
is
+ still somewhat experimental and thus not yet enabled by
default.
+
+ If your estimated Rx load is 10kpps or more, or if the card
will be
+ deployed on potentially unfriendly networks (e.g. in a
firewall),
+ then say Y here.
+
+ See  for more
+ information.
+
+ If in doubt, say N.
+
 config NS83820
tristate "National Semiconductor DP83820 support"
depends on PCI
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/ata: remove the wildcard from sata_nv driver

2007-04-24 Thread Peer Chen

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]>

=

--- linux-2.6.21-rc7/drivers/ata/sata_nv.c.orig
+++ linux-2.6.21-rc7/drivers/ata/sata_nv.c
@@ -285,12 +285,6 @@ 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_VENDOR_ID_NVIDIA, PCI_ANY_ID,
-   PCI_ANY_ID, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_IDE<<8, 0x00, GENERIC },
-   { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
-   PCI_ANY_ID, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_RAID<<8, 0x00, GENERIC },
 
{ } /* terminate list */
 };
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/ata: remove the wildcard from sata_nv driver

2007-04-24 Thread Peer Chen

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]

=

--- linux-2.6.21-rc7/drivers/ata/sata_nv.c.orig
+++ linux-2.6.21-rc7/drivers/ata/sata_nv.c
@@ -285,12 +285,6 @@ 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_VENDOR_ID_NVIDIA, PCI_ANY_ID,
-   PCI_ANY_ID, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_IDE8, 0x00, GENERIC },
-   { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
-   PCI_ANY_ID, PCI_ANY_ID,
-   PCI_CLASS_STORAGE_RAID8, 0x00, GENERIC },
 
{ } /* terminate list */
 };
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/net: move the nvidia forcedeth driver from 100M group to 1000M group

2007-04-24 Thread Peer Chen

nForce ehternet is a Gigabit NIC not 100M, move it to 1000M group to
avoid the confusion.

Signed-off-by: Peer Chen [EMAIL PROTECTED]



--- linux-2.6.21-rc7/drivers/net/Kconfig.orig
+++ linux-2.6.21-rc7/drivers/net/Kconfig
@@ -1399,35 +1399,6 @@ config B44
  file:Documentation/networking/net-modules.txt.  The module
will be
  called b44.
 
-config FORCEDETH
-   tristate nForce Ethernet support
-   depends on NET_PCI  PCI
-   help
- If you have a network (Ethernet) controller of this type, say
Y and
- read the Ethernet-HOWTO, available from
- http://www.tldp.org/docs.html#howto.
-
- To compile this driver as a module, choose M here and read
- file:Documentation/networking/net-modules.txt.  The module
will be
- called forcedeth.
-
-config FORCEDETH_NAPI
-   bool Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)
-   depends on FORCEDETH  EXPERIMENTAL
-   help
- NAPI is a new driver API designed to reduce CPU and interrupt
load
- when the driver is receiving lots of packets from the card. It
is
- still somewhat experimental and thus not yet enabled by
default.
-
- If your estimated Rx load is 10kpps or more, or if the card
will be
- deployed on potentially unfriendly networks (e.g. in a
firewall),
- then say Y here.
-
- See file:Documentation/networking/NAPI_HOWTO.txt for more
- information.
-
- If in doubt, say N.
-
 config CS89x0
tristate CS89x0 support
depends on NET_PCI  (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 ||
ARCH_PNX010X)
@@ -1999,6 +1970,35 @@ config MYRI_SBUS
  To compile this driver as a module, choose M here: the module
  will be called myri_sbus.  This is recommended.
 
+config FORCEDETH
+   tristate nForce Ethernet support
+   depends on NET_PCI  PCI
+   help
+ If you have a network (Ethernet) controller of this type, say
Y and
+ read the Ethernet-HOWTO, available from
+ http://www.tldp.org/docs.html#howto.
+
+ To compile this driver as a module, choose M here and read
+ file:Documentation/networking/net-modules.txt.  The module
will be
+ called forcedeth.
+
+config FORCEDETH_NAPI
+   bool Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)
+   depends on FORCEDETH  EXPERIMENTAL
+   help
+ NAPI is a new driver API designed to reduce CPU and interrupt
load
+ when the driver is receiving lots of packets from the card. It
is
+ still somewhat experimental and thus not yet enabled by
default.
+
+ If your estimated Rx load is 10kpps or more, or if the card
will be
+ deployed on potentially unfriendly networks (e.g. in a
firewall),
+ then say Y here.
+
+ See file:Documentation/networking/NAPI_HOWTO.txt for more
+ information.
+
+ If in doubt, say N.
+
 config NS83820
tristate National Semiconductor DP83820 support
depends on PCI
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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

[PATCH 1/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.sata_nv
Description: patch.sata_nv

[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

[PATCH 1/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.sata_nv
Description: patch.sata_nv

RE: [Alsa-devel] [Patch] Audio: Add nvidia HD Audio controllers of MCP67 support to hda_intel.c

2006-11-17 Thread Peer Chen

Takashi:
When this patch will be included into the -mm tree? Is it possible to be
included in kernel source before final release of  kernel 2.6.19.

BRs
Peer Chen

-Original Message-
From: Takashi Iwai [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 01, 2006 12:02 AM
To: Randy Dunlap
Cc: Peer Chen; alsa-devel@lists.sourceforge.net;
linux-kernel@vger.kernel.org; Andy Currid; Brian Lazara;
[EMAIL PROTECTED]; Emily Jiang
Subject: Re: [Alsa-devel] [Patch] Audio: Add nvidia HD Audio controllers
of MCP67 support to hda_intel.c

At Tue, 31 Oct 2006 07:43:45 -0800,
Randy Dunlap wrote:
> 
> On Tue, 31 Oct 2006 15:42:54 +0100 Takashi Iwai wrote:
> 
> > At Tue, 31 Oct 2006 15:33:58 +0800,
> > Peer Chen wrote:
> > > 
> > > Add the support for HD audio controllers of
MCP51,MCP55,MCP61,MCP65 & MCP67.
> > > The following hda_intel.c patch is based on kernel 2.6.18.
> > > 
> > > Signed-off by: Peer Chen <[EMAIL PROTECTED]>
> > 
> > Applied to ALSA tree.  But I didn't add it to push-to-2.6.19-tree
> > because apparently no one has tested the patch well yet.
> > 
> > (BTW, your patch attached there was broken, so I had to apply it
> > manually.  At the next time, please either inline the patch in a
text
> > mail, or attach a plain text patch if inlining is not possible with
> > your MUA/MTA.)
> 
> Patches should also be sent made to apply to a current kernel
> tree, like 2.6.19-rc3, 2.6.19-rc4, 2.6.19-rc3-git8,
> Linus's git tree, or Andrew's -mm tree if that is the only
> place where the patch fits, or even to a subsystem tree (e.g., ALSA).

Since I already applied it to ALSA tree, the next mm tree will include
it (automatically taken it from alsa.git#mm branch).


Takashi
---
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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;

>

RE: [Alsa-devel] [Patch] Audio: Add nvidia HD Audio controllers of MCP67 support to hda_intel.c

2006-11-17 Thread Peer Chen

Takashi:
When this patch will be included into the -mm tree? Is it possible to be
included in kernel source before final release of  kernel 2.6.19.

BRs
Peer Chen

-Original Message-
From: Takashi Iwai [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 01, 2006 12:02 AM
To: Randy Dunlap
Cc: Peer Chen; alsa-devel@lists.sourceforge.net;
linux-kernel@vger.kernel.org; Andy Currid; Brian Lazara;
[EMAIL PROTECTED]; Emily Jiang
Subject: Re: [Alsa-devel] [Patch] Audio: Add nvidia HD Audio controllers
of MCP67 support to hda_intel.c

At Tue, 31 Oct 2006 07:43:45 -0800,
Randy Dunlap wrote:
 
 On Tue, 31 Oct 2006 15:42:54 +0100 Takashi Iwai wrote:
 
  At Tue, 31 Oct 2006 15:33:58 +0800,
  Peer Chen wrote:
   
   Add the support for HD audio controllers of
MCP51,MCP55,MCP61,MCP65  MCP67.
   The following hda_intel.c patch is based on kernel 2.6.18.
   
   Signed-off by: Peer Chen [EMAIL PROTECTED]
  
  Applied to ALSA tree.  But I didn't add it to push-to-2.6.19-tree
  because apparently no one has tested the patch well yet.
  
  (BTW, your patch attached there was broken, so I had to apply it
  manually.  At the next time, please either inline the patch in a
text
  mail, or attach a plain text patch if inlining is not possible with
  your MUA/MTA.)
 
 Patches should also be sent made to apply to a current kernel
 tree, like 2.6.19-rc3, 2.6.19-rc4, 2.6.19-rc3-git8,
 Linus's git tree, or Andrew's -mm tree if that is the only
 place where the patch fits, or even to a subsystem tree (e.g., ALSA).

Since I already applied it to ALSA tree, the next mm tree will include
it (automatically taken it from alsa.git#mm branch).


Takashi
---
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

Re: Re: [patch] net/tulip: LAN driver for ULI M5261/M5263

2005-08-16 Thread Peer . Chen


Jeff:
The attached file is the incremental patch to the original uli526x.c I send
you first time,
I modify the source according to your advice, thanks.

Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
(See attached file: patch_uli526x_inc)

Best Regards
Peer


|-+--->
| |   Jeff Garzik |
| |   <[EMAIL PROTECTED]|
| |   om> |
| |   |
| |   2005-08-12 03:15|
| |   |
|-+--->
  
>--|
  | 
 |
  |收件人： [EMAIL PROTECTED]   
  |
  |抄送：   Alexey Dobriyan <[EMAIL PROTECTED]>, Alan Cox <[EMAIL 
PROTECTED]>, [EMAIL PROTECTED],   |
  |netdev@vger.kernel.org, [EMAIL PROTECTED]
|
  |主题：   Re: [patch] net/tulip: LAN driver for ULI M5261/M5263  
  |
  
>--|



[EMAIL PROTECTED] wrote:
> Jeff:
> I have removed the uli526x support from tulip core driver,check the patch
> file for detail,thanks.

Patch applied, thanks!


> Alexey:
> Here the new patch,please check it, thanks.
> (See attached file: patchuli526x)

Please submit a patch -incremental- to the original uli526x.c that you
sent.

I have already applied your original patch, so I am unable to apply this
new patch.

Also:

1) Obtain PCI vendor, device IDs from pdev->vendor and pdev->device, not
by reading PCI config registers directly:

 //add by clearzhang 2004/7/8
 pci_read_config_dword(pdev,0x0,);
 m526x_id = configval;
 if(configval == 0x526310b9)
 {
 //printk("is m5263\n");
 pci_read_config_dword(pdev,0x0c,);
 configval = ((configval & 0x00ff) | 0x8000);
 pci_write_config_dword(pdev,0x0c,configval);
 }


2) Check return value of pci_alloc_consistent() for failure, and handle
cleanup:

> db->desc_pool_ptr = pci_alloc_consistent(pdev, sizeof(struct
tx_desc) *
> DESC_ALL_CNT + 0x20, >desc_pool_dma_ptr);
> db->buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC *
TX_DESC_CNT
>  + 4, >buf_pool_dma_ptr);


3) uli526x_remove_one() should call pci_disable_device()






patch_uli526x_inc
Description: Binary data

Re: Re: [patch] net/tulip: LAN driver for ULI M5261/M5263

2005-08-16 Thread Peer . Chen


Jeff:
The attached file is the incremental patch to the original uli526x.c I send
you first time,
I modify the source according to your advice, thanks.

Signed-off-by: Peer Chen [EMAIL PROTECTED]
(See attached file: patch_uli526x_inc)

Best Regards
Peer


|-+---
| |   Jeff Garzik |
| |   [EMAIL PROTECTED]|
| |   om |
| |   |
| |   2005-08-12 03:15|
| |   |
|-+---
  
--|
  | 
 |
  |收件人： [EMAIL PROTECTED]   
  |
  |抄送：   Alexey Dobriyan [EMAIL PROTECTED], Alan Cox [EMAIL 
PROTECTED], [EMAIL PROTECTED],   |
  |netdev@vger.kernel.org, [EMAIL PROTECTED]
|
  |主题：   Re: [patch] net/tulip: LAN driver for ULI M5261/M5263  
  |
  
--|



[EMAIL PROTECTED] wrote:
 Jeff:
 I have removed the uli526x support from tulip core driver,check the patch
 file for detail,thanks.

Patch applied, thanks!


 Alexey:
 Here the new patch,please check it, thanks.
 (See attached file: patchuli526x)

Please submit a patch -incremental- to the original uli526x.c that you
sent.

I have already applied your original patch, so I am unable to apply this
new patch.

Also:

1) Obtain PCI vendor, device IDs from pdev-vendor and pdev-device, not
by reading PCI config registers directly:

 //add by clearzhang 2004/7/8
 pci_read_config_dword(pdev,0x0,configval);
 m526x_id = configval;
 if(configval == 0x526310b9)
 {
 //printk(is m5263\n);
 pci_read_config_dword(pdev,0x0c,configval);
 configval = ((configval  0x00ff) | 0x8000);
 pci_write_config_dword(pdev,0x0c,configval);
 }


2) Check return value of pci_alloc_consistent() for failure, and handle
cleanup:

 db-desc_pool_ptr = pci_alloc_consistent(pdev, sizeof(struct
tx_desc) *
 DESC_ALL_CNT + 0x20, db-desc_pool_dma_ptr);
 db-buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC *
TX_DESC_CNT
  + 4, db-buf_pool_dma_ptr);


3) uli526x_remove_one() should call pci_disable_device()






patch_uli526x_inc
Description: Binary data

80 matches

Mail list logo