Hi, Alexey.
On 01/29/2015 05:49 PM, Alexey Skidanov wrote:
> This patch is coming to fix compatibility issue of BKOPS_EN field of EXT_CSD.
> In eMMC-5.1, BKOPS_EN was changed, and now it has two operational bits:
> Bit 0 - MANUAL_EN
> Bit 1 - AUTO_EN
> In previous eMMC revisions, only Bit 0 was s
On 01/30/2015 09:13 AM, Doug Anderson wrote:
> Ulf,
>
> On Thu, Jan 29, 2015 at 1:16 AM, Ulf Hansson wrote:
>> - Drastically decreased cc-list.
>>
>> On 29 January 2015 at 01:55, Doug Anderson wrote:
>>> Ulf,
>>>
>>> On Tue, Jan 27, 2015 at 7:18 AM, Ulf Hansson wrote:
> I asked Addy to post
hi, Doug
On 2015/1/30 08:13, Doug Anderson wrote:
> Ulf,
>
> On Thu, Jan 29, 2015 at 1:16 AM, Ulf Hansson wrote:
>> - Drastically decreased cc-list.
>>
>> On 29 January 2015 at 01:55, Doug Anderson wrote:
>>> Ulf,
>>>
>>> On Tue, Jan 27, 2015 at 7:18 AM, Ulf Hansson wrote:
> I asked Addy t
Ulf,
On Thu, Jan 29, 2015 at 1:16 AM, Ulf Hansson wrote:
> - Drastically decreased cc-list.
>
> On 29 January 2015 at 01:55, Doug Anderson wrote:
>> Ulf,
>>
>> On Tue, Jan 27, 2015 at 7:18 AM, Ulf Hansson wrote:
I asked Addy to post upstream against mmc_send_tuning(), but I guess
he d
Jonas Jensen wanted to submit a patch for these, but apparently
forgot about it. I stumbled over this symptom first:
drivers/built-in.o: In function `moxart_probe':
:(.text+0x2af128): undefined reference to `of_dma_request_slave_channel'
This is because of_dma_request_slave_channel is an internal
On Thursday 29 January 2015 17:01:04 Russell King - ARM Linux wrote:
> On Thu, Jan 29, 2015 at 05:15:31PM +0100, Arnd Bergmann wrote:
> > @@ -586,10 +586,10 @@ static int moxart_probe(struct platform_device *pdev)
> > goto out;
> > }
> >
> > - clk = of_clk_get(node, 0);
>
On Thu, Jan 29, 2015 at 05:15:31PM +0100, Arnd Bergmann wrote:
> @@ -586,10 +586,10 @@ static int moxart_probe(struct platform_device *pdev)
> goto out;
> }
>
> - clk = of_clk_get(node, 0);
> - if (IS_ERR(clk)) {
> + host->clk = of_clk_get(node, 0);
> + if (IS_
The patch fixes some of the following error/warnings from the file block.c
./scripts/checkpatch.pl --file --terse drivers/mmc/card/block.c
drivers/mmc/card/block.c:45: WARNING: Use #include instead of
drivers/mmc/card/block.c:102: WARNING: line over 80 characters
drivers/mmc/card/block.c:186:
Jonas Jensen wanted to submit a patch for these, but apparently
forgot about it. I stumbled over this symptom first:
drivers/built-in.o: In function `moxart_probe':
:(.text+0x2af128): undefined reference to `of_dma_request_slave_channel'
This is because of_dma_request_slave_channel is an internal
Some WLAN chips attached to a SDIO interface, need an external clock
to be operational. Since this is very common, extend the simple MMC
power sequence DT binding to support an optional clock.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None.
Changes since v1: None.
---
Docum
Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.
This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed numbe
Some WLAN chips attached to a SDIO interface, need a reference clock.
Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.
Note: the external clock is optional. Thus an error is not returned
if the clock is not f
On 29 January 2015 at 15:17, Jean Delvare wrote:
> Hi Ulf,
>
> On Wed, 28 Jan 2015 15:04:24 +0100, Ulf Hansson wrote:
>> On 27 January 2015 at 15:34, Jean Delvare wrote:
>> > Hi Ulf,
>> >
>> > Le Tuesday 27 January 2015 à 15:06 +0100, Ulf Hansson a écrit :
>> >> On 26 January 2015 at 11:23, Jean
Many SDIO/MMC attached WLAN chips need more than one ping for their reset
sequence. Extend the pwrseq_simple binding to support more than one pin.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None.
Changes since v1:
- Make the explanation clearer by adding an explicit "they".
Enabling SDIO IRQ signalling for the wifi MMC/SDIO slot
doubles the transmission transfer rate.
Signed-off-by: Javier Martinez Canillas
---
Changes since v2: None.
Changes since v1: None, new patch.
---
arch/arm/boot/dts/exynos5250-snow.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/a
The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-as
Hello Ulf,
Many WLAN chips attached to an SDIO interface needs more than one GPIO
for their reset sequence and also an external clock to be operational.
Since this is very common, this series extend the simple MMC power sequence
to support more than one reset GPIO and also an optional external cl
Hi Ulf,
On Wed, 28 Jan 2015 15:04:24 +0100, Ulf Hansson wrote:
> On 27 January 2015 at 15:34, Jean Delvare wrote:
> > Hi Ulf,
> >
> > Le Tuesday 27 January 2015 à 15:06 +0100, Ulf Hansson a écrit :
> >> On 26 January 2015 at 11:23, Jean Delvare wrote:
> >> > I seem to understand that the sdhci-p
Hello Ulf,
Thanks a lot for your feedback.
On 01/29/2015 02:05 PM, Ulf Hansson wrote:
>>
>> struct mmc_pwrseq_simple {
>> struct mmc_pwrseq pwrseq;
>> + struct clk *ext_clk;
>
> You need to add a bool, maybe call it clk_enabled; See why below.
>
Ok
>> int nr_gpios;
>>
On 28 January 2015 at 19:15, Javier Martinez Canillas
wrote:
> Some WLAN chips attached to a SDIO interface, need a reference clock.
>
> Since this is very common, extend the prseq_simple driver to support
> an optional clock that is enabled prior the card power up procedure.
>
> Note: the externa
On 28 January 2015 at 20:52, Martin Hicks wrote:
>
> The reset code was pushed into the esdhc-imx driver, but missed being
> pushed into the FSL OF driver at the same time. The commit that broke
> the OF ESDHC driver was 0718e59ae259f7c48155b4e852d8b0632d59028e
>
> Signed-off-by: Martin Hicks
M
On 29 January 2015 at 12:36, Gregory CLEMENT
wrote:
> Hi,
>
> this series brings fixes and improvements for the SDHCI controller of
> the Armada 38x SoCs.
>
> The changes for this forth version was done on the 1st and 4th
> patches, see the changelog for the details.
>
> The first two patches are
Instead of hardcoding the values of the interrupt flags, use the
macros provided by
and for the
Armada 38x SDHCI node.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-38x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/a
From: Marcin Wojtas
According to erratum 'ERR-7878951' Armada 38x SDHCI controller has
different capabilities than the ones shown in its registers:
- it doesn't support the voltage switching: it can work either with
3.3V or 1.8V supply
- it doesn't support the SDR104 mode
- SDR50 mode doesn't
Hi,
this series brings fixes and improvements for the SDHCI controller of
the Armada 38x SoCs.
The changes for this forth version was done on the 1st and 4th
patches, see the changelog for the details.
The first two patches are fixes and should be also applied on the
stable branch (I added stabl
The SDHCI unit used on the Armada 38x needs using an extra register to
do specific clock adjustments in order to support the SDR50 and DDR50
modes. This patch extends the binding to allow using this register.
Signed-off-by: Gregory CLEMENT
---
Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register. However,
this register was not part of the device tree binding. Even if the
binding can (and will) be extended we still need handling the case
where this register was not
The binding of the armada-380-sdhci has been extended with a new
register in order to be able to use the SDR50 and DDR50 mode. This
commit add the resource associated to this new register for the
Armada 38x.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-38x.dtsi | 5 -
1 file c
From: Marcin Wojtas
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register.
This commit add the support of this register and for SDR50 or DDR50
mode use it as suggested by the erratum:
- Set the SDIO3 Clock Inv field in SDI
The Device Tree description of SDHCI on Armada 388 RD board was
missing. This commit adds the node for it.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-388-rd.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-rd.dts
b/arch/arm/boot/d
Hello,
On 2015-01-29 11:56, Javier Martinez Canillas wrote:
On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
wrote:
Also, I wonder whether we could extend the mmc-pwrseq to cover your
case? Did you consider that as an option?
I didn't consider mmc-pwrseq yet. For me it looked straightforwar
Hello Marek,
On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
wrote:
>> Also, I wonder whether we could extend the mmc-pwrseq to cover your
>> case? Did you consider that as an option?
>
>
> I didn't consider mmc-pwrseq yet. For me it looked straightforward to
I agree with Ulf that using mmc-p
On 29 January 2015 at 09:49, Alexey Skidanov
wrote:
> This patch is coming to fix compatibility issue of BKOPS_EN field of EXT_CSD.
> In eMMC-5.1, BKOPS_EN was changed, and now it has two operational bits:
> Bit 0 - MANUAL_EN
> Bit 1 - AUTO_EN
> In previous eMMC revisions, only Bit 0 was supporte
On 29 January 2015 at 10:42, Jisheng Zhang wrote:
> I observed the Host Control2 register isn't correctly restored
> after runtime resuming on BG2Q. For example, the register reads
> as 0x800c before runtime suspend, but it's set as 0x8004 after runtime
> resuming. This could results in a non work
On 28 January 2015 at 12:54, Jisheng Zhang wrote:
> Current code checks "clk_delay_cycles > 0" to know whether the optional
> "mrvl,clk_delay_cycles" is set or not. But of_property_read_u32() doesn't
> touch clk_delay_cycles if the property is not set. And type of
> clk_delay_cycles is u32, so we
On 28 January 2015 at 17:45, Rhyland Klein wrote:
> From: Pavan Kunapuli
>
> If there is a gap between xfer mode and command register writes,
> tegra SDMMC controller can sometimes issue a spurious command before
> the CMD register is written. To avoid this, these two registers need
> to be writt
On 29 January 2015 at 10:42, Gregory CLEMENT
wrote:
> Hi Ulf,
>
> On 29/01/2015 10:31, Ulf Hansson wrote:
>> [...]
>>
Seems like this function can be void instead of always returning 0.
>>>
>>> In patch 4 "mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
>>> DDR50 modes", this functi
Currently, there is core support for tuning during
initialization. There can also be a need to re-tune
periodically (e.g. sdhci) or to re-tune after the
host controller is powered off (e.g. after PM
runtime suspend / resume) or to re-tune in response
to CRC errors.
The main requirements for re-tun
Hi
Here is V2 of some patches to move re-tuning support
out of sdhci and into the core, and add support for HS400
re-tuning.
Currently sdhci does re-tuning transparently by
calling sdhci_execute_tuning() from its ->request()
function.
The problem with HS400 re-tuning is that it must be
done in H
At the start of each request, re-tune if needed and
then hold off re-tuning again until the request is done.
Note that though there is one function that starts
requests (mmc_start_request) there are two that wait for
the request to be done (mmc_wait_for_req_done and
mmc_wait_for_data_req_done). A
Re-tuning is done before a request is sent to the card.
Host controller drivers can choose to enable re-tuning
when tuning is done during card initialization. To
ensure that re-tuning gets disabled, add disabling to
mmc_set_initial_state() which is called whenever the
card is powered on, off, or re
CRC or End-Bit errors could possibly be alleviated by
re-tuning so flag re-tuning needed in those cases.
Note this has no effect if re-tuning has not been
enabled.
Signed-off-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff
Currently "mmc sleep" is only used before power off and
is not paired with waking up. If that ever changed,
re-tuning might need to be held, so add a comment for that.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/core/mm
If re-tuning is needed, do it in the recovery path to
give recovery commands a better chance of success.
Signed-off-by: Adrian Hunter
---
drivers/mmc/card/block.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c69afb5..293e938 100
Make use of mmc core support for re-tuning instead
of doing it all in the sdhci driver.
This patch also changes to flag the need for re-tuning
always after runtime suspend when tuning has been used
at initialization. Previously it was only done if
the re-tuning timer was in use.
Signed-off-by: Ad
Possibly a command is failing because re-tuning is needed.
Use mmc_retune_recheck() to check re-tuning. At that point
re-tuning is held, at least by the request, so
mmc_retune_recheck() does a mmc_retune_release() and
mmc_retune_hold().
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/core.c |
Hold re-tuning during switch commands to prevent
it from conflicting with the busy state or the CMD13
verification.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/mmc_ops.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/core/m
Hold re-tuning during bkops to prevent
it from conflicting with the busy state.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/core.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 91838ea..392a150 100644
--- a/drivers/mmc/c
Hold re-tuning during erase commands to prevent
it from conflicting with the sequence of commands.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index f1d663e..91838ea 100644
---
I observed the Host Control2 register isn't correctly restored
after runtime resuming on BG2Q. For example, the register reads
as 0x800c before runtime suspend, but it's set as 0x8004 after runtime
resuming. This could results in a non working host.
The reason is the Host Control2 is incorrectly r
Hi Ulf,
On 29/01/2015 10:31, Ulf Hansson wrote:
> [...]
>
>>> Seems like this function can be void instead of always returning 0.
>>
>> In patch 4 "mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
>> DDR50 modes", this function can return other values than 0.
>>
>> I could change the pro
[...]
>> Seems like this function can be void instead of always returning 0.
>
> In patch 4 "mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
> DDR50 modes", this function can return other values than 0.
>
> I could change the prototype in patch 4, but it would also imply
> removing the t
Hello,
On 2015-01-28 15:24, Ulf Hansson wrote:
On 28 January 2015 at 14:59, Marek Szyprowski wrote:
There are boards (like Hardkernel's Odroid boards) on which eMMC card's
reset line is connected to GPIO line instead of the hardware reset
logic. In case of such boards, if first stage of bootlo
- Drastically decreased cc-list.
On 29 January 2015 at 01:55, Doug Anderson wrote:
> Ulf,
>
> On Tue, Jan 27, 2015 at 7:18 AM, Ulf Hansson wrote:
>>> I asked Addy to post upstream against mmc_send_tuning(), but I guess
>>> he didn't (he posted against Alex's NAKed patch instead).
>>>
>>> ...when
Retry data requests when re-tuning is needed and
add a flag to struct mmc_blk_request so that the retry
is only done once.
Signed-off-by: Adrian Hunter
---
drivers/mmc/card/block.c | 12 +++-
drivers/mmc/card/queue.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/
Check the error code for EOPNOTSUPP and do not print
reset warning in that case.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 392a150..d439bf0 100644
--- a/dr
Make a separate function to do the mmc_switch status check
so it can be re-used. This is preparation for adding support
for HS400 re-tuning.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/mmc_ops.c | 30 --
drivers/mmc/core/mmc_ops.h | 1 +
2 files changed, 17 ins
HS400 re-tuning must be done in HS200 mode. Add
the ability to switch from HS400 mode to HS200
mode before re-tuning and switch back to HS400
after re-tuning.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/core.h | 2 ++
drivers/mmc/core/host.c | 17 ++
drivers/mmc/core/mmc.c | 86 +
On 01/22/2015 10:02 AM, Ulf Hansson wrote:
> On 21 January 2015 at 17:43, Karol Wrona wrote:
>> This patch adds runtime pm handling to dw_mmc and enables it for
>> dw_mmc-exynos.
>> It mainly uses mci_request/mci_request_end for mmc host state information.
>>
>> Signed-off-by: Karol Wrona
>> ---
This patch is coming to fix compatibility issue of BKOPS_EN field of EXT_CSD.
In eMMC-5.1, BKOPS_EN was changed, and now it has two operational bits:
Bit 0 - MANUAL_EN
Bit 1 - AUTO_EN
In previous eMMC revisions, only Bit 0 was supported.
Signed-off-by: Alexey Skidanov
---
drivers/mmc/core/core.
Hi Ulf,
[...]
>> + dev_warn(&pdev->dev, "conf-sdio3 register not found\n");
>> + dev_warn(&pdev->dev, "disabling SDR50 and DDR50 modes\n");
>> + dev_warn(&pdev->dev, "consider updating your dtb\n");
>
> One dev_warn() should be enough. Also I don't think
On 26 January 2015 at 12:19, Addy Ke wrote:
> This patch based on Alex's patch:
> https://patchwork.kernel.org/patch/5516411/
This above patch was rejected, since it doesn't use mmc_send_tuning().
Please base you work on my latest next branch.
If you need other patches which has been posted rece
Hi Ulf,
On 28/01/2015 21:36, Ulf Hansson wrote:
> On 23 January 2015 at 11:56, Gregory CLEMENT
> wrote:
>> According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
>> specific clock adjustments in SDIO3 Configuration register. However,
>> this register was not part of the device tree
63 matches
Mail list logo
