From: Dinh Nguyen <dinh.linux@gmail.com>
To: Jaehoon Chung <jh80.chung@samsung.com>,
Dinh Nguyen <dinguyen@altera.com>
Cc: zhangfei <zhangfei.gao@linaro.org>,
arnd@arndb.de, cjb@laptop.org, tgih.jun@samsung.com,
heiko@sntech.de, dianders@chromium.org, alim.akhtar@samsung.com,
bzhao@marvell.com, linux-mmc@vger.kernel.org
Subject: Re: [PATCHv4] mmc: dw_mmc: Enable the hold reg for certain speed modes
Date: Wed, 08 Jan 2014 08:12:52 -0600 [thread overview]
Message-ID: <52CD5CE4.7050108@gmail.com> (raw)
In-Reply-To: <52CC9DC7.8000400@samsung.com>
On 1/7/14 6:37 PM, Jaehoon Chung wrote:
> Hi, Dinh.
>
> Sorry for replying too late.
>
> ..[snip]..
>>>>>>>> + sdr_timing[1] = ddr_timing[1] = 1;
>>>>>>>> + of_property_read_u32_array(np,
>>>>>>>> + "samsung,dw-mshc-sdr-timing", sdr_timing, 2);
>>>>>>>> +
>>>>>>>> + of_property_read_u32_array(np,
>>>>>>>> + "samsung,dw-mshc-ddr-timing", ddr_timing, 2);
>>>>>>>> +
>>>>>>>> + pdata->cclk_in_drv = 1;
>>>>>>>> + if ((sdr_timing[1] == 0) || (ddr_timing[1] == 0))
>>>>>>>> + pdata->cclk_in_drv = 0;
>>>>>>>> +
>>>>>>> Have some concern about whether it is suitable putting "samsung,~"
>>>>>>> property in dw_mmc.c, is it supposed to be platform related?
>>>>>>> Any conflict with drivers/mmc/host/dw_mmc-exynos.c?
>>>>>>> If they are really commonly used, how about change name and define in
>>>>>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt?
>>>>>> I had submitted a patch to make this a common binding before:
>>>>>>
>>>>>> http://www.spinics.net/lists/devicetree/msg00638.html
>>>>>>
>>>>>> I think the ultimate conclusion to that thread was that its perfectly
>>>>>> acceptable to re-use bindings from other
>>>>>> platforms.
>>>>>>
>>>>> Hmm, ususally I may look for the properties of dw_mmc.c in synopsys-dw-mshc.txt.
>>>>> If this is the conclusion before, then just ignore this noise.
>>>> If can be removed the samsung property, then i think property of clock timing can be used into dw-mmc.c
>>>> But if samsung property is used, well. I think right that it's used into dw_mmc-exynos.c.
>>>> Dw-mmc.c is general driver..so we don't want to include any SoC specific code.
>>> Then do you suggest I go forward with an attempt to add a new generic
>>> "snps,dw-mshc-sdr-timing"
>>> binding?
>> Ping Jaehoon?
>>
>> Do you think I need to add a generic "snps,dw-mshc-sdr-timing" and
>> "snps,dw-mshc-ddr-timing" bindings then?
> Well, i think it's also something wrong. ddr/sdr-timing is exynos specific value, not synopsys value.
> If synopsys use the sdr/ddr timing, then it's right that "snps, dw-mshc-sdr/ddr-timing" is used.
I went through the databook and I think that the timing values are
mentioned throughout the spec. It
just does not explicitly mentions ddr/sdr timing, but it is mentioned as
cclk_in_drv(aka drvsel), and
cclk_in_sample(aka smpsel). Even the macro in dw_mmc-exynos,
SDMMC_CLKSEL_CCLK_DRIVE() and
SDMMC_CLKSEL_CCLK_SAMPLE() is stating this.
So I do not believe that "samsung, dw-mshc-sdr-timing" and
"samsung,dw-mshc-ddr-timing" are not
exclusive to only the exynos platform. Just the fact that the SOCFPGA
platform can re-use the same
"samsung,dw-mshc-sdr-timing" property proves that this is not just an
exynos specific value.
> But i didn't see sdr/ddr timing in synopsys DoC.
> I know you want to control the hold-reg bit.
> But this approach is not good.
The spec has a table on when to use the hold-reg bit. The conditions for
using the hold-reg bit is
only dependent the hold-reg hw implementation and the value of
cclk_in_drv. The value of cclk_in_drv
is specified by the 2nd parameter of "samsung,dw-mshc-sdr-timing".
So I don't understand why you think this approach is "not good"?
Thanks,
Dinh
> Rather, how about using the callback function for exynos specific value.
> Then other SoC can also use it.
>
> Best Regards,
> Jaehoon Chung
>
>> Dinh
>>> Dinh
>>>> If i missed something, then let me know, plz.
>>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>> Thanks
>>>>>
>>>
>>
>>
>>
next prev parent reply other threads:[~2014-01-08 14:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 17:01 [PATCHv4] mmc: dw_mmc: Enable the hold reg for certain speed modes dinguyen
2013-12-17 8:11 ` zhangfei
2013-12-17 14:03 ` Dinh Nguyen
2013-12-17 14:54 ` zhangfei
2013-12-26 2:57 ` Jaehoon Chung
2013-12-26 17:26 ` Dinh Nguyen
2014-01-08 0:18 ` Dinh Nguyen
2014-01-08 0:37 ` Jaehoon Chung
2014-01-08 14:12 ` Dinh Nguyen [this message]
2014-01-09 3:41 ` Jaehoon Chung
2014-01-09 16:15 ` Dinh Nguyen
2014-01-13 6:27 ` Jaehoon Chung
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=52CD5CE4.7050108@gmail.com \
--to=dinh.linux@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=arnd@arndb.de \
--cc=bzhao@marvell.com \
--cc=cjb@laptop.org \
--cc=dianders@chromium.org \
--cc=dinguyen@altera.com \
--cc=heiko@sntech.de \
--cc=jh80.chung@samsung.com \
--cc=linux-mmc@vger.kernel.org \
--cc=tgih.jun@samsung.com \
--cc=zhangfei.gao@linaro.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.