ENGR00233866: SAHARA4 RNG fails to auto-seed

Problem description:
The SAHARA driver hangs when more than 8192x1024 bytes of random data
are generated.

Explanation:
When auto-seed is enabled, SAHARA generates a seed every 4094x1024bytes.
The first seed is generated when auto-seed is set during the
initialization. At the same time, a second seed is generated, and will
replace the first one when 4094x1024bytes of random data are generated.
When it reaches that required number of bytes, a third seed should be
generated in anticipation to replace the second seed.
That seed is never generated, and the status bit request for
seed is set.
The next time the number of generated bytes reaches 4094x1024, the
descriptor that requests random data cannot be processed.
The driver hangs there waiting for the descriptor to finish, and this
never occurs. A reset of SAHARA does not recover from there, and a reset
of the chip is necessary.

Tried board:
This shouldn't be related to a board, just need a chip with SAHARA4 such
i.MX51.
i.MX53 might be affected too, but I did not verify it.

Detailed reproduce steps:
(1) Replace the attached rand.c in place of the default in the imx-test
package. It requests more than 8192x1024bytes which is the limit when it
hangs. It displays the amount of generated bytes every 4096x1024bytes.
(2) Use the attached 'go' script to only run the random data test in the
unit_tests.
The test will hang.

Solution:
After discussing with STC design team, there is no evidence of an IC
bug, but there is obviously a problem.
I provided a patch that allows to disable the auto-seed, and in the
fsl_shw_get_random function, a seed is generated manually through a
descriptor every 16Mbytes. This number is higher than default auto-seed,
but was suggested by design team. There is no need to re-seed
too often.
Alternative could be to do that every XX hours, or every YY
requests to that function,

The default schedule method to wait for events has been
replaced by "wait_event_interruptible_timeout" as in case
there is problem with SAHARA, such that issue, the driver
does not hang, and can report a problem.

Signed-off-by: Terry Lv <r65388@freescale.com>
ENGR00242159 MX5-Fix defect about cpu frequency change in DVFS

When setting the ARM_FREQ_SHIFT_DIVIDER bit in CCM_CDCR by DVFS,
it is possible that this bit remain set due to a pre-mature return
from set_cpu_freq() in dvfs_core.c. If the ARM_PODF field in
CCM_CACRR is modified at the same time by bus frequency change,
the system will run into dead loop becauae the ARM_PODF_BUSY bit
in CCM_CDHIPR will never clear indicating the ARM_PODF is always
busy.

This patch extends the mutual exclusive locking at set_cpu_freq()
in dvfs_core.c to protect the cpu frequency change by DVFS.

Signed-off-by: Peter Chan <B18700@freescale.com>
ENGR40066538-1 MX53: UART: update the DMA script for UART

This script fixes the following UART bug:
  "When enable the DMA for UART, the ATDMAEN(cr1) does not works."

Signed-off-by: Huang Shijie <b32955@freescale.com>
ENGR40066538-2 MX53: UART: fix the wrong CTS pinmux macro

This macro overwrites the 0x87c to 2, which has already been set by
the MX53_PAD_PATA_DIOR__UART2_RTS to 3.

So the RTS can not works. the mx53 can not send out the data in this
case.

Signed-off-by: Huang Shijie <b32955@freescale.com>
ENGR40066538-3 MX53: UART: enable the hardware flow control

enable the hardware flow control. fixes many bugs.

Signed-off-by: Huang Shijie <b32955@freescale.com>
ENGR00252150 Fix MX53 IOMUX setup for all UARTs

The UART TXD and CTS IOMUX for all UARTs is setup incorrectly as
the code writes to the INPUT_SELECT register to configure these pins
as input. This is not needed since we are configuring the UARTs as
DCE devices. Discussion from the community can be found below:
https://community.freescale.com/thread/304402

Signed-off-by: Mahesh Mahadevan <Mahesh.Mahadevan@freescale.com>