diff mbox

libata-pmp: add schedule timeout to support some PMP cards

Message ID 1320033440-1106-1-git-send-email-r66093@freescale.com
State Not Applicable
Delegated to: David Miller
Headers show

Commit Message

Changming Huang Oct. 31, 2011, 3:57 a.m. UTC 
From: Jerry Huang <r66093freescale.com>

With Freescale SATA controller, some PMP cards(e.g JMB393 PMP card)
can't work on some platforms (e.g mpc837x, p1022):
During PMP initialize, when reading the PMP SCR, we will observe the TIMEOUT
error because PMP card SCR is not ready.
Therefore, we need enough time to wait for the PMP card ready for SCR read:
1. read the SCR after 1ms sleep,
2. if failed, looping until read success or timeout (count = 0)

below is the error log:
fsl-sata e0018000.sata: Sata FSL Platform/CSB Driver init
scsi0 : sata_fsl
ata1: SATA max UDMA/133 irq 44
ata1: Signature Update detected @ 504 msecs
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.15: Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf
ata2.00: hard resetting link
ata2.15: qc timeout (cmd 0xe4)
ata2.00: failed to read SCR 0 (Emask=0x4)
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2: ATA_SRST issue failed
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2.00: reset failed, giving up
ata2.15: hard resetting link
ata2: Hardreset failed, not off-lined 0
ata2: No Signature Update
ata2.15: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: hard resetting link
ata2.15: qc timeout (cmd 0xe4)
ata2.00: failed to read SCR 0 (Emask=0x4)
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2: ATA_SRST issue failed
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2.00: reset failed, giving up
ata2.15: hard resetting link
ata2: Hardreset failed, not off-lined 0
ata2: No Signature Update
ata2.15: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: hard resetting link
ata2.15: qc timeout (cmd 0xe4)
ata2.00: failed to read SCR 0 (Emask=0x4)
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2: ATA_SRST issue failed
ata2.00: failed to read SCR 0 (Emask=0x40)
ata2.00: reset failed, giving up
ata2.00: failed to recover link after 3 tries, disabling
ata2.15: hard resetting link
ata2: Hardreset failed, not off-lined 0
ata2: No Signature Update
ata2.15: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.15: qc timeout (cmd 0xe4)
ata2.00: failed to read SCR 0 (Emask=0x4)
ata2.00: failed to write SCR 1 (Emask=0x40)
ata2.00: failed to clear SError.N (errno=-5)
ata2.15: hard resetting link
ata2: Hardreset failed, not off-lined 0
ata2: No Signature Update
ata2.15: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.01: hard resetting link
ata2.01: failed to resume link (SControl 0)
ata2.01: SATA link down (SStatus 0 SControl 0)
ata2.02: hard resetting link
ata2.02: failed to resume link (SControl 0)
ata2.02: SATA link down (SStatus 0 SControl 0)
......
ata2.14: hard resetting link
ata2.14: failed to resume link (SControl 0)
ata2.14: SATA link down (SStatus 0 SControl 0)
ata2: EH complete

Signed-off-by: Jerry Huang <r66093@freescale.com>
---
 drivers/ata/libata-pmp.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

Comments

Tejun Heo Nov. 3, 2011, 4:07 p.m. UTC | #1 
Hello,

On Mon, Oct 31, 2011 at 11:57:20AM +0800, r66093@freescale.com wrote:
> From: Jerry Huang <r66093freescale.com>
> 
> With Freescale SATA controller, some PMP cards(e.g JMB393 PMP card)
> can't work on some platforms (e.g mpc837x, p1022):
> During PMP initialize, when reading the PMP SCR, we will observe the TIMEOUT
> error because PMP card SCR is not ready.
> Therefore, we need enough time to wait for the PMP card ready for SCR read:
> 1. read the SCR after 1ms sleep,
> 2. if failed, looping until read success or timeout (count = 0)
...
> diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c
> index 224faab..18d5f8e 100644
> --- a/drivers/ata/libata-pmp.c
> +++ b/drivers/ata/libata-pmp.c
> @@ -140,11 +140,19 @@ int sata_pmp_qc_defer_cmd_switch(struct ata_queued_cmd *qc)
>  int sata_pmp_scr_read(struct ata_link *link, int reg, u32 *r_val)
>  {
>  	unsigned int err_mask;
> +	int count = 20;	/* try 20 times */
>  
>  	if (reg > SATA_PMP_PSCR_CONTROL)
>  		return -EINVAL;
>  
> -	err_mask = sata_pmp_read(link, reg, r_val);
> +	do {
> +		set_current_state(TASK_INTERRUPTIBLE);
> +		schedule_timeout(1 * HZ / 1000); /* sleep 1 msecond */
> +		set_current_state(TASK_RUNNING);
> +
> +		err_mask = sata_pmp_read(link, reg, r_val);
> +	} while ((count--) && err_mask);

Ummm... We can't really issue commands after failure without going
through recovery.  For ahci, it probably works.  For other
controllers, it may not.  Where does this delay come from?  Is there
any other way to wait for device readiness?

Thanks.
Changming Huang Nov. 10, 2011, 8:07 a.m. UTC | #2 
> -----Original Message-----
> From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-
> owner@vger.kernel.org] On Behalf Of Tejun Heo
> Sent: Friday, November 04, 2011 12:08 AM
> To: Huang Changming-R66093
> Cc: linux-ide@vger.kernel.org
> Subject: Re: [PATCH] libata-pmp: add schedule timeout to support some
> PMP cards
> 
> Hello,
> 
> On Mon, Oct 31, 2011 at 11:57:20AM +0800, r66093@freescale.com wrote:
> > From: Jerry Huang <r66093freescale.com>
> >
> > With Freescale SATA controller, some PMP cards(e.g JMB393 PMP card)
> > can't work on some platforms (e.g mpc837x, p1022):
> > During PMP initialize, when reading the PMP SCR, we will observe the
> > TIMEOUT error because PMP card SCR is not ready.
> > Therefore, we need enough time to wait for the PMP card ready for SCR
> read:
> > 1. read the SCR after 1ms sleep,
> > 2. if failed, looping until read success or timeout (count = 0)
> ...
> > diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c
> index
> > 224faab..18d5f8e 100644
> > --- a/drivers/ata/libata-pmp.c
> > +++ b/drivers/ata/libata-pmp.c
> > @@ -140,11 +140,19 @@ int sata_pmp_qc_defer_cmd_switch(struct
> > ata_queued_cmd *qc)  int sata_pmp_scr_read(struct ata_link *link, int
> > reg, u32 *r_val)  {
> >  	unsigned int err_mask;
> > +	int count = 20;	/* try 20 times */
> >
> >  	if (reg > SATA_PMP_PSCR_CONTROL)
> >  		return -EINVAL;
> >
> > -	err_mask = sata_pmp_read(link, reg, r_val);
> > +	do {
> > +		set_current_state(TASK_INTERRUPTIBLE);
> > +		schedule_timeout(1 * HZ / 1000); /* sleep 1 msecond */
> > +		set_current_state(TASK_RUNNING);
> > +
> > +		err_mask = sata_pmp_read(link, reg, r_val);
> > +	} while ((count--) && err_mask);
> 
> Ummm... We can't really issue commands after failure without going
> through recovery.  For ahci, it probably works.  For other controllers,
> it may not.  Where does this delay come from?  Is there any other way
> to wait for device readiness?
> 
It is very bad. 
I have two PMP cards, one (5 ports) can work well without the delay time before reading PMP SCR, but the other (15 ports) must delay enough time before reading the PMP SCR.
It seems there is no other way to detect the device readiness.

Maybe I will just delay some time before send SCR command, if it failed, then we will report this error to driver?

Thanks and Best Regards
Jerry Huang

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo Nov. 10, 2011, 3:20 p.m. UTC | #3 
Hello,

On Thu, Nov 10, 2011 at 08:07:47AM +0000, Huang Changming-R66093 wrote:
> > Ummm... We can't really issue commands after failure without going
> > through recovery.  For ahci, it probably works.  For other controllers,
> > it may not.  Where does this delay come from?  Is there any other way
> > to wait for device readiness?
> > 
> It is very bad.  I have two PMP cards, one (5 ports) can work well
> without the delay time before reading PMP SCR, but the other (15
> ports) must delay enough time before reading the PMP SCR.  It seems
> there is no other way to detect the device readiness.
> 
> Maybe I will just delay some time before send SCR command, if it
> failed, then we will report this error to driver?

Hmmm... I'm curious what's causing the problem.  Which port multiplier
are we talking about?  If it's specific to that PMP, we can add quirk
to support it.  Does the problem also happen when the PMP is connected
to a different controller?

Thanks.
Changming Huang Nov. 15, 2011, 8:43 a.m. UTC | #4 
Thanks and Best Regards
Jerry Huang

> -----Original Message-----
> From: Tejun Heo [mailto:htejun@gmail.com] On Behalf Of Tejun Heo
> Sent: Thursday, November 10, 2011 11:21 PM
> To: Huang Changming-R66093
> Cc: linux-ide@vger.kernel.org
> Subject: Re: [PATCH] libata-pmp: add schedule timeout to support some
> PMP cards
> 
> Hello,
> 
> On Thu, Nov 10, 2011 at 08:07:47AM +0000, Huang Changming-R66093 wrote:
> > > Ummm... We can't really issue commands after failure without going
> > > through recovery.  For ahci, it probably works.  For other
> > > controllers, it may not.  Where does this delay come from?  Is
> there
> > > any other way to wait for device readiness?
> > >
> > It is very bad.  I have two PMP cards, one (5 ports) can work well
> > without the delay time before reading PMP SCR, but the other (15
> > ports) must delay enough time before reading the PMP SCR.  It seems
> > there is no other way to detect the device readiness.
> >
> > Maybe I will just delay some time before send SCR command, if it
> > failed, then we will report this error to driver?
> 
> Hmmm... I'm curious what's causing the problem.  Which port multiplier
> are we talking about?  If it's specific to that PMP, we can add quirk
> to support it.  Does the problem also happen when the PMP is connected
> to a different controller?
> 
Hi,
The PMP card we are talking about is JMB393:
Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf.

This issue is observed on Freescale's Sata controller, including p1020e and mpc837xe.

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo Nov. 15, 2011, 2:51 p.m. UTC | #5 
Hello,

On Tue, Nov 15, 2011 at 08:43:02AM +0000, Huang Changming-R66093 wrote:
> The PMP card we are talking about is JMB393:
> Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf.
> 
> This issue is observed on Freescale's Sata controller, including p1020e and mpc837xe.

Can you please try different combinations?  ie. freescale sata + other
PMP and jmb393 + other sata controllers.  We need to know more before
adding workarounds to upstream.  Also, would you mind if I cc jmicron
ppl?

Thank you.
Mark Lord Nov. 15, 2011, 3:24 p.m. UTC | #6 
On 11-11-15 09:51 AM, Tejun Heo wrote:
> Hello,
> 
> On Tue, Nov 15, 2011 at 08:43:02AM +0000, Huang Changming-R66093 wrote:
>> The PMP card we are talking about is JMB393:
>> Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf.
>>
>> This issue is observed on Freescale's Sata controller, including p1020e and mpc837xe.
> 
> Can you please try different combinations?  ie. freescale sata + other
> PMP and jmb393 + other sata controllers.  We need to know more before
> adding workarounds to upstream.  Also, would you mind if I cc jmicron
> ppl?


I'm late tuning in here, but I have a JMB393 doorstop here
and would love to have it actually work with Linux.
It fails with all of my sata_sil, sata_sil24 and AHCI (including JMB) controllers.

What's the patch that I need to test ?
-ml
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord Nov. 15, 2011, 4:04 p.m. UTC | #7 
On 11-11-15 10:24 AM, Mark Lord wrote:
> On 11-11-15 09:51 AM, Tejun Heo wrote:
>> Hello,
>>
>> On Tue, Nov 15, 2011 at 08:43:02AM +0000, Huang Changming-R66093 wrote:
>>> The PMP card we are talking about is JMB393:
>>> Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf.
>>>
>>> This issue is observed on Freescale's Sata controller, including p1020e and mpc837xe.
>>
>> Can you please try different combinations?  ie. freescale sata + other
>> PMP and jmb393 + other sata controllers.  We need to know more before
>> adding workarounds to upstream.  Also, would you mind if I cc jmicron
>> ppl?
> 
> 
> I'm late tuning in here, but I have a JMB393 doorstop here
> and would love to have it actually work with Linux.
> It fails with all of my sata_sil, sata_sil24 and AHCI (including JMB) controllers.
> 
> What's the patch that I need to test ?

Found it, tried it, still have a Linux doorstop.
Works fine under that other O/S though.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Changming Huang Nov. 16, 2011, 9 a.m. UTC | #8 
> -----Original Message-----

> From: Mark Lord [mailto:kernel@teksavvy.com]

> Sent: Wednesday, November 16, 2011 12:04 AM

> To: Tejun Heo

> Cc: Huang Changming-R66093; linux-ide@vger.kernel.org

> Subject: Re: [PATCH] libata-pmp: add schedule timeout to support some

> PMP cards

> 

> On 11-11-15 10:24 AM, Mark Lord wrote:

> > On 11-11-15 09:51 AM, Tejun Heo wrote:

> >> Hello,

> >>

> >> On Tue, Nov 15, 2011 at 08:43:02AM +0000, Huang Changming-R66093

> wrote:

> >>> The PMP card we are talking about is JMB393:

> >>> Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf.

> >>>

> >>> This issue is observed on Freescale's Sata controller, including

> p1020e and mpc837xe.

> >>

> >> Can you please try different combinations?  ie. freescale sata +

> >> other PMP and jmb393 + other sata controllers.  We need to know more

> >> before adding workarounds to upstream.  Also, would you mind if I cc

> >> jmicron ppl?

> >

> >

> > I'm late tuning in here, but I have a JMB393 doorstop here and would

> > love to have it actually work with Linux.

> > It fails with all of my sata_sil, sata_sil24 and AHCI (including JMB)

> controllers.

> >

> > What's the patch that I need to test ?

> 

> Found it, tried it, still have a Linux doorstop.

> Works fine under that other O/S though.

> 

That’s a bad news. I think we need one workaround to fix it.
I tested the other two PMP cards, they work well on Freescale's board:
Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9 (Silicon Image)
Port Multiplier 1.2, 0x197b:0x0321 r0, 5 ports, feat 0x5/0xf (JMB391)
Changming Huang Nov. 16, 2011, 9:13 a.m. UTC | #9 
Thanks and Best Regards
Jerry Huang


>-----Original Message-----

>From: Mark Lord [mailto:kernel@teksavvy.com]

>Sent: Wednesday, November 16, 2011 12:04 AM

>To: Tejun Heo

>Cc: Huang Changming-R66093; linux-ide@vger.kernel.org

>Subject: Re: [PATCH] libata-pmp: add schedule timeout to support some

>PMP cards

>

>On 11-11-15 10:24 AM, Mark Lord wrote:

>> On 11-11-15 09:51 AM, Tejun Heo wrote:

>>> Hello,

>>>

>>> On Tue, Nov 15, 2011 at 08:43:02AM +0000, Huang Changming-R66093

>wrote:

>>>> The PMP card we are talking about is JMB393:

>>>> Port Multiplier 1.2, 0x197b:0x0325 r0, 15 ports, feat 0x5/0xf.

>>>>

>>>> This issue is observed on Freescale's Sata controller, including

>p1020e and mpc837xe.

>>>

>>> Can you please try different combinations?  ie. freescale sata +

>>> other PMP and jmb393 + other sata controllers.  We need to know more

>>> before adding workarounds to upstream.  Also, would you mind if I cc

>>> jmicron ppl?

>>

>>

>> I'm late tuning in here, but I have a JMB393 doorstop here and would

>> love to have it actually work with Linux.

>> It fails with all of my sata_sil, sata_sil24 and AHCI (including JMB)

>controllers.

>>

>> What's the patch that I need to test ?

>

>Found it, tried it, still have a Linux doorstop.

>Works fine under that other O/S though.

>

That’s a bad news. I think we need one workaround to fix it.
I tested the other two PMP cards, they work well on Freescale's board:
Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9 (Silicon Image)
Port Multiplier 1.2, 0x197b:0x0321 r0, 5 ports, feat 0x5/0xf (JMB391)
Mark Lord Nov. 16, 2011, 2:20 p.m. UTC | #10 
On 11-11-16 04:00 AM, Huang Changming-R66093 wrote:
>> -----Original Message-----
>> From: Mark Lord [mailto:kernel@teksavvy.com]
..
>>> What's the patch that I need to test ?
>>
>> Found it, tried it, still have a Linux doorstop.
>> Works fine under that other O/S though.
>>
> That’s a bad news. I think we need one workaround to fix it.
> I tested the other two PMP cards, they work well on Freescale's board:
> Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9 (Silicon Image)
> Port Multiplier 1.2, 0x197b:0x0321 r0, 5 ports, feat 0x5/0xf (JMB391)


No worries -- I'm just trying to get my JMB PMP to work on x86.
Your patch may still be good and necessary for Freescale; dunno.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Changming Huang Dec. 16, 2011, 10:58 a.m. UTC | #11 
Hi, have you any feedback about your PMP cards?

Now I must send out the patch to support the JMP393 PMP card.
Maybe I will simply to delay the enough time for PMP SCR as the below:

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(50)); /* sleep 50 msecond */

err_mask = sata_pmp_read(link, reg, r_val);


> -----Original Message-----

> From: Mark Lord [mailto:kernel@teksavvy.com]

> Sent: Wednesday, November 16, 2011 10:20 PM

> To: Huang Changming-R66093

> Cc: Tejun Heo; linux-ide@vger.kernel.org

> Subject: Re: [PATCH] libata-pmp: add schedule timeout to support some PMP

> cards

> 

> On 11-11-16 04:00 AM, Huang Changming-R66093 wrote:

> >> -----Original Message-----

> >> From: Mark Lord [mailto:kernel@teksavvy.com]

> ..

> >>> What's the patch that I need to test ?

> >>

> >> Found it, tried it, still have a Linux doorstop.

> >> Works fine under that other O/S though.

> >>

> > That’s a bad news. I think we need one workaround to fix it.

> > I tested the other two PMP cards, they work well on Freescale's board:

> > Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9 (Silicon

> Image)

> > Port Multiplier 1.2, 0x197b:0x0321 r0, 5 ports, feat 0x5/0xf (JMB391)

> 

> 

> No worries -- I'm just trying to get my JMB PMP to work on x86.

> Your patch may still be good and necessary for Freescale; dunno.

> 

> Cheers
Changming Huang Dec. 16, 2011, 11 a.m. UTC | #12 
For JMP393 PMP card, the VID: 0x197b, PID: 0x0325

> -----Original Message-----

> From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-

> owner@vger.kernel.org] On Behalf Of Huang Changming-R66093

> Sent: Friday, December 16, 2011 6:58 PM

> To: Mark Lord

> Cc: Tejun Heo; linux-ide@vger.kernel.org

> Subject: RE: [PATCH] libata-pmp: add schedule timeout to support some PMP

> cards

> 

> Hi, have you any feedback about your PMP cards?

> 

> Now I must send out the patch to support the JMP393 PMP card.

> Maybe I will simply to delay the enough time for PMP SCR as the below:

> 

> set_current_state(TASK_INTERRUPTIBLE);

> schedule_timeout(msecs_to_jiffies(50)); /* sleep 50 msecond */

> 

> err_mask = sata_pmp_read(link, reg, r_val);

> 

> 

> > -----Original Message-----

> > From: Mark Lord [mailto:kernel@teksavvy.com]

> > Sent: Wednesday, November 16, 2011 10:20 PM

> > To: Huang Changming-R66093

> > Cc: Tejun Heo; linux-ide@vger.kernel.org

> > Subject: Re: [PATCH] libata-pmp: add schedule timeout to support some

> > PMP cards

> >

> > On 11-11-16 04:00 AM, Huang Changming-R66093 wrote:

> > >> -----Original Message-----

> > >> From: Mark Lord [mailto:kernel@teksavvy.com]

> > ..

> > >>> What's the patch that I need to test ?

> > >>

> > >> Found it, tried it, still have a Linux doorstop.

> > >> Works fine under that other O/S though.

> > >>

> > > That’s a bad news. I think we need one workaround to fix it.

> > > I tested the other two PMP cards, they work well on Freescale's board:

> > > Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9

> > > (Silicon

> > Image)

> > > Port Multiplier 1.2, 0x197b:0x0321 r0, 5 ports, feat 0x5/0xf

> > > (JMB391)

> >

> >

> > No worries -- I'm just trying to get my JMB PMP to work on x86.

> > Your patch may still be good and necessary for Freescale; dunno.

> >

> > Cheers

> 

>   칻 & ~ &   +-  ݶ  w  ˛   m b  bu觶  ܨ}   Ơz &j:+v        zZ+  +zf

> h   ~    i   z  w   ?    & )ߢf
Changming Huang Dec. 16, 2011, 11:10 a.m. UTC | #13 
Or maybe I can add this PID/VID to the sata_pmp_quircks,
Before sata_pmp_read, driver will check this flag to decide if delay the time.

> -----Original Message-----

> From: Huang Changming-R66093

> Sent: Friday, December 16, 2011 7:01 PM

> To: Huang Changming-R66093; Mark Lord

> Cc: Tejun Heo; linux-ide@vger.kernel.org

> Subject: RE: [PATCH] libata-pmp: add schedule timeout to support some PMP

> cards

> 

> For JMP393 PMP card, the VID: 0x197b, PID: 0x0325

> 

> > -----Original Message-----

> > From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-

> > owner@vger.kernel.org] On Behalf Of Huang Changming-R66093

> > Sent: Friday, December 16, 2011 6:58 PM

> > To: Mark Lord

> > Cc: Tejun Heo; linux-ide@vger.kernel.org

> > Subject: RE: [PATCH] libata-pmp: add schedule timeout to support some

> > PMP cards

> >

> > Hi, have you any feedback about your PMP cards?

> >

> > Now I must send out the patch to support the JMP393 PMP card.

> > Maybe I will simply to delay the enough time for PMP SCR as the below:

> >

> > set_current_state(TASK_INTERRUPTIBLE);

> > schedule_timeout(msecs_to_jiffies(50)); /* sleep 50 msecond */

> >

> > err_mask = sata_pmp_read(link, reg, r_val);

> >

> >

> > > -----Original Message-----

> > > From: Mark Lord [mailto:kernel@teksavvy.com]

> > > Sent: Wednesday, November 16, 2011 10:20 PM

> > > To: Huang Changming-R66093

> > > Cc: Tejun Heo; linux-ide@vger.kernel.org

> > > Subject: Re: [PATCH] libata-pmp: add schedule timeout to support

> > > some PMP cards

> > >

> > > On 11-11-16 04:00 AM, Huang Changming-R66093 wrote:

> > > >> -----Original Message-----

> > > >> From: Mark Lord [mailto:kernel@teksavvy.com]

> > > ..

> > > >>> What's the patch that I need to test ?

> > > >>

> > > >> Found it, tried it, still have a Linux doorstop.

> > > >> Works fine under that other O/S though.

> > > >>

> > > > That’s a bad news. I think we need one workaround to fix it.

> > > > I tested the other two PMP cards, they work well on Freescale's

> board:

> > > > Port Multiplier 1.1, 0x1095:0x4726 r31, 7 ports, feat 0x1/0x9

> > > > (Silicon

> > > Image)

> > > > Port Multiplier 1.2, 0x197b:0x0321 r0, 5 ports, feat 0x5/0xf

> > > > (JMB391)

> > >

> > >

> > > No worries -- I'm just trying to get my JMB PMP to work on x86.

> > > Your patch may still be good and necessary for Freescale; dunno.

> > >

> > > Cheers

> >

> >   칻 & ~ &   +-  ݶ  w  ˛   m b  bu觶  ܨ}   Ơz &j:+v        zZ+

> +zf

> > h   ~    i   z  w   ?    & )ߢf
diff mbox

Patch

diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c
index 224faab..18d5f8e 100644
--- a/drivers/ata/libata-pmp.c
+++ b/drivers/ata/libata-pmp.c
@@ -140,11 +140,19 @@  int sata_pmp_qc_defer_cmd_switch(struct ata_queued_cmd *qc)
 int sata_pmp_scr_read(struct ata_link *link, int reg, u32 *r_val)
 {
 	unsigned int err_mask;
+	int count = 20;	/* try 20 times */
 
 	if (reg > SATA_PMP_PSCR_CONTROL)
 		return -EINVAL;
 
-	err_mask = sata_pmp_read(link, reg, r_val);
+	do {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout(1 * HZ / 1000); /* sleep 1 msecond */
+		set_current_state(TASK_RUNNING);
+
+		err_mask = sata_pmp_read(link, reg, r_val);
+	} while ((count--) && err_mask);
+
 	if (err_mask) {
 		ata_link_printk(link, KERN_WARNING, "failed to read SCR %d "
 				"(Emask=0x%x)\n", reg, err_mask);