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
next prev parent 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).