Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1693751 > unrolled thread

[PATCH 0/2] add ESP8089 WiFi chip driver

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] add ESP8089 WiFi chip driver Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-07-21 16:40 +0200
    Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver Greg KH <gregkh@linuxfoundation.org> - 2017-07-21 17:10 +0200
      Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-07-21 19:00 +0200
        Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver Marcel Holtmann <marcel@holtmann.org> - 2017-07-21 19:00 +0200
          Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-07-21 19:10 +0200
            Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver Kalle Valo <kvalo@codeaurora.org> - 2017-07-25 10:40 +0200
    Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver Marcel Holtmann <marcel@holtmann.org> - 2017-07-21 17:30 +0200
    [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-07-21 17:50 +0200
      Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end  functions Shawn Lin <shawn.lin@rock-chips.com> - 2017-07-22 16:20 +0200

#1693751 — [PATCH 0/2] add ESP8089 WiFi chip driver

The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
There is one in A23 Polaroid tablets for example.

The chip is often embedded as an eMMC SDIO device.

At the moment, there is no publicly available datasheet for this chip.

The code was taken from an out-of-tree repository and has seen a first
pass in the cleanup process.

Three firmwares are needed and will be soon posted to linux-firmware.

Hans already tried to push the first patch and there had been some
discussions going on with Ulf here[1]. Basically, Ulf proposed to send
an RFC of a better solution to the problem Hans exposed in his cover
letter.
I've been looking for a few hours where this RFC could be and I
unfortunately haven't found it. Moreover, nothing recently submitted
matches a potential solution to this problem (but I may be wrong). I'm
basically trying to revive the discussion on this matter since only a
hack can make this driver work ATM (see Hans' cover letter).

I am posting this driver to staging as it still requires some cleanup
but can be used as is.

Thanks,
Quentin

[1] http://www.spinics.net/lists/linux-mmc/msg38410.html

Hans de Goede (1):
  mmc: Add mmc_force_detect_change_begin / _end functions

Quentin Schulz (1):
  staging: net: wireless: add ESP8089 WiFi driver

 drivers/mmc/core/core.c                     |   47 +-
 drivers/staging/Kconfig                     |    2 +
 drivers/staging/Makefile                    |    1 +
 drivers/staging/esp8089/Kconfig             |   13 +
 drivers/staging/esp8089/Makefile            |    7 +
 drivers/staging/esp8089/esp_ctrl.c          |  527 ++++++++
 drivers/staging/esp8089/esp_ctrl.h          |   48 +
 drivers/staging/esp8089/esp_debug.c         |  247 ++++
 drivers/staging/esp8089/esp_debug.h         |   69 ++
 drivers/staging/esp8089/esp_file.c          |  221 ++++
 drivers/staging/esp8089/esp_file.h          |   30 +
 drivers/staging/esp8089/esp_init_data.h     |   17 +
 drivers/staging/esp8089/esp_io.c            |  294 +++++
 drivers/staging/esp8089/esp_mac80211.c      | 1496 +++++++++++++++++++++++
 drivers/staging/esp8089/esp_mac80211.h      |   33 +
 drivers/staging/esp8089/esp_main.c          |  199 ++++
 drivers/staging/esp8089/esp_pub.h           |  188 +++
 drivers/staging/esp8089/esp_sif.h           |  131 ++
 drivers/staging/esp8089/esp_sip.c           | 1718 +++++++++++++++++++++++++++
 drivers/staging/esp8089/esp_sip.h           |  150 +++
 drivers/staging/esp8089/esp_utils.c         |  133 +++
 drivers/staging/esp8089/esp_utils.h         |   27 +
 drivers/staging/esp8089/esp_wl.h            |   35 +
 drivers/staging/esp8089/esp_wmac.h          |   87 ++
 drivers/staging/esp8089/sdio_sif_esp.c      |  552 +++++++++
 drivers/staging/esp8089/sip2_common.h       |  388 ++++++
 drivers/staging/esp8089/slc_host_register.h |  263 ++++
 include/linux/mmc/host.h                    |    7 +
 28 files changed, 6925 insertions(+), 5 deletions(-)
 create mode 100644 drivers/staging/esp8089/Kconfig
 create mode 100644 drivers/staging/esp8089/Makefile
 create mode 100644 drivers/staging/esp8089/esp_ctrl.c
 create mode 100644 drivers/staging/esp8089/esp_ctrl.h
 create mode 100644 drivers/staging/esp8089/esp_debug.c
 create mode 100644 drivers/staging/esp8089/esp_debug.h
 create mode 100644 drivers/staging/esp8089/esp_file.c
 create mode 100644 drivers/staging/esp8089/esp_file.h
 create mode 100644 drivers/staging/esp8089/esp_init_data.h
 create mode 100644 drivers/staging/esp8089/esp_io.c
 create mode 100644 drivers/staging/esp8089/esp_mac80211.c
 create mode 100644 drivers/staging/esp8089/esp_mac80211.h
 create mode 100644 drivers/staging/esp8089/esp_main.c
 create mode 100644 drivers/staging/esp8089/esp_pub.h
 create mode 100644 drivers/staging/esp8089/esp_sif.h
 create mode 100644 drivers/staging/esp8089/esp_sip.c
 create mode 100644 drivers/staging/esp8089/esp_sip.h
 create mode 100644 drivers/staging/esp8089/esp_utils.c
 create mode 100644 drivers/staging/esp8089/esp_utils.h
 create mode 100644 drivers/staging/esp8089/esp_wl.h
 create mode 100644 drivers/staging/esp8089/esp_wmac.h
 create mode 100644 drivers/staging/esp8089/sdio_sif_esp.c
 create mode 100644 drivers/staging/esp8089/sip2_common.h
 create mode 100644 drivers/staging/esp8089/slc_host_register.h

-- 
2.11.0

[toc] | [next] | [standalone]

#1693776 — Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

On Fri, Jul 21, 2017 at 04:35:01PM +0200, Quentin Schulz wrote:
> The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
> There is one in A23 Polaroid tablets for example.
> 
> The chip is often embedded as an eMMC SDIO device.
> 
> The code was taken from an out-of-tree repository and has seen a first
> pass in the cleanup process.
> 
> At the moment, there is no publicly available datasheet for this chip.
> 
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Icenowy Zheng <icenowy@aosc.xyz>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>

Staging drivers need a TODO file that lists what has to be done to the
code to get it out of staging.  Why not just take a day or so and fix up
the remaining issues and get it into the "real" part of the kernel
correctly?

Also, staging drivers have to be "stand-alone", I can't take stuff that
requires core changes only for one staging driver.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1693861 — Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Greg,

On 21/07/2017 17:01, Greg KH wrote:
> On Fri, Jul 21, 2017 at 04:35:01PM +0200, Quentin Schulz wrote:
>> The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
>> There is one in A23 Polaroid tablets for example.
>>
>> The chip is often embedded as an eMMC SDIO device.
>>
>> The code was taken from an out-of-tree repository and has seen a first
>> pass in the cleanup process.
>>
>> At the moment, there is no publicly available datasheet for this chip.
>>
>> Cc: Hans de Goede <hdegoede@redhat.com>
>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> 
> Staging drivers need a TODO file that lists what has to be done to the
> code to get it out of staging.  Why not just take a day or so and fix up
> the remaining issues and get it into the "real" part of the kernel
> correctly?
> 

OK, I'll work on a TODO list. Is there anything else I should know about
staging drivers so I can address everything at the same time?

From a driver that has already been cleaned up a bit by Icenowy and
Hans, it took me between 10 and 15 working days to this step, which I
estimate to be around 50% of total clean up (and we're only speaking
about coding style and dead code mainly, nothing about a bit of code
review, code robustness...). I find the code not really easy to follow
(might be because I'm a beginner in the subsystem as well).

I might not be the most efficient person in cleaning up drivers but I'm
pretty sure this isn't a one day cleanup. (Would be happy to be proven
otherwise :) ), else I would have done it as you suggest.

> Also, staging drivers have to be "stand-alone", I can't take stuff that
> requires core changes only for one staging driver.
> 

Yes, I didn't expect the first version to go through, the goal was to
revive the discussion on this core patch as there was a consensus that
the requested feature was needed.

Thanks,
Quentin

> thanks,
> 
> greg k-h
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1693864 — Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Quentin,

>>> The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
>>> There is one in A23 Polaroid tablets for example.
>>> 
>>> The chip is often embedded as an eMMC SDIO device.
>>> 
>>> The code was taken from an out-of-tree repository and has seen a first
>>> pass in the cleanup process.
>>> 
>>> At the moment, there is no publicly available datasheet for this chip.
>>> 
>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> 
>> Staging drivers need a TODO file that lists what has to be done to the
>> code to get it out of staging.  Why not just take a day or so and fix up
>> the remaining issues and get it into the "real" part of the kernel
>> correctly?
>> 
> 
> OK, I'll work on a TODO list. Is there anything else I should know about
> staging drivers so I can address everything at the same time?
> 
> From a driver that has already been cleaned up a bit by Icenowy and
> Hans, it took me between 10 and 15 working days to this step, which I
> estimate to be around 50% of total clean up (and we're only speaking
> about coding style and dead code mainly, nothing about a bit of code
> review, code robustness...). I find the code not really easy to follow
> (might be because I'm a beginner in the subsystem as well).
> 
> I might not be the most efficient person in cleaning up drivers but I'm
> pretty sure this isn't a one day cleanup. (Would be happy to be proven
> otherwise :) ), else I would have done it as you suggest.

even if it takes you 1 month to clean it up, get it reviewed on linux-wireless and target wireless-drivers instead of staging. When I had a brief a look at your patch, it didn't look like staging material to me.

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1693869 — Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Marcel,

On 21/07/2017 18:52, Marcel Holtmann wrote:
> Hi Quentin,
> 
>>>> The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
>>>> There is one in A23 Polaroid tablets for example.
>>>>
>>>> The chip is often embedded as an eMMC SDIO device.
>>>>
>>>> The code was taken from an out-of-tree repository and has seen a first
>>>> pass in the cleanup process.
>>>>
>>>> At the moment, there is no publicly available datasheet for this chip.
>>>>
>>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>>
>>> Staging drivers need a TODO file that lists what has to be done to the
>>> code to get it out of staging.  Why not just take a day or so and fix up
>>> the remaining issues and get it into the "real" part of the kernel
>>> correctly?
>>>
>>
>> OK, I'll work on a TODO list. Is there anything else I should know about
>> staging drivers so I can address everything at the same time?
>>
>> From a driver that has already been cleaned up a bit by Icenowy and
>> Hans, it took me between 10 and 15 working days to this step, which I
>> estimate to be around 50% of total clean up (and we're only speaking
>> about coding style and dead code mainly, nothing about a bit of code
>> review, code robustness...). I find the code not really easy to follow
>> (might be because I'm a beginner in the subsystem as well).
>>
>> I might not be the most efficient person in cleaning up drivers but I'm
>> pretty sure this isn't a one day cleanup. (Would be happy to be proven
>> otherwise :) ), else I would have done it as you suggest.
> 
> even if it takes you 1 month to clean it up, get it reviewed on linux-wireless and target wireless-drivers instead of staging. When I had a brief a look at your patch, it didn't look like staging material to me.
> 

We don't have a client supporting this effort and I don't think the
company I work for would support this effort (maybe it would, but
definitely spread over a long long period), so we're talking about 10-15
working days spread over my free time/week-end, that isn't for in one
month :) I could use help for sure on this driver, that's why I posted
it in staging.

I've done the cleanup on a per-file basis so maybe you looked at one of
the cleaned up files?

Just to be sure, you're telling me that I should post it as is on
linux-wireless and then work with the reviews? Or are you telling me to
take "1 month to clean it up" and then post it on linux-wireless?

Thanks,
Quentin

> Regards
> 
> Marcel
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1695495 — Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

(adding linux-wireless)

Quentin Schulz <quentin.schulz@free-electrons.com> writes:

> Hi Marcel,
>
> On 21/07/2017 18:52, Marcel Holtmann wrote:
>> Hi Quentin,
>> 
>>>>> The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
>>>>> There is one in A23 Polaroid tablets for example.
>>>>>
>>>>> The chip is often embedded as an eMMC SDIO device.
>>>>>
>>>>> The code was taken from an out-of-tree repository and has seen a first
>>>>> pass in the cleanup process.
>>>>>
>>>>> At the moment, there is no publicly available datasheet for this chip.
>>>>>
>>>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>>>> Cc: Icenowy Zheng <icenowy@aosc.xyz>
>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>>>
>>>> Staging drivers need a TODO file that lists what has to be done to the
>>>> code to get it out of staging.  Why not just take a day or so and fix up
>>>> the remaining issues and get it into the "real" part of the kernel
>>>> correctly?
>>>>
>>>
>>> OK, I'll work on a TODO list. Is there anything else I should know about
>>> staging drivers so I can address everything at the same time?
>>>
>>> From a driver that has already been cleaned up a bit by Icenowy and
>>> Hans, it took me between 10 and 15 working days to this step, which I
>>> estimate to be around 50% of total clean up (and we're only speaking
>>> about coding style and dead code mainly, nothing about a bit of code
>>> review, code robustness...). I find the code not really easy to follow
>>> (might be because I'm a beginner in the subsystem as well).
>>>
>>> I might not be the most efficient person in cleaning up drivers but I'm
>>> pretty sure this isn't a one day cleanup. (Would be happy to be proven
>>> otherwise :) ), else I would have done it as you suggest.
>> 
>> even if it takes you 1 month to clean it up, get it reviewed on
>> linux-wireless and target wireless-drivers instead of staging. When I
>> had a brief a look at your patch, it didn't look like staging
>> material to me.

I did only a 30 sec review (right now no time for proper review because
I have quite a lot of catching up after vacation) but based on what I
saw the driver looks promising. So I agree with Marcel, you should try
to submit this via linux-wireless first and only use staging as the last
resort.

> We don't have a client supporting this effort and I don't think the
> company I work for would support this effort (maybe it would, but
> definitely spread over a long long period), so we're talking about 10-15
> working days spread over my free time/week-end, that isn't for in one
> month :) I could use help for sure on this driver, that's why I posted
> it in staging.
>
> I've done the cleanup on a per-file basis so maybe you looked at one of
> the cleaned up files?
>
> Just to be sure, you're telling me that I should post it as is on
> linux-wireless and then work with the reviews? Or are you telling me to
> take "1 month to clean it up" and then post it on linux-wireless?

I recommend to post the patch to linux-wireless now and see what
comments you get. Then I can also when a proper review and have better
guidance.

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]

#1693794 — Re: [PATCH 1/2] staging: net: wireless: add ESP8089 WiFi driver

Hi Quentin,

> The Espressif ESP8089 WiFi chips can be often found in cheap tablets.
> There is one in A23 Polaroid tablets for example.
> 
> The chip is often embedded as an eMMC SDIO device.
> 
> The code was taken from an out-of-tree repository and has seen a first
> pass in the cleanup process.
> 
> At the moment, there is no publicly available datasheet for this chip.
> 
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Icenowy Zheng <icenowy@aosc.xyz>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/staging/Kconfig                     |    2 +
> drivers/staging/Makefile                    |    1 +
> drivers/staging/esp8089/Kconfig             |   13 +
> drivers/staging/esp8089/Makefile            |    7 +
> drivers/staging/esp8089/esp_ctrl.c          |  527 ++++++++
> drivers/staging/esp8089/esp_ctrl.h          |   48 +
> drivers/staging/esp8089/esp_debug.c         |  247 ++++
> drivers/staging/esp8089/esp_debug.h         |   69 ++
> drivers/staging/esp8089/esp_file.c          |  221 ++++
> drivers/staging/esp8089/esp_file.h          |   30 +
> drivers/staging/esp8089/esp_init_data.h     |   17 +
> drivers/staging/esp8089/esp_io.c            |  294 +++++
> drivers/staging/esp8089/esp_mac80211.c      | 1496 +++++++++++++++++++++++
> drivers/staging/esp8089/esp_mac80211.h      |   33 +
> drivers/staging/esp8089/esp_main.c          |  199 ++++
> drivers/staging/esp8089/esp_pub.h           |  188 +++
> drivers/staging/esp8089/esp_sif.h           |  131 ++
> drivers/staging/esp8089/esp_sip.c           | 1718 +++++++++++++++++++++++++++
> drivers/staging/esp8089/esp_sip.h           |  150 +++
> drivers/staging/esp8089/esp_utils.c         |  133 +++
> drivers/staging/esp8089/esp_utils.h         |   27 +
> drivers/staging/esp8089/esp_wl.h            |   35 +
> drivers/staging/esp8089/esp_wmac.h          |   87 ++
> drivers/staging/esp8089/sdio_sif_esp.c      |  552 +++++++++
> drivers/staging/esp8089/sip2_common.h       |  388 ++++++
> drivers/staging/esp8089/slc_host_register.h |  263 ++++
> 26 files changed, 6876 insertions(+)
> create mode 100644 drivers/staging/esp8089/Kconfig
> create mode 100644 drivers/staging/esp8089/Makefile
> create mode 100644 drivers/staging/esp8089/esp_ctrl.c
> create mode 100644 drivers/staging/esp8089/esp_ctrl.h
> create mode 100644 drivers/staging/esp8089/esp_debug.c
> create mode 100644 drivers/staging/esp8089/esp_debug.h
> create mode 100644 drivers/staging/esp8089/esp_file.c
> create mode 100644 drivers/staging/esp8089/esp_file.h
> create mode 100644 drivers/staging/esp8089/esp_init_data.h
> create mode 100644 drivers/staging/esp8089/esp_io.c
> create mode 100644 drivers/staging/esp8089/esp_mac80211.c
> create mode 100644 drivers/staging/esp8089/esp_mac80211.h
> create mode 100644 drivers/staging/esp8089/esp_main.c
> create mode 100644 drivers/staging/esp8089/esp_pub.h
> create mode 100644 drivers/staging/esp8089/esp_sif.h
> create mode 100644 drivers/staging/esp8089/esp_sip.c
> create mode 100644 drivers/staging/esp8089/esp_sip.h
> create mode 100644 drivers/staging/esp8089/esp_utils.c
> create mode 100644 drivers/staging/esp8089/esp_utils.h
> create mode 100644 drivers/staging/esp8089/esp_wl.h
> create mode 100644 drivers/staging/esp8089/esp_wmac.h
> create mode 100644 drivers/staging/esp8089/sdio_sif_esp.c
> create mode 100644 drivers/staging/esp8089/sip2_common.h
> create mode 100644 drivers/staging/esp8089/slc_host_register.h

why are you putting this into staging? Is it that bad?

Regards

Marcel

[toc] | [prev] | [next] | [standalone]

#1693808 — [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

From: Hans de Goede <hdegoede@redhat.com>

Some sdio devices have a multiple stage bring-up process. Specifically
the esp8089 (for which an out of tree driver is available) loads firmware
on the first call to its sdio-drivers' probe function and then resets
the device causing it to reboot from its RAM with the new firmware.

When this sdio device reboots it comes back up in 1 bit 400 KHz mode
again, and we need to walk through the whole ios negatiation and sdio setup
again.

There are 2 problems with this:

1) Typically these devices are soldered onto some (ARM) tablet / SBC
PCB and as such are described in devicetree as "non-removable", which
causes the mmc-core to scan them only once and not poll for the device
dropping of the bus. Normally this is the right thing todo but in the
eso8089 example we need the mmc-core to notice the module has disconnected
(since it is now in 1 bit mode again it will not talk to the host in 4 bit
mode). This can be worked around by using "broken-cd" in devicetree
instead of "non-removable", but that is not a proper fix since the device
really is non-removable.

2) When the mmc-core detects the device has disconnected it will poweroff
the device, causing the RAM loaded firmware to be lost. This can be worked
around in devicetree by using regulator-always-on (and avoiding the use of
mmc-pwrseq), but again that is more of a hack then a proper fix.

This commmit fixes 1) by adding a mmc_force_detect_change function which
will cause scanning for device removal / insertion until a new device is
detected. 2) Is fixed by a keep_power flag to the mmc_force_detect_change
function which when set causes the mmc-core to keep the power to the device
on during the rescan.

Cc: Icenowy Zheng <icenowy@aosc.xyz>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/mmc/core/core.c  | 47 ++++++++++++++++++++++++++++++++++++++++++-----
 include/linux/mmc/host.h |  7 +++++++
 2 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 26431267a3e2..103badde910b 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1620,8 +1620,11 @@ int mmc_select_drive_strength(struct mmc_card *card, unsigned int max_dtr,
  */
 void mmc_power_up(struct mmc_host *host, u32 ocr)
 {
-	if (host->ios.power_mode == MMC_POWER_ON)
+	if (host->ios.power_mode == MMC_POWER_ON) {
+		if (host->ios.clock == 0)
+			goto set_clock;
 		return;
+	}
 
 	mmc_pwrseq_pre_power_on(host);
 
@@ -1646,6 +1649,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
 
 	mmc_pwrseq_post_power_on(host);
 
+set_clock:
 	host->ios.clock = host->f_init;
 
 	host->ios.power_mode = MMC_POWER_ON;
@@ -1663,6 +1667,11 @@ void mmc_power_off(struct mmc_host *host)
 	if (host->ios.power_mode == MMC_POWER_OFF)
 		return;
 
+	if (host->rescan_keep_power) {
+		mmc_set_clock(host, 0);
+		return;
+	}
+
 	mmc_pwrseq_power_off(host);
 
 	host->ios.clock = 0;
@@ -1804,6 +1813,27 @@ void mmc_detect_change(struct mmc_host *host, unsigned long delay)
 }
 EXPORT_SYMBOL(mmc_detect_change);
 
+/**
+ *	mmc_force_detect_change - force rescanning of a MMC socket even if
+ *				  it is non-removable
+ *	@host: host to rescan
+ *	@delay: optional delay to wait before detection (jiffies)
+ *	@keep_power: if set do not turn of vdd / call pwrseq_off during rescan
+ *
+ *	MMC drivers which need non-removable sdio devices to be rescanned
+ *	(e.g. because the device reboots its fw after a firmware upload),
+ *	can call this to force scanning the MMC socket for changes, even
+ *	if it is non-removable.
+ */
+void mmc_force_detect_change(struct mmc_host *host, unsigned long delay,
+			     bool keep_power)
+{
+	host->rescan_force = 1;
+	host->rescan_keep_power = keep_power;
+	_mmc_detect_change(host, delay, false);
+}
+EXPORT_SYMBOL(mmc_force_detect_change);
+
 void mmc_init_erase(struct mmc_card *card)
 {
 	unsigned int sz;
@@ -2566,7 +2596,8 @@ void mmc_rescan(struct work_struct *work)
 		return;
 
 	/* If there is a non-removable card registered, only scan once */
-	if (!mmc_card_is_removable(host) && host->rescan_entered)
+	if (!mmc_card_is_removable(host) && host->rescan_entered &&
+	    !host->rescan_force)
 		return;
 	host->rescan_entered = 1;
 
@@ -2583,7 +2614,8 @@ void mmc_rescan(struct work_struct *work)
 	 * if there is a _removable_ card registered, check whether it is
 	 * still present
 	 */
-	if (host->bus_ops && !host->bus_dead && mmc_card_is_removable(host))
+	if (host->bus_ops && !host->bus_dead &&
+	    (mmc_card_is_removable(host) || host->rescan_force))
 		host->bus_ops->detect(host);
 
 	host->detect_change = 0;
@@ -2616,15 +2648,20 @@ void mmc_rescan(struct work_struct *work)
 	}
 
 	for (i = 0; i < ARRAY_SIZE(freqs); i++) {
-		if (!mmc_rescan_try_freq(host, max(freqs[i], host->f_min)))
+		if (!mmc_rescan_try_freq(host, max(freqs[i], host->f_min))) {
+			if (host->rescan_force) {
+				host->rescan_force = 0;
+				host->rescan_keep_power = 0;
+			}
 			break;
+		}
 		if (freqs[i] <= host->f_min)
 			break;
 	}
 	mmc_release_host(host);
 
  out:
-	if (host->caps & MMC_CAP_NEEDS_POLL)
+	if ((host->caps & MMC_CAP_NEEDS_POLL) || host->rescan_force)
 		mmc_schedule_delayed_work(&host->detect, HZ);
 }
 
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ebd1cebbef0c..d56d79867bbd 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -338,6 +338,8 @@ struct mmc_host {
 
 	int			rescan_disable;	/* disable card detection */
 	int			rescan_entered;	/* used with nonremovable devices */
+	int			rescan_force;	/* force rescan of (nonremovable) devices */
+	int			rescan_keep_power; /* Do not power off card */
 
 	int			need_retune;	/* re-tuning is needed */
 	int			hold_retune;	/* hold off re-tuning */
@@ -420,6 +422,11 @@ int mmc_power_save_host(struct mmc_host *host);
 int mmc_power_restore_host(struct mmc_host *host);
 
 void mmc_detect_change(struct mmc_host *, unsigned long delay);
+
+/* HdG: HACK HACK HACK do not upstream */
+#define MMC_HAS_FORCE_DETECT_CHANGE
+void mmc_force_detect_change(struct mmc_host *host, unsigned long delay,
+			     bool keep_power);
 void mmc_request_done(struct mmc_host *, struct mmc_request *);
 void mmc_command_done(struct mmc_host *host, struct mmc_request *mrq);
 
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1694161 — Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

invite Jack from expressif

在 2017/7/21 22:35, Quentin Schulz 写道:
> From: Hans de Goede <hdegoede@redhat.com>
>
> Some sdio devices have a multiple stage bring-up process. Specifically
> the esp8089 (for which an out of tree driver is available) loads firmware
> on the first call to its sdio-drivers' probe function and then resets
> the device causing it to reboot from its RAM with the new firmware.
>

Nice to see finally someone get into here!

I was bringing up ESP8089 for rockchip platforms 4 yeas ago with
Jack from espressif, the ESP8089 RD team, face 2 face. And I forgot
most the details but it seems indeed the limitation of RAM size so that
it has to use 2 stages boot-up method.

I hople Jack could give some suggestion or details about this.


> When this sdio device reboots it comes back up in 1 bit 400 KHz mode
> again, and we need to walk through the whole ios negatiation and sdio setup
> again.
>
> There are 2 problems with this:
>
> 1) Typically these devices are soldered onto some (ARM) tablet / SBC
> PCB and as such are described in devicetree as "non-removable", which
> causes the mmc-core to scan them only once and not poll for the device
> dropping of the bus. Normally this is the right thing todo but in the
> eso8089 example we need the mmc-core to notice the module has disconnected
> (since it is now in 1 bit mode again it will not talk to the host in 4 bit
> mode). This can be worked around by using "broken-cd" in devicetree
> instead of "non-removable", but that is not a proper fix since the device
> really is non-removable.
>
> 2) When the mmc-core detects the device has disconnected it will poweroff
> the device, causing the RAM loaded firmware to be lost. This can be worked
> around in devicetree by using regulator-always-on (and avoiding the use of
> mmc-pwrseq), but again that is more of a hack then a proper fix.
>
> This commmit fixes 1) by adding a mmc_force_detect_change function which
> will cause scanning for device removal / insertion until a new device is
> detected. 2) Is fixed by a keep_power flag to the mmc_force_detect_change
> function which when set causes the mmc-core to keep the power to the device
> on during the rescan.
>
> Cc: Icenowy Zheng <icenowy@aosc.xyz>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/mmc/core/core.c  | 47 ++++++++++++++++++++++++++++++++++++++++++-----
>  include/linux/mmc/host.h |  7 +++++++
>  2 files changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 26431267a3e2..103badde910b 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1620,8 +1620,11 @@ int mmc_select_drive_strength(struct mmc_card *card, unsigned int max_dtr,
>   */
>  void mmc_power_up(struct mmc_host *host, u32 ocr)
>  {
> -	if (host->ios.power_mode == MMC_POWER_ON)
> +	if (host->ios.power_mode == MMC_POWER_ON) {
> +		if (host->ios.clock == 0)
> +			goto set_clock;
>  		return;
> +	}
>
>  	mmc_pwrseq_pre_power_on(host);
>
> @@ -1646,6 +1649,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
>
>  	mmc_pwrseq_post_power_on(host);
>
> +set_clock:
>  	host->ios.clock = host->f_init;
>
>  	host->ios.power_mode = MMC_POWER_ON;
> @@ -1663,6 +1667,11 @@ void mmc_power_off(struct mmc_host *host)
>  	if (host->ios.power_mode == MMC_POWER_OFF)
>  		return;
>
> +	if (host->rescan_keep_power) {
> +		mmc_set_clock(host, 0);
> +		return;
> +	}
> +
>  	mmc_pwrseq_power_off(host);
>
>  	host->ios.clock = 0;
> @@ -1804,6 +1813,27 @@ void mmc_detect_change(struct mmc_host *host, unsigned long delay)
>  }
>  EXPORT_SYMBOL(mmc_detect_change);
>
> +/**
> + *	mmc_force_detect_change - force rescanning of a MMC socket even if
> + *				  it is non-removable
> + *	@host: host to rescan
> + *	@delay: optional delay to wait before detection (jiffies)
> + *	@keep_power: if set do not turn of vdd / call pwrseq_off during rescan
> + *
> + *	MMC drivers which need non-removable sdio devices to be rescanned
> + *	(e.g. because the device reboots its fw after a firmware upload),
> + *	can call this to force scanning the MMC socket for changes, even
> + *	if it is non-removable.
> + */
> +void mmc_force_detect_change(struct mmc_host *host, unsigned long delay,
> +			     bool keep_power)
> +{
> +	host->rescan_force = 1;
> +	host->rescan_keep_power = keep_power;
> +	_mmc_detect_change(host, delay, false);
> +}
> +EXPORT_SYMBOL(mmc_force_detect_change);
> +
>  void mmc_init_erase(struct mmc_card *card)
>  {
>  	unsigned int sz;
> @@ -2566,7 +2596,8 @@ void mmc_rescan(struct work_struct *work)
>  		return;
>
>  	/* If there is a non-removable card registered, only scan once */
> -	if (!mmc_card_is_removable(host) && host->rescan_entered)
> +	if (!mmc_card_is_removable(host) && host->rescan_entered &&
> +	    !host->rescan_force)
>  		return;
>  	host->rescan_entered = 1;
>
> @@ -2583,7 +2614,8 @@ void mmc_rescan(struct work_struct *work)
>  	 * if there is a _removable_ card registered, check whether it is
>  	 * still present
>  	 */
> -	if (host->bus_ops && !host->bus_dead && mmc_card_is_removable(host))
> +	if (host->bus_ops && !host->bus_dead &&
> +	    (mmc_card_is_removable(host) || host->rescan_force))
>  		host->bus_ops->detect(host);
>
>  	host->detect_change = 0;
> @@ -2616,15 +2648,20 @@ void mmc_rescan(struct work_struct *work)
>  	}
>
>  	for (i = 0; i < ARRAY_SIZE(freqs); i++) {
> -		if (!mmc_rescan_try_freq(host, max(freqs[i], host->f_min)))
> +		if (!mmc_rescan_try_freq(host, max(freqs[i], host->f_min))) {
> +			if (host->rescan_force) {
> +				host->rescan_force = 0;
> +				host->rescan_keep_power = 0;
> +			}
>  			break;
> +		}
>  		if (freqs[i] <= host->f_min)
>  			break;
>  	}
>  	mmc_release_host(host);
>
>   out:
> -	if (host->caps & MMC_CAP_NEEDS_POLL)
> +	if ((host->caps & MMC_CAP_NEEDS_POLL) || host->rescan_force)
>  		mmc_schedule_delayed_work(&host->detect, HZ);
>  }
>
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index ebd1cebbef0c..d56d79867bbd 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -338,6 +338,8 @@ struct mmc_host {
>
>  	int			rescan_disable;	/* disable card detection */
>  	int			rescan_entered;	/* used with nonremovable devices */
> +	int			rescan_force;	/* force rescan of (nonremovable) devices */
> +	int			rescan_keep_power; /* Do not power off card */
>
>  	int			need_retune;	/* re-tuning is needed */
>  	int			hold_retune;	/* hold off re-tuning */
> @@ -420,6 +422,11 @@ int mmc_power_save_host(struct mmc_host *host);
>  int mmc_power_restore_host(struct mmc_host *host);
>
>  void mmc_detect_change(struct mmc_host *, unsigned long delay);
> +
> +/* HdG: HACK HACK HACK do not upstream */
> +#define MMC_HAS_FORCE_DETECT_CHANGE
> +void mmc_force_detect_change(struct mmc_host *host, unsigned long delay,
> +			     bool keep_power);
>  void mmc_request_done(struct mmc_host *, struct mmc_request *);
>  void mmc_command_done(struct mmc_host *host, struct mmc_request *mrq);
>
>


-- 
Best Regards
Shawn Lin

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web