n dependency between devices. This patch
> enables MMC/SD/SDIO card and SDIO function devices to suspend/resume
> asynchronously. This will take advantage of multicore and improve
> system suspend/resume speed. After applying this patch and enabling
> all SDIO function's ch
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition dependency between devices. This patch
enables MMC/SD/SDIO card and
o_retune_release(). They are used in the 2nd patch
>> to prevent re-tuning for the 'wake-up' command.
>>
>>
>> Adrian Hunter (2):
>> mmc: core: Add functions for SDIO to hold re-tuning
>> brcmfmac: Prevent re-tuning conflicting with 'wa
t; I didn't find this patch in mainline kernel, where is this patch?
It's queued for 4.5 on my next branch via my mmc git. Thus also
available in linux-next.
One should know that it's affecting MMC/SD cards and not SDIO.
Future wise I was hoping we could do something similar
nous suspend/resume mode for devices
>>>> during system suspend/resume, and the power state transition of one
>>>> device may be completed in separate kernel thread. PM core ensures
>>>> all power state transition timing dependency between devices. This
> What "
g for the 'wake-up' command.
>
>
> Adrian Hunter (2):
> mmc: core: Add functions for SDIO to hold re-tuning
> brcmfmac: Prevent re-tuning conflicting with 'wake-up'
>
> drivers/mmc/core/host.c| 6 ++
> driver
The 'ocr' parameter passed to mmc_set_signal_voltage()
defines the power-on voltage used when power cycling
after a failure to set the voltage. However, in the
case of mmc_sdio_init_card(), the value passed has the
R4_18V_PRESENT flag set which is not valid for power-on
and results in an invalid v
sume, and the power state transition of one
>>> device may be completed in separate kernel thread. PM core ensures
>>> all power state transition timing dependency between devices. This
What "timing dependency"?
>>> patch enables SDIO card and function devices to
nd the power state transition of one
>>> device may be completed in separate kernel thread. PM core ensures
>>> all power state transition timing dependency between devices. This
>>> patch enables SDIO card and function devices to suspend/resume
>>> asynchronously. Thi
parate kernel thread. PM core ensures
>> all power state transition timing dependency between devices. This
>> patch enables SDIO card and function devices to suspend/resume
>> asynchronously. This will take advantage of multicore and improve
>> system suspend/resume speed.
ition timing dependency between devices. This
> patch enables SDIO card and function devices to suspend/resume
> asynchronously. This will take advantage of multicore and improve
> system suspend/resume speed. After enabling the SDIO devices and all
> their child devices to suspend/resum
6:26, Fu, Zhonghui wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Any comments are welcome.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Zhonghui
>>>>>>
>>>>>&
Please see the latest version: "[PATCH v3] MMC/SDIO: enable SDIO device to
suspend/resume asynchronously".
Thanks,
Zhonghui
On 9/21/2015 12:30 PM, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables SDIO card and
Hi,
Is there any Linux MMC stack utility to read/write SDIO registers with CMD52s?
--
Thanks,
Sekhar
--
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
On 16.10.2015 14:47, Michael Turquette wrote:
Quoting Jisheng Zhang (2015-10-11 22:46:35)
Since we have added the necessary axi clk properties in dts, we can
remove the "sdio" clk's CLK_IGNORE_UNUSED flag now.
Signed-off-by: Jisheng Zhang
Applied to clk-next.
Mike,
these t
Quoting Jisheng Zhang (2015-10-11 22:46:36)
> The axi clock properties already exists, so there's no need to set this
> flag for sdio0 and sdio1 clk any more.
>
> Signed-off-by: Jisheng Zhang
Applied to clk-next.
Regards,
Mike
> ---
> drivers/clk/berlin/bg2.c | 4 ++--
> 1 file changed, 2 ins
Quoting Jisheng Zhang (2015-10-11 22:46:35)
> Since we have added the necessary axi clk properties in dts, we can
> remove the "sdio" clk's CLK_IGNORE_UNUSED flag now.
>
> Signed-off-by: Jisheng Zhang
Applied to clk-next.
Regards,
Mike
> ---
> drivers/c
Since we have added the necessary axi clk properties in dts, we can
remove the "sdio" clk's CLK_IGNORE_UNUSED flag now.
Signed-off-by: Jisheng Zhang
---
drivers/clk/berlin/bg2q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/berlin/bg2q.c b/dri
The axi clock properties already exists, so there's no need to set this
flag for sdio0 and sdio1 clk any more.
Signed-off-by: Jisheng Zhang
---
drivers/clk/berlin/bg2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/berlin/bg2.c b/drivers/clk/berlin/bg2.c
ind
ition timing dependency between devices. This
> patch enables SDIO card and function devices to suspend/resume
> asynchronously. This will take advantage of multicore and improve
> system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> Changes in v2:
> - Amend c
its that I've had to debug... Really my
knowledge of SD/MMC/SDIO is limited to having to deal with dw_mmc
since all the SoCs I've worked with have had that controller.
I'll put it on my list to try to come up with a patch, but it might be
a while before I get to it since I've alr
was even posted upstream!
:)
https://patchwork.kernel.org/patch/5858221/
I said:
Sorry for the quick spin. After I posted this I re-read all the
messages and it looks like Addy has an actual SD card (not SDIO) that
is also asserting busy. He's seeing it assert busy around the clock
update.
but, oh, I see why this is. It was even posted upstream!
:)
https://patchwork.kernel.org/patch/5858221/
I said:
> Sorry for the quick spin. After I posted this I re-read all the
> messages and it looks like Addy has an actual SD card (not SDIO) that
> is also asserting busy. He's seei
t;>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 23-09-15 23:43, Ulf Hansson wrote:
>>>>>>>>
>>>>>>>> On 22 September 2015 at 17:30, Hans de Goede
>>>>>>>> wrot
wrote:
Hi,
On 23-09-15 23:43, Ulf Hansson wrote:
On 22 September 2015 at 17:30, Hans de Goede wrote:
Hi Ulf,
Here is a non RFC version of my patch-set to wait for card_busy before
starting sdio requests. It is the same as the RFC version of the set,
but this time it has been tested no hardware
;>>
>>>> On Thu, Sep 24, 2015 at 2:19 AM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 23-09-15 23:43, Ulf Hansson wrote:
>>>>>>
>>>>>> On 22 September 2015 at 17:30, Hans de Goede wrote:
>>
Goede wrote:
Hi Ulf,
Here is a non RFC version of my patch-set to wait for card_busy before
starting sdio requests. It is the same as the RFC version of the set,
but this time it has been tested no hardware which actually needs this
and I can confirm now that this fixes wifi on that hardware
;>>
>>>> On 22 September 2015 at 17:30, Hans de Goede wrote:
>>>>>
>>>>> Hi Ulf,
>>>>>
>>>>> Here is a non RFC version of my patch-set to wait for card_busy before
>>>>> starting sdio requests. It is the same as
sdio requests. It is the same as the RFC version of the set,
but this time it has been tested no hardware which actually needs this
and I can confirm now that this fixes wifi on that hardware.
Great! Thanks, applied for next!
Great, thanks, I guess it is too late for this to go as a fix into
;>> Hi Ulf,
>>>>
>>>> Here is a non RFC version of my patch-set to wait for card_busy before
>>>> starting sdio requests. It is the same as the RFC version of the set,
>>>> but this time it has been tested no hardware which actually nee
Hi,
On Thu, Sep 24, 2015 at 2:19 AM, Hans de Goede wrote:
> Hi,
>
> On 23-09-15 23:43, Ulf Hansson wrote:
>>
>> On 22 September 2015 at 17:30, Hans de Goede wrote:
>>>
>>> Hi Ulf,
>>>
>>> Here is a non RFC version of my patch-set to wa
On 09/24/2015 11:19 AM, Hans de Goede wrote:
Hi,
On 23-09-15 23:43, Ulf Hansson wrote:
On 22 September 2015 at 17:30, Hans de Goede wrote:
Hi Ulf,
Here is a non RFC version of my patch-set to wait for card_busy before
starting sdio requests. It is the same as the RFC version of the set,
but
Hi,
On 23-09-15 23:43, Ulf Hansson wrote:
On 22 September 2015 at 17:30, Hans de Goede wrote:
Hi Ulf,
Here is a non RFC version of my patch-set to wait for card_busy before
starting sdio requests. It is the same as the RFC version of the set,
but this time it has been tested no hardware
On 22 September 2015 at 17:30, Hans de Goede wrote:
> Hi Ulf,
>
> Here is a non RFC version of my patch-set to wait for card_busy before
> starting sdio requests. It is the same as the RFC version of the set,
> but this time it has been tested no hardware which actually needs t
Some sdio wifi chips will not work properly if we try to start new
sdio-rw requests while the device is signalling that it is busy.
Signed-off-by: Hans de Goede
---
drivers/mmc/core/core.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers
Hi Ulf,
Here is a non RFC version of my patch-set to wait for card_busy before
starting sdio requests. It is the same as the RFC version of the set,
but this time it has been tested no hardware which actually needs this
and I can confirm now that this fixes wifi on that hardware.
This patch-set
Hi,
>>>>>
>>>>> Any comments are welcome.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Zhonghui
>>>>>
>>>>> On 2015/7/30 15:40, Fu, Zhonghui wrote:
>>>>>> Enable SDIO card and
;>>>
>>>>
>>>> Thanks,
>>>> Zhonghui
>>>>
>>>> On 2015/7/30 15:40, Fu, Zhonghui wrote:
>>>>> Enable SDIO card and function device to suspend/resume asynchronously.
>>>>> This can improve system suspend/res
Now, PM core supports asynchronous suspend/resume mode for devices
during system suspend/resume, and the power state transition of one
device may be completed in separate kernel thread. PM core ensures
all power state transition timing dependency between devices. This
patch enables SDIO card and
Some sdio wifi chips will not work properly if we try to start new
sdio-rw requests while the device is signalling that it is busy.
Signed-off-by: Hans de Goede
---
drivers/mmc/core/core.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers
Hi Ulf,
As discussed before here is a series to make the mmc core check the
card_busy op before submitting sdio-rw commands to the host driver.
Not sure if this is what you've in mind, but it is a start :)
This series is RFC because currently I'm travelling, and I do not
have any sunx
Hi,
On Friday 11 September 2015 06:15 PM, Ulf Hansson wrote:
> On 24 August 2015 at 12:15, Kishon Vijay Abraham I wrote:
>> mmc_sdio_runtime_resume and mmc_sdio_runtime_suspend does power up and
>> power off respectively but does so without claiming the host. Among other
>> things mmc_claim_host
On 24 August 2015 at 12:15, Kishon Vijay Abraham I wrote:
> mmc_sdio_runtime_resume and mmc_sdio_runtime_suspend does power up and
> power off respectively but does so without claiming the host. Among other
> things mmc_claim_host inovkes pm_runtime_get_sync to enable the clocks.
> Invoke mmc_clai
mmc_sdio_runtime_resume and mmc_sdio_runtime_suspend does power up and
power off respectively but does so without claiming the host. Among other
things mmc_claim_host inovkes pm_runtime_get_sync to enable the clocks.
Invoke mmc_claim_host before mmc_power_up and mmc_power_off in
mmc_sdio_runtime_re
No functional change. Move mmc_sdio_init_card to a separate
function (_mmc_sdio_power_restore) and invoke it from
mmc_sdio_power_restore. This is in preparation to invoke
_mmc_sdio_power_restore from mmc_sdio_runtime_resume so that
mmc_claim_host can be invoked before mmc_power_up.
Signed-off-by:
On 2015/8/17 14:48, Adrian Hunter wrote:
> On 17/08/15 06:26, Fu, Zhonghui wrote:
>> Hi,
>>
>> Any comments are welcome.
>>
>>
>> Thanks,
>> Zhonghui
>>
>> On 2015/7/30 15:40, Fu, Zhonghui wrote:
>>> Enable SDIO card and func
On 17/08/15 06:26, Fu, Zhonghui wrote:
>
> Hi,
>
> Any comments are welcome.
>
>
> Thanks,
> Zhonghui
>
> On 2015/7/30 15:40, Fu, Zhonghui wrote:
>> Enable SDIO card and function device to suspend/resume asynchronously.
>> This can improve system su
Hi,
Any comments are welcome.
Thanks,
Zhonghui
On 2015/7/30 15:40, Fu, Zhonghui wrote:
> Enable SDIO card and function device to suspend/resume asynchronously.
> This can improve system suspend/resume speed.
>
> Signed-off-by: Zhonghui Fu
> ---
> drivers/mmc/core/sdio.
Enable SDIO card and function device to suspend/resume asynchronously.
This can improve system suspend/resume speed.
Signed-off-by: Zhonghui Fu
---
drivers/mmc/core/sdio.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core
On 10 July 2015 at 05:36, Yangbo Lu wrote:
> For Freescale QorIQ LS1021AQDS board, there is a SDIO interrupt
> in the process of resume without inserting SD adapter because of
> some unknown issue. But the driver doesn't assign sdio_irq_thread
> pointer. This will block the resum
For Freescale QorIQ LS1021AQDS board, there is a SDIO interrupt
in the process of resume without inserting SD adapter because of
some unknown issue. But the driver doesn't assign sdio_irq_thread
pointer. This will block the resume of kernel. This patch is used
to avoid using NULL sdio_irq_t
On 10 June 2015 at 18:30, Ben Dooks wrote:
> We are having an issue with 3.18 on an OMAP3517 and a TI WL1271
> Wifi SDIO card attached to an hsmmc port. The module is powered
> from the main 3.3/1.8V supply rails so cannot be powered down.
>
> The wifi driver is built as a modul
We are having an issue with 3.18 on an OMAP3517 and a TI WL1271
Wifi SDIO card attached to an hsmmc port. The module is powered
from the main 3.3/1.8V supply rails so cannot be powered down.
The wifi driver is built as a module, and when the module is
unloaded and then reloaded the driver attach
[...]
>> > * When we create a device which we know has a PM domain which should be
>> > attached, try to look up that PM domain.
>> > * If we find the PM domain, attach the domain, otherwise create the
>> > domain but mark it "incomplete".
>> > * When the device is attempted to be probed, forc
On Tue, Jun 02, 2015 at 03:18:07PM +0200, Ulf Hansson wrote:
> On 2 June 2015 at 13:07, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 02, 2015 at 09:51:01AM +0100, Russell King - ARM Linux wrote:
> >> What would resolve that would be to have the device registration succeed,
> >> but also to sc
On 2 June 2015 at 13:07, Russell King - ARM Linux
wrote:
> On Tue, Jun 02, 2015 at 09:51:01AM +0100, Russell King - ARM Linux wrote:
>> What would resolve that would be to have the device registration succeed,
>> but also to scan all devices in the system when a PM domain is attached
>> and attach
On Tue, Jun 02, 2015 at 09:51:01AM +0100, Russell King - ARM Linux wrote:
> What would resolve that would be to have the device registration succeed,
> but also to scan all devices in the system when a PM domain is attached
> and attach the PM domain to matching devices. The problem you then have
On Tue, Jun 02, 2015 at 09:54:13AM +0200, Ulf Hansson wrote:
> On the other hand, the "long term plan" is to have PM domain pointers
> assigned at device registration point instead of at probe. Since
> driver core then invokes the ->activate|sync|dismiss() callbacks, it
> will make the dev_pm_domai
the PM
>> domain will be done after invoking the driver's ->remove() callback.
>>
>> Convert the SDIO bus to follow this behavior and add error handling.
>>
>> Signed-off-by: Ulf Hansson
>> ---
>>
>> A similar patch as $subject patch has
;s ->remove() callback.
>
> Convert the SDIO bus to follow this behavior and add error handling.
>
> Signed-off-by: Ulf Hansson
> ---
>
> A similar patch as $subject patch has been posted and discussed earlier.
>
> According to Aaron Lu, who added the initial support for
Other subsystem buses attach PM domains during probe, but prior calling
the driver's ->probe() method. During the removal phase, detaching the PM
domain will be done after invoking the driver's ->remove() callback.
Convert the SDIO bus to follow this behavior and add error handl
mmc: core: Add functions for SDIO to hold re-tuning
brcmfmac: Prevent re-tuning conflicting with 'wake-up'
drivers/mmc/core/host.c| 6 ++
drivers/mmc/core/host.h| 1 +
drivers/mmc/core/sdio_io.c | 13 ++
Add sdio_retune_hold_now() and sdio_retune_release()
in order to allow SDIO function drivers to prevent
re-tuning in cases where it conflicts with the
device state.
Signed-off-by: Adrian Hunter
---
drivers/mmc/core/host.c | 6 ++
drivers/mmc/core/host.h | 1 +
drivers/mmc/core
Some drivers schedule automatic hw resets. An example is mwifiex,
which schedules a card reset if the command handler between driver
and card firmware becomes out of sync
Signed-off-by: Andreas Fenkart
---
drivers/mmc/core/sdio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers
:
>>>>
>>>>
>>>> On 14 April 2015 at 20:10, Arend van Spriel wrote:
>>>>>
>>>>>
>>>>> commit 330b4e4be937 ("brcmfmac: Add wowl support for SDIO devices.")
>>>>> changed the behaviour by removing th
On 04/22/15 11:18, Ulf Hansson wrote:
On 22 April 2015 at 10:52, Arend van Spriel wrote:
- wireless list/maintainer
On 04/22/15 09:32, Ulf Hansson wrote:
On 14 April 2015 at 20:10, Arend van Spriel wrote:
commit 330b4e4be937 ("brcmfmac: Add wowl support for SDIO devices.")
c
On 22 April 2015 at 10:52, Arend van Spriel wrote:
> - wireless list/maintainer
>
>
> On 04/22/15 09:32, Ulf Hansson wrote:
>>
>> On 14 April 2015 at 20:10, Arend van Spriel wrote:
>>>
>>> commit 330b4e4be937 ("brcmfmac: Add wowl support for SDIO d
- wireless list/maintainer
On 04/22/15 09:32, Ulf Hansson wrote:
On 14 April 2015 at 20:10, Arend van Spriel wrote:
commit 330b4e4be937 ("brcmfmac: Add wowl support for SDIO devices.")
changed the behaviour by removing the MMC_PM_KEEP_POWER flag for
non-wowl scenario, which n
Some drivers schedule automatic hw resets. An example is mwifiex,
which schedules a card reset if the command handler between driver
and card firmware becomes out of sync
Signed-off-by: Andreas Fenkart
---
drivers/mmc/core/sdio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers
On Mon, 23 Mar 2015 10:10:18 +0100 Ulf Hansson wrote:
> On 24 February 2015 at 03:42, NeilBrown wrote:
> > @@ -941,8 +947,12 @@ void mmc_release_host(struct mmc_host *host)
> >
> > WARN_ON(!host->claimed);
> >
> > - if (host->ops->disable && host->claim_cnt == 1)
> > -
hat I think it is doing...
Comments?
Thanks,
NeilBrown
---
NeilBrown (4):
mmc: core: fold mmc_set_bus_width calls into sdio_enable_4bit_bus.
mmc/core: add pm_runtime tracking to mmc_host devices.
mmc/sdio: keep device awake when interrupts expected in 4bit mode
mmc/host
In 4-bit mode, SDIO interrupts are only reliable if clocks
are maintained.
So get an extra reference when that is the case.
Signed-off-by: NeilBrown
---
drivers/mmc/core/sdio.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index
t; - when the host is claimed, if sdio_narrowed is 2, restore the
>4-bit bus
> - When the host is released, if sdio_narrowed is 1, then some
>caller other than our worker claimed the host first, so
>clear sdio_narrowed.
>
> This all allows a graceful and race-free switch to 1-
d, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/CREDITS b/CREDITS
>> index 96935df..843e176 100644
>> --- a/CREDITS
>> +++ b/CREDITS
>> @@ -187,6 +187,10 @@ N: Krishna Balasubramanian
>> E: bala...@cis.ohio-state.edu
>> D: Wrote SYS V IPC (part
4
> --- a/CREDITS
> +++ b/CREDITS
> @@ -187,6 +187,10 @@ N: Krishna Balasubramanian
> E: bala...@cis.ohio-state.edu
> D: Wrote SYS V IPC (part of standard kernel since 0.99.10)
>
> +N: Chris Ball
> +E: ch...@printf.net
> +D: Former maintainer of the MMC/SD/SD
IPC (part of standard kernel since 0.99.10)
+N: Chris Ball
+E: ch...@printf.net
+D: Former maintainer of the MMC/SD/SDIO subsystem.
+
N: Dario Ballabio
E: ballabio_da...@emc.com
E: dario.balla...@tiscalinet.it
diff --git a/MAINTAINERS b/MAINTAINERS
index 582b4b4..50479c8 100644
--- a/MAINTAI
AINTAINERS b/MAINTAINERS
>> index 582b4b4..50479c8 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6547,10 +6547,8 @@ F: drivers/mfd/
>> F: include/linux/mfd/
>>
>> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
>> -M: Chris
mfd/
>
> MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
> -M: Chris Ball
> M: Ulf Hansson
> L: linux-mmc@vger.kernel.org
> -T: git git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
> T: git git://git.linaro.org/people/ulf.hansson/mmc.
--
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 582b4b4..50479c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6547,10 +6547,8 @@ F: drivers/mfd/
F: include/linux/mfd/
MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
-M:
* NeilBrown [150303 21:29]:
> On Tue, 3 Mar 2015 14:53:55 -0800 Tony Lindgren wrote:
> >
> > --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> > +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> > @@ -367,6 +367,7 @@
> > };
> >
> > &mmc2 {
> > + interrupts-extended = <&intc 86 &omap3_pmx_core 0x12e>;
>
t;4-bit bus
> > - When the host is released, if sdio_narrowed is 1, then some
> >caller other than our worker claimed the host first, so
> >clear sdio_narrowed.
> >
> > This all allows a graceful and race-free switch to 1-bit mode
> > before swi
t is claimed, if sdio_narrowed is 2, restore the
>4-bit bus
> - When the host is released, if sdio_narrowed is 1, then some
>caller other than our worker claimed the host first, so
>clear sdio_narrowed.
>
> This all allows a graceful and race-free switch to 1-bit mode
>
Dear all,
i am trying to have working this module with kernel 3.10 over
sdio, 4 lines, high speed, on a imx6q.
The bcm43362 CHIP_ID is still missing in kernel 3.10 so i merged
some small parts of 3.14 wifi drivers into 3.10.
Actually, seems this module does not reply to the SDIO probing
all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if SDIO interrupts are enabled.
A host should call mmc_sdio_want_no_clocks() when about to turn off
clocks if sdio interrupts are enabled, and the ->disable() function
should not use a timeout (pm_runtime_pu
This is a reworking of this code that I promised at the end of
January.
SDIO interrupt in 4-bit mode require the clock to be running. So we
need to switch to 1-bit mode before turning off the clock.
This series provides infrastructure in mmc-core, and adds the
functionality to omap_hsmmc
Hi Fabio,
In order NOT to permit the SDIO core controller to communicate in 3.3v
signal voltage, you need to define the vqmmc, voltage-ranges and vmmc
(see the example below).
I've tested this settings on 3.19 kernel and able to backport on 3.13.
wlan_en_reg: fixedregulator {
compa
On Sun, Feb 15, 2015 at 4:54 AM, John Tobias wrote:
> Hi Fabio,
>
> I was able to work it.
Care to share the solution?
--
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/major
Hi Fabio,
I was able to work it.
Regards,
John
On Sat, Feb 14, 2015 at 10:48 AM, Fabio Estevam wrote:
> Hi John,
>
> On Wed, Feb 11, 2015 at 10:24 PM, John Tobias
> wrote:
>> Hello All,
>>
>> We interface the WiLink8 (http://www.ti.com/lit/gpn/wl1807mod) in iMX6
>> custom board. The VIO is 1
Hi John,
On Wed, Feb 11, 2015 at 10:24 PM, John Tobias wrote:
> Hello All,
>
> We interface the WiLink8 (http://www.ti.com/lit/gpn/wl1807mod) in iMX6
> custom board. The VIO is 1.8v and the kernel detect the chip in high
> speed mode with a signal voltage of 3.3v.
>
> Is there a way to force the
Hello All,
We interface the WiLink8 (http://www.ti.com/lit/gpn/wl1807mod) in iMX6
custom board. The VIO is 1.8v and the kernel detect the chip in high
speed mode with a signal voltage of 3.3v.
Is there a way to force the kernel to use a 1.8v signal voltage?.
Regards,
John Tobias
--
To unsubscri
rrowed.
This all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if SDIO interrupts are enabled.
A host should call mmc_sdio_want_no_clocks() when about to turn of
clocks if sdio interrupts are enabled, and the ->disable() function
should not use a t
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
Enabling SDIO IRQ signalling for the wifi MMC/SDIO slot
doubles the transmission transfer rate.
Signed-off-by: Javier Martinez Canillas
---
Changes since v1: None, new patch.
---
arch/arm/boot/dts/exynos5250-snow.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts
On 27 January 2015 at 12:47, NeilBrown wrote:
>
> The (libertas) wifi chip in my GTA04 is connected to an OMAP3 HS_MMC port as
> an SDIO card.
>
> When I configure it (via devicetree) to respond to the SD interrupt line
> (rather than polling for SD interrupts) it doesn&
The (libertas) wifi chip in my GTA04 is connected to an OMAP3 HS_MMC port as
an SDIO card.
When I configure it (via devicetree) to respond to the SD interrupt line
(rather than polling for SD interrupts) it doesn't work well at all.
After lots of experimenting and beating my head agai
> http://storage.kernelci.org/stable/v3.14.29/arm-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html
> >
> > This happens if the sdhci interrupt status contains SDHCI_INT_CARD_INT,
> > while the sdio irq was never setup. This patch fixes that in a minimal
> > way
wake_up_process+0x8/0x40
> LR is at sdhci_irq+0x748/0x9c4
>
> Full boot log can be found at:
>
> http://storage.kernelci.org/stable/v3.14.29/arm-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html
>
> This happens if the sdhci interrupt status contains SDHCI_INT_
-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html
This happens if the sdhci interrupt status contains SDHCI_INT_CARD_INT,
while the sdio irq was never setup. This patch fixes that in a minimal
way by checking if the sdio irq was setup.
In more recent kernels this bug went away due to refactoring done
resend or if it's possible to just send an incremental path
>> > on top?
>>
>> The patches that landed look good to me, but I think you might break
>> omap3pandora's WiFi until you land patch #1 in the series. It has
>> Tony's Ack so I think he inte
1 - 100 of 1792 matches
Mail list logo
