- 14 2月, 2014 2 次提交
-
-
由 Ulf Hansson 提交于
There are no active users of this host capability. The primary reason for adding this cap was due to a bug in ux500 boot loader code, which is not a relevant issue any more. So, let's remove it. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
由 Ulf Hansson 提交于
Invoking system suspend or shutdown without using the Kconfig option MMC_UNSAFE_RESUME, did trigger an ungraceful power cut of the card. To improve the situation, change the behavior to always make use of the available bus_ops callbacks that handles system suspend and shutdown properly. By changing the behavior MMC_UNSAFE_RESUME becomes redundant, so lets's remove it. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <chris@printf.net>
-
- 14 1月, 2014 1 次提交
-
-
由 Dong Aisheng 提交于
The MMC_CAP_UHS_DDR50 must work on 1.8v. However, the eMMC DDR mode can work on either 1.8v or 3.3v and should not depend on UHS_DDR50. So get rid of this limitation to let controller without 1.8v signal voltage support can also work for eMMC DDR mode if it claims. Signed-off-by: NDong Aisheng <b29396@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 31 10月, 2013 9 次提交
-
-
由 Ulf Hansson 提交于
In some environments it is to prefer to postpone the resume of the card device until runtime_resume is being carried out, since it will mean a signficant decrease of the total system resume time. The reason of the decreased resume time is simply because of the actual re-initalization of the card, which typically takes hundreds of milliseconds, is performed outside the resume sequence and wont thus affect it. For removable card, the detect work tries to re-detect the card to make sure it is still present, as a part of that sequence the card will also be runtime_resumed and thus also fully resumed. For a non-removable card, typically a mmc blk request will trigger a runtime_resume and thus fully resume the card. This also means the first request will likely suffer from an inital latency since the re-initialization of the card needs to be performed. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
The card device is considered as in-active after it has been suspended. To prevent any further runtime PM requests in suspend state, we then disable runtime PM. After the card device has been resumed, we shall consider it as active, like we also do after a probe sequence. When resumed, we can safely enable runtime PM again. This will make sure the PM core can request the card device to go to in-active state after a resume has been completed. Previously we had to wait for new pm_runtime_get->pm_runtime_put cycle to be executed. Additionally, once a resume has been carried out, update the last busy mark. At the moment this will have no effect but if the PM core will respect autosuspend enabled devices, when it directly triggers a runtime_suspend from a runtime_idle, it will mean the card device will be scheduled for a delayed runtime_suspend instead of done immediately. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Commit "mmc: core: Push common suspend|resume code into each bus_ops" moved the responsibility for doing mmc_power_up|off into each suspend/resume bus_ops. When using MMC_CAP_AGGRESSIVE_PM, through the runtime callbacks, calls to mmc_power_up|off became redundant. When removing them, we are also able to remove the calls to mmc_claim|release_host, thus simplifing code a bit more. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
By adding a card state that records if it is suspended or resumed, we can accept asyncronus suspend/resume requests for the mmc and sd bus_ops. MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime bus_ops callbacks, execute a suspend of the the card. In the state were this has been done, we can receive a suspend request for the mmc bus, which for sd and mmc forced the card to active state by a pm_runtime_get_sync. In other words, the card was resumed and then immediately suspended again, completely unnecessary. Since the suspend/resume bus_ops callbacks for sd and mmc are now capable of handling asynchronous requests, we no longer need to force the card to active state before executing suspend. Evidently preventing the above sequence for MMC_CAP_AGGRESSIVE_PM. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Since mmc_select_voltage now only gets called from the attach sequence, it makes sense to move the out of spec validations of the card ocr into this function. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
According to eMMC/SD/SDIO specs, the VDD (VCC) voltage level must be maintained during the initialization sequence. If we want/need to tune the voltage level, a complete power cycle of the card must be executed. Most host drivers conforms to the specifications by only allowing to change VDD voltage level at the MMC_POWER_UP state, but some also cares about MMC_POWER_ON state, which they should'nt. This patch will not break those drivers, but they could clean up code to better reflect what is expected from the protocol layer. A big re-work of the mmc_select_voltage function is done to only change VDD voltage level if the host supports MMC_CAP2_FULL_PWR_CYCLE. Otherwise only validation of the host and card ocr mask will be done. A very nice side-effect of this patch is that we now don't need to reset the negotiated ocr mask at the mmc_power_off function, since now it will actually reflect the present voltage level, which safely can be used at the next power up and re-initialization. Moreover, we then only need to execute mmc_select_voltage from the attach sequence. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
The negotiated ocr mask is directly related to the card. Once a card gets removed, the mask shall be dropped. By moving the cache of the ocr mask from the host struct to the card struct we have accomplished this. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
As a step to fixup the setup of the negotiated ocr mask, we need the mmc_power_up|cycle functions to take the ocr as a parameter. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Some switch operations like poweroff notify, shall according to the spec not be followed by any other new commands. For these cases and when the host does'nt support MMC_CAP_WAIT_WHILE_BUSY, we must not send status commands to poll for busy detection. Instead wait for the stated timeout from the EXT_CSD before completing the request. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Cc: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 06 7月, 2013 1 次提交
-
-
由 Romain Izard 提交于
The field containing the production date in the CID register only uses 4 bits to encode the year, starting from 1997 in the original standard. In 2013, the production year field contains 0, and the kernel reports a 1997 production date. The eMMC 4.51 specification adds a new interpretation rule. For all devices implementing the 4.41 specification or later, the production year field will be interpreted as a value between 2010 and 2025, with 0 corresponding to 2013. Signed-off-by: NRomain Izard <romain.izard.pro@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 28 6月, 2013 5 次提交
-
-
由 Ulf Hansson 提交于
MMC_CAP2_FULL_PWR_CYCLE shall be set by host drivers which are able to do a complete power cycle of the card. In the eMMC case that includes both vcc and vccq. This CAP is providing the protocol layer with important information, needed to take optimized decisions during card initialization and in the suspend/resume sequence. MMC_CAP2_POWEROFF_NOTIFY is replaced by MMC_CAP2_FULL_PWR_CYCLE, since it makes sense to use a wider scope for it. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
In suspend mode it is important to save power. If the host is able to cut buth vcc and vccq, the MMC_CAP2_POWEROFF_NOTIFY shall be set. It will mean the card will be completely powered down at suspend and the power off notification cmd will be sent prior power down. It seems common not being able to cut both vcc and vccq for a host. In this situation we issue the sleep cmd in favor of the power off notification cmd, to save more power. While maintainng the above policy, we also want to make use of the power off notification in the shutdown sequence, even in the case were the host has not set MMC_CAP2_POWEROFF_NOTIFY, since we know vcc and vccq will regardless be cut. We accomplish this by always enabling the power off notification byte in the EXT_CSD and issue the power off notification when either MMC_CAP2_POWEROFF_NOTIFY is set or we are executing a shutdown. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
The shutdown sequence of an (e)MMC is very similar to a suspend. We re-use the suspend function and tell it we are not in suspend context. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Depending on the context of the operation while powering down the card, either POWER_OFF_NOTIFY_SHORT or POWER_OFF_NOTIFY_LONG will be used. In suspend context a short timeout is preferred while a long timeout would be acceptable in a shutdown/hibernation context. We add a new parameter to the mmc_suspend function so we can provide an indication of what notification type to use. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
By moving code from the mmc_suspend|resume_host down into each .suspend|resume bus_ops callback, we get a more flexible solution. Some nice side effects are that we get a better understanding of each bus_ops suspend|resume sequence and the common code don't have to take care of specific corner cases, especially for the SDIO case. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 27 6月, 2013 1 次提交
-
-
由 Yuvaraj Kumar C D 提交于
With the new eMMC5.1 spec, there is a new EXT_CSD register with the revision number(EXT_CSD_REV) 7. This patch updates the check for ext-csd.rev number as 7. Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com> Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com> Reviewed-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 27 5月, 2013 5 次提交
-
-
由 Fredrik Soderstedt 提交于
Use the saved values in card->ext_csd when selecting power class. By doing this the power class will be selected even if mmc_init_card is called with oldcard != NULL, which is the case after a suspend/resume. Today ext_csd is NULL if mmc_init_card is called with oldcard != NULL and power class will not be selected. According to the eMMC specification the POWER_CLASS value is reset after power failure, H/W reset assertion and any CMD0 reset. Signed-off-by: NFredrik Soderstedt <fredrik.soderstedt@stericsson.com> Reviewed-by: NJohan Rudholm <jrudholm@gmail.com> Acked By: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
The mmc_card_sleep|awake APIs are not being used since the support is already properly encapsulated within the suspend sequence. Sleep|awake command is also specific for eMMC. We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and move the code into the mmc specific core instead. This also includes the mmc ops function, mmc_sleepawake. All releated functions have then become static and we have got far less code to maintain. Additionally this patch also simplifies the code from mmc_sleepawake, since it is only used to put the card to sleep and not awake. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Aggressive power management is suitable when saving power is essential. At request inactivity timeout, aka pm runtime autosuspend timeout, the card will be suspended. Once a new request arrives, the card will be re-initalized and thus the first request will suffer from a latency. This latency is card-specific, experiments has shown in general that SD-cards has quite poor initialization time, around 300ms-1100ms. eMMC is not surprisingly far better but still a couple of hundreds of ms has been observed. Except for the request latency, it is important to know that suspending the card will also prevent the card from executing internal house-keeping operations in idle mode. This could mean degradation in performance. To use this feature make sure the request inactivity timeout is chosen carefully. This has not been done as a part of this patch. Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and by setting CONFIG_MMC_UNSAFE_RESUME. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Once the mmc blkdevice is being probed, runtime pm will be enabled. By using runtime autosuspend, the power save operations can be done when request inactivity occurs for a certain time. Right now the selected timeout value is set to 3 s. Obviously this value will likely need to be configurable somehow since it needs to be trimmed depending on the power save algorithm. For SD-combo cards, we are still leaving the enablement of runtime PM to the SDIO init sequence since it depends on the capabilities of the SDIO func driver. Moreover, when the blk device is being suspended, we make sure the device will be runtime resumed. The reason for doing this is that we want the host suspend sequence to be unaware of any runtime power save operations done for the card in this phase. Thus it can just handle the suspend as the card is fully powered from a runtime perspective. Finally, this patch prepares to make it possible to move BKOPS handling into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be accomplished. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Ulf Hansson 提交于
Move mmc suspend specific operations to be executed from the .suspend callback in the mmc bus_ops. This simplifies the mmc_suspend_host function which is supposed to handle nothing but common suspend tasks. Since eMMC can be considered non-removable there are no need to check for ongoing bkops at PM_SUSPEND_PREPARE notification so remove it. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 05 4月, 2013 1 次提交
-
-
由 Philip Rakity 提交于
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: NElad Yi <elad.yi@gmail.com> Signed-off-by: NPhilip Rakity <prakity@yahoo.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 23 3月, 2013 1 次提交
-
-
由 Bernie Thompson 提交于
The JEDEC MMC v4 spec defines a new PRV value in place of the original fwrev and hwrev specified in v1. We can expose this in the kernel to enable user space to more easily determine the product revision of a given MMC. Signed-off-by: NBernie Thompson <bhthompson@chromium.org> Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 25 2月, 2013 4 次提交
-
-
由 Seungwon Jeon 提交于
This patch adds packed command feature of eMMC4.5. The maximum number for packing read (or write) is offered and exception event relevant to packed command which is used for error handling is enabled. If host wants to use this feature, MMC_CAP2_PACKED_CMD should be set. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Reviewed-by: NMaya Erez <merez@codeaurora.org> Reviewed-by: NSubhash Jadavani <subhashj@codeaurora.org> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Johan Rudholm 提交于
Allow callers to access the start_signal_voltage_switch host_ops member without going through any cmd11 logic. This is mostly a preparation for the following signal voltage switch patch. Also, reset ios.signal_voltage to its original value if start_signal_voltage_switch fails. Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NWei WANG <wei_wang@realsil.com.cn> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Balaji T K 提交于
SET_BLOCK_COUNT CMD23 is needed for all access to RPMB partition. If block count is not set by CMD23, all subsequent read/write commands fail as per eMMC specification. So, If the host does not support CMD23, do not expose RPMB partition. Accessing RPMB partition can cause hang / huge delay for hosts which do not support CMD23. Signed-off-by: NBalaji T K <balajitk@ti.com> Reported-and-Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Maya Erez 提交于
Cache control is an eMMC feature and in therefore should be part of MMC's bus resume operations, performed in mmc_suspend, rather than in the generic mmc_suspend_host(). Signed-off-by: NMaya Erez <merez@codeaurora.org> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 07 12月, 2012 4 次提交
-
-
由 Al Cooper 提交于
If "caps2" host capabilities does not indicate support for MMC HS200, don't allow clock speeds >52MHz. Currently, for MMC, the clock speed is set to the lesser of the max speed the eMMC module supports (card->ext_csd.hs_max_dtr) or the max base clock of the host controller (host->f_max based on BASE_CLK_FREQ in the host CAPS register). This means that a host controller that doesn't support HS200 mode but has a base clock of 100MHz and an eMMC module that supports HS200 speeds will end up using a 100MHz clock. Signed-off-by: NAl Cooper <alcooperx@gmail.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Loic Pallardy 提交于
Extend current sysfs access to ext_csd rpmb parameters (RPMB partition size) and rel_sector information. Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NJohan Rudholm <johan.rudholm@stericsson.com> Acked-by: NKrishna Konda <kkonda@codeaurora.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Loic Pallardy 提交于
Following JEDEC standard, if the mmc supports RPMB partition, a new interface is created and exposed via /dev/block. Users will be able to access RPMB partition using standard mmc IOCTL commands. Signed-off-by: NAlex Macro <alex.macro@stericsson.com> Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NJohan Rudholm <johan.rudholm@stericsson.com> Acked-by: NKrishna Konda <kkonda@codeaurora.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
由 Lee Jones 提交于
There are discrepancies with regards to how MMC capabilities are carried throughout the subsystem. Let's standardise them to eliminate any confusion. Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 08 10月, 2012 1 次提交
-
-
由 Ulf Hansson 提交于
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. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NSaugata Das <saugata.das@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 03 10月, 2012 1 次提交
-
-
由 Jaehoon Chung 提交于
Enable eMMC background operations (BKOPS) feature. If URGENT_BKOPS is set after a response, note that BKOPS are required. Immediately run BKOPS if required. Read/write operations should be requested during BKOPS(LEVEL-1), then issue HPI to interrupt the ongoing BKOPS and service the foreground operation. (This patch only controls the LEVEL2/3.) When repeating the writing 1GB data, at a certain time, performance is decreased. At that time, card triggers the Level-3 or Level-2. After running bkops, performance is recovered. Future considerations: * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner. * Interrupt ongoing BKOPS before powering off the card. * How do we get BKOPS_STATUS value (periodically send ext_csd command)? * If using periodic bkops, also consider runtime_pm control. Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org> Reviewed-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 23 7月, 2012 1 次提交
-
-
由 Aaron Lu 提交于
Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in mmc_power_up so that we do not need to touch signal voltage setting in mmc/sd/sdio init functions and rescan function. For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe resume case, the card will lose its power and when powered on again, we will set signal voltage to 3.3v in mmc_power_up before its resume function gets called, which will re-init the card. And for sdio cards, when doing a suspend/resume cycle, consider the unsafe resume case, the card will either lose its power or not depending on if it wants to wakeup the host. If power is not maintained, it is the same case as mmc/sd cards. If power is maintained, mmc_power_up will not be called and the card's signal voltage will remain at the last setting. Signed-off-by: NAaron Lu <aaron.lu@amd.com> Tested-by: NVenkatraman S <svenkatr@ti.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 11 7月, 2012 1 次提交
-
-
由 Venkatraman S 提交于
This reverts commit 3d93576e(skip card initialization if power class selection fails). Problem has been reported when this is used with eMMC4.41 card with Tegra Platform. Till the issue is root caused, bus width selection failure should not be treated as fatal. Reported-by: NMarc Dietrich <marvin24@gmx.de> Signed-Off-by: NVenkatraman S <svenkatr@ti.com> CC: Ulf Hansson <ulf.hansson@stericsson.com> CC: Subhash Jadavani <subhashj@codeaurora.org> CC: Saugata Das <saugata.das@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 06 6月, 2012 1 次提交
-
-
由 Jaehoon Chung 提交于
When mmc_host is not spi mode, mmc/sd is doing mmc_deselect_cards(). mmc_deselect_cards could be returned error. If returned error, we can know something wrong when enter suspend. Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 17 5月, 2012 1 次提交
-
-
由 Saugata Das 提交于
This patch adds support for large sector size of 4KB by disabling emulation. This patch passes eMMC DATA_SECTOR_SIZE as the logical block size during mmc_blk_alloc_req. In order to use this patch for 4KB sector size, ensure that USE_NATIVE_SECTOR is enabled, partition table is 4KB sector size aligned and file system block and sector size are 4KB multiples. Signed-off-by: NSaugata Das <saugata.das@linaro.org> Reviewed-by: NSubhash Jadavani <subhashj@codeaurora.org> Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com> Reviewed-by: NSubhash Jadavani <subhashj@codeaurora.org> Signed-off-by: NChris Ball <cjb@laptop.org>
-