Hello Omar,
On Wed, 2 May 2012, Omar Ramirez Luna wrote:
> Recently a patch went in for tidspbridge code, to ioremap
> SCM registers and solve a build break[1]. However it has
> been pointed out before that this is a layer violation
> given that control module should handle its own registers, thi
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
> To add a few more thoughts, while I agree with Paul that there is room for
> improvement in the APIs, I think the difference in opinion comes when we ask
> the question:
>
> "When we eventually refine the APIs in the future to be more
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
> This common clk API has been under development for over *two* years
> already, with several attempts to merge it. And each previous merge
> attempt aborted because someone came along at the last minute to do
> exactly what you are doing
Hello Sascha,
On Sat, 17 Mar 2012, Sascha Hauer wrote:
> On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
>
> > If the common clock code is to go upstream now, it should be marked as
> > experimental.
>
> No, please don't do this. This effectively
ode
might mistake the implementation or API as being stable and well-defined.
It sounds like the primary objection is to the use of CONFIG_EXPERIMENTAL.
So here is a patch to simply note the status of this code in its Kconfig
text.
- Paul
From: Paul Walmsley
Date: Tue, 20 Mar 2012 17:19:06 -060
and underlying code is likely to change in
significant ways.
Once at least two major SoC ports have DVFS with external I/O devices
safely up and running on their mainline kernels with the common clk code,
I'd suggest removing the experimental designation.
...
None of this is meant to reflect on
On Thu, 8 Mar 2012, Grant Likely wrote:
> Yes, absolutely use separate compatible values. It is always important
> to be specific as to the silicon implementing the IP.
In that case, it is probably best to use the full chip name in the
compatible string, e.g., omap2420 or omap2430 rather than j
, until the
UART driver takes control of it, for debug prints to appear on
the console.
Acked-by: Kevin Hilman
Acked-by: Benoit Cousson
Signed-off-by: Rajendra Nayak
[p...@pwsan.com: use a flag rather than a state; updated commit message;
edited some documentation]
Signed-off-by: Paul Walmsley
---
le.
Acked-by: Kevin Hilman
Acked-by: Benoit Cousson
Signed-off-by: Rajendra Nayak
[p...@pwsan.com: use a flag rather than a state; updated commit message;
edited some documentation]
Signed-off-by: Paul Walmsley
---
This patch needs to be applied along with Govindraj & Kevin's UART
Hi
On Tue, 13 Dec 2011, Mike Turquette wrote:
> omap_clk_get_by_name must die.
You do realize that it exists for a reason? That hardware clock names
don't have anything to do with the Linux device model?
- Paul
___
linaro-dev mailing list
linaro-d
On Tue, 13 Dec 2011, Turquette, Mike wrote:
> On Tue, Dec 13, 2011 at 8:27 PM, Paul Walmsley wrote:
> > On Tue, 13 Dec 2011, Mike Turquette wrote:
> >
> >> omap_clk_get_by_name must die.
> >
> > You do realize that it exists for a reason? That hardware clock
On Mon, 5 Dec 2011, Russell King - ARM Linux wrote:
> On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
>
> > But I'd propose that we instead increase the size of struct clk.rate to be
> > s64:
> >
> > s64 clk_round_rate(struct clk *clk, s64
On Mon, 5 Dec 2011, Paul Walmsley wrote:
> For example, here's a trivial implementation for rate recalculation for a
> integer divider clock node (that can't be handled with a right shift):
>
> s64 div(struct clk *clk, u32 div) {
> if (clk->fla
Hi
a brief comment concerning clock rates:
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +unsigned long clk_get_rate(struct clk *clk)
...
> +long clk_round_rate(struct clk *clk, unsigned long rate)
...
> +int clk_set_rate(struct clk *clk, unsigned long rate)
...
> +struct clk {
...
> +
Hi Russell,
On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
> On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> > 1. When a clock user calls clk_enable() on a clock, the clock framework
> > should prevent other users of the clock from changing the clock
On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
> On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> > The intention behind the clk_{allow,block}_rate_change() proposal was to
> > allow the current user of the clock to change its rate without having to
>
Hi Mark,
On Thu, 1 Dec 2011, Mark Brown wrote:
> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
>
> > Clock rate/parent-change notifiers are requirements for DVFS use-cases,
> > and they must be paired with something like the
> > clk_{allow,block}_ra
Hi Mike
a few brief comments.
On Wed, 30 Nov 2011, Turquette, Mike wrote:
> Likewise when a clk is requested to transition to a new frequency it
> will have to clear it with all of the clks below it, so there is still
> a need to propagate a request throughout the clk tree whenever
> clk_set_rat
Hello,
Here are some initial comments on clk_get_rate().
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +/**
> + * clk_get_rate - return the rate of clk
> + * @clk: the clk whose rate is being returned
> + *
> + * Simply returns the cached rate of the clk. Does not query the hardware.
> If
> +
Hi
a few initial comments on clk_get_parent().
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +/**
> + * clk_get_parent - return the parent of a clk
> + * @clk: the clk whose parent gets returned
> + *
> + * Simply returns clk->parent. It is up to the caller to hold the
> + * prepare_lock, if des
On Thu, 19 May 2011, Grant Likely wrote:
> Would either of you mind looking at this bug report? On the IGEP,
> when booting with DT is used, something appears to get messed up with
> initializing the clocks. In this case, the device tree isn't actually
> doing anything other than replacing ATAGs
21 matches
Mail list logo
