For normal request mmc_blk_issue_rq is called twice with asynchronous
transfer(cur and prev). Host's claim and release can be done in each
mmc_blk_issue_rq. However, Special request is currently excluded in
asynchronous transfer. After special request is finished, if there is
no new request, mmc_re
Hi Johan,
Thursday, March 14, 2013, Johan Rudholm wrote:
> Hi Seungwon,
>
> we've just backported mmc-related patches from 3.9rc1 to our internal
> tree, and I'm seeing an issue with:
>
> 369d321 mmc: queue: exclude asynchronous transfer for special request
>
> When the device is going into sus
2013/3/14, Sergey Yanovich :
> MMC hosts are added asynchronously. We need to wait until detect returns to
> avoid failed root filesystem mounts.
> ---8<---
> VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
> Please append a correct "root=" boot option; here are the availab
On Thu, Mar 14, 2013 at 05:06:23AM +0400, Sergey Yanovich wrote:
> MMC hosts are added asynchronously. We need to wait until detect returns to
> avoid failed root filesystem mounts.
> ---8<---
> VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
> Please append a correct "root
MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.
---8<---
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not supp
MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.
---8<---
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not supp
Hi Jonas,
On 13.03.2013 16:37, Jonas Jensen wrote:
> I ask for feedback and to submit (if possible) a new ARM SoC platform
> port. This is now near complete (I think) (tested on UC-7112-LX Plus)
> and applies to 2.6.34.14.
First of all - thanks for submitting to the upstream kernel!
However, you
On 03/13/2013 12:26 PM, Lars-Peter Clausen wrote:
> The sdhci_pltfm_data struct is never modified within the sdhci_pltfm module.
> So
> make the pdata parameter to sdhci_pltfm_init and sdhci_pltfm_register const.
> This allows drivers to declare their sdhci_pltfm_data struct as const.
>
> This pa
Basically all drivers can have sdhci_ops struct const, but almost none do so.
This patch constifies all sdhci_ops struct declarations where possible.
The patch was auto-generated with the following coccinelle semantic patch:
//
@r1@
identifier ops;
identifier fld;
@@
ops.fld = ...;
@disable opt
All users of the sdhci_ops struct in the sdhci core already treat it as const.
The sdhci-pltfm code itself never actually looks at the ops field of the
sdhci_pltfm_data struct and merely passes it on to the sdhci core, so make we
can make it const in the sdhci_pltfm_data struct as well. This allows
The sdhci_pltfm_data struct is never modified within the sdhci_pltfm module. So
make the pdata parameter to sdhci_pltfm_init and sdhci_pltfm_register const.
This allows drivers to declare their sdhci_pltfm_data struct as const.
This patch also makes the sdhci_pltfm_data declarations const where po
Hi Seungwon,
we've just backported mmc-related patches from 3.9rc1 to our internal
tree, and I'm seeing an issue with:
369d321 mmc: queue: exclude asynchronous transfer for special request
When the device is going into suspend, it seems that mmcqd still has
claimed the host and so the 20s DPM de
Fix regression introduced by commit 796211b7953 ("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 en
Hi,
I ask for feedback and to submit (if possible) a new ARM SoC platform
port. This is now near complete (I think) (tested on UC-7112-LX Plus)
and applies to 2.6.34.14.
The patch contains the following drivers and platform specific implementations:
* ARCH_MOXART (FA526 processor)
* 100Hz interr
Hi Chris,
On 13 March 2013 19:47, Seungwon Jeon wrote:
> On Monday, February 18, 2013, Sachin Kamat wrote:
>> 'dw_mci_exynos_match' is always compiled in. Hence of_match_ptr
>> is not required.
>>
>> Signed-off-by: Sachin Kamat
>
> Acked-by: Seungwon Jeon
Here are the required Ack's for you t
On Wed, Mar 13, 2013 at 3:59 AM, Adrian Hunter wrote:
> On 12/03/13 18:13, Mark Deneen wrote:
>> I assume that this never made it into mainline? I'm looking to do something
>> similar, and I was wondering if it somehow did make it in but in a different
>> form that I'm not seeing.
>
> There is BL
On 13/03/13 14:20, Seungwon Jeon wrote:
> Hi James,
>
> On Tuesday, March 12, 2013, James Hogan wrote:
>> Call the setpower platform callback in response to set_ios with
>> ios->power_mode == MMC_POWER_UP or MMC_POWER_OFF, instead of from the
>> card detect work function.
>>
>> This appears to fix
On 03/13/2013 02:26 PM, Chris Ball wrote:
Hi,
On Wed, Mar 13 2013, Seungwon Jeon wrote:
On Tuesday, March 12, 2013, Markos Chandras wrote:
There is no reason to loop when handling an interrupt. The "if" clauses
will handle all of them sequentially. This also eliminates the extra loop
we used t
Hi,
On Wed, Mar 13 2013, Seungwon Jeon wrote:
> On Tuesday, March 12, 2013, Markos Chandras wrote:
>> There is no reason to loop when handling an interrupt. The "if" clauses
>> will handle all of them sequentially. This also eliminates the extra loop
>> we used to take with no pending interrupts a
On 03/13/2013 02:22 PM, Seungwon Jeon wrote:
> On Tuesday, March 12, 2013, Markos Chandras wrote:
>> There is no reason to loop when handling an interrupt. The "if" clauses
>> will handle all of them sequentially. This also eliminates the extra loop
>> we used to take with no pending interrupts and
On Tuesday, March 12, 2013, Markos Chandras wrote:
> There is no reason to loop when handling an interrupt. The "if" clauses
> will handle all of them sequentially. This also eliminates the extra loop
> we used to take with no pending interrupts and we ended up breaking out
> of the while loop.
>
On Tuesday, March 12, 2013, James Hogan wrote:
> host->data_offset is initialised at the end of the probe function
> depending on the VERID register, and is used for PIO operations. Move
> this initialisation earlier, before IRQs or slots are initialised, to be
> sure that PIO won't occur prior to
Hi James,
On Tuesday, March 12, 2013, James Hogan wrote:
> Call the setpower platform callback in response to set_ios with
> ios->power_mode == MMC_POWER_UP or MMC_POWER_OFF, instead of from the
> card detect work function.
>
> This appears to fix a problem I have where a card stuck in a funny st
On Saturday, February 23, 2013, Dongjin Kim wrote:
> This patch adds the compatible string for MSHC controller of Exynos4412.
> And exynos5250_dwmmc_caps is renamed to exynos_dwmmc_caps, since it has the
> capablities of common feature supported by Exynos4 and Exynos5.
>
> Cc: Seungwon Jeon
Acke
On Monday, February 18, 2013, Sachin Kamat wrote:
> 'dw_mci_exynos_match' is always compiled in. Hence of_match_ptr
> is not required.
>
> Signed-off-by: Sachin Kamat
Acked-by: Seungwon Jeon
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to maj
Acked-by: Jaehoon Chung
On 03/12/2013 07:53 PM, Markos Chandras wrote:
> There is no reason to loop when handling an interrupt. The "if" clauses
> will handle all of them sequentially. This also eliminates the extra loop
> we used to take with no pending interrupts and we ended up breaking out
>
On 12/03/13 18:13, Mark Deneen wrote:
> I assume that this never made it into mainline? I'm looking to do something
> similar, and I was wondering if it somehow did make it in but in a different
> form that I'm not seeing.
There is BLKDISCARD and BLKSECDISCARD
Perhaps MMC_IOC_CMD could be useful
27 matches
Mail list logo
