linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Kyle Evans <kvans32@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: sdio failure to initialize on warm boot.
Date: Mon, 22 Jan 2018 10:22:12 +0100	[thread overview]
Message-ID: <5A65AD44.6020506@broadcom.com> (raw)
In-Reply-To: <20180119160554.GA4162@localhost.localdomain>

On 1/19/2018 5:05 PM, Kyle Evans wrote:
> * Arend van Spriel <arend.vanspriel@broadcom.com>:
>> On 1/18/2018 6:50 PM, Kyle Evans wrote:
>>> * Arend van Spriel <arend.vanspriel@broadcom.com>:
>>>> On 1/12/2018 9:18 PM, Kyle Evans wrote:
>>>>> 2) After reboot I get this nasty error...
>>>>> [    0.000000] Kernel command line: console=tty0 selinux=0
>>>>> video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x20000
>>>>> [    2.269750] mmc0: Invalid maximum block size, assuming 512 bytes
>>>>> [    2.330010] mmc0: SDHCI controller on c8000000.sdhci [c8000000.sdhci]
>>>>> using ADMA
>>>>> [    2.645242] mmc0: error -110 whilst initialising SDIO card
>>>>
>>>> Ok. I suppose you mean a warm reboot. So I suppose the card is not
>>>> properly power cycled. If your SDHCI controller driver (is it
>>>> sdhci-acpi?) is loaded as a module, you could try to unload it and load
>>>> it again. Let me know if that works for you to confirm my guess.
>>>
>>> Your guess is correct. The following brings up wifi after failure to do
>>> so during warm boot.
>>>
>>> modprobe -r sdhci-tegra; modprobe sdhci-tegra;
>>
>> Do you know if your uses a device tree and where I can find it?
>> Typically, there is a GPIO to the wifi device that needs to be toggled
>> using mmc powerseq.
>
> I had a hunch this is was the next step. This device did not ship with a
> DT, but I have one in the works. My initial trial & error has been met
> with error.

So I am getting predictable huh?

> This is what I have so far, which is wrong since adding pwrseq (boot panic):
> 	sdhci@c8000000 {
>                  compatible = "nvidia,tegra20-sdhci";
>                  reg = <0xc8000000 0x200>;
>                  interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
>                  clocks = <&tegra_car TEGRA20_CLK_SDMMC1>;
>                  resets = <&tegra_car 14>;
>                  reset-names = "sdhci";
>
>                  status = "okay";
>                  //power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
>                  bus-width = <4>;
>                  keep-power-in-suspend;
>                  non-removable;
>                  mmc-pwrseq = <&wlan_rst>;
>
>                  brcmf: wifi@1 {
>                          compatible = "brcm,bcm4329-fmac";
>                          interrupt-parent = <&gpio>;
>                          interrupts = <TEGRA_GPIO(Y, 6) GPIO_ACTIVE_HIGH>,
>                                       <TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
>                          interrupt-names = "host-wake";

Always having a hard time reading this stuff. So does interrupts 
property state 2 interrupts here? If so, than interrupt-names should 
also have two names. Actually, according to the binding only a single 
interrupt should be given (only (S, 0) I think). Furthermore, you are 
missing the 'reg' property to specify the SDIO function, ie. "reg = <1>;".

>                  };
>          };
>
>          wlan_rst: sdhci0_pwrseq {
>                  compatible = "mmc-pwrseq-simple";
>                  reset-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_LOW>;
>          };

Ignoring the ext_clk stuff, the pwrseq-simple does following: upon power 
on, set reset-gpios to 1, power on bus, set reset-gpios back to 0, 
optionally wait for post_power_on_delay_ms. The pre-DT kernel stuff is 
different. It simply sets the reset gpio to 1 upon power on, and wait 
for 200ms leaving the gpio as is and does the same for power off.

TF101_SDIO_WOW seems for enabling host wakeup by the host-controller 
device for which I would expect the driver to call device_init_wakeup(). 
However, this functionality does not seem present in the sdhci-tegra driver.

Regards,
Arend

  reply	other threads:[~2018-01-22  9:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 12:51 brcmfmac4329-sdio firmware load failed Kyle Evans
2018-01-10  8:47 ` Arend van Spriel
2018-01-12 20:18   ` Kyle Evans
2018-01-13  9:19     ` Arend van Spriel
2018-01-16  1:20       ` Kyle Evans
2018-01-16 20:18         ` Arend van Spriel
2018-01-18 17:50       ` sdio failure to initialize on warm boot Kyle Evans
2018-01-19  8:21         ` Arend van Spriel
2018-01-19 16:05           ` Kyle Evans
2018-01-22  9:22             ` Arend van Spriel [this message]
2018-01-26 10:45               ` Kyle Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5A65AD44.6020506@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=kvans32@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).