From: Stephen Warren <swarren@wwwdotorg.org>
To: Dinh Nguyen <dinguyen@altera.com>
Cc: cjb@laptop.org, dinh.linux@gmail.com,
Jaehoon Chung <jh80.chung@samsung.com>,
Seungwon Jeon <tgih.jun@samsung.com>,
Rob Herring <rob.herring@calxeda.com>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ian.campbell@citrix.com>,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2] ARM: socfpga: dts: Add support for SD/MMC
Date: Fri, 09 Aug 2013 16:58:18 -0600 [thread overview]
Message-ID: <5205740A.50206@wwwdotorg.org> (raw)
In-Reply-To: <1376088088.14580.4.camel@linux-builds1>
On 08/09/2013 04:41 PM, Dinh Nguyen wrote:
> On Fri, 2013-08-09 at 15:00 -0600, Stephen Warren wrote:
>> On 08/08/2013 05:10 PM, Dinh Nguyen wrote:
>>> On Thu, 2013-08-08 at 15:13 -0600, Stephen Warren wrote:
>> ...
>>>> Why is there a need to directly represent the divider anywhere? The
>>>> driver can find the rate of the input clock, and I assume it knows what
>>>> rate it wants the clock to run at, so can't it calculate the divider
>>>> based on those two pieces of information?
>>>
>>> CC: Chris Ball
>>>>
>>>> Or, does the driver really not know what rate it wants the clock to be
>>>> after the internal divider? If not, then I think that *rate* should be
>>>> recorded in DT, not the divider to obtain that rate.
>>>>
>>>
>>> I believe that this is the case, that the driver does not know what rate
>>> it will clock the SD card at. I think internally we did have a "bus_hz"
>>> in DT a while back. I guess I don't really understand why it would be
>>> better to have a *rate* DT entry instead of a fixed-divider entry?
>>
>> The value of the divider depends on two things:
>>
>> 1) Input clock rate.
>> 2) Desired rate after applying the internal divider.
>>
>> The input clock rate may vary, either between SoCs the IP is integrated
>> into, or even at run-time perhaps base on clk_set_rate() etc.
>>
>> If the MMC driver knows the clock rate it wants to run at, it can
>> calculate the divider easily; it can automatically adjust to any input
>> clock that its environment may provide.
>>
>> If the MMC driver is simply told "use this divider", that's encoding
>> assumptions about the rate of the input clock which might not be valid;.
>> Encoding the desire clock rate within the MMC HW block allows the
>> divider to be calculated based on the actual environment.
>
> Thanks Stephen. That makes sense.
>
> Chris, Jaehoon, and Seungwon, do you have any inputs? If not I will go
> down the path of have the "bus-hz" in the DTS node for the clock rate of
> the CIU clock. Then I would also make the same change to dw_mmc-exynos
> but would need your help on what the rate would be.
>
> For SOCFPGA, its 12.5 MHZ.
I'm not sure "bus-hz" is the right name; it's not clear from that name
that it refers to an internal clock inside the MMC controller rather
than the SD bus out to the card itself. Perhaps "controller-clock-hz" or
something like that?
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2] ARM: socfpga: dts: Add support for SD/MMC
Date: Fri, 09 Aug 2013 16:58:18 -0600 [thread overview]
Message-ID: <5205740A.50206@wwwdotorg.org> (raw)
In-Reply-To: <1376088088.14580.4.camel@linux-builds1>
On 08/09/2013 04:41 PM, Dinh Nguyen wrote:
> On Fri, 2013-08-09 at 15:00 -0600, Stephen Warren wrote:
>> On 08/08/2013 05:10 PM, Dinh Nguyen wrote:
>>> On Thu, 2013-08-08 at 15:13 -0600, Stephen Warren wrote:
>> ...
>>>> Why is there a need to directly represent the divider anywhere? The
>>>> driver can find the rate of the input clock, and I assume it knows what
>>>> rate it wants the clock to run at, so can't it calculate the divider
>>>> based on those two pieces of information?
>>>
>>> CC: Chris Ball
>>>>
>>>> Or, does the driver really not know what rate it wants the clock to be
>>>> after the internal divider? If not, then I think that *rate* should be
>>>> recorded in DT, not the divider to obtain that rate.
>>>>
>>>
>>> I believe that this is the case, that the driver does not know what rate
>>> it will clock the SD card at. I think internally we did have a "bus_hz"
>>> in DT a while back. I guess I don't really understand why it would be
>>> better to have a *rate* DT entry instead of a fixed-divider entry?
>>
>> The value of the divider depends on two things:
>>
>> 1) Input clock rate.
>> 2) Desired rate after applying the internal divider.
>>
>> The input clock rate may vary, either between SoCs the IP is integrated
>> into, or even at run-time perhaps base on clk_set_rate() etc.
>>
>> If the MMC driver knows the clock rate it wants to run at, it can
>> calculate the divider easily; it can automatically adjust to any input
>> clock that its environment may provide.
>>
>> If the MMC driver is simply told "use this divider", that's encoding
>> assumptions about the rate of the input clock which might not be valid;.
>> Encoding the desire clock rate within the MMC HW block allows the
>> divider to be calculated based on the actual environment.
>
> Thanks Stephen. That makes sense.
>
> Chris, Jaehoon, and Seungwon, do you have any inputs? If not I will go
> down the path of have the "bus-hz" in the DTS node for the clock rate of
> the CIU clock. Then I would also make the same change to dw_mmc-exynos
> but would need your help on what the rate would be.
>
> For SOCFPGA, its 12.5 MHZ.
I'm not sure "bus-hz" is the right name; it's not clear from that name
that it refers to an internal clock inside the MMC controller rather
than the SD bus out to the card itself. Perhaps "controller-clock-hz" or
something like that?
next prev parent reply other threads:[~2013-08-09 22:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 20:43 [PATCHv2] ARM: socfpga: dts: Add support for SD/MMC dinguyen
2013-08-05 20:43 ` dinguyen at altera.com
2013-08-08 20:14 ` Stephen Warren
2013-08-08 20:14 ` Stephen Warren
2013-08-08 20:32 ` Dinh Nguyen
2013-08-08 20:32 ` Dinh Nguyen
2013-08-08 20:37 ` Stephen Warren
2013-08-08 20:37 ` Stephen Warren
2013-08-08 20:54 ` Dinh Nguyen
2013-08-08 20:54 ` Dinh Nguyen
2013-08-08 21:13 ` Stephen Warren
2013-08-08 21:13 ` Stephen Warren
2013-08-08 23:10 ` Dinh Nguyen
2013-08-08 23:10 ` Dinh Nguyen
2013-08-09 21:00 ` Stephen Warren
2013-08-09 21:00 ` Stephen Warren
2013-08-09 22:41 ` Dinh Nguyen
2013-08-09 22:41 ` Dinh Nguyen
2013-08-09 22:58 ` Stephen Warren [this message]
2013-08-09 22:58 ` Stephen Warren
2013-08-12 15:11 ` Dinh Nguyen
2013-08-12 15:11 ` 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=5205740A.50206@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=cjb@laptop.org \
--cc=devicetree@vger.kernel.org \
--cc=dinguyen@altera.com \
--cc=dinh.linux@gmail.com \
--cc=ian.campbell@citrix.com \
--cc=jh80.chung@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=tgih.jun@samsung.com \
/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.