Re: System fails to connect to iHOS-104 DVD drive with nvidia MCP61 chipset.

[Bruce Link <Bruce@1045.ca>]

> Hello,
>
> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
> > > Is there any more information I can supply that would be helpful?
> >
> > I'm not quite sure what the next step would be. It's quite possible
> > that the NVIDIA driver in Windows is doing some magic to work around
> > the problem that we don't know about, but it's hard to say what that
> > might be. The fact that the default drivers used in the WinPE boot
> > don't seem to work would tend to point toward some kind of hardware
> > incompatibility issue.
> >
> > Tejun, think you poked with some of this stuff before - any ideas?
>
> It has been years since I looked at MCP quirks, of which there are too
> many.  It's likely another quirk on the controller side that nvidia
> worked around somehow without telling anyone.  Given the history and
> that nvidia is out of chipset market, I think it's highly unlikely to
> learn what the issue and workaround are without reverse engineering
> it.  So, um, no idea.
>
> Thanks.
>
> -- 
> tejun
> --

Robert,

I've inquired about this problem with Allen Martin at Nvidia, he had the 
following reply:

/--------SNIP---------------/
Hi Bruce, I did work on the Windows SATA driver for those chipsets, so 
I’m familiar with it. I’m not aware of any of any timing workarounds for 
any devices in the driver, but it’s certainly true that there are 
devices that have timing sensitivity, especially around the IDENTIFY 
command and it may inadvertently work with one driver and not another.

 From the bug reports it looks like it’s always timing out on a 
TEST_UNIT_READY command? I assume this is probably the first command 
sent down after IDENTIFY to check for presense of a CD in the drive? If 
so it’s likely the drive is locked up and any command at that point will 
fail. If you want to test out the theory about it being a timing issue, 
I would stick some udelay()s in the identify code path, both before and 
after starting the transfer to see if it makes any difference. Also do 
you know if the driver does a PHY reset when it resets the link? If not, 
you can try doing that by writing a 0 to SControl and then restoring it 
with the original value.

Hope this helps,

-Allen
/--------SNIP---------------/

Does this provide any actionable information? I've tried searching for 
the proper location to impliment these delays in the sata_nv.c and 
libata-eh.c files but admittedly, am in over my head.

Thanks
Bruce