Shane Huang | 1 Aug 20:21 2012
Picon

[PATCH] ahci: implement aggressive SATA device sleep support

Device Sleep is a feature as described in AHCI 1.3.1 Technical Proposal.
This feature enables an HBA and SATA storage device to enter the DevSleep
interface state, enabling lower power SATA-based systems.

Signed-off-by: Shane Huang <shane.huang <at> amd.com>
---
 drivers/ata/ahci.h        |   14 +++++++++
 drivers/ata/libahci.c     |   71 ++++++++++++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-core.c |    9 ++++--
 include/linux/ata.h       |    2 ++
 include/linux/libata.h    |    1 +
 5 files changed, 93 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index c2594dd..7b6fcf7 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
 <at>  <at>  -115,6 +115,9  <at>  <at>  enum {
 	HOST_CAP2_BOH		= (1 << 0),  /* BIOS/OS handoff supported */
 	HOST_CAP2_NVMHCI	= (1 << 1),  /* NVMHCI supported */
 	HOST_CAP2_APST		= (1 << 2),  /* Automatic partial to slumber */
+	HOST_CAP2_SDS		= (1 << 3),  /* Support device sleep */
+	HOST_CAP2_SADM		= (1 << 4),  /* Support aggressive DevSlp */
+	HOST_CAP2_DESO		= (1 << 5),  /* DevSlp from slumber only */

 	/* registers for each SATA port */
 	PORT_LST_ADDR		= 0x00, /* command list DMA addr */
 <at>  <at>  -133,6 +136,7  <at>  <at>  enum {
 	PORT_SCR_ACT		= 0x34, /* SATA phy register: SActive */
 	PORT_SCR_NTF		= 0x3c, /* SATA phy register: SNotification */
(Continue reading)

Andrew Morton | 2 Aug 01:08 2012

Re: An Andre To Remember

On Fri, 27 Jul 2012 13:56:55 -0400
Jeff Garzik <jeff <at> garzik.org> wrote:

> Rest in peace Andre,

He was a nice guy, and sure did like to talk on the phone.

He was very active and popular in the local Porsche enthusiast
community and is remember for his generosity.  People share memories
here: http://forums.rennlist.com/rennforums/928-forum/707680-andre-hedrick.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Stirling Westrup | 2 Aug 01:43 2012
Picon

Re: IRQ issues with multiple SiI3114's on Kernel 3.2

On Sun, Jul 29, 2012 at 3:00 PM, Stirling Westrup <swestrup <at> gmail.com> wrote:
> On Sun, Jul 29, 2012 at 5:24 AM, Stan Hoeppner <stan <at> hardwarefreak.com> wrote:
>> On 7/28/2012 6:41 PM, Stirling Westrup wrote:
>>
>>> Okay, it looks like its a known hardware chipset problem, and was
>>> first reported 6-months ago.
>>>
>>> It affects all PCI cards in Asus Sandy-Bridge Motherboards. No known
>>> fix as of yet.
>>>
>>> https://lkml.org/lkml/2012/1/30/216
>>
>> At least our discussion got you looking in multiple directions, one of
>> which led you to this information.
>>
>> Given the problem is related to legacy PCI INTx sharing/routing, whether
>> on the PCI or PCIe bus, I'd recommend you step up to a high quality PCIe
>> x8 SAS/SATA HBA, such as the LSI 9211-8i PCIe x8, which supports MSI-X
>> and should instantly solve your problem.
>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816118112
>>
>> You'll need two breakout cables:
>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816116098
>>
>> This solution will set you back almost $300 USD.  I just did some
>> research on the Syba 4 port SiI 3124 PCIe x1 card.  The SiI 3124 is a
>> native PCI/X chip, thus the board uses a PCI-X to PCIe bridge chip which
>> hides under the large heatsink.  Thus this card will not work, as it
>> uses legacy PCI interrupts:
>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816124027
(Continue reading)

Stan Hoeppner | 2 Aug 03:08 2012

Re: IRQ issues with multiple SiI3114's on Kernel 3.2

On 8/1/2012 6:43 PM, Stirling Westrup wrote:
> On Sun, Jul 29, 2012 at 3:00 PM, Stirling Westrup <swestrup <at> gmail.com> wrote:
>> On Sun, Jul 29, 2012 at 5:24 AM, Stan Hoeppner <stan <at> hardwarefreak.com> wrote:
>>> On 7/28/2012 6:41 PM, Stirling Westrup wrote:
>>>
>>>> Okay, it looks like its a known hardware chipset problem, and was
>>>> first reported 6-months ago.
>>>>
>>>> It affects all PCI cards in Asus Sandy-Bridge Motherboards. No known
>>>> fix as of yet.
>>>>
>>>> https://lkml.org/lkml/2012/1/30/216
>>>
>>> At least our discussion got you looking in multiple directions, one of
>>> which led you to this information.
>>>
>>> Given the problem is related to legacy PCI INTx sharing/routing, whether
>>> on the PCI or PCIe bus, I'd recommend you step up to a high quality PCIe
>>> x8 SAS/SATA HBA, such as the LSI 9211-8i PCIe x8, which supports MSI-X
>>> and should instantly solve your problem.
>>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816118112
>>>
>>> You'll need two breakout cables:
>>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816116098
>>>
>>> This solution will set you back almost $300 USD.  I just did some
>>> research on the Syba 4 port SiI 3124 PCIe x1 card.  The SiI 3124 is a
>>> native PCI/X chip, thus the board uses a PCI-X to PCIe bridge chip which
>>> hides under the large heatsink.  Thus this card will not work, as it
>>> uses legacy PCI interrupts:
(Continue reading)

Leslee Lecuyer | 2 Aug 15:26 2012
Picon

Hey!! My name is Leslee...

Good evening, master 
I wanna be your  servant and I am ready to satisfy all your wishes and dreams My name is Leslee. I'm young,
beautiful and I like sexual experiments like BDSM, roleplaying and so on. I think that sex is all about
expressiveness and not only about missionary pose, right? 
I am looking for a man who is able to satisfy me completely, u know what I mean, don't you?) If you don't admit
any boundaries and ready to experience the strongest desire and best sex in ur life then don't hesitate and
write me back as soon as you can! I am already waiting! 
Can't wait to hear from you! 
Yours, Leslee
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Aaron Lu | 3 Aug 11:50 2012
Picon

Re: [PATCH v4 4/7] scsi: sr: block events when runtime suspended

Hello,

Not sure if I should use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL, any
comments?

Thanks,
Aaron

On 07/27/2012 05:00 PM, Aaron Lu wrote:
> When the ODD is runtime suspended, there is no need to poll it for
> events, so block events poll for it and unblock when resumed.
>
> Signed-off-by: Aaron Lu <aaron.lu <at> amd.com>
> ---
>   block/genhd.c     | 2 ++
>   drivers/scsi/sr.c | 7 ++++---
>   2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/block/genhd.c b/block/genhd.c
> index 9cf5583..bdb3682 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
>  <at>  <at>  -1458,6 +1458,7  <at>  <at>  void disk_block_events(struct gendisk *disk)
>
>   	mutex_unlock(&ev->block_mutex);
>   }
> +EXPORT_SYMBOL(disk_block_events);
>
>   static void __disk_unblock_events(struct gendisk *disk, bool check_now)
>   {
(Continue reading)

Jeff Garzik | 3 Aug 16:52 2012
Picon

Re: [PATCH v4 4/7] scsi: sr: block events when runtime suspended

On 08/03/2012 05:50 AM, Aaron Lu wrote:
> Hello,
>
> Not sure if I should use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL, any
> comments?

Typically you follow the pattern of similar exports in the file (or in 
the API, if no others are in the file).

	Jeff

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Aaron Lu | 7 Aug 08:18 2012
Picon

Re: [PATCH v4 4/7] scsi: sr: block events when runtime suspended

On 08/03/2012 10:52 PM, Jeff Garzik wrote:
> On 08/03/2012 05:50 AM, Aaron Lu wrote:
>> Hello,
>>
>> Not sure if I should use EXPORT_SYMBOL or EXPORT_SYMBOL_GPL, any
>> comments?
>
> Typically you follow the pattern of similar exports in the file (or in
> the API, if no others are in the file).

Thanks Jeff for your suggestion, and I'll keep using EXPORT_SYMBOL.
If anyone thinks this is wrong, please kindly let me know, thanks.

-Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Shane Huang | 7 Aug 19:44 2012
Picon

[PATCH RESEND] ahci: implement aggressive SATA device sleep support

Device Sleep is a feature as described in AHCI 1.3.1 Technical Proposal.
This feature enables an HBA and SATA storage device to enter the DevSleep
interface state, enabling lower power SATA-based systems.

Signed-off-by: Shane Huang <shane.huang <at> amd.com>
---
 drivers/ata/ahci.h        |   14 +++++++++
 drivers/ata/libahci.c     |   71 ++++++++++++++++++++++++++++++++++++++++++++-
 drivers/ata/libata-core.c |    9 ++++--
 include/linux/ata.h       |    2 ++
 include/linux/libata.h    |    1 +
 5 files changed, 93 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index c2594dd..7b6fcf7 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
 <at>  <at>  -115,6 +115,9  <at>  <at>  enum {
 	HOST_CAP2_BOH		= (1 << 0),  /* BIOS/OS handoff supported */
 	HOST_CAP2_NVMHCI	= (1 << 1),  /* NVMHCI supported */
 	HOST_CAP2_APST		= (1 << 2),  /* Automatic partial to slumber */
+	HOST_CAP2_SDS		= (1 << 3),  /* Support device sleep */
+	HOST_CAP2_SADM		= (1 << 4),  /* Support aggressive DevSlp */
+	HOST_CAP2_DESO		= (1 << 5),  /* DevSlp from slumber only */

 	/* registers for each SATA port */
 	PORT_LST_ADDR		= 0x00, /* command list DMA addr */
 <at>  <at>  -133,6 +136,7  <at>  <at>  enum {
 	PORT_SCR_ACT		= 0x34, /* SATA phy register: SActive */
 	PORT_SCR_NTF		= 0x3c, /* SATA phy register: SNotification */
(Continue reading)

Mark Lord | 7 Aug 19:16 2012

Re: sata_mv query

On 12-08-07 10:54 AM, Barry J Sturgeon wrote:
> when loading the 3.2.1. kernel onto my supermicro pdsm4 motherboard (with
> marvell 8 port sata controller) i have encountered performance degradation
> due to excessive cpu usage (i.e. three busy kworkers). after some
> investigation i have tracked down the problem to:
> 
> +static void mv_wait_for_edma_empty_idle(struct ata_port *ap)
> +{
> +       void __iomem *port_mmio = mv_ap_base(ap);
> +       const u32 empty_idle = (edma_status_cache_empty | edma_status_idle);
> +       const int per_loop = 5, timeout = (15 * 1000 / per_loop);
> +       int i;
> +
> +       /*
> +        * wait for the edma engine to finish transactions in progress.
> +        */
> +       for (i = 0; i < timeout; ++i) {
> +               u32 edma_stat = readl(port_mmio + edma_status_ofs);
> +               if ((edma_stat & empty_idle) == empty_idle)
> +                       break;
> *+               udelay(per_loop);*
> +       }
> +       /* ata_port_printk(ap, kern_info, "%s: %u+ usecs\n", __func__, i); */
> +}
>  
> it appears that we always reach the timeout value.
> note that empty_idle = 0xc0 (as you know),
> but most edma_stat values are (1100 or 1000).

Okay, that's weird.
(Continue reading)


Gmane