* Re: Regression after "do not use CMD13 to get status after speed mode switch"
From: Linus Walleij @ 2016-10-18 8:36 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org, Ulf Hansson, Chaotian Jing
Cc: linux-arm-msm@vger.kernel.org, Bjorn Andersson, Stephen Boyd,
Andy Gross
In-Reply-To: <CACRpkdbfNq+R9U9AwsKBM=xyKKTzyVDkiW4jqJ0Nb2LXvq20BA@mail.gmail.com>
On Mon, Oct 17, 2016 at 4:32 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Before this patch the eMMC is detected and all partitions enumerated
> immediately, but after the patch it doesn't come up at all, except
> sometimes, when it appears minutes (!) after boot, all of a sudden.
FYI this is what it looks like when it eventually happens:
root@msm8660:/ [ 627.710175] mmc0: new high speed MMC card at address 0001
[ 627.711641] mmcblk0: mmc0:0001 SEM04G 3.69 GiB
[ 627.715485] mmcblk0boot0: mmc0:0001 SEM04G partition 1 1.00 MiB
[ 627.736654] mmcblk0boot1: mmc0:0001 SEM04G partition 2 1.00 MiB
[ 627.747397] mmcblk0rpmb: mmc0:0001 SEM04G partition 3 128 KiB
[ 627.756326] mmcblk0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 p10 p11 p12 p13
p14 p15 p16 p17 p18 p19 p20 p21 >
So after 627 seconds, a bit hard for users to wait this long for their
root filesystem.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org
From: Ulf Hansson @ 2016-10-18 7:17 UTC (permalink / raw)
To: Shawn Lin
Cc: linux-mmc, linux-kernel@vger.kernel.org, Jaehoon Chung,
Adrian Hunter
In-Reply-To: <e4cfb009-07a3-972c-d93c-d777c5da3899@rock-chips.com>
On 18 October 2016 at 05:19, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> Hi Ulf,
>
> On 2016/10/17 20:54, Ulf Hansson wrote:
>>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> MAINTAINERS | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a009e00..e685724 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8164,7 +8164,7 @@ F: include/linux/mfd/
>> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
>> M: Ulf Hansson <ulf.hansson@linaro.org>
>> L: linux-mmc@vger.kernel.org
>> -T: git git://git.linaro.org/people/ulf.hansson/mmc.git
>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
>
>
> I cannot clone this tree, and I have tried some of my servers, although.
>
> remote: Total 5031043 (delta 4225582), reused 5030965 (delta 4225531)
> Resolving deltas: 100% (4225582/4225582), done.
> Checking connectivity... done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
The reason for the error message was the default HEAD pointed to a
non-existent "master" branch.
As I can't change the default HEAD (because kernel.org's gitolite
server configurations don't allow it), I decided to publish a master
branch. That should resolve the problem, sorry for inconvenience!
BTW. In case your aren't familiar with using remote branches in git;
those are really convenient as you don't need to do a complete new
clone.
git remote add mmc http://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
git remote update
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org
From: Jaehoon Chung @ 2016-10-18 4:11 UTC (permalink / raw)
To: Shawn Lin, Ulf Hansson, linux-mmc; +Cc: linux-kernel, Adrian Hunter
In-Reply-To: <78f0352f-70a5-a836-c8df-6c4a02182c6e@rock-chips.com>
On 10/18/2016 01:08 PM, Shawn Lin wrote:
> 在 2016/10/18 11:52, Jaehoon Chung 写道:
>> On 10/18/2016 12:19 PM, Shawn Lin wrote:
>>> Hi Ulf,
>>>
>>> On 2016/10/17 20:54, Ulf Hansson wrote:
>>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>> ---
>>>> MAINTAINERS | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index a009e00..e685724 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -8164,7 +8164,7 @@ F: include/linux/mfd/
>>>> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
>>>> M: Ulf Hansson <ulf.hansson@linaro.org>
>>>> L: linux-mmc@vger.kernel.org
>>>> -T: git git://git.linaro.org/people/ulf.hansson/mmc.git
>>>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
>>>
>>> I cannot clone this tree, and I have tried some of my servers, although.
>>>
>>> remote: Total 5031043 (delta 4225582), reused 5030965 (delta 4225531)
>>> Resolving deltas: 100% (4225582/4225582), done.
>>> Checking connectivity... done.
>>> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>>
>> you have to checkout to "next"
>
> yep, it does need to assign a HEAD blob after cloning.
> But I never did it when cloning other maintainers' tree.
Indeed.
Best Regards,
Jaehoon Chung
>
> Thanks.
>
>> e.g) git checkout next
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> ...then the clone process failed.
>>>
>>>> S: Maintained
>>>> F: Documentation/devicetree/bindings/mmc/
>>>> F: drivers/mmc/
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org
From: Shawn Lin @ 2016-10-18 4:08 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson, linux-mmc
Cc: shawn.lin, linux-kernel, Adrian Hunter
In-Reply-To: <beed04c1-ba03-445f-5394-d294a98bf45d@samsung.com>
在 2016/10/18 11:52, Jaehoon Chung 写道:
> On 10/18/2016 12:19 PM, Shawn Lin wrote:
>> Hi Ulf,
>>
>> On 2016/10/17 20:54, Ulf Hansson wrote:
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> ---
>>> MAINTAINERS | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index a009e00..e685724 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -8164,7 +8164,7 @@ F: include/linux/mfd/
>>> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
>>> M: Ulf Hansson <ulf.hansson@linaro.org>
>>> L: linux-mmc@vger.kernel.org
>>> -T: git git://git.linaro.org/people/ulf.hansson/mmc.git
>>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
>>
>> I cannot clone this tree, and I have tried some of my servers, although.
>>
>> remote: Total 5031043 (delta 4225582), reused 5030965 (delta 4225531)
>> Resolving deltas: 100% (4225582/4225582), done.
>> Checking connectivity... done.
>> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> you have to checkout to "next"
yep, it does need to assign a HEAD blob after cloning.
But I never did it when cloning other maintainers' tree.
Thanks.
> e.g) git checkout next
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ...then the clone process failed.
>>
>>> S: Maintained
>>> F: Documentation/devicetree/bindings/mmc/
>>> F: drivers/mmc/
>>>
>>
>>
>
>
>
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: Regression after "do not use CMD13 to get status after speed mode switch"
From: Ritesh Harjani @ 2016-10-18 4:06 UTC (permalink / raw)
To: Linus Walleij, linux-mmc@vger.kernel.org, Ulf Hansson,
Chaotian Jing
Cc: linux-arm-msm@vger.kernel.org, Bjorn Andersson, Stephen Boyd,
Andy Gross, Georgi Djakov
In-Reply-To: <CACRpkdbfNq+R9U9AwsKBM=xyKKTzyVDkiW4jqJ0Nb2LXvq20BA@mail.gmail.com>
Hi Linus,
Recently for the same patch below was submitted for Qcom sdhci-msm driver.
https://patchwork.kernel.org/patch/9237679/
You mentioned yours is mmci driver.
See if it provides any hints.
Regards
Ritesh
On 10/17/2016 8:02 PM, Linus Walleij wrote:
> Hi Chaotian,
>
> my Dragonboard 8060 has a regression on detecting the eMMC after
> bisecting it down to this patch (which is sadly already in v4.8):
>
> commit 08573eaf1a70104f83fdbee9b84e5be03480e9ed
> Author: Chaotian Jing <chaotian.jing@mediatek.com>
> Date: Thu May 19 16:47:41 2016 +0800
> mmc: mmc: do not use CMD13 to get status after speed mode switch
>
> Before this patch the eMMC is detected and all partitions enumerated
> immediately, but after the patch it doesn't come up at all, except
> sometimes, when it appears minutes (!) after boot, all of a sudden.
>
> Do you have any ideas on what can be wrong?
>
> This is the Qualcomm MMCI variant whid does *not* support
> busydetection in hardware.
>
> I will continue looking at it but would be happy for any hints on how to
> solve it, currently I cannot mount root off the eMMC because of this.
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org
From: Jaehoon Chung @ 2016-10-18 3:52 UTC (permalink / raw)
To: Shawn Lin, Ulf Hansson, linux-mmc; +Cc: linux-kernel, Adrian Hunter
In-Reply-To: <e4cfb009-07a3-972c-d93c-d777c5da3899@rock-chips.com>
On 10/18/2016 12:19 PM, Shawn Lin wrote:
> Hi Ulf,
>
> On 2016/10/17 20:54, Ulf Hansson wrote:
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> MAINTAINERS | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a009e00..e685724 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8164,7 +8164,7 @@ F: include/linux/mfd/
>> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
>> M: Ulf Hansson <ulf.hansson@linaro.org>
>> L: linux-mmc@vger.kernel.org
>> -T: git git://git.linaro.org/people/ulf.hansson/mmc.git
>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
>
> I cannot clone this tree, and I have tried some of my servers, although.
>
> remote: Total 5031043 (delta 4225582), reused 5030965 (delta 4225531)
> Resolving deltas: 100% (4225582/4225582), done.
> Checking connectivity... done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
you have to checkout to "next"
e.g) git checkout next
Best Regards,
Jaehoon Chung
>
> ...then the clone process failed.
>
>> S: Maintained
>> F: Documentation/devicetree/bindings/mmc/
>> F: drivers/mmc/
>>
>
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org
From: Shawn Lin @ 2016-10-18 3:19 UTC (permalink / raw)
To: Ulf Hansson, linux-mmc
Cc: shawn.lin, linux-kernel, Jaehoon Chung, Adrian Hunter
In-Reply-To: <1476708880-5333-1-git-send-email-ulf.hansson@linaro.org>
Hi Ulf,
On 2016/10/17 20:54, Ulf Hansson wrote:
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a009e00..e685724 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8164,7 +8164,7 @@ F: include/linux/mfd/
> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
> M: Ulf Hansson <ulf.hansson@linaro.org>
> L: linux-mmc@vger.kernel.org
> -T: git git://git.linaro.org/people/ulf.hansson/mmc.git
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
I cannot clone this tree, and I have tried some of my servers, although.
remote: Total 5031043 (delta 4225582), reused 5030965 (delta 4225531)
Resolving deltas: 100% (4225582/4225582), done.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
...then the clone process failed.
> S: Maintained
> F: Documentation/devicetree/bindings/mmc/
> F: drivers/mmc/
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH v2 0/9] Init runtime PM support for dw_mmc
From: Shawn Lin @ 2016-10-18 1:04 UTC (permalink / raw)
To: Jaehoon Chung, Ulf Hansson
Cc: shawn.lin, linux-mmc, Doug Anderson, linux-rockchip
In-Reply-To: <488999ee-acf5-47bd-3ebd-707899224749@samsung.com>
Hi Jaehoon,
On 2016/10/18 8:24, Jaehoon Chung wrote:
> Hi Shawn,
>
> On 10/12/2016 11:50 AM, Shawn Lin wrote:
>> Hi Jaehoon and Ulf,
>>
>> This patch is gonna support runtime PM for dw_mmc.
>> It could support to disable ciu_clk by default and disable
>> biu_clk if the devices are non-removeable, or removeable
>> with gpio-base card detect.
>>
>> Then I remove the system PM since the runtime PM actually
>> does the same thing as it. So I help migrate the dw_mmc variant
>> drivers to use runtime PM pairs and pm_runtime_force_*. Note
>> that I only enable runtime PM for dw_mmc-rockchip as I will
>> leave the decision to the owners of the corresponding drivers.
>> I just tested it on my RK3288 platform with linux-next to make
>> the runtime PM and system PM work fine for my emmc, sd card and
>> sdio. But I don't have hardware to help test other variant drivers.
>> But in theory it should work fine as I mentioned that the runtime
>> PM does the same thing as system PM except for disabling ciu_clk
>> aggressively which should not be related to the variant hosts.
>>
>> As you could see that I just extend the slot-gpio a bit, so the
>> ideal way is Ulf could pick them up with Jaehoon's ack. :)
>
> I have tested with my boards..it's working fine..I will apply on this if there is no special issue.
Great to hear this. The test for this patchset have been running for a
while on my rk3288/3368 boards and it seems no failures were found
until now.
Thanks!
>
> Thanks!
>
> Best Regards,
> Jaehoon Chung
>
>>
>>
>> Changes in v2:
>> - use struct device as argument for runtime callback
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>> - minor fix since I change the argument for dw_mci_runtime_*
>> - use dw_mci_runtime_* directly
>> - use dw_mci_runtime_* directly
>>
>> Shawn Lin (9):
>> mmc: dw_mmc: add runtime PM callback
>> mmc: dw_mmc-rockchip: add runtime PM support
>> mmc: core: expose the capability of gpio card detect
>> mmc: dw_mmc: disable biu clk if possible
>> mmc: dw_mmc-k3: deploy runtime PM facilities
>> mmc: dw_mmc-exynos: deploy runtime PM facilities
>> mmc: dw_mmc-pci: deploy runtime PM facilities
>> mmc: dw_mmc-pltfm: deploy runtime PM facilities
>> mmc: dw_mmc: remove system PM callback
>>
>> drivers/mmc/core/slot-gpio.c | 8 +++++++
>> drivers/mmc/host/dw_mmc-exynos.c | 24 +++++++++-----------
>> drivers/mmc/host/dw_mmc-k3.c | 39 ++++++++------------------------
>> drivers/mmc/host/dw_mmc-pci.c | 29 ++++++++----------------
>> drivers/mmc/host/dw_mmc-pltfm.c | 28 +++++++----------------
>> drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
>> drivers/mmc/host/dw_mmc.c | 46 +++++++++++++++++++++++++-------------
>> drivers/mmc/host/dw_mmc.h | 6 ++---
>> include/linux/mmc/slot-gpio.h | 1 +
>> 9 files changed, 117 insertions(+), 106 deletions(-)
>>
>
>
>
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH v2 0/9] Init runtime PM support for dw_mmc
From: Jaehoon Chung @ 2016-10-18 0:24 UTC (permalink / raw)
To: Shawn Lin, Ulf Hansson; +Cc: linux-mmc, Doug Anderson, linux-rockchip
In-Reply-To: <1476240643-5701-1-git-send-email-shawn.lin@rock-chips.com>
Hi Shawn,
On 10/12/2016 11:50 AM, Shawn Lin wrote:
> Hi Jaehoon and Ulf,
>
> This patch is gonna support runtime PM for dw_mmc.
> It could support to disable ciu_clk by default and disable
> biu_clk if the devices are non-removeable, or removeable
> with gpio-base card detect.
>
> Then I remove the system PM since the runtime PM actually
> does the same thing as it. So I help migrate the dw_mmc variant
> drivers to use runtime PM pairs and pm_runtime_force_*. Note
> that I only enable runtime PM for dw_mmc-rockchip as I will
> leave the decision to the owners of the corresponding drivers.
> I just tested it on my RK3288 platform with linux-next to make
> the runtime PM and system PM work fine for my emmc, sd card and
> sdio. But I don't have hardware to help test other variant drivers.
> But in theory it should work fine as I mentioned that the runtime
> PM does the same thing as system PM except for disabling ciu_clk
> aggressively which should not be related to the variant hosts.
>
> As you could see that I just extend the slot-gpio a bit, so the
> ideal way is Ulf could pick them up with Jaehoon's ack. :)
I have tested with my boards..it's working fine..I will apply on this if there is no special issue.
Thanks!
Best Regards,
Jaehoon Chung
>
>
> Changes in v2:
> - use struct device as argument for runtime callback
> - use dw_mci_runtime_* directly
> - use dw_mci_runtime_* directly
> - minor fix since I change the argument for dw_mci_runtime_*
> - use dw_mci_runtime_* directly
> - use dw_mci_runtime_* directly
>
> Shawn Lin (9):
> mmc: dw_mmc: add runtime PM callback
> mmc: dw_mmc-rockchip: add runtime PM support
> mmc: core: expose the capability of gpio card detect
> mmc: dw_mmc: disable biu clk if possible
> mmc: dw_mmc-k3: deploy runtime PM facilities
> mmc: dw_mmc-exynos: deploy runtime PM facilities
> mmc: dw_mmc-pci: deploy runtime PM facilities
> mmc: dw_mmc-pltfm: deploy runtime PM facilities
> mmc: dw_mmc: remove system PM callback
>
> drivers/mmc/core/slot-gpio.c | 8 +++++++
> drivers/mmc/host/dw_mmc-exynos.c | 24 +++++++++-----------
> drivers/mmc/host/dw_mmc-k3.c | 39 ++++++++------------------------
> drivers/mmc/host/dw_mmc-pci.c | 29 ++++++++----------------
> drivers/mmc/host/dw_mmc-pltfm.c | 28 +++++++----------------
> drivers/mmc/host/dw_mmc-rockchip.c | 42 +++++++++++++++++++++++++++++++---
> drivers/mmc/host/dw_mmc.c | 46 +++++++++++++++++++++++++-------------
> drivers/mmc/host/dw_mmc.h | 6 ++---
> include/linux/mmc/slot-gpio.h | 1 +
> 9 files changed, 117 insertions(+), 106 deletions(-)
>
^ permalink raw reply
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed
From: Zach Brown @ 2016-10-17 21:49 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Adrian Hunter, Mark Rutland, linux-mmc,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAPDyKFqw7mcvW=HTnZ9AoDFEk4TTBsecphaYxMGrEneDoKOevw@mail.gmail.com>
On Thu, Oct 06, 2016 at 10:03:56AM +0200, Ulf Hansson wrote:
> On 5 October 2016 at 22:03, Rob Herring <robh+dt@kernel.org> wrote:
> > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote:
> >>> Certain board configurations can make highspeed malfunction due to
> >>> timing issues. In these cases a way is needed to force the controller
> >>> and card into standard speed even if they otherwise appear to be capable
> >>> of highspeed.
> >>>
> >>> The sd-broken-highspeed property will let the sdhci driver know that
> >>> highspeed will not work.
> >>>
> >>> Signed-off-by: Zach Brown <zach.brown@ni.com>
> >>> ---
> >>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> >>> index 8a37782..59332ea 100644
> >>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> >>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> >>> @@ -52,6 +52,8 @@ Optional properties:
> >>> - no-sdio: controller is limited to send sdio cmd during initialization
> >>> - no-sd: controller is limited to send sd cmd during initialization
> >>> - no-mmc: controller is limited to send mmc cmd during initialization
> >>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card
> >>> + themselves claim they support highspeed.
> >>
> >> Regarding a broken card, that is managed via the card quirks and not in DT.
> >>
> >> If this is about a controller limitation, we already have the option
> >> to describe what it supports, so we don't need an option to tell what
> >> it *not* supports.
> >>
> >> For example "cap-sd-highspeed" tells whether the controller supports
> >> SD high-speed, please use that instead.
> >
> > If a controller has a capability register and it lies (perhaps the
> > board has limitations that the SoC does not), then you may need to
> > disable a feature.
>
> I understand, although the SDHCI capabilities register is broken for
> most SDHCI variants. In principle, we would more or less have to add a
> *-broken binding for each bit in that register. I don't like that!
>
> Maybe a better option is to add a "sdhci-cap-broken" or perhaps
> "sdhci-cap-speed-modes-broken", which tells the driver to not rely on
> the capabilities register and instead find out what *is* supported by
> looking at the other mmc generic DT bindings.
>
> What do you think of that?
>
> Kind regards
> Uffe
"sdhci-cap-broken" seems too aggressive. There might only be one capability
that the register incorrectly advertises.
"sdhci-cap-speed-modes-broken" makes more sense and I will re-create this patch
set using that idea.
^ permalink raw reply
* Re: linux-next: Moving mmc tree to kernel.org
From: Stephen Rothwell @ 2016-10-17 22:09 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-kernel@vger.kernel.org, linux-mmc, Adrian Hunter,
Jaehoon Chung
In-Reply-To: <CAPDyKFqCvZKzr5fnnKgxc1=3iU+BhhkDkHFv_a01bdxWyAnrHg@mail.gmail.com>
Hi Ulf,
On Mon, 17 Oct 2016 14:51:45 +0200 Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> I have moved my mmc tree from linaro.org to kernel.org and I would
> appreciate if you could switch to pull my next branch for linux-next
> from there instead.
>
> Old tree:
> git://git.linaro.org/people/ulf.hansson/mmc.git next
>
> New tree
> git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
Moved from today, thanks. I also renamed the tree from mmc-uh to just
plain mmc.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH v2] mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error
From: Haibo Chen @ 2016-10-17 8:18 UTC (permalink / raw)
To: adrian.hunter, ulf.hansson, rmk+kernel; +Cc: stable, linux-mmc, haibo.chen
Potentially overflowing expression 1000000 * data->timeout_clks with
type unsigned int is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type unsigned long long.
To avoid overflow, cast 1000000U to type unsigned long long.
Special thanks to Coverity.
Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Cc: stable@vger.kernel.org # v3.15+
---
drivers/mmc/host/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 223a91e..71654b9 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -687,7 +687,7 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
* host->clock is in Hz. target_timeout is in us.
* Hence, us = 1000000 * cycles / Hz. Round up.
*/
- val = 1000000 * data->timeout_clks;
+ val = 1000000ULL * data->timeout_clks;
if (do_div(val, host->clock))
target_timeout++;
target_timeout += val;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues
From: Alan Stern @ 2016-10-17 16:34 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ritesh Raj Sarraf, Oliver Neukum, USB list, Roger Tseng, Wei WANG
In-Reply-To: <CAPDyKFpzq2wRfh_5x119ouP-e8EAaibsSvM36msxm7oepxRoDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 17 Oct 2016, Ulf Hansson wrote:
> On 13 October 2016 at 13:37, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing
> > an rtsx_usb device (managed by an mfd driver) while communicating with the
> > cards. The mmc/sd and memstick devices are children of the usb device.
> >
> > Issues has been reported [1] for rtsx, which have been investigated, discussed,
> > fixed, tested, etc, particularly when using mmc/sd cards. During the
> > investigation, some changes was proposed and tested successfully. In this
> > series I have picked up these changes and created some proper patches with
> > change-logs.
> >
> > It turned out that most of the problems was related to the runtime PM
> > deployment in the memstick and the mmc/sd driver, which are fixed in this
> > series.
> >
> > A couple of more issues were also discussed [2], which needs to be fixed as
> > well. Although they are out of scope for this series, so we will have to look
> > into those at a later point. Here's a brief summary of these leftovers:
> >
> > *)
> > It seems reasonable to turn off autosuspend for usb devices and instead rely on
> > the usb device's children to deal with autosuspend. The reason is simply that
> > the children has better knowledge of when using autosuspend makes sense.
> >
> > **)
> > Polling card detect mode is used both for mmc/sd and memstick. Because of the
> > lack of synchronization between the polling attempts for these subsystems, the
> > usb device may be powered on for unnecessary long intervals, thus we are
> > wasting power.
> >
> > Besides the above changes, I folded in a change in the mmc core which improves
> > the behaviour for mmc hosts using MMC_CAP2_NO_PRESCAN_POWERUP, which is the
> > case for the rtsx_usb_sdmmc driver. This change should improve the boot time
> > with ~100ms per rtsx_usb_sdmmc device.
> >
> > Finally, as I couldn't find an active maintainer for the memstick
> > subsystem/driver and because the author of the drivers can be reached, I
> > volunteer to take this all through my mmc tree. Please tell me if that is
> > problem to any of you.
> >
> > [1]
> > https://www.spinics.net/lists/linux-usb/msg146998.html
> > [2]
> > https://www.spinics.net/lists/linux-mmc/msg39235.html
> >
> >
> > Alan Stern (1):
> > memstick: rtsx_usb_ms: Runtime resume the device when polling for
> > cards
> >
> > Ulf Hansson (5):
> > mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when
> > unused
> > mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
> > memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
> > mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend
> > mmc: core: Don't power off the card when starting the host
> >
> > drivers/memstick/host/rtsx_usb_ms.c | 6 ++++++
> > drivers/mmc/core/core.c | 9 ++++-----
> > drivers/mmc/host/rtsx_usb_sdmmc.c | 10 +++++-----
> > 3 files changed, 15 insertions(+), 10 deletions(-)
> >
> > --
> > 1.9.1
> >
>
> Patch 1->4 applied for fixes. Holding patch 5->6 for a while, as they
> are intended for next!
Thanks for taking care of all these updates.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci-of-at91: Fix module autoload
From: Javier Martinez Canillas @ 2016-10-17 16:13 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Ludovic Desroches, linux-mmc,
Adrian Hunter, Ulf Hansson
In-Reply-To: <1476720825-30442-1-git-send-email-javier@osg.samsung.com>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/mmc/host/sdhci-of-at91.ko | grep alias
$
After this patch:
$ modinfo drivers/mmc/host/sdhci-of-at91.ko | grep alias
alias: of:N*T*Catmel,sama5d2-sdhciC*
alias: of:N*T*Catmel,sama5d2-sdhci
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/mmc/host/sdhci-of-at91.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
index a9b7fc06c434..2f9ad213377a 100644
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -100,6 +100,7 @@ static const struct of_device_id sdhci_at91_dt_match[] = {
{ .compatible = "atmel,sama5d2-sdhci", .data = &soc_data_sama5d2 },
{}
};
+MODULE_DEVICE_TABLE(of, sdhci_at91_dt_match);
#ifdef CONFIG_PM
static int sdhci_at91_runtime_suspend(struct device *dev)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] mmc: mediatek: Fix module autoload
From: Javier Martinez Canillas @ 2016-10-17 16:13 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, linux-mmc, Geert Uytterhoeven,
Douglas Anderson, linux-mediatek, linux-arm-kernel, Chaotian Jing,
Nicolas Boichat, Matthias Brugger, Ulf Hansson
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/mmc/host/mtk-sd.ko | grep alias
$
After this patch:
$ modinfo drivers/mmc/host/mtk-sd.ko | grep alias
alias: of:N*T*Cmediatek,mt8135-mmcC*
alias: of:N*T*Cmediatek,mt8135-mmc
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/mmc/host/mtk-sd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 84e9afcb5c09..86af0b199a54 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1713,6 +1713,7 @@ static const struct of_device_id msdc_of_ids[] = {
{ .compatible = "mediatek,mt8135-mmc", },
{}
};
+MODULE_DEVICE_TABLE(of, msdc_of_ids);
static struct platform_driver mt_msdc_driver = {
.probe = msdc_drv_probe,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port
From: Wolfram Sang @ 2016-10-17 15:15 UTC (permalink / raw)
To: Ulf Hansson
Cc: Chris Brandt, Lee Jones, Wolfram Sang, Sergei Shtylyov,
Geert Uytterhoeven, Simon Horman, linux-mmc, Linux-Renesas
In-Reply-To: <CAPDyKFrXYQPEfh8YMAFb4+0dr=WMyo8D-VCjd9KY5hpPxTv7PQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
> > Is this still waiting on an ACK from Lee Jones because it touches the tmio.h file under include/linux/mfd/ ?
> >
>
> Yes, but more important is Wolfram's ack as he maintains
> drivers/mmc/host/tmio_mmc*
Sorry, LinuxCon and ELC Europe kept me very busy. Will do this week.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Regression after "do not use CMD13 to get status after speed mode switch"
From: Linus Walleij @ 2016-10-17 14:32 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org, Ulf Hansson, Chaotian Jing
Cc: linux-arm-msm@vger.kernel.org, Bjorn Andersson, Stephen Boyd,
Andy Gross
Hi Chaotian,
my Dragonboard 8060 has a regression on detecting the eMMC after
bisecting it down to this patch (which is sadly already in v4.8):
commit 08573eaf1a70104f83fdbee9b84e5be03480e9ed
Author: Chaotian Jing <chaotian.jing@mediatek.com>
Date: Thu May 19 16:47:41 2016 +0800
mmc: mmc: do not use CMD13 to get status after speed mode switch
Before this patch the eMMC is detected and all partitions enumerated
immediately, but after the patch it doesn't come up at all, except
sometimes, when it appears minutes (!) after boot, all of a sudden.
Do you have any ideas on what can be wrong?
This is the Qualcomm MMCI variant whid does *not* support
busydetection in hardware.
I will continue looking at it but would be happy for any hints on how to
solve it, currently I cannot mount root off the eMMC because of this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues
From: Ulf Hansson @ 2016-10-17 13:49 UTC (permalink / raw)
To: linux-mmc, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ulf Hansson
Cc: Ritesh Raj Sarraf, Alan Stern, Oliver Neukum, USB list,
Roger Tseng, Wei WANG
In-Reply-To: <1476358660-8338-1-git-send-email-ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 13 October 2016 at 13:37, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing
> an rtsx_usb device (managed by an mfd driver) while communicating with the
> cards. The mmc/sd and memstick devices are children of the usb device.
>
> Issues has been reported [1] for rtsx, which have been investigated, discussed,
> fixed, tested, etc, particularly when using mmc/sd cards. During the
> investigation, some changes was proposed and tested successfully. In this
> series I have picked up these changes and created some proper patches with
> change-logs.
>
> It turned out that most of the problems was related to the runtime PM
> deployment in the memstick and the mmc/sd driver, which are fixed in this
> series.
>
> A couple of more issues were also discussed [2], which needs to be fixed as
> well. Although they are out of scope for this series, so we will have to look
> into those at a later point. Here's a brief summary of these leftovers:
>
> *)
> It seems reasonable to turn off autosuspend for usb devices and instead rely on
> the usb device's children to deal with autosuspend. The reason is simply that
> the children has better knowledge of when using autosuspend makes sense.
>
> **)
> Polling card detect mode is used both for mmc/sd and memstick. Because of the
> lack of synchronization between the polling attempts for these subsystems, the
> usb device may be powered on for unnecessary long intervals, thus we are
> wasting power.
>
> Besides the above changes, I folded in a change in the mmc core which improves
> the behaviour for mmc hosts using MMC_CAP2_NO_PRESCAN_POWERUP, which is the
> case for the rtsx_usb_sdmmc driver. This change should improve the boot time
> with ~100ms per rtsx_usb_sdmmc device.
>
> Finally, as I couldn't find an active maintainer for the memstick
> subsystem/driver and because the author of the drivers can be reached, I
> volunteer to take this all through my mmc tree. Please tell me if that is
> problem to any of you.
>
> [1]
> https://www.spinics.net/lists/linux-usb/msg146998.html
> [2]
> https://www.spinics.net/lists/linux-mmc/msg39235.html
>
>
> Alan Stern (1):
> memstick: rtsx_usb_ms: Runtime resume the device when polling for
> cards
>
> Ulf Hansson (5):
> mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when
> unused
> mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
> memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
> mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend
> mmc: core: Don't power off the card when starting the host
>
> drivers/memstick/host/rtsx_usb_ms.c | 6 ++++++
> drivers/mmc/core/core.c | 9 ++++-----
> drivers/mmc/host/rtsx_usb_sdmmc.c | 10 +++++-----
> 3 files changed, 15 insertions(+), 10 deletions(-)
>
> --
> 1.9.1
>
Patch 1->4 applied for fixes. Holding patch 5->6 for a while, as they
are intended for next!
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mmc: sdhci: put together into one condition checking
From: Ulf Hansson @ 2016-10-17 13:49 UTC (permalink / raw)
To: Jaehoon Chung; +Cc: linux-mmc, Adrian Hunter
In-Reply-To: <1475816923-24532-1-git-send-email-jh80.chung@samsung.com>
On 7 October 2016 at 07:08, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> value of ios->timing is not related with SDCHI v3.0.
> If Controller version is v3.0, SDHCI_QUIRK_NO_HISPD_BIT is meaningless.
> To prevent the setting wrong bit moves into one codntion checking.
> (e.g sdhci-s3c doesn't use SDHCI_CTRL_HISPD bit, instead using this bit as
> other purpose.)
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 4805566..f854c66 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1619,7 +1619,14 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
>
> if ((ios->timing == MMC_TIMING_SD_HS ||
> - ios->timing == MMC_TIMING_MMC_HS)
> + ios->timing == MMC_TIMING_MMC_HS ||
> + ios->timing == MMC_TIMING_MMC_HS400 ||
> + ios->timing == MMC_TIMING_MMC_HS200 ||
> + ios->timing == MMC_TIMING_MMC_DDR52 ||
> + ios->timing == MMC_TIMING_UHS_SDR50 ||
> + ios->timing == MMC_TIMING_UHS_SDR104 ||
> + ios->timing == MMC_TIMING_UHS_DDR50 ||
> + ios->timing == MMC_TIMING_UHS_SDR25)
> && !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> ctrl |= SDHCI_CTRL_HISPD;
> else
> @@ -1628,16 +1635,6 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> if (host->version >= SDHCI_SPEC_300) {
> u16 clk, ctrl_2;
>
> - /* In case of UHS-I modes, set High Speed Enable */
> - if ((ios->timing == MMC_TIMING_MMC_HS400) ||
> - (ios->timing == MMC_TIMING_MMC_HS200) ||
> - (ios->timing == MMC_TIMING_MMC_DDR52) ||
> - (ios->timing == MMC_TIMING_UHS_SDR50) ||
> - (ios->timing == MMC_TIMING_UHS_SDR104) ||
> - (ios->timing == MMC_TIMING_UHS_DDR50) ||
> - (ios->timing == MMC_TIMING_UHS_SDR25))
> - ctrl |= SDHCI_CTRL_HISPD;
> -
> if (!host->preset_enabled) {
> sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> /*
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 0/2] mmc: sdhci-iproc: Add byte register access support
From: Ulf Hansson @ 2016-10-17 13:49 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1476297352-7812-1-git-send-email-scott.branden@broadcom.com>
On 12 October 2016 at 20:35, Scott Branden <scott.branden@broadcom.com> wrote:
> Add brcm,sdhci-iproc compat string and code for support of newer versions of
> sdhci-iproc controller that allow byte-wise register accesses.
>
> Scott Branden (2):
> mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
> document
> mmc: sdhci-iproc: support standard byte register accesses
>
> .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 1 +
> drivers/mmc/host/sdhci-iproc.c | 35 ++++++++++++++++++++--
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>
Thanks, applied for next!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2] mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error
From: Ulf Hansson @ 2016-10-17 13:49 UTC (permalink / raw)
To: Haibo Chen; +Cc: Adrian Hunter, Russell King, # 4.0+, linux-mmc
In-Reply-To: <1476692317-26845-1-git-send-email-haibo.chen@nxp.com>
On 17 October 2016 at 10:18, Haibo Chen <haibo.chen@nxp.com> wrote:
> Potentially overflowing expression 1000000 * data->timeout_clks with
> type unsigned int is evaluated using 32-bit arithmetic, and then used
> in a context that expects an expression of type unsigned long long.
>
> To avoid overflow, cast 1000000U to type unsigned long long.
> Special thanks to Coverity.
>
> Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
> Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
> Cc: stable@vger.kernel.org # v3.15+
Thanks, applied for fixes!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 223a91e..71654b9 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -687,7 +687,7 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
> * host->clock is in Hz. target_timeout is in us.
> * Hence, us = 1000000 * cycles / Hz. Round up.
> */
> - val = 1000000 * data->timeout_clks;
> + val = 1000000ULL * data->timeout_clks;
> if (do_div(val, host->clock))
> target_timeout++;
> target_timeout += val;
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port
From: Ulf Hansson @ 2016-10-17 13:36 UTC (permalink / raw)
To: Chris Brandt
Cc: Lee Jones, Wolfram Sang, Sergei Shtylyov, Geert Uytterhoeven,
Simon Horman, linux-mmc, Linux-Renesas
In-Reply-To: <SG2PR06MB11656EAD9F036EC0FFEDFF7F8ADF0@SG2PR06MB1165.apcprd06.prod.outlook.com>
On 14 October 2016 at 15:18, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On 9/22/2016, Ulf Hansson wrote:
>> To: Chris Brandt <Chris.Brandt@renesas.com>
>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>; Sergei Shtylyov
>> <sergei.shtylyov@cogentembedded.com>; Geert Uytterhoeven <geert@linux-
>> m68k.org>; Simon Horman <horms+renesas@verge.net.au>; linux-mmc <linux-
>> mmc@vger.kernel.org>; Linux-Renesas <linux-renesas-soc@vger.kernel.org>;
>> Lee Jones <lee@kernel.org>
>> Subject: Re: [PATCH v3 2/3] mmc: tmio-mmc: add support for 32bit data port
>>
>> + Lee
>>
>> On 12 September 2016 at 16:15, Chris Brandt <chris.brandt@renesas.com>
>> wrote:
>> > For the r7s72100 SOC, the DATA_PORT register was changed to 32-bits wide.
>> > Therefore a new flag has been created that will allow 32-bit
>> > reads/writes to the DATA_PORT register instead of 16-bit (because
>> > 16-bits accesses are not supported).
>> >
>> > Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
>> > ---
>> > v3:
>> > * changed loops to memcpy
>> > v2:
>> > * changed 'data * 0xFF' to 'data & 0xFF'
>> > * added 'const' for sd_ctrl_write32_rep
>> > ---
>> > drivers/mmc/host/tmio_mmc.h | 12 ++++++++++++
>> > drivers/mmc/host/tmio_mmc_pio.c | 30 ++++++++++++++++++++++++++++++
>> > include/linux/mfd/tmio.h | 5 +++++
>>
>> This header file needs to be split up. The mmc specific bits, should be
>> moved to a local header file under driver/mmc/host/*.
>>
>> Sure, we don't need to do that as part of $subject patch, but then I need
>> an ack from Lee Jones, the mfd maintainer. I have added him on cc.
>
>
> Is this still waiting on an ACK from Lee Jones because it touches the tmio.h file under include/linux/mfd/ ?
>
Yes, but more important is Wolfram's ack as he maintains
drivers/mmc/host/tmio_mmc*
Kind regards
Uffe
^ permalink raw reply
* [PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org
From: Ulf Hansson @ 2016-10-17 12:54 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson; +Cc: linux-kernel, Jaehoon Chung, Adrian Hunter
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a009e00..e685724 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8164,7 +8164,7 @@ F: include/linux/mfd/
MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
M: Ulf Hansson <ulf.hansson@linaro.org>
L: linux-mmc@vger.kernel.org
-T: git git://git.linaro.org/people/ulf.hansson/mmc.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
S: Maintained
F: Documentation/devicetree/bindings/mmc/
F: drivers/mmc/
--
1.9.1
^ permalink raw reply related
* linux-next: Moving mmc tree to kernel.org
From: Ulf Hansson @ 2016-10-17 12:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel@vger.kernel.org, linux-mmc, Adrian Hunter,
Jaehoon Chung
Hi Stephen,
I have moved my mmc tree from linaro.org to kernel.org and I would
appreciate if you could switch to pull my next branch for linux-next
from there instead.
Old tree:
git://git.linaro.org/people/ulf.hansson/mmc.git next
New tree
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Adrian Hunter @ 2016-10-17 8:14 UTC (permalink / raw)
To: Ziji Hu, Gregory CLEMENT, Ulf Hansson, linux-mmc
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree, Thomas Petazzoni, linux-arm-kernel, Jack(SH) Zhu,
Jimmy Xu, Jisheng Zhang, Nadav Haklai, Ryan Gao, Doug Jones,
Shiwu Zhang, Victor Gu, Wei(SOCP) Liu, Wilson Ding, Xueping Liu,
Hilbert Zhang, Liuliu Zhao, Peng Zhu, Yu Cao
In-Reply-To: <6bed26dc-f4c1-7f0d-36b6-d7d5fcbf0da9@marvell.com>
On 13/10/16 08:38, Ziji Hu wrote:
> Hi Adrian,
>
> On 2016/10/12 21:07, Adrian Hunter wrote:
>> On 12/10/16 14:58, Ziji Hu wrote:
>>> Hi Adrian,
>>>
>>> Thank you very much for your review.
>>> I will firstly fix the typo.
>>>
>>> On 2016/10/11 20:37, Adrian Hunter wrote:
> <snip>
>>>>> +
>>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>>> + struct mmc_ios *ios)
>>>>> +{
>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>> +
>>>>> + /*
>>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>>> + * clock in mmc_set_signal_voltage().
>>>>> + * If Internal clock is disabled, the 3.3V/1.8V bit can not be updated.
>>>>> + * Thus here manually enable internal clock.
>>>>> + *
>>>>> + * After switch completes, it is unnecessary to disable internal clock,
>>>>> + * since keeping internal clock active obeys SD spec.
>>>>> + */
>>>>> + enable_xenon_internal_clk(host);
>>>>> +
>>>>> + if (priv->card_candidate) {
>>>>
>>>> mmc_power_up() calls __mmc_set_signal_voltage() calls
>>>> host->ops->start_signal_voltage_switch so priv->card_candidate could be an
>>>> invalid reference to an old card.
>>>>
>>>> So that's not going to work if the card changes - not only for removable
>>>> cards but even for eMMC if init fails and retries.
>>>>
>>> As you point out, this piece of code have defects, even though it actually works on Marvell multiple platforms, unless eMMC card is removable.
>>>
>>> I can add a property to explicitly indicate eMMC type in DTS.
>>> Then card_candidate access can be removed here.
>>> Does it sounds more reasonable to you?
>>
>> Sure
>>
>>>
>>>>> + if (mmc_card_mmc(priv->card_candidate))
>>>>> + return xenon_emmc_signal_voltage_switch(mmc, ios);
>>>>
>>>> So if all you need to know is whether it is a eMMC, why can't DT tell you?
>>>>
>>> I can add an eMMC type property in DTS, to remove the card_candidate access here.
>>>
>>>>> + }
>>>>> +
>>>>> + return sdhci_start_signal_voltage_switch(mmc, ios);
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * After determining which slot is used for SDIO,
>>>>> + * some additional task is required.
>>>>> + */
>>>>> +static void xenon_init_card(struct mmc_host *mmc, struct mmc_card *card)
>>>>> +{
>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>> + u32 reg;
>>>>> + u8 slot_idx;
>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>> +
>>>>> + /* Link the card for delay adjustment */
>>>>> + priv->card_candidate = card;
>>>>
>>>> You really need a better way to get the card. I suggest you take up the
>>>> issue with Ulf. One possibility is to have mmc core set host->card = card
>>>> much earlier.
>>>>
>>> Could you please tell me if any issue related to card_candidate still exists, after the card_candidate is removed from xenon_start_signal_voltage_switch() in above?
>>> It seems that when init_card is called, the structure card has already been updated and stable in MMC/SD/SDIO initialization sequence.
>>> May I keep it here?
>>
>> It works by accident rather than by design. We can do better.
>>
> Could you please tell me some details which are satisfied about card_candidate?
>
> I must admit that card_candidate in xenon_start_signal_voltage_switch() is imperfect.
> But card_candidate in init_card() and later in set_ios() work by design, rather than by accident. We did a lot of tests on several platforms.
>
> The structure mmc_card passed in here is a stable one. Thus in my very own opinion, it is safe and stable to use mmc_card here.
> card_candidate is used only in card initialization. It is not active in later transfers after initialization is done.
> It will always updated with mmc_card in next card initialization.
Ok, so maybe just add some comments and more explanation of how it works.
>
>>>
>>>>> + /* Set tuning functionality of this slot */
>>>>> + xenon_slot_tuning_setup(host);
>>>>> +
>>>>> + slot_idx = priv->slot_idx;
>>>>> + if (!mmc_card_sdio(card)) {
>>>>> + /* Re-enable the Auto-CMD12 cap flag. */
>>>>> + host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>> + host->flags |= SDHCI_AUTO_CMD12;
>>>>> +
>>>>> + /* Clear SDIO Card Inserted indication */
>>>>> + reg = sdhci_readl(host, SDHC_SYS_CFG_INFO);
>>>>> + reg &= ~(1 << (slot_idx + SLOT_TYPE_SDIO_SHIFT));
>>>>> + sdhci_writel(host, reg, SDHC_SYS_CFG_INFO);
>>>>> +
>>>>> + if (mmc_card_mmc(card)) {
>>>>> + mmc->caps |= MMC_CAP_NONREMOVABLE;
>>>>> + if (!(host->quirks2 & SDHCI_QUIRK2_NO_1_8_V))
>>>>> + mmc->caps |= MMC_CAP_1_8V_DDR;
>>>>> + /*
>>>>> + * Force to clear BUS_TEST to
>>>>> + * skip bus_test_pre and bus_test_post
>>>>> + */
>>>>> + mmc->caps &= ~MMC_CAP_BUS_WIDTH_TEST;
>>>>> + mmc->caps2 |= MMC_CAP2_HC_ERASE_SZ |
>>>>> + MMC_CAP2_PACKED_CMD;
>>>>> + if (mmc->caps & MMC_CAP_8_BIT_DATA)
>>>>> + mmc->caps2 |= MMC_CAP2_HS400_1_8V;
>>>>> + }
>>>>> + } else {
>>>>> + /*
>>>>> + * Delete the Auto-CMD12 cap flag.
>>>>> + * Otherwise, when sending multi-block CMD53,
>>>>> + * Driver will set Transfer Mode Register to enable Auto CMD12.
>>>>> + * However, SDIO device cannot recognize CMD12.
>>>>> + * Thus SDHC will time-out for waiting for CMD12 response.
>>>>> + */
>>>>> + host->quirks &= ~SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>> + host->flags &= ~SDHCI_AUTO_CMD12;
>>>>
>>>> sdhci_set_transfer_mode() won't enable auto-CMD12 for CMD53 anyway, so is
>>>> this needed?
>>>>
>>> In Xenon driver, Auto-CMD12 flag is set to enable full support to Auto-CMD feature, both Auto-CMD12 and Auto-CMD23.
>>> As a result, when Xenon SDHC slot can both support SD and SDIO, Auto-CMD12 is disabled when SDIO card is inserted, and renabled when SD is inserted.
>>>
>>> I recheck the sdhci code to set Auto-CMD bit in Transfer Mode register, in sdhci_set_transfer_mode():
>>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1)
>>> As you can see, as long as it is CMD18/CMD25 OR there are multiple data blocks, Auto-CMD field will be set.
>>> CMD53 doesn't have CMD23. Thus Auto-CMD12 is selected since Auto-CMD12 flag is set.
>>> Thus I have to clear Auto-CMD12 to avoid issuing Auto-CMD12 in SDIO transfer.
>>
>>
>> The code is:
>>
>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1) {
>> mode = SDHCI_TRNS_BLK_CNT_EN | SDHCI_TRNS_MULTI;
>> /*
>> * If we are sending CMD23, CMD12 never gets sent
>> * on successful completion (so no Auto-CMD12).
>> */
>> if (sdhci_auto_cmd12(host, cmd->mrq) &&
>> (cmd->opcode != SD_IO_RW_EXTENDED))
>> mode |= SDHCI_TRNS_AUTO_CMD12;
>> else if (cmd->mrq->sbc && (host->flags & SDHCI_AUTO_CMD23)) {
>> mode |= SDHCI_TRNS_AUTO_CMD23;
>> sdhci_writel(host, cmd->mrq->sbc->arg, SDHCI_ARGUMENT2);
>> }
>> }
>>
>> You can see the check for SD_IO_RW_EXTENDED which is CMD53.
>>
> Sorry. I didn't notice CMD53 check was added.
> I introduced this Auto-CMD12 hack since kernel 3.8. It seems that this check is not added in kernel 3.8.
> Thanks for the information. I will remove the Auto-CMD12 hack.
>
>>>
>>> I just meet a similar issue in RPMB.
>>> When Auto-CMD12 flag is set, eMMC RPMB access will trigger Auto-CMD12, since CMD25 is in use.
>>> It will cause RPMB access failed.
>>
>> Can you explain more about the RPMB issue. Doesn't it use CMD23, so CMD12
>> wouldn't be used - auto or manually.
>>
> RPMB go through the MMC ioctl routine.
> Unlike normal data transfer, MMC ioctl for RPMB explicitly issues CMD23. When CMD25 is issued, there is neither data->sbc nor Auto-CMD23.
> As a result, sdhci driver will automatically enable Auto-CMD12 for RPMB CMD25 if Auto-CMD12 flag is set.
OK, so SDHCI should also not allow auto-cmd12 if there is no stop command
i.e. data->stop is null.
>
>>>
>>> One possible solution is to drop Auto-CMD12 support and use Auto-CMD23 only, in Xenon driver.
>>> May I know you opinion, please?
>>
>> I don't use auto-CMD12 because I don't know if it provides any benefit and
>> sdhci does not seem to have implemented Auto CMD12 Error Recovery, although
>> I have never looked at it closely.
>>
> Actually, Auto-CMD23 is always used on our Xenon. Auto-CMD12 is not used at all.
> But since this driver is a general one for all Marvell products, Auto-CMD12 is also supported in case that Auto-CMD23 is not available.
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox