From: dinguyen@opensource.altera.com (Dinh Nguyen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect
Date: Mon, 20 Oct 2014 14:56:28 -0500 [thread overview]
Message-ID: <544568EC.5010201@opensource.altera.com> (raw)
In-Reply-To: <CAD=FV=Wcp8XsM52mMSNps4zR_GFchCKxJ+HpRc0j-CSFCZ_7PA@mail.gmail.com>
On 10/20/2014 02:48 PM, Doug Anderson wrote:
> Dinh,
>
> On Mon, Oct 20, 2014 at 12:30 PM, Doug Anderson <dianders@chromium.org> wrote:
>> Dinh,
>>
>> On Mon, Oct 20, 2014 at 9:31 AM, Dinh Nguyen
>> <dinguyen@opensource.altera.com> wrote:
>>>>> &mmc0 {
>>>>> - cd-gpios = <&gpio1 18 0>;
>>>>> + cd = <&gpio1 18 0>;
>>>>
>>>> This doesn't look right to me. What was the error that was passed back?
>>>>
>>>> I think your change has the same net effect as just deleting the
>>>> "cd-gpios" line. ...or is there some code somewhere that is parsing
>>>> the "cd" property.
>>>>
>>>
>>> It just hangs here:
>>>
>>> dw_mmc ff704000.dwmmc0: Using PIO mode.
>>> dw_mmc ff704000.dwmmc0: Version ID is 240a
>>> dw_mmc ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host data
>>> width, 1024 deep fifo
>>> platform ff704000.dwmmc0: Driver dw_mmc requests probe deferral
>>>
>>>
>>> Without this patch :
>>> mmc_of_parse ret=-517 (EPROBE_DEFER)
>>
>> I think you need to dig more into this error. Why are you getting an
>> -EPROBE_DEFER when you asked for this GPIO?
>>
>> The -EPROBE_DEFER tells the system that a resource is not available
>> yet and that it should try to re-run the dw_mmc init later once the
>> resource becomes available. I believe that some other bug is causing
>> the resource to never become available.
>>
>> Guesses:
>>
>> * The GPIO specifier is wrong in the DTB and is pointing to a GPIO
>> that would never exist.
>>
>> * Something is happening in the GPIO driver that is causing it to fail.
>>
>>
>> ...so we need to dig in further.
>
> One odd thing is that it looks like the GPIO controller you're
> referencing is disabled. On today's linuxnext, you can see the
> "disabled":
>
> arch/arm/boot/dts/socfpga.dtsi: gpio at ff709000 {
> arch/arm/boot/dts/socfpga.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/socfpga.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/socfpga.dtsi- compatible = "snps,dw-apb-gpio";
> arch/arm/boot/dts/socfpga.dtsi- reg = <0xff709000 0x1000>;
> arch/arm/boot/dts/socfpga.dtsi- clocks = <&per_base_clk>;
> arch/arm/boot/dts/socfpga.dtsi- status = "disabled";
> arch/arm/boot/dts/socfpga.dtsi-
> arch/arm/boot/dts/socfpga.dtsi- gpio1: gpio-controller at 0 {
> arch/arm/boot/dts/socfpga.dtsi- compatible =
> "snps,dw-apb-gpio-port";
> arch/arm/boot/dts/socfpga.dtsi- gpio-controller;
>
> I don't see anyone else referencing that node to enable it. ...to me
> that means that you can't use GPIOs on GPIO1 (???).
>
>
> ...or did I find something wrong?
>
Ah yes, yes! Thanks so much for find this Doug!
With the following patch, boots fine with SD driver loading.
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -37,6 +37,12 @@
*/
ethernet0 = &gmac1;
};
+
+ soc {
+ gpio at ff709000 {
+ status = "okay";
+ };
+ };
Thanks,
Dinh
WARNING: multiple messages have this Message-ID (diff)
From: Dinh Nguyen <dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Jaehoon Chung
<jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Dinh Nguyen <dinh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org"
<atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>,
"s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org"
<s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Subject: Re: [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect
Date: Mon, 20 Oct 2014 14:56:28 -0500 [thread overview]
Message-ID: <544568EC.5010201@opensource.altera.com> (raw)
In-Reply-To: <CAD=FV=Wcp8XsM52mMSNps4zR_GFchCKxJ+HpRc0j-CSFCZ_7PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/20/2014 02:48 PM, Doug Anderson wrote:
> Dinh,
>
> On Mon, Oct 20, 2014 at 12:30 PM, Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> Dinh,
>>
>> On Mon, Oct 20, 2014 at 9:31 AM, Dinh Nguyen
>> <dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org> wrote:
>>>>> &mmc0 {
>>>>> - cd-gpios = <&gpio1 18 0>;
>>>>> + cd = <&gpio1 18 0>;
>>>>
>>>> This doesn't look right to me. What was the error that was passed back?
>>>>
>>>> I think your change has the same net effect as just deleting the
>>>> "cd-gpios" line. ...or is there some code somewhere that is parsing
>>>> the "cd" property.
>>>>
>>>
>>> It just hangs here:
>>>
>>> dw_mmc ff704000.dwmmc0: Using PIO mode.
>>> dw_mmc ff704000.dwmmc0: Version ID is 240a
>>> dw_mmc ff704000.dwmmc0: DW MMC controller at irq 171, 32 bit host data
>>> width, 1024 deep fifo
>>> platform ff704000.dwmmc0: Driver dw_mmc requests probe deferral
>>>
>>>
>>> Without this patch :
>>> mmc_of_parse ret=-517 (EPROBE_DEFER)
>>
>> I think you need to dig more into this error. Why are you getting an
>> -EPROBE_DEFER when you asked for this GPIO?
>>
>> The -EPROBE_DEFER tells the system that a resource is not available
>> yet and that it should try to re-run the dw_mmc init later once the
>> resource becomes available. I believe that some other bug is causing
>> the resource to never become available.
>>
>> Guesses:
>>
>> * The GPIO specifier is wrong in the DTB and is pointing to a GPIO
>> that would never exist.
>>
>> * Something is happening in the GPIO driver that is causing it to fail.
>>
>>
>> ...so we need to dig in further.
>
> One odd thing is that it looks like the GPIO controller you're
> referencing is disabled. On today's linuxnext, you can see the
> "disabled":
>
> arch/arm/boot/dts/socfpga.dtsi: gpio@ff709000 {
> arch/arm/boot/dts/socfpga.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/socfpga.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/socfpga.dtsi- compatible = "snps,dw-apb-gpio";
> arch/arm/boot/dts/socfpga.dtsi- reg = <0xff709000 0x1000>;
> arch/arm/boot/dts/socfpga.dtsi- clocks = <&per_base_clk>;
> arch/arm/boot/dts/socfpga.dtsi- status = "disabled";
> arch/arm/boot/dts/socfpga.dtsi-
> arch/arm/boot/dts/socfpga.dtsi- gpio1: gpio-controller@0 {
> arch/arm/boot/dts/socfpga.dtsi- compatible =
> "snps,dw-apb-gpio-port";
> arch/arm/boot/dts/socfpga.dtsi- gpio-controller;
>
> I don't see anyone else referencing that node to enable it. ...to me
> that means that you can't use GPIOs on GPIO1 (???).
>
>
> ...or did I find something wrong?
>
Ah yes, yes! Thanks so much for find this Doug!
With the following patch, boots fine with SD driver loading.
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -37,6 +37,12 @@
*/
ethernet0 = &gmac1;
};
+
+ soc {
+ gpio@ff709000 {
+ status = "okay";
+ };
+ };
Thanks,
Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-10-20 19:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 15:31 [PATCHv2 0/2] ARM: dts: socfpga: fix booting with SD/MMC dinguyen at opensource.altera.com
2014-10-20 15:31 ` dinguyen
2014-10-20 15:31 ` [PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect dinguyen at opensource.altera.com
2014-10-20 15:31 ` dinguyen
2014-10-20 15:46 ` Doug Anderson
2014-10-20 15:46 ` Doug Anderson
2014-10-20 16:31 ` Dinh Nguyen
2014-10-20 16:31 ` Dinh Nguyen
2014-10-20 19:30 ` Doug Anderson
2014-10-20 19:30 ` Doug Anderson
2014-10-20 19:48 ` Doug Anderson
2014-10-20 19:48 ` Doug Anderson
2014-10-20 19:56 ` Dinh Nguyen [this message]
2014-10-20 19:56 ` Dinh Nguyen
2014-10-20 18:41 ` Mark Rutland
2014-10-20 18:41 ` Mark Rutland
2014-10-20 19:04 ` Dinh Nguyen
2014-10-20 19:04 ` Dinh Nguyen
2014-10-20 19:26 ` Doug Anderson
2014-10-20 19:26 ` Doug Anderson
2014-10-20 22:41 ` Mark Rutland
2014-10-20 22:41 ` Mark Rutland
2014-10-20 22:49 ` Jaehoon Chung
2014-10-20 22:49 ` Jaehoon Chung
2014-10-21 0:02 ` Doug Anderson
2014-10-21 0:02 ` Doug Anderson
2014-10-21 9:07 ` Mark Rutland
2014-10-21 9:07 ` Mark Rutland
2014-10-20 15:31 ` [PATCHv2 2/2] ARM: dts: socfpga: Add a 3.3V fixed regulator node dinguyen at opensource.altera.com
2014-10-20 15:31 ` dinguyen
2014-10-20 15:51 ` Doug Anderson
2014-10-20 15:51 ` Doug Anderson
2014-10-20 21:02 ` Dinh Nguyen
2014-10-20 21:02 ` Dinh Nguyen
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=544568EC.5010201@opensource.altera.com \
--to=dinguyen@opensource.altera.com \
--cc=linux-arm-kernel@lists.infradead.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.