All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.