Running mmcqd as a prio 120 thread forces it to compete with standard
user processes for IO performance, especially when the system is under
severe CPU load. Move it to a SCHED_FIFO thread to reduce the impact of
load on IO performance.
bug 25392275
Change-Id: I1edfe73baa25e181367c30c1f40fee886e92b60d
(cherry picked from commit b277da0a8a)
Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
QUEUE_FLAG_NONROT.
Historically, all block devices have automatically made entropy
contributions. But as previously stated in commit e2e1a148 ("block: add
sysfs knob for turning off disk entropy contributions"):
- On SSD disks, the completion times aren't as random as they
are for rotational drives. So it's questionable whether they
should contribute to the random pool in the first place.
- Calling add_disk_randomness() has a lot of overhead.
There are more reliable sources for randomness than non-rotational block
devices. From a security perspective it is better to err on the side of
caution than to allow entropy contributions from unreliable "random"
sources.
Change-Id: I8e9005feeedf301e486cf1aa13c804e322a3591b
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
In mmc_block_test, the debug_fs based read function handlers write to an
arbitrary buffer which is given by any user. We add an access_ok check
to verify that the address pointed by *buffer is not in kernel space.
Only if the buffer is valid, do we continue the read handler.
Backport reference:
* Ignore changes from following upstream functions:
- bkops_test_read
- long_sequential_read_test_read,
- long_sequential_write_test_read
- new_req_notification_test_read
Change-Id: I1413f71be13509a3b4e56b919cfbcbd9fcc9d2bd
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Adrian DC <radian.dc@gmail.com>
In the MMC card debug_fs the read and write handlers use the strlcat
and sscanf, without checking the pointer given.
Since the pointer is not checked it is possible to write
everywhere (ring 0 or 3).
In order to fix it, an access_ok function is being used to verify
the buffer's pointer supplied by user is valid.
Bug: 28769136
CRs-fixed: 545716
Change-Id: Ia710b6af5a95974fc930ca902e8ff18afa4e17ba
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 upstream.
The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
may cause new coming request permanent missing when the ongoing
request (previoulsy started) complete end.
The problem scenario is as follows:
(1) Request A is ongoing;
(2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
(3) Request A encounters the MMC_BLK_CMD_ERR error;
(4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
end request A completed and return zero. Continue the error handling,
suppose mmc_blk_reset() reset device success;
(5) Continue the execution, while loop completed because variable ret
is zero now;
(6) Finally, mmc_blk_issue_rw_rq() return without processing request B.
The process related to the missing request may wait that IO request
complete forever, possibly crashing the application or hanging the system.
Fix this issue by starting new request when reset success.
Signed-off-by: Ding Wang <justin.wang@spreadtrum.com>
Fixes: 67716327ee ("mmc: block: add eMMC hardware reset support")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 60c8f783a18feb95ad967c87e9660caf09fb4700 upstream.
clkdiv is declared as an u32 but it can be set to a negative value
causing a huge divisor value. Change its type to int to avoid this case.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:
WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
Fixes: 4c2ef25fe0 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
sending power off notify to eMMC before power off.
trigger sw reset before actual HW reset.
Change-Id: I4e3df098b084cc5f39cfd1c52718ed0833d8ba24
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
bug: 17968808 Kernel change for new eMMC v5.0 parts for FLO/DEB
Change-Id: Ia18152457fe3ff70401b199c267fa37374b9d544
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
commit 66b512eda7 upstream.
With some SDIO devices, timeout errors can happen when reading data.
To solve this issue, the DMA transfer has to be activated before sending
the command to the device. This order is incorrect in PDC mode. So we
have to take care if we are using DMA or PDC to know when to send the
MMC command.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c876006962 upstream.
Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.
This patch includes the following functionality:
1. To enable error checking for the response of CMD12 and CMD13
in write command sequence
2. To retry write sequence when a generic error occurs
Messages are added for v2 to show what occurs.
Signed-off-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Current MMC driver doesn't handle generic error (bit19 of device
status) in write sequence. As a result, write data gets lost when
generic error occurs. For example, a generic error when updating a
filesystem management information causes a loss of write data and
corrupts the filesystem. In the worst case, the system will never
boot.
This patch includes the following functionality:
1. To enable error checking for the response of CMD12 and CMD13
in write command sequence
2. To retry write sequence when a generic error occurs
Messages are added for v2 to show what occurs.
cherry-picked from
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc?id=c8760069627ad3b0dbbea170f0c4c58b16e18d3d
Signed-off-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Signed-off-by: Chris Ball <cjb@laptop.org>
Conflicts:
drivers/mmc/card/block.c
Change-Id: Ieeb9fb142ff1be7904e322354d9647cfa239e862
Signed-off-by: Devin Kim <dojip.kim@lge.com>
commit f936f9b67b upstream.
I'm testing SH-Mobile SDHI driver in DMA mode with a new DMA controller using
'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
to PIO but all commands time out after that. It turned out that the fallback
code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
to them cleared, so that the function bails out early instead of clearing the
DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
162f43e31c (mmc: tmio: fix a deadlock).
Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
tmio_mmc_start_dma_{rx|tx}() helps.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bdbc5d0c60 upstream.
The driver is doing, by default, multi-block reads. When a block error
occurs, card/block.c instigates a single block read: "mmcblk0: retrying
using single block read". It leaves the sg chain intact and just changes
the length attribute for the first sg entry and the overall sg_len
parameter. When atmci_read_data_pio is called to read the single block
of data it ignores the sg_len and expects to read more than 512 bytes as
it sees there are multiple items in the sg list. No more data comes as
the controller has only been commanded to get one block.
Signed-off-by: Terry Barnaby <terry@beam.ltd.uk>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 836dc2fe89 upstream.
PARTITION_SUPPORT needs to be set before doing the compare on version
number so the bit width test does not get invalid data. Before this
patch, a Sandisk iNAND eMMC card would detect 1-bit width although
the hardware supports 4-bit.
Only affects old emmc devices - pre 4.4 devices.
Reported-by: Elad Yi <elad.yi@gmail.com>
Signed-off-by: Philip Rakity <prakity@yahoo.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 91cf54feec upstream.
Fix regression introduced by commit 796211b795 ("mmc: atmel-mci: add
pdc support and runtime capabilities detection") which removed the need
for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the
compile guards around dma_release_channel() in remove(). Consequently,
DMA is always enabled (if supported), but the DMA-channel is not
released on module unload unless the DMA-config option is selected.
Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
when recieving PON, some eMMC tend to program spare block with
init data for next power cycle. If eMMC recieved PON frequently
but not actually powered off. blocks being programed became
really dirty and caused performance decline.
Sending cmd5 frequently could also be stress to NAND block for
some eMMC. Hence bypass cmd5 to extend eMMC life cycle.
Change-Id: I2cee3a048da8d4e814befd0192675d3f58cd3f90
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
SDR104 (supported by SD3.0 spec compliant SD cards) bus speed mode
requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz. To help the sampling clock
tuning SD3.0 specification has added CMD19.
During card initialization, driver uses these tuning commands to search
for optimal sampling point and then programs the DLL HW with this optimal
sampling point.
In addition, our SDCC controller's DLL HW has a mechansim of data
tracking (CDR) which can be enabled during read transaction so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern commands (CMD19) can be sent
automatically by HW (by using AUTO_CMD19 bit) before any RX transaction
for helping the CDR to track after the correct sampling point.
Although sending CMD19 automatically before every read commands is
overhead and reduces read performance by ~1 MB/s. SD spec does
not mandate to send these commands before every read operations.
This change keeps AUTO_CMD19 disabled by default but provides sysfs
attribute to enable or disable AUTO_CMD19 as per need.
Change-Id: I9ef99a8dde9b9733ea99639cdab2b6714ac50d76
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Expose the packing control test.
Test the packing control feature under these scenarios:
- Packing expected: entering write packing state,
staying in write packing state.
- Packing not expected: not entering write packing state
when not supposed to.
- Mixed states: test the ability to shift from packing
to no-packing and back, and the opposite.
(cherry picked from commit 202befb5a5a344f88a0b4fd1ed07b9a2c7ce4e3d)
(cherry picked from commit 91e1e32573321986b141f153ffdb5bcc8affe95b)
Change-Id: I06638dc19aa7703d0571d9699b24ce9977b1bcb8
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 273c29cec62e3f771bc726cf226c66234ceb80cb)
When hitting a stop potential packing event, we should zero
num_of_potential_packed_wr_reqs, so that the packing won't be
enabled too early.
(cherry picked from commit 285ee17e20580759ef349b43e48565cfad8adb10)
Change-Id: I384d74dc6eece67358a51fb0add5d988aee44d5d
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 659fc08c2d5f7b46c3543feb618f4708dc78b77b)
mmc_stop_bkops calls cancel_delayed_work_sync while the host is taken.
This can cause a deadlock since the delayed work is blocked on claiming
the host. In order to prevent that, mmc_start_bkops will not
be blocked waiting on mmc_claim_host and if the host is already taken
BKOPS will not be performed.
CRs-Fixed: 446090
Change-Id: I5cda5489e254764b3231b8a12da9e3c241c969c3
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 8571386b83bea1cbadd81c75bf0614da30b6b7c0)
If there is a race condition between the delayed BKOPS work and
the runtime suspend, and the suspend occurs before the delayed work,
the delayed work should be canceled.
Since mmc_claim_host can fail in case the host is suspended, we should
check if the delayed work is canceled before trying to claim the host.
CRs-Fixed: 443236
Change-Id: I9df506de4da6f9277a89ed608724f5b6e8585bfd
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5a3d216c005725baad96b6858dbcd370056e470c)
In order to keep card endurance, it is best not to check the need for
BKOPS every time the MMC is idle.
However, the decision when to check the card need for BKOPS according
to number of changed sectors doesn't fit all cards sizes. Therefore,
the check for BKOPS need is based on percentages of changed sectors
of the card size.
In order to assure that BKOPS will be triggered again in case it was
interrupted, the accumulated number of changed sectors is cleared only
in case BKOPS was completed without interruption.
Change-Id: I598f64b652a524a431b87d103fd5890b808f11b1
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit e1eae988976536834759a45cf7f62e1cb2b82838)
BKOPS operations can take long time and cause bad user experience and
failure of time critical operations as EFS sync.
In order to prevent the above failures all the levels will be handled only
in idle time BKOPS handling and will allow interrupting the BKOPS when
needed.
In case the card raised an exception with a need for BKOPS, a flag will
be set to indicate MMC to start the BKOPS activity when it becomes idle.
Fixed-CRs: 432027
Change-Id: I5f7b43569c0242f0fea83355f76f286b1ad037bc
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5f8ac3b955e44def61c2238192000ffe5f126714)
The timeout for the BKOPS polling is increased in order to allow the
card to complete the BKOPS before going to suspend.
In case we exit due to timeout we need to stop the BKOPS activity
performed by the card.
Change-Id: I39686de0c06a57242f11c8b1c9ae50b33417c088
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit ea1385e6d7542d4e3ad510de94ead00bece7823e)
mmc_cache_ctrl was called in runtime suspend before MMC interrupted
BKOPS in case it is still running on the card. This caused the cache
disable to timeout.
Therefore, mmc_cache_ctrl has to move to mmc_suspend where we are sure
that the card can go into suspend and there is no pending activity.
CRs-Fixed: 436805
Change-Id: I76281a766f48ccacc24685a64067df4e60cfe1d8
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 67a51386fd99be62e5e68f4bc76ee00c19099cd6)
In order to allow the card to perform BKOPS as early as possible without
causing degradation to a flow of requests, we reduce the time of the
BKOPS delayed work to 200ms.
Based on experience, 200ms will allow requests to be performed without
a delay of checking the BKOPS.
This patch also allows the host controller to set any other time if
required.
Change-Id: I1e56bfd0c9471abf4da50befe6d14fe0199129e7
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 70b00220e7564b00e3b0747260fe2c2dbe62f45d)
Sanitize command should never be issued with timeout argument of 0,
cause then it invokes timeout.
Moreover, sanitize command should not be called from routines that
does erase/trim/secure-discard commands, but only from a routine that
issues the sanitize spesifically.(mmc_blk_issue_sanitize_rq)
Change-Id: Ia3e3737f4bad149edc2248b8a30d74a9bd812be1
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
(cherry picked from commit 9a87427db940047907aee0dc86965645656f1ca9)
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
For APQ8064 V2 (SDCC version = 0x06000018) doing a soft
reset on errors doesn't reset the state machine that
handles side-band signalling with SPS-BAM fully and can
lead to controller hang for the data transfers after
the reset.
Since there is no register interface to soft reset such
state machine inside the controller, we do hard reset of
the controller in case of errors. SDCC hard reset is
defined as assert and de-assert of asynchronous clock
reset line of the controller.
CRs-Fixed: 451632
Change-Id: I366856e7508a3843688c8acead8a701e7b06fc19
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
We have seen instances where card is surprisingly taking lot of time
to complete their bkops operations. And if we let the card take long
time to complete the BKOPs then it would affect the user experience
if user tries to launch some application (or any other user operation
resulting in read from the card) while card is busy doing BKOPs.
User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.
If reduce the timeout to 30 secs then we may see the request timeout
errors during BKOPs so let's silence them out.
Change-Id: I31b11f60d1fae098770aa5797742eaf623b09ac9
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 926a9cb47ebfa40428b49f110135fde9e82f9cbe)
Currently we have 4 mins timeout for the blocking bkops to be completed
but we have seen instances where card is surprisingly taking even more
time to complete their bkops operations. So if we let the card take
more than 4 mins then it would affect the user experience if user tries
to launch some application (or any other user operation resulting in
read from the card) while card is busy doing BKOPs.
User experience is most important aspect so we are reducing the maximum
BKOPs timeout to max 30 secs and if card doesn't complete the BKOPs in
the timeout specified above, we will send the HPI command to interrupt
the on going BKOPs.
Change-Id: I14355fb79979058f388cd726091752797c316503
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 188b2a8723b4728c7c0c4c445e1aefe6e42895c9)
Currently we have 4 mins timeout for the blocking BKOPs to complete
but we have seen instances where card is surprisingly taking even
longer time to complete background operations.
If card doesn't complete the BKOPs within specified timeout, we
will send the HPI command to interrupt the ongoing BKOPs.
Change-Id: I5df81bdfd9b19bee30a394ee0ff4390b292691d0
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 1b22222ec61924de9b8ac51f08de113548946eb5)
Currently SDCC driver is waiting for the PROG_DONE interrupt after
sending out the CMD13 to card even if command flags doesn't indicate
so. This may cause the issue in when we try to HPI (High Priority
Interrupt) the ongoing BKOPs (Background Operations). Hence this
change removes the busy wait (PROG_DONE) for CMD13.
Change-Id: I8fb6ab4908bf1c4c5a939413d27eec29cde22f68
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
(cherry picked from commit 56fd45187495f27a7f9c3ebe947c1ffc9851fffd)
Reset SDCC controller if the check for TX/RX ACTIVE bit fails while
carrying out DPSM reset after the end of current transaction
instead of taking the entire system down by doing BUG().
CRs-Fixed: 423356
Change-Id: I9e2e945eb9a31d12e0a435df29a8215ae634724b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit 0a29588be6d3d6bd9122191e7e850c687bb1b166)
Signed-off-by: Maya Erez <merez@codeaurora.org>
Resetting SDCC-BAM after reset of SDCC-DML causes
interface disconnect between SDCC-BAM and SDCC-DML
and lead to hang when SDCC driver initiates data
transfer in BAM mode. Modify the SDCC reset sequence
to reset SDCC-DML after reset of SDCC-BAM.
CRs-Fixed: 423399
Change-Id: Ia31d40e30cbf95befba3b1133a525a81903789f2
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
(cherry picked from commit b745eeb229a476d81ee4177adfe168d3a35bda47)
Reset SDCC controller if the check for TX/RX ACTIVE bit fails while
carrying out DPSM reset after the end of current transaction
instead of taking the entire system down by doing BUG().
CRs-Fixed: 423356
Change-Id: I9e2e945eb9a31d12e0a435df29a8215ae634724b
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
be reinitialized during resume but as we are not resetting
(CMD52 reset) the SDIO card during this reinitialization, card may
fail to respond back to subsequent commands (CMD5 etc...).
This change resets the card before the reinitialization of card
during resume.
(cherry picked from commit 2679307563a616af7ab189706604a245c6a3be92)
CRs-Fixed: 424805
Change-Id: I1ccd93e9221de631a407064219793e7378ac8f31
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Notifying the device of the hosts intention to power it off, gives the
device the ability to better prepare itself.
(cherry picked from commit f495d1b0d837af16a9e9881dbbcd7908abf88b33)
Change-Id: I43a6c576ea48508d60723f1002fc0fb26e9eafe4
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 916072e4cb9373c054bc5a91ff289ac769958993)
This patch fixes up the broken suspend sequence for eMMC with sleep
support. Additionally it reworks the eMMC4.5 Power Off Notification
feature so it fits together with the existing sleep feature.
The CMD0 based re-initialization of the eMMC at resume is re-introduced
to maintain compatiblity for devices using sleep.
A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off
Notification feature. We might be able to remove this cap later on,
if we think that Power Off Notification always is preferred over
sleep, even if the host is not able to cut the eMMC VCCQ power.
[merez@codeaurora.org: resolved various merge conflicts.
Fix in mmc_resume already exists]
(cherry picked from commit cec02a451276a70cdeb0576ec89d6b5b76e4e18b)
Change-Id: I4f29c213d745dcb1ec50b34b535657328042b4b2
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saugata Das <saugata.das@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 91cf2698afab3f0707f739a02eb639205798f1dc)
When a failure occurs while creating a device attribute,
we need to remove previously created attributes prior to deleting
the disk.
(cherry picked from commit 8d006d3f139c46beaeee138bda9d0807185661a9)
Change-Id: Ic5ebba9c06f3811534f5b5e8c0399809e5dc9f23
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 7256cdc299a4d42c1d316afbac98d320154ce6da)
The version of PON support accepted by the linux community is
slightly different from the one that was merged. This revert is needed
in order to upload the latest version from the linux community.
This reverts commit 76058d7388c6edde07fd6289ce082dc1a1813b26.
(cherry picked from commit 8b458cf768db937d3a2274e216819a1a217e97f8)
Change-Id: I0cb611698b25de600dbaa54678edae661456e485
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 6e3e74d3ba5c825108b0a63018376b12e61592f9)
In the current soft reset sequence performed as part of
CMD/DATA error recovery we do the following:
1) Write 1 to DML_SW_RESET
2) Reset CPSM/DPSM by clearing MCI_CMD and MCI_DATA_CTL
or by writing to MCI_SW_RST_CONFIG.
3) Re-init DML
4) Reconfigure both consumer and producer BAM pipes.
The BAM pipe reset does not reset the sideband signals, since
only SDCC side is reset SDCC - BAM communication will go out
of sync and cause DML to be stuck without transferring data.
Hence reset BAM core every time SDCC is reset (which is on
error recovery).
Fix error handling for sps pipe or device reset.
(cherry picked from commit 3ca90f02963ddbbdb300eb55c49aca18091c3f49)
Change-Id: I82bd6c5f3db6ac71da912cef935dfd179b099ed4
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
(cherry picked from commit 9b2f00f099f4f17025a9834eb38fc67254164608)
Signed-off-by: Maya Erez <merez@codeaurora.org>
