From: Jerry Huang
CMD23 causes lots of errors in kernel on some freescale SoCs
(P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
which is because these controllers does not support CMD23,
even on the SoCs which declares CMD23 is supported.
Therefore, we'll not use CMD23.
Signed-o
Next version, I will change it to the warning and report to user.
Best Regards
Jerry Huang
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Huang Changming-R66093
> Sent: Wednesday, September 26, 2012 10:40 AM
> To: Gir
Best Regards
Jerry Huang
> -Original Message-
> From: Girish K S [mailto:girish.shivananja...@linaro.org]
> Sent: Tuesday, September 25, 2012 10:45 PM
> To: Huang Changming-R66093
> Cc: linux-mmc@vger.kernel.org; Huang Changming-R66093; Xie Shaohui-B21989;
> Anton Vorontsov; Chris Ball
Dear linux-mmc maintainer,
(09/19/2012 11:50 AM), Tetsuyuki Kobayashi wrote:
> (2012/08/22 15:49), Guennadi Liakhovetski wrote:
>> On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
>> interrupts without any active request. To prevent the Oops, that results
>> in such cases, don't
2012/9/25 Girish K S :
> On 25 September 2012 19:38, Kevin Liu wrote:
>> From: Kevin Liu
>>
>> Commands without data transfer like cmd5/cmd7 will use previous
>> transfer mode setting, which may lead to error since some bits
>> may have been set unexpectedly.
>> For example, cmd5 following cmd18/
2012/9/25 Girish K S :
> On 25 September 2012 19:38, Kevin Liu wrote:
>> From: Kevin Liu
>>
>> Use voltage range as below rather than a specific value
>> 3.3v: (3.2v, 3.4v)
>> 3.0v: (2.9v, 3.1v)
>> 1.8v: (1.65v, 1.95v)
> Any specific reason to give range and not specific value?
Regulator voltage
On Sep 25, 2012, at 12:30 AM, Ulf Hansson wrote:
> Hi Johan,
>
> An overall comment; would it be possible to include this patch as a
> piece of patch 1/2 "mmc: core: Proper signal voltage switch".
> They seems like quite tight connected.
>
> Anyway, some comment below.
>
> On 25 September 20
On 25 September 2012 19:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Use voltage range as below rather than a specific value
> 3.3v: (3.2v, 3.4v)
> 3.0v: (2.9v, 3.1v)
> 1.8v: (1.65v, 1.95v)
Any specific reason to give range and not specific value?
>
> Signed-off-by: Jialing Fu
> Signed-off-by: Kev
On 25 September 2012 19:38, Kevin Liu wrote:
> From: Kevin Liu
>
> Commands without data transfer like cmd5/cmd7 will use previous
> transfer mode setting, which may lead to error since some bits
> may have been set unexpectedly.
> For example, cmd5 following cmd18/cmd25 will have timeout error
>
On 25 September 2012 18:00, wrote:
> From: Jerry Huang
>
> CMD23 causes lots of errors in kernel on some freescale SoCs
> (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
> which is because these controllers does not support CMD23,
> even on the SoCs which declares CMD23 is supp
From: Kevin Liu
Signed-off-by: Bin Wang
Signed-off-by: Philip Rakity
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci-pxav3.c | 25 +
include/linux/platform_data/pxa_sdhci.h |2 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/driver
From: Kevin Liu
Some soc/platform need specific handling for signal voltage
switch. For example, mmp2/mmp3 need to set the AIB IO domain
control register accordingly.
Signed-off-by: Bin Wang
Signed-off-by: Philip Rakity
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c | 17 +++
From: Kevin Liu
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci-pxav3.c |2 ++
include/linux/platform_data/pxa_sdhci.h |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 75cc79b..04db9f
From: Kevin Liu
Preset value support was added by 4d55c5a1.
But preset value is enabled after setting clock finished,
which means the clock is still set by driver firstly and
then switch to preset value at this point. So the
driver setting beforehand is useless and unnecessary.
What's more, driv
From: Kevin Liu
Both of MMC_TIMING_LEGACY and MMC_TIMING_UHS_SDR12 are defined
to 0. And ios->timing is set to MMC_TIMING_LEGACY during power up.
But set_ios can't distinguish these two timing if host support
spec 3.0. Just adjust timing values to be different can resolve
this issue without any o
From: Kevin Liu
Enable the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN since
SD_CAPABILITIES_1[15:8](BASE_FREQ) can't get correct base
clock value. It return a fixed pre-set value like 200 on
some sdhci-pxav3 based platforms like MMP3 while return 0
on the other sdhci-pxav3 based platforms.
So we ena
From: Kevin Liu
regulator_get() returns NULL when CONFIG_REGULATOR not defined,
which should not print out the warning.
Reviewed-by: Philip Rakity
Signed-off-by: Bin Wang
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c | 18 --
1 files changed, 12 insertions(+), 6 del
From: Kevin Liu
The clock rate set to the sdh controller may not exactly as requested
by the mmc core, this patch make the clock rate saved in the mmc_ios
and sdhci_host updated with the actual setting as in the controller. Thus
"/sys/kernel/debug/mmcx/ios" and card detect prints can show the cor
From: Kevin Liu
With preset value enabled, there are two continuous times
of sd clock disable/enable. They can be combined into one
to save time and make code cleaner.
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c | 29 +
1 files changed, 9 insertions(+),
From: Kevin Liu
Use voltage range as below rather than a specific value
3.3v: (3.2v, 3.4v)
3.0v: (2.9v, 3.1v)
1.8v: (1.65v, 1.95v)
Signed-off-by: Jialing Fu
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff
From: Kevin Liu
Commands without data transfer like cmd5/cmd7 will use previous
transfer mode setting, which may lead to error since some bits
may have been set unexpectedly.
For example, cmd5 following cmd18/cmd25 will have timeout error
since audo cmd23 has been enabled.
Signed-off-by: Jialing
This patchset does as follows:
[PATCH v3 01/11] mmc: sdhci: fix transfer mode setting bug for cmds w/o data
transfer
[PATCH v3 02/11] mmc: sdhci: set regulator min/max voltage according to spec
[PATCH v3 03/11] mmc: sdhci: refine code for sd clock disable/enable in set ios
[PATCH v3 04/11] mmc: s
On Tue, Sep 25, 2012 at 04:50:52PM +0800, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 10:05:25AM +0200, Sascha Hauer wrote:
> > Ok, how about this:
> >
> > - I add a bus-width = <4> property to all i.MX dtsi files
> > - we merge the patch adding bus-width as an optional property
> > - Make the bus-
From: Jerry Huang
CMD23 causes lots of errors in kernel on some freescale SoCs
(P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
which is because these controllers does not support CMD23,
even on the SoCs which declares CMD23 is supported.
Therefore, we'll not use CMD23.
Signed-o
On 20 September 2012 03:35, Chris Ball wrote:
> Hi,
>
> On Wed, Sep 19 2012, Ulf Hansson wrote:
>> Just pinging you to see if you have an opinion in merging this without
>> full testing on eMMC4.5 device?
>>
>> I am kind of eager to fixup the broken suspend for eMMC with sleep,
>> which this does.
Anton,
Thanks a lot for your comments. I've just reviewed those host drivers under
drivers/mmc/host who use SDHCI_QUIRK_BROKEN_CARD_DETECTION. And here are the
details,
1. sdhci-pxav2/3.c
Actually they set "SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE"
together for a permanent car
Hi Ulf,
2012/9/25 Ulf Hansson :
> Hi Johan,
>
> An overall comment; would it be possible to include this patch as a
> piece of patch 1/2 "mmc: core: Proper signal voltage switch".
> They seems like quite tight connected.
Sure, I can do this. Let me see what comes out of the SDIO patch first thoug
On Tue, Sep 25, 2012 at 10:05:25AM +0200, Sascha Hauer wrote:
> Ok, how about this:
>
> - I add a bus-width = <4> property to all i.MX dtsi files
> - we merge the patch adding bus-width as an optional property
> - Make the bus-width option mandatory in the next step.
>
> This way we can merge the
Hi Ulf,
2012/9/25 Ulf Hansson :
> On 25 September 2012 09:03, Johan Rudholm
> wrote:
>> @@ -1243,8 +1244,29 @@ int mmc_set_signal_voltage(struct mmc_host *host, int
>> signal_voltage, bool cmd11
>> host->ios.signal_voltage = signal_voltage;
>>
>> if (host->ops->start_signal_volt
Hi, Ulf
2012/9/25 Ulf Hansson :
> Hi Kevin,
>
> This make sense to me.
>
> Acked-by: Ulf Hansson
>
Thanks for the review.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
On Tue, Sep 25, 2012 at 03:45:50PM +0800, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 09:38:08AM +0200, Sascha Hauer wrote:
> > So you want to make the code conform to the common spec which has
> > bus-width as a required property. Is this really worth it to add an
> > incompatible change to our dev
Hi,
On Tue, Sep 25 2012, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 03:52:09AM -0400, Chris Ball wrote:
>> We could also break the stalemate by just changing the common spec to
>> have bus-width become optional, default 4. It's not going to break the
>> code of anyone who's been treating it as re
On Tue, Sep 25, 2012 at 09:38:08AM +0200, Sascha Hauer wrote:
> So you want to make the code conform to the common spec which has
> bus-width as a required property. Is this really worth it to add an
> incompatible change to our devicetrees?
>
I do want to have our implementation conform to common
On Tue, Sep 25, 2012 at 03:52:09AM -0400, Chris Ball wrote:
> We could also break the stalemate by just changing the common spec to
> have bus-width become optional, default 4. It's not going to break the
> code of anyone who's been treating it as required. I don't think there
> there was a princ
Hi,
On Tue, Sep 25 2012, Sascha Hauer wrote:
>> > > > +- bus-width : Maximum supported bus width. Defaults to 4 if omitted
>> > > >
>> > > This is a common mmc property documented in bindings/mmc/mmc.txt.
>> > > Instead of duplicating the documentation, we should try to make our
>> > > implementat
On Tue, Sep 25, 2012 at 03:33:19PM +0800, Shawn Guo wrote:
> On Tue, Sep 25, 2012 at 09:27:15AM +0200, Sascha Hauer wrote:
> > > > Optional properties:
> > > > - fsl,cd-controller : Indicate to use controller internal card
> > > > detection
> > > > - fsl,wp-controller : Indicate to use controll
Hi Kevin,
This make sense to me.
Acked-by: Ulf Hansson
Kind regards
Ulf Hansson
On 24 September 2012 10:15, Kevin Liu wrote:
> From: Kevin Liu
>
> Both of MMC_TIMING_LEGACY and MMC_TIMING_UHS_SDR12 are defined
> to 0. And ios->timing is set to MMC_TIMING_LEGACY during power up.
> But set_ios
On Tue, Sep 25, 2012 at 09:27:15AM +0200, Sascha Hauer wrote:
> > > Optional properties:
> > > - fsl,cd-controller : Indicate to use controller internal card detection
> > > - fsl,wp-controller : Indicate to use controller internal write
> > > protection
> > > +- bus-width : Maximum supported b
Hi Johan,
An overall comment; would it be possible to include this patch as a
piece of patch 1/2 "mmc: core: Proper signal voltage switch".
They seems like quite tight connected.
Anyway, some comment below.
On 25 September 2012 09:04, Johan Rudholm wrote:
> Signed-off-by: Johan Rudholm
> ---
>
On 09/25/2012 03:15 PM, Sascha Hauer wrote:
> On Tue, Sep 25, 2012 at 11:35:14AM +0900, Jaehoon Chung wrote:
>> On 09/24/2012 04:22 PM, Sascha Hauer wrote:
>>> /*
>>> * If your platform has 8-bit width support but is not a v3 controller,
>>> * or if it requires special setup code, you
On Tue, Sep 25, 2012 at 03:15:08PM +0800, Shawn Guo wrote:
> On Mon, Sep 24, 2012 at 09:22:25AM +0200, Sascha Hauer wrote:
> > The i.MX esdhc has a nonstandard bit layout for the SDHCI_HOST_CONTROL
> > register. To support 8bit bus width on i.MX populate the platform_bus_width
> > callback. This is
Hi Johan,
On 25 September 2012 09:03, Johan Rudholm wrote:
> When switching SD and SDIO cards from 3.3V to 1.8V signal levels, the
> clock should be gated for 5 ms during the step. Failure by the card to
> switch is indicated by dat0 being pulled low. The host should check for
> this condition an
On Mon, Sep 24, 2012 at 09:22:25AM +0200, Sascha Hauer wrote:
> The i.MX esdhc has a nonstandard bit layout for the SDHCI_HOST_CONTROL
> register. To support 8bit bus width on i.MX populate the platform_bus_width
> callback. This is tested on an i.MX25, but should according to the datasheets
> work
On Tue, Sep 25, 2012 at 02:34:07PM +0800, yongd wrote:
> From: yongd
[...]
> And the better one to decide whether we use polling or not should be
> the host driver itself. Actually, some host driver has already been
> like this. Eg, in drivers/mmc/host/Au1xmmc.c, polling will be enabled
> only aft
Signed-off-by: Johan Rudholm
---
drivers/mmc/core/core.c |2 +-
drivers/mmc/core/core.h |1 +
drivers/mmc/core/sd.c |8 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index dae6744..fb03bd9 100644
--- a/drive
When switching SD and SDIO cards from 3.3V to 1.8V signal levels, the
clock should be gated for 5 ms during the step. Failure by the card to
switch is indicated by dat0 being pulled low. The host should check for
this condition and power-cycle the card if failure is indicated.
Signed-off-by: Johan
46 matches
Mail list logo