This function fixes few possible buffer overflow
conditions in find_most_appropriate_phase()
function.
Change-Id: Icc17469a3850aa8531a6ef176bacc83fa2c50159
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Merge Upstream's stable 3.0.21 branch into msm-3.0
This consists 814 commits and some merge conflicts.
The merge conflicts are because of some local changes to
msm-3.0 as well as some conflicts between google's tree and
the upstream tree.
Conflicts:
arch/arm/kernel/head.S
drivers/bluetooth/ath3k.c
drivers/bluetooth/btusb.c
drivers/mmc/core/core.c
drivers/tty/serial/serial_core.c
drivers/usb/host/ehci-hub.c
drivers/usb/serial/qcserial.c
fs/namespace.c
fs/proc/base.c
Change-Id: I62e2edbe213f84915e27f8cd6e4f6ce23db22a21
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
HS200 bus speed mode requires DLL (Delay locked loop) HW block
to be tuned as clock rate (192 MHz) is greater than 100MHz.
While tuning the DLL block by sending CMD21 for different DLL
phases, it is quite possible that few CMD21 may fail with data
CRC errors as clock phase is not correct but these errors are not
really worth to be printed out as kernel messages. This change
doesn't allow these errors to be printed.
Change-Id: I5e18b61015f0b3a2478cc2d92e3e1ae5da9eb576
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
With SDCC4, driver can check the register synchronization
by polling REG_WR_ACTIVE bit in MCI_STATUS2 register so in
that case there is no need to ensure register synchronize
using explicit delay (achieved by calling udelay()).
But there are many places in driver which calls the msmsdcc_delay()
to achieve atleast 1us delay. So this patch have identified such
places and changed them to call a function which guarantees
to have atleast 1us of blocking delay.
CRs-fixed: 345170
Change-Id: I3236496ae6edf0108687b897558091cbb32e0a39
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
If SDCC device runtime status was RPM_RESUMED before system suspend
happens, during next system resume SDCC will also be resumed
synchronously. As SDCC resume is happening as part of system resume
path and it may take around 150ms to resume for SDCC slot which have
SD card connected. As this resume latency is too high, it may impact
overall system resume time and can effect the user experience.
This change makes sure that during system suspend, device runtime
status gets set to RPM_SUSPENDED. So when system resume happens,
SDCC resume can be skipped which means SDCC resume is deferred
until next SDCC transfer request comes in.
CRs-fixed: 344459
Change-Id: I579030b3759fee2c566ab06daad10ff4dd4c0085
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Since there is no access required to boot partitions,
mmcboot0/1 devices should not be created. Advertise
MMC_CAP2_BOOTPART_NOACC host capability to reflect this.
Change-Id: If3adbc6585e3ba652183ee3ede117503d709ce70
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Intel Medfield platform blocks access to eMMC boot partitions which
results in switch errors. Since there is no access, mmcboot0/1
devices should not be created. Add a host capability to reflect that.
Change-Id: I67d7e1301bb13ce6b01fb44e511ea21cfbf7e4bd
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
[subhashj@codeaurora.org: Fixed merge conflicts]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
If card clock rate passed by set_ios() is less than
minimum clock rate supported by the host controller,
set the clock rate to minimum clock rate supported by host.
Change-Id: I22f2a7413dfdb8c9a5188992aed99726c3c3d7a7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SD/MMC card erase functionality is available in core
layer. Enable MMC_CAP_ERASE capability from host side
so that users can use erase, trim, secure erase, secure trim
operations based on the card capability.
Change-Id: Icf35cd3038b0a95d653387d42870357c4c3853c0
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
In the current implementation, turning off SDCC clocks when
SDIO card is inserted, is controlled by the SDCC driver in
suspend/resume callbacks. This makes the dynamic clock gating
(MMC_CLKGATE) feature, when enabled, to be broken for SDIO cards,
as configuring of sdio wakeup interrupt is entirely handled
in system suspend/resume callbacks. Handle this by moving all
of the wakeup handling code to generic set_ios function which can be
called either from core layer or driver layer.
Since the SDCC controller supports asynchronous notification of
SDIO card activity when the clocks are off use this for enabling
MMC_CLKGATE feature which helps in TCX0 during idle state.
Also, handle the case where the SDIO function driver is not interested
in waking up the system during suspend but the SDCC driver still
configures DAT1 line as wakeup interrupt.
Change-Id: I260ae2161cfe9160f93e6af4f9b6c34db96397c0
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Free hardware resources such as regulators
on shutdown so card will be in expected state
during soft reset such as adb reboot.
Change-Id: I2aab44de2c7cb20e09213decb29a3ac6b6441148
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
"wait_for_auto_prog_done" flag is set when CMD53, single block write
(CMD24) or pre-defined (prefixed with CMD23) multi block write
(CMD25) need to be sent to card. This flag tells the
msmsdcc_start_data() to set the AUTO_PROG_DONE bit in MCI_DATA_CTL
register. If AUTO_PROG_DONE bit is set, SDCC controller will raise
the PROG_DONE at the end of above mentioned write transfers
(command + data) and "wait_for_auto_prog_done" gets cleared at
the end of transfer.
But if we get the error during the command transfer phase itself,
there is a chance that "wait_for_auto_prog_done" remains set which
means it remains sticky during next SDCC transfer request as well.
And if next data transfer is data read operation, having this
"wait_for_auto_prog_done" flag set will not allow the transfer to
end which may cause SDCC driver to raise request timeout.
Following is one such error condition:
<6>[ 667.001892] mmc1: CMD6: Request timeout
<6>[ 667.004700] mmc1: SDCC PWR is ON
<6>[ 667.007904] mmc1: SDCC clks are ON, MCLK rate=400000
<6>[ 667.012848] mmc1: SDCC irq is enabled
<6>[ 667.067633] mmc1: SPS mode: busy=0
<6>[ 667.071020] mmc1: xfer_size=64, data_xfered=64, xfer_remain=0
<6>[ 667.076758] mmc1: got_dataend=1, prog_enable=0,
wait_for_auto_prog_done=1, got_auto_prog_done=0
This patch ensures that "wait_for_auto_prog_done" gets cleared even when
error is seen during command transfer phase itself.
CRs-fixed: 342901
Change-Id: I27f635775ca488826fb46995784b544772fd8e16
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The following changes are required in host driver to
enable/configure the controller in HS200 mode -
1. Define new eMMC host capabilities as supported by the
host. These capabilities allows the MMC core driver to
enable HS200 timing in device.
2. After the device is set to HS200 mode, the host driver
must send tuning command CMD21 to find the optimal sampling
point for data lines.
3. Depending on the voltage range and HS200 modes supported
by the host and device, host driver must change the voltage
range of VccQ whenever the MMC core driver requests it.
4. Change the controller timing mode and MCLK frequency to
maximum frequency supported by host.
Change-Id: Iaa30778a509eb800b0193f32f85ce494610e94c3
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Some reboot methods (eg. adb reboot) may not power
down SDCC slots. This can result in cards being
in unexpected states after reboot. Explicitly reset
slot voltage regulator on reboot.
CRs-Fixed: 341840
Change-Id: I8cdb52bc58e34900378af468794760653f3babad
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
The eMMC 4.5 devices have support for 200MHz bus speed. The function
prototype of the tuning function is modified to handle the tuning
command number which is different in sd and mmc case.
Change-Id: If52eab150592d96adb58d98ec19110fe43d2fbc0
Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
[subhashj@codeaurora.org: Fixed merge conflicts and compilation errors]
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
sg_miter_next() does not place byte alignment restrictions on
sgl lengths. However, SDCC FIFO must be accessed in multiples
of 4 bytes, requiring rounding which can cause data corruption.
For example, an sgl of length 481 is decribed below:
struct scatterlist sgl;
sgl.page_link = 0xXXXX_XXXX;
sgl.length = 481;
sgl.offset = 3821;
First call to sg_miter_next():
Sgl length returned = (PAGE_SIZE - 3821) = 275 bytes
Driver rounds this length to multiple of 4 = 276 bytes
Next call to sg_miter_next():
Sgl length returned = (481 - 275) = 206 bytes
Driver rounds this length to 208 bytes
On a write, the extra byte written to the FIFO during the first
276 byte chunk is assumed valid. The next call writes 208 bytes,
but the last 3 bytes (276 + 208 - 481) including 1 valid byte,
are ignored, as the controller uses the MCI_DATA_LENGTH register
to figure out that it only needs to write a total of 481 bytes.
To fix the data corruption in cases as above, a 4 byte bounce
buffer is used realign buffer access to the FIFO, such that 4 byte
multiples are written until the last buffer chunk.
Note that in a simple case where all 481 bytes lie within a page,
the driver rounds the length to 484, but the MCI_DATA_LENGTH
register enusres only 481 bytes are actually written.
Change-Id: I164bae2df4857017b35857e465d753b9dc9edf6a
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
If "total_phases" argument of find_most_appropriate_phase()
function have value greater than 16, it may cause the
out bound access for arrays used within this function.
So this patch validates the value of "total_phases" to
avoid buffer overflow.
Change-Id: I0519066b37595e1ee2121b77965b119cfd995eb4
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SDCC driver sets the IO_PAD_PWR_SWITCH bit to 1 to indicate
SDCC controller that IO pad voltage level needs to be switched
from 3.3v to 1.8v when initializing UHS-I (SD3.0 compliant) cards.
But if UHS-I card is inserted first and then removed after that
and now if we insert the non UHS-I card then there is a possibility
that IO_PAD_PWR_SWITCH bit may still remain set to 1.
This change resets the IO_PAD_PWR_SWITCH bit to 0 if voltage
switch from 3.3v to 1.8v is not required.
CRs-fixed: 337145
Change-Id: Iaafd96a40a132a4c3a614ae72b22f24d3e11be3f
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
We are cleaning up the implicit presence of module.h; these guys are
some of the people who just assume it will be there. Call it out
explitly for those that really need it.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
[kdorfman@codeaurora.org: files are not exists: sdhci-pxav2.c, sdhci-pxav3.c
file is not updated: sdhci-pltfm.c]
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
This patch adds support for the power off notify feature, available in
eMMC 4.5 devices. If the host has support for this feature, then the
mmc core will notify the device by setting the POWER_OFF_NOTIFICATION
byte in the extended csd register with a value of 1 (POWER_ON).
For suspend mode short timeout is used, whereas for the normal poweroff
long timeout is used.
Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
[kdorfman@codeaurora.org: caps2 field added to struct mmc_host]
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Use sgl mapping iterator to process sgls in PIO mode instead
of pointer arithmetic. This prevents possible page faults
caused by accessing kmapped memory when sge buffer is larger
than PAGE_SIZE or straddles several pages. The buffer returned
by kmap_atomic() is only one PAGE_SIZE large, and an sge buffer
larger than a PAGE_SIZE must be processed in PAGE_SIZEd chunks.
Change-Id: I59f130ca2963b5327a4ce7d3016cc558dcb87218
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
SDR104 mode requires DLL (Delay locked loop) HW block to be tuned
as clock rate is greater than 100MHz. But we observed multiple CMD
CRC errors while erasing the SD card and DATA/CMD timeout errors
while writing/reading on to SD card if it's running in SDR104 bus
speed mode (SD clock rate @192MHz).
DLL has a mechansim of data tracking (CDR) which can be enabled
during RX transaction so the host will not lose the sampling point.
CMD19 (tuning pattern command) can be sent automatically before
any RX transaction for helping the CDR to track after the correct
sampling point.
But if this data tracking is kept enabled during TX transactions then
it may cause the DATA/CMD CRC errors during TX transactions. So this
patch ensures that data tracking is only enabled during RX transactions
and remains disabled for TX transactions.
In addition to this change, it is found that DLL valid phase windows
may be cyclic so this patch also ensures that 2 different valid phase
windows are treated as single valid window if it's cyclic.
CRs-fixed: 334000
Change-Id: I8a0568e6e89779746933b9dc1247320abff32d5e
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
DLL (Delay Locked Loop) HW block inside SDCC4 controller
can take 16 different phases (0 to 15). Value of these phases
should be written in gray code format in HW register.
But gray code values used in driver are wrong and differs
from standard definition of gray codes. This patch fixes the
gray code values to be compliant with standard definition of
gray codes.
CRs-fixed: 334493
Change-Id: I347fee0c801ae7cdb177ea4066f18af6f49a3fdc
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
During the SDCC DMA transfer, if DMA transfer time is
long enough to do IDLE power collapse then system may
go into IDLE power collapse and once SDCC DMA transfer
is completed, system wakes up from Idle Power Collapse
due to SDCC DMA interrupt. But delay for waking up
from Idle Power collapse could be as large as 5 ms which
really degrades the overall read & write throughputs
for SD/eMMC/SDIO cards.
For example, following are the performance numbers with
eMMC card on MSM8960 platform with and without Idle Power
Collapse.
Idle Power collapse enabled:
LMDD Read throughput = ~14 MB/s
LMDD Write throughput = ~6 MB/s
Idle Power Collapse disabled:
LMDD Read throughput = ~25 MB/s
LMDD Write throughput = ~8 MB/s
So this change votes against the Idle power collapse by registering
with PM QOS about it's acceptable DMA latency when SDCC transfer is
active. This latency value is one more than the latency of SWFI
which means system can go into SWFI but not in any of the other
low power modes (including Idle power collapse).
CRs-fixed: 327751
Change-Id: Iae5e12cade383544243f17c448346dd5d0faa60e
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
commit dd8df17fe83483d7ea06ff229895e35a42071599 upstream.
This patch fixes a failure to recognize SD cards reported on a Dell
Vostro with O2 Micro SD card reader. Patch 49c468f ("mmc: sd: add
support for uhs bus speed mode selection") caused the problem, by
setting the SDHCI_CTRL_HISPD flag even for legacy timings.
Signed-off-by: Alexander Elbs <alex@segv.de>
Acked-by: Philip Rakity <prakity@marvell.com>
Acked-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit c6ced0db08010ed75df221a2946c5228454b38d5 upstream.
When suspending host, the tuning timer shoule be deactivated.
And the HOST_NEEDS_TUNING flag should be set after tuning timer is
deactivated.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts commit 521cdcead0.
Sending CMD12 when r/w command has errors is taken care by
MMC block layer. So there is no need of this on >= 3.0 kernel.
Change-Id: Ibf9753b837b1c702be1790b017b8da4bc828d2b5
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
This patch simplifies the code needed to handle both ACTIVE LOW and
ACTIVE HIGH cases for SD card detect gpio line when the card is present.
Change-Id: I6cfdf0fea4992204ef4cfbefe4dc63bfc8ae3033
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
commit b63038d6f4ca5d1849ce01d9fc5bb9cb426dec73 upstream.
The interrupt was previously enabled and then correctly cleared.
Now we also handle it correctly.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In SD/eMMC cards read/write multi block commands (CMD18/CMD25)
cause state transition from Transfer state to Data/Receive
state. If there are errors in recieving the response for
these commands the driver doesn't send CMD12 to stop the
transaction and hence the card forever be in Data/Rcv
state until further CMD7 or CMD12 is issued. Fix this by
sending CMD12 (STOP_TRANSMISSION) to change the state back to
transfer mode aborting data transfers.
Note: With current r/w command response it is impossible to
determine if the card has actually transitioned to Data/Rcv
state since the actual card status is reflected at execution
time. Also, there may be errors in "sending" CMD18/25 itself.
Sending CMD12 in this case doesn't cause any harm except one
more command timeout error which is non-fatal.
Change-Id: I1e298260d39cfac796113a4276652626c4011fc3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
The value returned by the msmsdcc_pio_read() will be a 32bit
aligned value, which could be more than what we have requested
to read due to alignment force. Make sure that
host->curr.xfer_remain is updated with correct value.
Change-Id: I8fe1ec7b51626c53d39fe392122f357a3a8db8e2
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
SDCC runtime suspend can race with mmc_rescan causing deadlock.
The call flow would be this:
1) When runtime suspend is triggered:
msmsdcc_runtime_suspend()
-> mmc_suspend_host()
-> mmc_flush_scheduled_work()
2) mmc_flush_schedule_work() waits for mmc_rescan() work
to be completed if it is already in runqueue.
3) When mmc_rescan() is scheduled to run:
mmc_claim_host()
-> msmsdcc_enable()
->pm_runtime_get_sync()
4) pm_runtime_get_sync() waits for runtime_suspend to complete,
and hence cause two threads to wait upon each other.
Fix this deadlock by aborting runtime suspend when mmc_rescan
is scheduled.
CRs-Fixed: 326610
Change-Id: I4ca88651f80f5a1bfccb6e0c07e3ea83fadcdc57
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
commit e58f516ff4730c4047c3f104b061f7a03e9a263c upstream.
When we can't configure the dma channel we want to fall
back to PIO. We do this by setting host->do_dma to zero.
This does not work as do_dma is used to see whether dma
can be used for the current transfer. Instead, we have
to set host->dma to NULL.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1. SDR50 mode operates at 96MHz MCLK and there are random failures
(data timeouts or command CRC errors) seen if DLL is used in SDR50
mode. It is found that DLL may have issues if used for
clock <= 100MHz. According to SD3.01 Specification, Sampling clock
tuning is optional for SDR50 mode and is only mandatory for SDR104
(which requires clock > 100MHz). So this change removes the DLL
tuning in SDR50 mode.
2. CDR_SELECT field in MCI_DLL_CONFIG register expect the phase value
in gray coded binary format but currently driver was programming
this field with normal binary numbers. This change maps the phase
to gray coded binary numbers before programming CDR_SELECT field.
3. Find out the greatest range of consecuitive selected DLL clock
output phases that can be used as sampling setting for SD3.0
UHS-I card read operation (in SDR50/SDR104 timing mode) or
for eMMC4.5 card read operation (in HS200 timing mode).
Select the 3/4 of the range and configure the DLL with the
selected DLL clock output phase.
4. Added few extra debug messages to be printed out when errors
are seen while performing tuning.
CRs-fixed: 323399
Change-Id: Iadcb63930681b8f3a3d04252bc5b643c106baad7
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SD card detect GPIO line can be ACTIVE HIGH or ACTIVE LOW based on the way
the board is designed. This change will allow the polarity information to
be used when determining if a card was inserted or removed for a given
board.
CRs-fixed: 318036
Change-Id: I30b96e840a28030af3141fd722383722a24089c8
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
msmsdcc_dbg_state_read() allocates a 1024 byte array on the stack
to fill in some debug information. There isn't more than a couple
hundred bytes actually used though so reduce the on stack array
to a more conservative value. This avoids problems with big stack
frames in the kernel.
Change-Id: I6ea03b843a31ece2c54b360bf144c97c02672c78
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
eMMC4.5 specifcation defines the packed commands where
block I/O scheduler can club multiple read/write transfer
request in single packed transfer request before posting
it to block driver. Clubbing multiple transfer requests
in single packed transfer request may require block driver
to support more segments in scatter-gather list.
But as of now, msm sdcc driver is supporting maximum 128
segments in scatter-gather list which seems to be not enough
for effcient packed transfer request.
max segments supported by driver (in SPS DMA mode) are only
limited by the max number of descriptors that can be
queued in SPS Descriptor FIFO for a single transfer request.
So this change changes the max segments supported by driver
to max SPS descriptors.
Change-Id: If2f7d7eea59eb14b82a1a361f5216fee7ff8104e
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Turn off SDCC clocks when there is no active request posted to
the driver. This saves power and allows TCXO shutdown
in idle power collapse. This is useful when CONFIG_PM_RUNTIME
is disabled, otherwise the same it is taken care by runtime PM
functionality. The disable delay is set to 200msecs as not to be
aggressive which can impact performance.
Change-Id: Iaa91a02ad9b146c0fea98ba2d4880dc80c4d1ace
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
DMA hardware (ADM or SPS) connected to SDCC controllers
is capable of addressing the entire 32 bit adddress space
so this change sets the sdcc devices dma_mask to
0xffffffff.
Changing the dma_mask to indicate full 32 bit address space
will avoid unnecessary bouncing of buffers from high memory
to low memory.
CRs-fixed: 321813
Change-Id: I3180953d02361a7ea9e7f33ee7d547a8034ee133
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
If status indicates both MCI_CMDTIMEOUT and MCI_DATATIMEOUT has
occurred when handling the IRQ, MCI_CMDTIMEOUT handler ends the
pending request that cleans up the current request pointer followed
by MCI_DATATIMEOUT trying to perform similar operation causing a
NULL pointer reference. Check whether msmsdcc_request_end() has been
done before proceeding to service any status bit in the handler.
Change-Id: I26ddffae35779749102d04b5d66a8abf06d3fb6c
Signed-off-by: Sathish Ambley <sambley@codeaurora.org>
1) dma_map_sg() should be called before sg_dma_address()
is passed to dmov. This makes sure that buffer adresses
are bounced if present in HIGH_MEM region.
2) The maximum length of data transfer that DMA
can handle in box mode while operating with SDCC
would be 4095 (rows(64K-1)*fifo_size(64)) KiB.
It is likely that upper layers can send more
data than this as suggested by host->max_seg_size.
The data mover hangs if such requests are passed
to driver. Fix this by limiting box mode command
to handle only requests upto 4095KiB and iterate
over many such commands for larger requests.
3) Increase NR_SG to 128 for optimal performance.
4) Clean up hardcoded values to proper macros in .h file
Change-Id: I06d53396a639e2108f87022a2eef6822dda88305
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Driver is using some magic numbers to indentify few specific
commands but as these magic numbers are not self explainatory,
this change replace them with appropriate macros.
Change-Id: I47cf0723ea29ceb1e470edd95e08ff4d59546535
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
SDCC4 controller has added support of auto_prog_done (automatic
programming done indication) for both single and multi block
write commands. MSM SDCC driver is already making use of this
capability for multi block write commands. This change extends
the use of this capability for single block write commands as well.
Change-Id: Ia6e841705bab24d2867fc8298a85eb40d81bb191
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
The sdiowakeup irq handler turns on the clock and takes sdio
wake_lock, but the wake_lock is set to expire on any msmsdcc_request
even before sdio_al has had a chance to finish the lpm disable
sequence. This causes power drain if the system enters suspend, hence
hold the sdio wake_lock till sdio_al is finished lpm disable sequence.
This change is only applicable to sdio_al clients.
Change-Id: I10c00059c3d071b90a81cb8f7664eedf4e772d8a
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
