Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.

[Shawn Lin]

On 2015/9/6 22:51, Yousong Zhou wrote:

all of this is under control of the mmc core.
So if Yongsong does want this card to work for any linux-based mmc stack,
I
guess something like that should be "better"?

if (switch to HS fail) {
  set_bus_clk
  goto retry switch to HS
}

BUT...I admit it seems strange as well.



The SD Specification (simplified version) says "If CRC error occurs on
the status data, the host should issue a power cycle.", so I guess the
above approach is anti-spec in some way :)



Right，I was guessing that way from your intention.


In case it may help debug this problem, I'd like to add that the card
previously worked fine with U-Boot before commit [1].  This can also
be confirmed by Debian Jessie installer image with which the old
U-Boot there worked fine while the kernel (3.16) did not.

   [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,

http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c



Interesting... but that at least prove your patch is a workaround but not
find the root cause.

Anyway, look into commit-sha [1], can you have a test by restoring mod-clk
and clock sampling phases before jump to kernel.



Maybe my statement about U-Boot commit [1] above was a little
ambiguous, sorry.  I meant to say that with that commit applied,
U-Boot failed initialising the card the same way as the kernel, i.e.
response crc error.

The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened.  However after that
the 3.16 kernel failed initialising the card.



So I undertand your point:  Uboot w/o commit[1] + 3.16 kernel failed 
that way just as Uboot w/ commit[1] + pre-3.16 kernel, right?


If that is it, could you check sunxi-platform's patches merged into 
v3.16 for sure whether there is any patch do the same things just like 
what commit[1] did for uboot or not?



So, with commit [1], U-Boot failed right away without any chance at
all jumping to kernel.

OpenWrt ticket 20387 has more info about the U-Boot failure.

https://dev.openwrt.org/ticket/20387

Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases".  Never played with such things before :)

 yousong


I happended to fix some problems which seems *similar* to yours(but I'm not
sure just from commit[1]'s msg):

https://patchwork.kernel.org/patch/7119661/







--
Best Regards
Shawn Lin

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.

[Yousong Zhou]

>>> all of this is under control of the mmc core.
>>> So if Yongsong does want this card to work for any linux-based mmc stack,
>>> I
>>> guess something like that should be "better"?
>>>
>>> if (switch to HS fail) {
>>>  set_bus_clk
>>>  goto retry switch to HS
>>> }
>>>
>>> BUT...I admit it seems strange as well.
>>>
>>
>> The SD Specification (simplified version) says "If CRC error occurs on
>> the status data, the host should issue a power cycle.", so I guess the
>> above approach is anti-spec in some way :)
>>
>
> Right，I was guessing that way from your intention.
>
>> In case it may help debug this problem, I'd like to add that the card
>> previously worked fine with U-Boot before commit [1].  This can also
>> be confirmed by Debian Jessie installer image with which the old
>> U-Boot there worked fine while the kernel (3.16) did not.
>>
>>   [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
>>
>> http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
>>
>
> Interesting... but that at least prove your patch is a workaround but not
> find the root cause.
>
> Anyway, look into commit-sha [1], can you have a test by restoring mod-clk
> and clock sampling phases before jump to kernel.
>

Maybe my statement about U-Boot commit [1] above was a little
ambiguous, sorry.  I meant to say that with that commit applied,
U-Boot failed initialising the card the same way as the kernel, i.e.
response crc error.

The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened.  However after that
the 3.16 kernel failed initialising the card.

So, with commit [1], U-Boot failed right away without any chance at
all jumping to kernel.

OpenWrt ticket 20387 has more info about the U-Boot failure.

https://dev.openwrt.org/ticket/20387

Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases".  Never played with such things before :)

yousong

> I happended to fix some problems which seems *similar* to yours(but I'm not
> sure just from commit[1]'s msg):
>
> https://patchwork.kernel.org/patch/7119661/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.

[Shawn Lin]

在 2015/9/6 20:09, Yousong Zhou 写道:

Hi,

On 6 September 2015 at 08:12, Shawn Lin  wrote:

On 2015/9/5 22:58, Hans de Goede wrote:


Hi Shawn Lin,

On 05-09-15 16:07, Shawn Lin wrote:


On 2015/9/5 18:19, Yousong Zhou wrote:


A SD card with sunxi-mmc can fail with the following error message
(RCD for
response CRC error) when trying to switch to highspeed mode.  Setting
the bus
clock before the access mode switch fixed it.



No, that's wrong!

Before this card is switched to highspeed, it works under
identification mode(From spec: bus clock <= 400KHz). How could you
raise bus clock to higher clk rate which I _guess_ is 52MHz before you
notify sd cards to run into highspeed mode?

Althought it works for this card, this patch will not please the other
cards that they might not reply CMDs any longer including the
following CMD6.



Thanks for the feedback, this is exactly why I asked Yousong Zhou to
take this
to the mmc list.

So if this is not the proper fix for the problem that Yousong Zhou is
seeing, then
what might be the proper fix ?



 From my knowledge of mmc, there hadn't have a way to deal with this "broken"
case. In another word, IMO,it's ANTI-SPEC. We can't be too spec sometimes,
but at least we shouldn't violate it.



Maybe the fix is anti-spec.  But the fact is that the card works on
many other platforms with the builtin card reader (not through an USB
adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.


Could it be that the sunxi-mmc is doing some things in the wrong order
when
changing the clock, or is this all under control of the mmc core ?



all of this is under control of the mmc core.
So if Yongsong does want this card to work for any linux-based mmc stack, I
guess something like that should be "better"?

if (switch to HS fail) {
 set_bus_clk
 goto retry switch to HS
}

BUT...I admit it seems strange as well.



The SD Specification (simplified version) says "If CRC error occurs on
the status data, the host should issue a power cycle.", so I guess the
above approach is anti-spec in some way :)



Right，I was guessing that way from your intention.


In case it may help debug this problem, I'd like to add that the card
previously worked fine with U-Boot before commit [1].  This can also
be confirmed by Debian Jessie installer image with which the old
U-Boot there worked fine while the kernel (3.16) did not.

  [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c



Interesting... but that at least prove your patch is a workaround but 
not find the root cause.


Anyway, look into commit-sha [1], can you have a test by restoring 
mod-clk and clock sampling phases before jump to kernel.


I happended to fix some problems which seems *similar* to yours(but I'm 
not sure just from commit[1]'s msg):


https://patchwork.kernel.org/patch/7119661/


Cheers

 yousong
--
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.kernel.org/majordomo-info.html






--
Best Regards
Shawn Lin

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.

[Yousong Zhou]

On Sep 6, 2015 10:14 PM, "Shawn Lin"  wrote:
>
> 在 2015/9/6 20:09, Yousong Zhou 写道:
>>
>> Hi,
>>
>> On 6 September 2015 at 08:12, Shawn Lin  wrote:
>>>
>>> On 2015/9/5 22:58, Hans de Goede wrote:


 Hi Shawn Lin,

 On 05-09-15 16:07, Shawn Lin wrote:
>
>
> On 2015/9/5 18:19, Yousong Zhou wrote:
>>
>>
>> A SD card with sunxi-mmc can fail with the following error message
>> (RCD for
>> response CRC error) when trying to switch to highspeed mode.  Setting
>> the bus
>> clock before the access mode switch fixed it.
>
>
>
> No, that's wrong!
>
> Before this card is switched to highspeed, it works under
> identification mode(From spec: bus clock <= 400KHz). How could you
> raise bus clock to higher clk rate which I _guess_ is 52MHz before you
> notify sd cards to run into highspeed mode?
>
> Althought it works for this card, this patch will not please the other
> cards that they might not reply CMDs any longer including the
> following CMD6.



 Thanks for the feedback, this is exactly why I asked Yousong Zhou to
 take this
 to the mmc list.

 So if this is not the proper fix for the problem that Yousong Zhou is
 seeing, then
 what might be the proper fix ?

>>>
>>>  From my knowledge of mmc, there hadn't have a way to deal with this
"broken"
>>> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec
sometimes,
>>> but at least we shouldn't violate it.
>>>
>>
>> Maybe the fix is anti-spec.  But the fact is that the card works on
>> many other platforms with the builtin card reader (not through an USB
>> adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
>>
 Could it be that the sunxi-mmc is doing some things in the wrong order
 when
 changing the clock, or is this all under control of the mmc core ?

>>>
>>> all of this is under control of the mmc core.
>>> So if Yongsong does want this card to work for any linux-based mmc
stack, I
>>> guess something like that should be "better"?
>>>
>>> if (switch to HS fail) {
>>>  set_bus_clk
>>>  goto retry switch to HS
>>> }
>>>
>>> BUT...I admit it seems strange as well.
>>>
>>
>> The SD Specification (simplified version) says "If CRC error occurs on
>> the status data, the host should issue a power cycle.", so I guess the
>> above approach is anti-spec in some way :)
>>
>
> Right，I was guessing that way from your intention.
>
>
>> In case it may help debug this problem, I'd like to add that the card
>> previously worked fine with U-Boot before commit [1].  This can also
>> be confirmed by Debian Jessie installer image with which the old
>> U-Boot there worked fine while the kernel (3.16) did not.
>>
>>   [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
>>
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
>>
>
> Interesting... but that at least prove your patch is a workaround but not
find the root cause.
>
> Anyway, look into commit-sha [1], can you have a test by restoring
mod-clk and clock sampling phases before jump to kernel.
>

Maybe my statement about U-Boot commit [1] above was a little ambiguous,
sorry.  I meant to say that with that commit applied, U-Boot failed
initialising the card the same way as the kernel, i.e. response crc error.

The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened.  However after that the
3.16 kernel failed initialising the card.

So, with commit [1], U-Boot failed right away without any chance at all
jumping to kernel.

OpenWrt ticket 20387 has more info about the U-Boot failure.

https://dev.openwrt.org/ticket/20387

Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases".  Never played with such things before :)

> I happended to fix some problems which seems *similar* to yours(but I'm
not sure just from commit[1]'s msg):
>
> https://patchwork.kernel.org/patch/7119661/
>
>> Cheers
>>
>>  yousong
>> --
>> 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.kernel.org/majordomo-info.html
>>
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
> --
> You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.

[Yousong Zhou]

Hi,

On 6 September 2015 at 08:12, Shawn Lin  wrote:
> On 2015/9/5 22:58, Hans de Goede wrote:
>>
>> Hi Shawn Lin,
>>
>> On 05-09-15 16:07, Shawn Lin wrote:
>>>
>>> On 2015/9/5 18:19, Yousong Zhou wrote:

 A SD card with sunxi-mmc can fail with the following error message
 (RCD for
 response CRC error) when trying to switch to highspeed mode.  Setting
 the bus
 clock before the access mode switch fixed it.
>>>
>>>
>>> No, that's wrong!
>>>
>>> Before this card is switched to highspeed, it works under
>>> identification mode(From spec: bus clock <= 400KHz). How could you
>>> raise bus clock to higher clk rate which I _guess_ is 52MHz before you
>>> notify sd cards to run into highspeed mode?
>>>
>>> Althought it works for this card, this patch will not please the other
>>> cards that they might not reply CMDs any longer including the
>>> following CMD6.
>>
>>
>> Thanks for the feedback, this is exactly why I asked Yousong Zhou to
>> take this
>> to the mmc list.
>>
>> So if this is not the proper fix for the problem that Yousong Zhou is
>> seeing, then
>> what might be the proper fix ?
>>
>
> From my knowledge of mmc, there hadn't have a way to deal with this "broken"
> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec sometimes,
> but at least we shouldn't violate it.
>

Maybe the fix is anti-spec.  But the fact is that the card works on
many other platforms with the builtin card reader (not through an USB
adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.

>> Could it be that the sunxi-mmc is doing some things in the wrong order
>> when
>> changing the clock, or is this all under control of the mmc core ?
>>
>
> all of this is under control of the mmc core.
> So if Yongsong does want this card to work for any linux-based mmc stack, I
> guess something like that should be "better"?
>
> if (switch to HS fail) {
> set_bus_clk
> goto retry switch to HS
> }
>
> BUT...I admit it seems strange as well.
>

The SD Specification (simplified version) says "If CRC error occurs on
the status data, the host should issue a power cycle.", so I guess the
above approach is anti-spec in some way :)

In case it may help debug this problem, I'd like to add that the card
previously worked fine with U-Boot before commit [1].  This can also
be confirmed by Debian Jessie installer image with which the old
U-Boot there worked fine while the kernel (3.16) did not.

 [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c

Cheers

yousong

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] ARM: dts: sun4i: Add dts file for the pov protab2-ips9 tablet

[Maxime Ripard]

On Sat, Sep 05, 2015 at 10:21:59AM +0200, Hans de Goede wrote:
> The Point of View protab2-ips9 is a tablet with a 9" ips 1024x768 lcd screen,
> microsd slot, headphones, mini hdmi, mini usb b and power barrel connectors.
> 
> It uses a rtl8188cus usb wifi chip and a RDA 5875Y bluetooth chip attached
> to uart2. It has a bma250 accelerometer attached to i2c1 addr 0x18.
> 
> It has a pixcir,pixcir_tangoc compatible touchscreen attached to i2c2 addr
> 0x5c. This is not enabled in this dts, because this variant of the
> pixcir_tangoc has separate wakeup and enable pins both of which need
> to be driven low before the touchscreen will work. Before we can enable
> this the pixcir driver and devicetree-bindings need to be extended to
> support these pins.
> 
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/Makefile   |   3 +-
>  arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts | 209 
> +++
>  2 files changed, 211 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e981fd6..c08883c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -561,7 +561,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
>   sun4i-a10-mk802.dtb \
>   sun4i-a10-mk802ii.dtb \
>   sun4i-a10-olinuxino-lime.dtb \
> - sun4i-a10-pcduino.dtb
> + sun4i-a10-pcduino.dtb \
> + sun4i-a10-pov-protab2-ips9.dtb
>  dtb-$(CONFIG_MACH_SUN5I) += \
>   sun5i-a10s-auxtek-t003.dtb \
>   sun5i-a10s-auxtek-t004.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts 
> b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> new file mode 100644
> index 000..223515e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright 2015 Hans de Goede 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Point of View Protab2-IPS9";
> + compatible = "pov,protab2-ips9", "allwinner,sun4i-a10";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> + {
> + cpu-supply = <_dcdc2>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> +
> + axp209: pmic@34 {
> + reg = <0x34>;
> + interrupts = <0>;
> + };
> +};
> +
> +#include "axp209.dtsi"
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> +};
> +
> + {
> + vref-supply = <_ldo2>;
>