Dinh,
On Mon, Oct 20, 2014 at 9:31 AM, Dinh Nguyen
<dinguyen@xxxxxxxxxxxxxxxxxxxxx> 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.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
