From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver
Date: Wed, 18 Jun 2014 17:24:47 -0600 [thread overview]
Message-ID: <53A21FBF.5090806@wwwdotorg.org> (raw)
In-Reply-To: <20140618231410.GG26514@mithrandir>
On 06/18/2014 05:14 PM, Thierry Reding wrote:
> On Wed, Jun 18, 2014 at 04:09:06PM -0600, Stephen Warren wrote:
>> On 06/18/2014 04:03 PM, Thierry Reding wrote:
...
>>> From what I remember, Mike was fairly strongly opposing the idea of
>>> virtual clocks, but what you're proposing here sounds like it would
>>> assume the existence of virtual clocks. clk_set_rate() per client
>>> doesn't work with the current API as I understand it.
>>>
>>> Or perhaps what you're proposing isn't about the individual clocks at
>>> all but rather about a mechanism to express constraints for a set of
>>> clocks?
>>
>> This doesn't have anything to do with virtual clocks. As you mention,
>> it's just about constraints.
>>
>> One user of clock "cpu" wants min rate 216MHz. Another wants max rate
>> 1GHz. cpufreq will request some rate between the 2, or be capped to
>> those limits. These set of imposed constraints would need to be stored
>> per client of the clock, not per HW clock, since many clients could set
>> different max rates (e.g. thermal throttle 1.5GHz due to temperature,
>> CPU policy 1GHz due to the user selecting low CPU power, etc.)
>>
>> Similarly for audio, of there are N clients of 1 clock/PLL, and they
>> each want the PLL to run at a different rate, something needs to detect
>> that and deny it.
>
> I'm wondering how this should work with the current API. Could the clock
> core be modified to return a per-client struct clk * that references the
> hardware clock internally? Or do we need to add a new API?
I would assume the we can just change struct clk and hide the details
from any driver. Hopefully only clock-core and clock-drivers would need
any changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/e86187fa/attachment.sig>
next prev parent reply other threads:[~2014-06-18 23:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 13:35 [RFC PATCH 0/4] Tegra124: EMC scaling Tomeu Vizoso
2014-06-16 13:35 ` [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver Tomeu Vizoso
2014-06-16 14:03 ` Mikko Perttunen
2014-06-16 20:02 ` Stephen Warren
2014-06-17 12:16 ` Tomeu Vizoso
2014-06-17 16:15 ` Stephen Warren
2014-06-17 16:59 ` Mikko Perttunen
2014-06-18 17:23 ` Tomeu Vizoso
2014-06-18 17:46 ` Stephen Warren
2014-06-18 22:03 ` Thierry Reding
2014-06-18 22:09 ` Stephen Warren
2014-06-18 23:14 ` Thierry Reding
2014-06-18 23:24 ` Stephen Warren [this message]
2014-06-18 22:00 ` Thierry Reding
2014-06-18 22:19 ` Stéphane Marchesin
2014-06-18 22:33 ` Stephen Warren
2014-06-18 23:20 ` Thierry Reding
2014-06-17 22:35 ` Thierry Reding
2014-06-18 8:57 ` Peter De Schrijver
2014-06-16 13:35 ` [RFC PATCH 2/4] ARM: tegra: Add Tegra124 EMC support Tomeu Vizoso
2014-06-17 22:38 ` Thierry Reding
2014-06-16 13:35 ` [RFC PATCH 3/4] drm/tegra: Request memory bandwidth for the display controller Tomeu Vizoso
2014-06-16 20:06 ` Stephen Warren
2014-06-17 22:43 ` Thierry Reding
2014-06-16 13:35 ` [RFC PATCH 4/4] cpufreq: tegra: Register a minimum EMC frequency based on the CPU clock Tomeu Vizoso
2014-06-16 14:08 ` Mikko Perttunen
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=53A21FBF.5090806@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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