[nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work

[Luse, Paul E]

There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites.  We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release:


-         We weren't handling the CC register correctly in a few places.  Details are below, but this one is critical for new HW.

-         We were exposing LBA ranges that are identified by the controller as hidden

-         We weren't correctly handing the report_luns command for multiple luns

-         We weren't correctly checking status on init state machine completion handlers

As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J

Thx
Paul


Sources:

-         New switch for chatham2, removed inclusion of chatham switch by default


Nvmestd.h

-         Chatham stuff

-         Moved some NVME register defines to nvmereg.h

-         For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long)

Nvmestd.c

-         Chatham stuff

-         Added readback of CC before we write it again (to toggle EN for initial reset).  Without this some HW will surely fail to init correctly

Nvmestat.c

-         Chatham stuff


Nvmesnti.ch

-         Chatham stuff


Nvmesnti.c

-         Changes to honor the ExposeNamespace field we learn from LBA ranges.  Previously we were not hiding namespaces that were supposed to be hidden

-         Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get  second call with the correctly sized buffer.  Tested, of course, and it works as expected

-         Chatham stuff

Nvmereg.h

-         Moved reg defines to here from the other .h file mentioned above

Nveinit.c

-         In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it

-         In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes

-         in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field.  Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check

-         chatham stuff

-         in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not


____________________________________
Paul Luse
Sr. Staff Engineer
PCG Server Software Engineering
Desk: 480.554.3688, Mobile: 480.334.4630

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120416/5f0901ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source.zip
Type: application/x-zip-compressed
Size: 158591 bytes
Desc: source.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120416/5f0901ee/attachment.bin>