Hi,
On 12-08-15 14:23, Michal Suchanek wrote:
> When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
> automatic hardware controlled clock gating on the mmc interface.
>
> Signed-off-by: Michal Suchanek <[email protected]>
In general this looks good, but I wonder how intensively this has
been tested ? Also given the long latencies when using manual
clock on/off support, have you done any testing to check what
sort of latencies this adds, e.g. Both with and without
the patch, dump all the filesystem caches:
echo 3 > /proc/sys/vm/drop_caches
And then do:
time cat /some/small/file/on/the/sdcard
Do this at least 3 time both with and without the patch, and see
if there are any noticable differences ?
Regards,
Hans
> ---
> drivers/mmc/host/sunxi-mmc.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index f808a02..443cab5 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -601,8 +601,13 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
> rval = mmc_readl(host, REG_CLKCR);
> rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
>
> - if (oclk_en)
> + if (oclk_en) {
> rval |= SDXC_CARD_CLOCK_ON;
> + if (!host->mmc->card ||
> + !(host->mmc->card->quirks & MMC_QUIRK_BROKEN_CLK_GATING))
> +
> + rval |= SDXC_LOW_POWER_ON;
> + }
>
> start = jiffies;
> end = start + msecs_to_jiffies(750);
>
On 12 August 2015 at 14:35, Hans de Goede <[email protected]> wrote:
> Hi,
>
> On 12-08-15 14:23, Michal Suchanek wrote:
>>
>> When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
>> automatic hardware controlled clock gating on the mmc interface.
>>
>> Signed-off-by: Michal Suchanek <[email protected]>
>
>
> In general this looks good, but I wonder how intensively this has
> been tested ?
Unlike the wrong timeout it does not cause the boards to crash frequently ;-)
It would be nice if somebody actively using some board atm tested this.
> Also given the long latencies when using manual
> clock on/off support, have you done any testing to check what
I suspect the long latency is due to the controller flushing data to
the card or something like that since it happens only under load.
> sort of latencies this adds, e.g. Both with and without
> the patch, dump all the filesystem caches:
>
> echo 3 > /proc/sys/vm/drop_caches
>
> And then do:
>
> time cat /some/small/file/on/the/sdcard
>
> Do this at least 3 time both with and without the patch, and see
> if there are any noticable differences ?
Yes, it would be good idea to test.
Thanks
Michal
Hey,
On 12-08-15 14:35, Hans de Goede wrote:
> Hi,
>
> On 12-08-15 14:23, Michal Suchanek wrote:
>> When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
>> automatic hardware controlled clock gating on the mmc interface.
>>
>> Signed-off-by: Michal Suchanek <[email protected]>
>
> In general this looks good, but I wonder how intensively this has
> been tested ?
It doesn't matter actually, it took some time longer, but the mmc still
craps out even with Michal's 3 patches. I'll revert hans's earlier patch
again and do a bit more extensive testing.
> Also given the long latencies when using manual
> clock on/off support, have you done any testing to check what
> sort of latencies this adds, e.g. Both with and without
> the patch, dump all the filesystem caches:
>
> echo 3 > /proc/sys/vm/drop_caches
>
> And then do:
>
> time cat /some/small/file/on/the/sdcard
>
> Do this at least 3 time both with and without the patch, and see
> if there are any noticable differences ?
>
> Regards,
>
> Hans
>
>
>
>> ---
>> drivers/mmc/host/sunxi-mmc.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index f808a02..443cab5 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -601,8 +601,13 @@ static int sunxi_mmc_oclk_onoff(struct
>> sunxi_mmc_host *host, u32 oclk_en)
>> rval = mmc_readl(host, REG_CLKCR);
>> rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
>>
>> - if (oclk_en)
>> + if (oclk_en) {
>> rval |= SDXC_CARD_CLOCK_ON;
>> + if (!host->mmc->card ||
>> + !(host->mmc->card->quirks & MMC_QUIRK_BROKEN_CLK_GATING))
>> +
>> + rval |= SDXC_LOW_POWER_ON;
>> + }
>>
>> start = jiffies;
>> end = start + msecs_to_jiffies(750);
>>
>
On 12 August 2015 at 15:19, Olliver Schinagl <[email protected]> wrote:
> Hey,
>
> On 12-08-15 14:35, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 12-08-15 14:23, Michal Suchanek wrote:
>>>
>>> When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
>>> automatic hardware controlled clock gating on the mmc interface.
>>>
>>> Signed-off-by: Michal Suchanek <[email protected]>
>>
>>
>> In general this looks good, but I wonder how intensively this has
>> been tested ?
>
> It doesn't matter actually, it took some time longer, but the mmc still
> craps out even with Michal's 3 patches. I'll revert hans's earlier patch
> again and do a bit more extensive testing.
Does the oclk switch timeout even after 750ms?
In some earlier tests I tried to enable/disable the clock repeatedly
when it failed but it seemed to have little effect on the total time
it took to disable the clock in the end.
Maybe it would be worh trying to set the timeout to some insanely long
value and test stability with that. I picked 750 as around twice the
maximum time it ever took on my board.
Thanks
Michal
The thing is, I never saw the prints in my console (i assume that it
prints on the console by default with earlyprintk/debug stuff enabled as
per sunxi-usual)?
P.S. what I do as a basic test, is on our very very minimal empty debian
image (think < 150 mb) i do a apt-get build-essential that installs
about 150mb worth of packages.
Without these patches, everything works as before. All packages
successfully installed. I can do more intense testing later, but I
figured that this is pretty intense.
Olliver
On 12-08-15 15:37, Michal Suchanek wrote:
> On 12 August 2015 at 15:19, Olliver Schinagl <[email protected]> wrote:
>> Hey,
>>
>> On 12-08-15 14:35, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 12-08-15 14:23, Michal Suchanek wrote:
>>>> When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
>>>> automatic hardware controlled clock gating on the mmc interface.
>>>>
>>>> Signed-off-by: Michal Suchanek <[email protected]>
>>>
>>> In general this looks good, but I wonder how intensively this has
>>> been tested ?
>> It doesn't matter actually, it took some time longer, but the mmc still
>> craps out even with Michal's 3 patches. I'll revert hans's earlier patch
>> again and do a bit more extensive testing.
> Does the oclk switch timeout even after 750ms?
>
> In some earlier tests I tried to enable/disable the clock repeatedly
> when it failed but it seemed to have little effect on the total time
> it took to disable the clock in the end.
>
> Maybe it would be worh trying to set the timeout to some insanely long
> value and test stability with that. I picked 750 as around twice the
> maximum time it ever took on my board.
>
> Thanks
>
> Michal
>