mmc: cavium: execute_tuning for octeontx2

commit 7089742578fe4054d8da70ca713e9916db7353de from
git@git.assembla.com:cavium/WindRiver.linux.git

At higher speeds, the sampling point for valid
capture on command or data lines becomes more
critical. The board, chip, device, temperature,
voltage changes can all cause variations in the
sampling delay. This needs to be evaluated
dynamically by invoking the tuning function.

For tuning the data in, host sends ext_csd command
to get 512 bytes of ext_csd data for tap delays
ranging from 0 to 63. For certain delay value,
the EXT_CSD command would be successful. Adding
more delay, in the iteration, would start causing
failure. The patch picks up the first success and
then the first failure after the first success. It
then takes an average of that. The average is to be
programmed in the MIO_EMM_TIMING.DATA_IN.

For cmd in tuning, host sends a SEND_STATUS command
and gets a response. Host checks for CRC error in
response and terms them success or failure for
varying values of tap from 0 to 63. Similar to the
above mechanism, an average is take to program
MIO_EMM_TIMING.CMD_IN.

Repaired execute_tuning, added card_reset
These changes make it functional on cn96xx:

- cope with NULL mmc->card when get_ext_csd called early
  as part of slot init, and still try to give a sensible
  result for the invoking ops->execute_tuning(mmc, opcode)

- similar small first-run problems

- add ops->hw_reset to allow card, not necessarily all the
  cards on a common slot and/or vmmc, to be reset.
  This should speed up multi-card bringups when HS200/HS400
  ops->execute_tuning gets called, as when tuning to a new
  mmc/sd while accessing another mmc/sd.
  Earlier code was observed to thrash.
  This should reliably clear any hung mmc/core ops where
  tuning ops have spun the knobs too far, invoking CRCs

- advertise mmc_can_retune(mmc) during slot_probe

Expanded  two tap-adjusters to four,
which excute in order, sanitizing CMD_IN/OUT comms
before moving on to DATA_IN/OUT.
(DATA_IN tuning best done with CMD19/14/21, and the opcode
passthrough should help the mmc/core smarts best tune that)

For each of these 4 dimensions, sweep all the possible
tap values, find the longest run of correct response,
and save the midpoint as current tuning.
Uses the mmc/core-supplied CMD19/CMD14/CMD21 machine
for tuning DATA[0-7], and for CMD path SEND_STATUS
and READ_EXT_CSD.

When not in DDR modes (like HS400) skip DATA_OUT_TAP

This will get called again on mmc_switch actions, like
escalation along HS->HS200->HS400 path, speed/power
budget changes, or CRC errors.

Default tuning: every cmd/data in/out tap count 32 (max/2)
runs at 100MHz HS400 (ddr, 8bit) with no CRC errs observed.
On cn96-A0 this is the max supported clock

Forcing CRC errors (by hand-modifying MIO_EMM_TIMING to
provoke failure) causes re-tuning to happen, command retry
to happen in the mmc/core logic, and transfers complete

Change footprint (apart from what's mentioned above)

- cvm_mmc_set_timing() is a common func for all the places
  MIO_EMM_TIMING is changed

- slot->tuned flag is set when tuning has been run for a
  particular bus config, else defaults are imposed until
  tuning run can refine them

- emmc_io_drive_setup() & cvm_mmc_configure_delay() should
  be run when a slot-switch or power/timing/width switch
  is done.  Previously this could be missed

- host->current_req (used by irq code to find request/slot)
  was not being NULLed on multi-sector DMA failure, so CRC
  errors during read/write ops caused exception when _next_
  command (perhaps a tuning command in response to the fail)
  was handled

- cvm_mmc_send_status() expanded to pass back status as
    cvm_mmc_r1_cmd(mmc, &status, opcode)
  to be examined by tuning code. Now takes an opcode arg
  (if zero, SEND_STATUS is done).

- internal functions for sending status & ext_csd for tuning
  do not yet reliably teardown on timeout, so data structures
  are static to avoid out-of-scope refs from irq context when
  the previously on-stack objects are explored. Still ugly,
  Will study mmc/core shootdown code more, and clean this up.
  Or could just leave them static.

Change-Id: I36c8368406ee41da0cd227957515971340b60a21
Signed-off-by: Peter Swain <pswain@marvell.com>
Reviewed-on: https://sj1git1.cavium.com/8548


Tested-by: Sunil Kovvuri Goutham <Sunil.Goutham@cavium.com>
Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>