On 12/22, Sylwester Nawrocki wrote:
> Mike,
>
> On 22/12/15 19:44, Mike Turquette wrote:
> > This is superseded by the pull request found in Message-ID:
> > <5671a456.9030...@samsung.com>, correct?
>
> The two pull requests are based on same branch, first 2 comm
On 12/17, Krzysztof Kozlowski wrote:
> On 17.12.2015 02:23, Sylwester Nawrocki wrote:
> > Krzysztof,
> >
> > On 09/12/15 14:36, Krzysztof Kozlowski wrote:
> >> W dniu 09.12.2015 o 19:14, Sylwester Nawrocki pisze:
> Adding Stephen and linux-clk at Cc.
>
> On 09/12/15 05:49,
On 12/17, Krzysztof Kozlowski wrote:
> On 17.12.2015 02:23, Sylwester Nawrocki wrote:
> > Krzysztof,
> >
> > On 09/12/15 14:36, Krzysztof Kozlowski wrote:
> >> W dniu 09.12.2015 o 19:14, Sylwester Nawrocki pisze:
> Adding Stephen and linux-clk at Cc.
>
> On 09/12/15 05:49,
On 12/22, Sylwester Nawrocki wrote:
> Mike,
>
> On 22/12/15 19:44, Mike Turquette wrote:
> > This is superseded by the pull request found in Message-ID:
> > <5671a456.9030...@samsung.com>, correct?
>
> The two pull requests are based on same branch, first 2 comm
On Mon, May 4, 2015 at 4:27 PM, Rafael J. Wysocki wrote:
> On Monday, May 04, 2015 03:10:37 PM Michael Turquette wrote:
>> This series implements an event-driven cpufreq governor that scales cpu
>> frequency as a function of cfs runqueue utilization. The intent of this RFC
>> is
>> to get some
On Mon, May 4, 2015 at 4:27 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, May 04, 2015 03:10:37 PM Michael Turquette wrote:
This series implements an event-driven cpufreq governor that scales cpu
frequency as a function of cfs runqueue utilization. The intent of this RFC
is
to
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling wrote:
> On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
>> On 04/15/2015 05:09 PM, Michael Welling wrote:
>> >On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
>> >>On 04/15/2015 12:17 AM, Michael Welling wrote:
>>
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Hi Stephen R.,
Stephen Boyd has kindly agreed to co-maintain the clk framework with
me and we have shared commit access to a new git tree at kernel.org:
https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/
Can you update linux-next to pull from this tree instead of the
git.linaro.org
Hi Stephen R.,
Stephen Boyd has kindly agreed to co-maintain the clk framework with
me and we have shared commit access to a new git tree at kernel.org:
https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/
Can you update linux-next to pull from this tree instead of the
git.linaro.org
Quoting Viresh Kumar (2015-03-05 00:59:50)
> On 5 March 2015 at 13:12, Sascha Hauer wrote:
> > We have clk_set_parent for changing the parent and clk_set_rate to
> > change the rate. Use the former for changing the parent and the latter
> > for changing the rate. What you are interested in is
Quoting Viresh Kumar (2015-03-05 03:02:06)
> On 5 March 2015 at 16:21, Sascha Hauer wrote:
> > Given the variance of different SoCs I don't think it makes sense
> > to try to handle all these cases. Instead the cpufreq-dt driver
> > should just call clk_set_rate() on the CPU clock with the
Quoting Viresh Kumar (2015-03-05 03:02:06)
On 5 March 2015 at 16:21, Sascha Hauer s.ha...@pengutronix.de wrote:
Given the variance of different SoCs I don't think it makes sense
to try to handle all these cases. Instead the cpufreq-dt driver
should just call clk_set_rate() on the CPU clock
Quoting Viresh Kumar (2015-03-05 00:59:50)
On 5 March 2015 at 13:12, Sascha Hauer s.ha...@pengutronix.de wrote:
We have clk_set_parent for changing the parent and clk_set_rate to
change the rate. Use the former for changing the parent and the latter
for changing the rate. What you are
Quoting Boris Brezillon (2015-03-02 01:18:16)
> The irq line used by the PMC block is shared with several peripherals
> including the init timer which is registering its handler with
> IRQF_NO_SUSPEND.
> Implement the appropriate suspend/resume callback for the PMC irqchip,
> and inform irq core
Quoting Stephen Boyd (2015-03-09 12:05:34)
> On 03/09/15 02:58, Philipp Zabel wrote:
> > Am Freitag, den 06.03.2015, 11:40 -0800 schrieb Stephen Boyd:
> >> On 03/06/15 11:28, Uwe Kleine-König wrote:
> >>> Hello Mike,
> >>>
> >>> On Fri,
Quoting Stephen Boyd (2015-03-09 12:05:34)
On 03/09/15 02:58, Philipp Zabel wrote:
Am Freitag, den 06.03.2015, 11:40 -0800 schrieb Stephen Boyd:
On 03/06/15 11:28, Uwe Kleine-König wrote:
Hello Mike,
On Fri, Mar 06, 2015 at 10:57:30AM -0800, Mike Turquette wrote:
Quoting Uwe Kleine
Quoting Boris Brezillon (2015-03-02 01:18:16)
The irq line used by the PMC block is shared with several peripherals
including the init timer which is registering its handler with
IRQF_NO_SUSPEND.
Implement the appropriate suspend/resume callback for the PMC irqchip,
and inform irq core that
Quoting Ray Jui (2015-03-06 12:07:13)
> Hi Mike,
>
> On 3/6/2015 11:55 AM, Mike Turquette wrote:
> > Quoting Sascha Hauer (2015-02-26 00:43:19)
> >> On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote:
> >>> On 2/25/2015 10:51 PM, Sascha Hauer wrote:
>
Quoting Sascha Hauer (2015-02-26 00:43:19)
> On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote:
> > On 2/25/2015 10:51 PM, Sascha Hauer wrote:
> > > On Wed, Feb 25, 2015 at 10:13:15PM -0800, Ray Jui wrote:
> > >> Hi Sascha,
> > >>
> > >> On 2/25/2015 9:54 PM, Sascha Hauer wrote:
> > >>> Hi
Quoting Lee Jones (2015-03-04 04:00:03)
> Mike,
>
> Do you want me to resend this set with Robert's Reviewed-by applied,
> or are you happy to apply it yourself?
No need for the resend. I am hoping for a final review from a DT human.
This approach looks fine to me. In practice I think it is
Quoting Uwe Kleine-König (2015-02-21 02:40:22)
> Hello,
>
> TLDR: only apply patch 1 and rip of CLK_DIVIDER_ROUND_CLOSEST.
>
> I stared at clk-divider.c for some time now given Sascha's failing test
> case. I found a fix for the failure (which happens to be what Sascha
> suspected).
>
> The
Quoting Stephen Boyd (2015-02-25 16:13:15)
> On 02/24/15 02:39, Heiko Stübner wrote:
> > Commit bca9690b9426 ("clk: divider: Make generic for usage elsewhere")
> > returned only the divider value for read-only dividers instead of the
> > actual rate.
> >
> > Fixes: bca9690b9426 ("clk: divider:
Quoting Ray Jui (2015-03-06 12:07:13)
Hi Mike,
On 3/6/2015 11:55 AM, Mike Turquette wrote:
Quoting Sascha Hauer (2015-02-26 00:43:19)
On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote:
On 2/25/2015 10:51 PM, Sascha Hauer wrote:
On Wed, Feb 25, 2015 at 10:13:15PM -0800, Ray Jui
Quoting Stephen Boyd (2015-02-25 16:13:15)
On 02/24/15 02:39, Heiko Stübner wrote:
Commit bca9690b9426 (clk: divider: Make generic for usage elsewhere)
returned only the divider value for read-only dividers instead of the
actual rate.
Fixes: bca9690b9426 (clk: divider: Make generic for
Quoting Uwe Kleine-König (2015-02-21 02:40:22)
Hello,
TLDR: only apply patch 1 and rip of CLK_DIVIDER_ROUND_CLOSEST.
I stared at clk-divider.c for some time now given Sascha's failing test
case. I found a fix for the failure (which happens to be what Sascha
suspected).
The other two
Quoting Lee Jones (2015-03-04 04:00:03)
Mike,
Do you want me to resend this set with Robert's Reviewed-by applied,
or are you happy to apply it yourself?
No need for the resend. I am hoping for a final review from a DT human.
This approach looks fine to me. In practice I think it is
Quoting Sascha Hauer (2015-02-26 00:43:19)
On Wed, Feb 25, 2015 at 11:42:44PM -0800, Ray Jui wrote:
On 2/25/2015 10:51 PM, Sascha Hauer wrote:
On Wed, Feb 25, 2015 at 10:13:15PM -0800, Ray Jui wrote:
Hi Sascha,
On 2/25/2015 9:54 PM, Sascha Hauer wrote:
Hi Ray,
On Wed, Feb
Quoting Geert Uytterhoeven (2015-03-04 01:56:42)
> On Fri, Feb 27, 2015 at 6:42 PM, Stephen Boyd wrote:
> > The problem is the patch was written before struct clk_core moved into
> > the clk.c file and then applied after it moved. So before the move the
> > order of includes would cause the
Quoting Geert Uytterhoeven (2015-03-04 01:56:42)
On Fri, Feb 27, 2015 at 6:42 PM, Stephen Boyd sb...@codeaurora.org wrote:
The problem is the patch was written before struct clk_core moved into
the clk.c file and then applied after it moved. So before the move the
order of includes would
Quoting Chanwoo Choi (2015-02-27 16:52:59)
> Dear Mike and Sylwester,
>
> Gently ping.
Hello,
I'll merge this into clk-next towards 4.1 later this week. v3.19 was
released on February 8, so this merge request came too late for
inclusion into 4.0.
Regards,
Mike
>
> Best Regards,
> Chanwoo
Quoting Chanwoo Choi (2015-02-27 16:52:59)
Dear Mike and Sylwester,
Gently ping.
Hello,
I'll merge this into clk-next towards 4.1 later this week. v3.19 was
released on February 8, so this merge request came too late for
inclusion into 4.0.
Regards,
Mike
Best Regards,
Chanwoo Choi
Quoting Stephen Boyd (2015-02-23 13:30:28)
> PXO is 25MHz, not 27MHz. Fix the table.
>
> Fixes: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global
> clock controller (GCC)"
>
> Signed-off-by: Stephen Boyd
Applied to clk-next.
Regards,
Mike
> ---
> drivers/clk/qcom/gcc-ipq806x.c | 2
On Thu, Feb 26, 2015 at 1:09 AM, Krzysztof Kozlowski
wrote:
> On czw, 2015-02-26 at 13:14 +1100, Stephen Rothwell wrote:
>> Hi Mike,
>>
>> After merging the clk tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> drivers/clk/clk.c: In function
On Thu, Feb 26, 2015 at 1:09 AM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
On czw, 2015-02-26 at 13:14 +1100, Stephen Rothwell wrote:
Hi Mike,
After merging the clk tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/clk/clk.c: In function
Quoting Stephen Boyd (2015-02-23 13:30:28)
PXO is 25MHz, not 27MHz. Fix the table.
Fixes: 24d8fba44af3 clk: qcom: Add support for IPQ8064's global
clock controller (GCC)
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Applied to clk-next.
Regards,
Mike
---
Quoting Philipp Zabel (2015-02-03 01:42:34)
> Am Montag, den 02.02.2015, 14:11 -0800 schrieb Stephen Boyd:
> > If a driver calls clk_set_parent(clk, parent) and parent is the
> > current parent of clk we shouldn't fail in any case.
> > Unfortunately if clk is a read-only mux we return -ENOSYS
> >
Quoting Stephen Boyd (2015-02-02 14:37:41)
> It's useful to have tracepoints around operations that change the
> hardware state so that we can debug clock hardware performance
> and operations. Four basic types of events are supported: on/off
> events for enable, disable, prepare, unprepare that
Quoting Stephen Boyd (2015-02-02 14:09:43)
> If a clock's clk_ops doesn't have the set_phase op set we should
> return an error from clk_set_phase(). This way clock consumers
> know that when they tried to set a phase it didn't work, as
> opposed to the current behavior where the return value is 0
Quoting Stephen Boyd (2015-02-02 11:42:55)
> On 02/02/15 05:37, Heikki Krogerus wrote:
> > If the divider or multiplier values values are 0 in the
>
> s/values//
>
> > register, bypassing the divider and returning the parent
> > clock rate in clk_fd_recalc_rate().
> >
> > Signed-off-by: Heikki
Quoting Stephen Boyd (2015-02-02 11:42:55)
> On 02/02/15 05:37, Heikki Krogerus wrote:
> > If the divider or multiplier values values are 0 in the
>
> s/values//
>
> > register, bypassing the divider and returning the parent
> > clock rate in clk_fd_recalc_rate().
> >
> > Signed-off-by: Heikki
Quoting Stephen Boyd (2015-01-29 15:38:10)
> A couple of small fixes found while testing the audio clock control
> on apq8064.
Applied to clk-fixes.
Regards,
Mike
>
> Stephen Boyd (3):
> clk: qcom: lcc-msm8960: Fix slimbus n and m val offsets
> clk: qcom: lcc-msm8960: Fix PLL rate
Quoting Stephen Boyd (2015-01-28 12:49:32)
> On 01/27/15 23:00, kbuild test robot wrote:
> > drivers/clk/qcom/lcc-ipq806x.c:465:3-8: No need to set .owner here. The
> > core will do it.
> >
> > Remove .owner field if calls are used which set it automatically
> >
> > Generated by:
Quoting Stephen Boyd (2015-01-28 12:51:05)
> On 01/27/15 23:11, kbuild test robot wrote:
> > drivers/clk/qcom/lcc-msm8960.c:577:3-8: No need to set .owner here. The
> > core will do it.
> >
> > Remove .owner field if calls are used which set it automatically
> >
> > Generated by:
Quoting Mark Brown (2015-01-18 05:41:24)
> On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote:
> > W dniu 18.01.2015 o 07:30, Tomasz Figa pisze:
>
> > >So, the question is, do we actually have hardware that _really_
> > >requires _actual_ preparation or all the
Quoting Krzysztof Kozlowski (2015-01-09 00:28:10)
> Add lockdep asserts for holding the prepare_lock to all functions
> marking this as a requirement in description. Add this to private and
> exported functions so all locking misuse could be detected during
> debugging.
>
> Signed-off-by:
Quoting Lee Jones (2015-02-25 07:48:08)
> On Wed, 25 Feb 2015, Rob Herring wrote:
>
> > On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette
> > wrote:
> > > Quoting Lee Jones (2015-02-18 08:15:00)
> > >> Much h/w contain clocks which if turned off would prove
Quoting Stephen Boyd (2015-02-02 11:42:55)
On 02/02/15 05:37, Heikki Krogerus wrote:
If the divider or multiplier values values are 0 in the
s/values//
register, bypassing the divider and returning the parent
clock rate in clk_fd_recalc_rate().
Signed-off-by: Heikki Krogerus
Quoting Stephen Boyd (2015-01-28 12:51:05)
On 01/27/15 23:11, kbuild test robot wrote:
drivers/clk/qcom/lcc-msm8960.c:577:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by:
Quoting Stephen Boyd (2015-01-28 12:49:32)
On 01/27/15 23:00, kbuild test robot wrote:
drivers/clk/qcom/lcc-ipq806x.c:465:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by:
Quoting Stephen Boyd (2015-02-02 11:42:55)
On 02/02/15 05:37, Heikki Krogerus wrote:
If the divider or multiplier values values are 0 in the
s/values//
register, bypassing the divider and returning the parent
clock rate in clk_fd_recalc_rate().
Signed-off-by: Heikki Krogerus
Quoting Krzysztof Kozlowski (2015-01-09 00:28:10)
Add lockdep asserts for holding the prepare_lock to all functions
marking this as a requirement in description. Add this to private and
exported functions so all locking misuse could be detected during
debugging.
Signed-off-by: Krzysztof
Quoting Mark Brown (2015-01-18 05:41:24)
On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote:
W dniu 18.01.2015 o 07:30, Tomasz Figa pisze:
So, the question is, do we actually have hardware that _really_
requires _actual_ preparation or all the clk_prepare_enable()s in I2C
Quoting Stephen Boyd (2015-01-29 15:38:10)
A couple of small fixes found while testing the audio clock control
on apq8064.
Applied to clk-fixes.
Regards,
Mike
Stephen Boyd (3):
clk: qcom: lcc-msm8960: Fix slimbus n and m val offsets
clk: qcom: lcc-msm8960: Fix PLL rate detection
Quoting Lee Jones (2015-02-25 07:48:08)
On Wed, 25 Feb 2015, Rob Herring wrote:
On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette mturque...@linaro.org
wrote:
Quoting Lee Jones (2015-02-18 08:15:00)
Much h/w contain clocks which if turned off would prove fatal. The
only way
Quoting Stephen Boyd (2015-02-02 14:09:43)
If a clock's clk_ops doesn't have the set_phase op set we should
return an error from clk_set_phase(). This way clock consumers
know that when they tried to set a phase it didn't work, as
opposed to the current behavior where the return value is 0
Quoting Stephen Boyd (2015-02-02 14:37:41)
It's useful to have tracepoints around operations that change the
hardware state so that we can debug clock hardware performance
and operations. Four basic types of events are supported: on/off
events for enable, disable, prepare, unprepare that only
Quoting Philipp Zabel (2015-02-03 01:42:34)
Am Montag, den 02.02.2015, 14:11 -0800 schrieb Stephen Boyd:
If a driver calls clk_set_parent(clk, parent) and parent is the
current parent of clk we shouldn't fail in any case.
Unfortunately if clk is a read-only mux we return -ENOSYS
because
Quoting Lee Jones (2015-02-18 08:15:00)
> Much h/w contain clocks which if turned off would prove fatal. The
> only way to recover is to restart the board(s). This driver takes
> references to clocks which are required to be always-on in order to
> prevent the common clk framework from trying to
Quoting Lee Jones (2015-02-18 08:15:00)
Much h/w contain clocks which if turned off would prove fatal. The
only way to recover is to restart the board(s). This driver takes
references to clocks which are required to be always-on in order to
prevent the common clk framework from trying to
The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e:
Linux 3.19-rc7 (2015-02-01 20:07:21 -0800)
are available in the git repository at:
https://git.linaro.org/people/mike.turquette/linux.git tags/clk-for-linus-3.20
for you to fetch changes up to
Quoting Russell King - ARM Linux (2015-02-16 03:27:24)
> On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
> > I agree that it's a bit odd, but I think it has to be like this.
> > Consider that you request a rate of 100Hz, but the clock can only
> > produce 99.5Hz, so due to rounding
Quoting Russell King - ARM Linux (2015-02-16 03:27:24)
On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
I agree that it's a bit odd, but I think it has to be like this.
Consider that you request a rate of 100Hz, but the clock can only
produce 99.5Hz, so due to rounding
The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e:
Linux 3.19-rc7 (2015-02-01 20:07:21 -0800)
are available in the git repository at:
https://git.linaro.org/people/mike.turquette/linux.git tags/clk-for-linus-3.20
for you to fetch changes up to
Quoting Tomeu Vizoso (2015-02-06 06:13:01)
> We don't really need to recalculate the effective rate of a clock when a
> per-user clock is removed, if the constraints of the later aren't
> limiting the requested rate.
>
> This was causing problems with clocks that never had a rate set before,
> as
Quoting Lee Jones (2015-02-19 04:13:04)
> On Thu, 19 Feb 2015, Sascha Hauer wrote:
>
> > On Thu, Feb 19, 2015 at 08:43:49AM +, Lee Jones wrote:
> > > On Thu, 19 Feb 2015, Sascha Hauer wrote:
> > >
> > > > > > Looks okay to me now.
> > > > > >
> > > > > > Acked-by: Lee Jones
> > > > > >
>
Quoting Stephen Boyd (2015-02-06 11:30:18)
> On 02/06/15 05:39, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> >
> >> From what I can tell this code is
> >> now broken because we made all clk getting functions (there's quite a
> >> few...)
Quoting Stephen Boyd (2015-02-06 11:30:18)
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique
Quoting Lee Jones (2015-02-19 04:13:04)
On Thu, 19 Feb 2015, Sascha Hauer wrote:
On Thu, Feb 19, 2015 at 08:43:49AM +, Lee Jones wrote:
On Thu, 19 Feb 2015, Sascha Hauer wrote:
Looks okay to me now.
Acked-by: Lee Jones lee.jo...@linaro.org
What's the
Quoting Tomeu Vizoso (2015-02-06 06:13:01)
We don't really need to recalculate the effective rate of a clock when a
per-user clock is removed, if the constraints of the later aren't
limiting the requested rate.
This was causing problems with clocks that never had a rate set before,
as
Quoting Fabio Estevam (2015-02-12 13:12:37)
> On Thu, Feb 12, 2015 at 6:30 PM, Stefan Wahren wrote:
> > Revert commit 039e59707507 (clk: mxs: Fix invalid 32-bit access to frac
> > registers), because it leads to a faulty spi communication on mx28evk.
> >
> > Signed-off-by: Stefan Wahren
> >
Quoting Stephen Boyd (2015-02-13 08:39:10)
> On 02/13/15 05:34, Tomeu Vizoso wrote:
> > They were added to this function by mistake when they were added to the
> > clk_ops.determine_rate callback.
> >
> > Fixes: 1c8e600440c7 ("clk: Add rate constraints to clocks")
> > Signed-off-by: Tomeu Vizoso
Quoting Stephen Boyd (2015-02-13 08:39:10)
On 02/13/15 05:34, Tomeu Vizoso wrote:
They were added to this function by mistake when they were added to the
clk_ops.determine_rate callback.
Fixes: 1c8e600440c7 (clk: Add rate constraints to clocks)
Signed-off-by: Tomeu Vizoso
Quoting Fabio Estevam (2015-02-12 13:12:37)
On Thu, Feb 12, 2015 at 6:30 PM, Stefan Wahren stefan.wah...@i2se.com wrote:
Revert commit 039e59707507 (clk: mxs: Fix invalid 32-bit access to frac
registers), because it leads to a faulty spi communication on mx28evk.
Signed-off-by: Stefan
Quoting Stephen Boyd (2015-02-06 11:42:43)
> of_clk_get_by_clkspec() returns a struct clk pointer but it
> doesn't create a new handle for the consumers when we're using
> the common clock framework. Instead it just returns whatever the
> clk provider hands out. When the consumers go to call
Quoting Marek Vasut (2015-02-10 14:07:51)
> On Tuesday, February 10, 2015 at 10:54:52 PM, Fabio Estevam wrote:
> > Hi Stefan,
> >
> > On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren
> > wrote:
> > > thanks this is very helpful. I built the linux-next for my Duckbill and
> > > add the SSP2
Quoting Stephen Boyd (2015-02-06 11:42:43)
of_clk_get_by_clkspec() returns a struct clk pointer but it
doesn't create a new handle for the consumers when we're using
the common clock framework. Instead it just returns whatever the
clk provider hands out. When the consumers go to call clk_put()
Quoting Marek Vasut (2015-02-10 14:07:51)
On Tuesday, February 10, 2015 at 10:54:52 PM, Fabio Estevam wrote:
Hi Stefan,
On Tue, Feb 10, 2015 at 7:24 PM, Stefan Wahren stefan.wah...@i2se.com
wrote:
thanks this is very helpful. I built the linux-next for my Duckbill and
add the SSP2
Quoting Laurent Pinchart (2015-02-05 09:19:14)
> Hi Sergei,
>
> On Thursday 05 February 2015 01:14:46 Sergei Shtylyov wrote:
> > On 02/05/2015 01:04 AM, Sergei Shtylyov wrote:
> > > Anyone may call clk_round_rate() with a zero rate value, so we have to
> > > protect against that.
> >
Quoting Laurent Pinchart (2015-02-05 09:19:14)
Hi Sergei,
On Thursday 05 February 2015 01:14:46 Sergei Shtylyov wrote:
On 02/05/2015 01:04 AM, Sergei Shtylyov wrote:
Anyone may call clk_round_rate() with a zero rate value, so we have to
protect against that.
Signed-off-by: Geert
Quoting Wolfram Sang (2015-02-04 09:32:34)
> On Wed, Feb 04, 2015 at 01:27:21PM +0100, Geert Uytterhoeven wrote:
> > Anyone may call clk_round_rate() with a zero rate value, so we have to
> > protect against that.
> >
> > Signed-off-by: Geert Uytterhoeven
>
> Acked-by: Wolfram Sang
>
> I
Quoting Sergei Shtylyov (2015-02-04 09:45:14)
> Hello.
>
> On 02/04/2015 08:32 PM, Wolfram Sang wrote:
>
> >> Anyone may call clk_round_rate() with a zero rate value, so we have to
> >> protect against that.
>
> >> Signed-off-by: Geert Uytterhoeven
>
> > Acked-by: Wolfram Sang
>
> > I agree
Quoting Sergei Shtylyov (2015-02-04 09:45:14)
Hello.
On 02/04/2015 08:32 PM, Wolfram Sang wrote:
Anyone may call clk_round_rate() with a zero rate value, so we have to
protect against that.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Acked-by: Wolfram Sang
Quoting Wolfram Sang (2015-02-04 09:32:34)
On Wed, Feb 04, 2015 at 01:27:21PM +0100, Geert Uytterhoeven wrote:
Anyone may call clk_round_rate() with a zero rate value, so we have to
protect against that.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Acked-by: Wolfram Sang
Quoting Fabio Estevam (2015-01-30 11:28:32)
> On Fri, Jan 30, 2015 at 5:20 PM, Stefan Wahren wrote:
> > According to i.MX23 and i.MX28 reference manual [1],[2] the fractional
> > clock control register is 32-bit wide, but is separated in 4 parts.
> > So write instructions must not apply to more
Quoting Stephen Rothwell (2015-02-02 21:31:40)
> Hi Mike,
>
> Today's linux-next merge of the clk tree got a conflict in
> arch/arm/mach-omap2/cclock3xxx_data.c between commit ca662ee7b8a8
> ("ARM: OMAP2+: Remove unused ti81xx platform init code") from the
> arm-soc tree and commit d6540b193719
Quoting Stephen Rothwell (2015-02-02 21:31:40)
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
arch/arm/mach-omap2/cclock3xxx_data.c between commit ca662ee7b8a8
(ARM: OMAP2+: Remove unused ti81xx platform init code) from the
arm-soc tree and commit d6540b193719 (ARM:
Quoting Fabio Estevam (2015-01-30 11:28:32)
On Fri, Jan 30, 2015 at 5:20 PM, Stefan Wahren stefan.wah...@i2se.com wrote:
According to i.MX23 and i.MX28 reference manual [1],[2] the fractional
clock control register is 32-bit wide, but is separated in 4 parts.
So write instructions must not
Quoting Stephen Boyd (2015-02-02 14:35:59)
> On 02/02/15 13:31, Julia Lawall wrote:
> >
> > On Mon, 2 Feb 2015, Stephen Boyd wrote:
> >
> >> Julia,
> >>
> >> Is there a way we can write a coccinelle script to check for this? The
> >> goal being to find all drivers that are comparing struct clk
Quoting Tony Lindgren (2015-02-02 12:44:02)
> * Tero Kristo [150202 11:35]:
> > On 02/01/2015 11:24 PM, Mike Turquette wrote:
> > >Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> > >
> > >AFAICT this doesn't break anything, but booting on OMAP3+ results in
Quoting Tero Kristo (2015-02-02 11:32:01)
> On 02/01/2015 11:24 PM, Mike Turquette wrote:
> > Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >> Moves clock state to struct clk_core, but takes care to change as little
> >> API as
> >> possible.
> >>
>
Quoting Steven Rostedt (2015-02-02 08:00:33)
> On Fri, 30 Jan 2015 16:16:11 -0800
> Stephen Boyd wrote:
>
> > It's useful to have tracepoints around operations that change the
> > hardware state so that we can debug clock hardware performance
> > and operations. Four basic types of events are
Quoting Tony Lindgren (2015-02-02 08:12:37)
> * Geert Uytterhoeven [150202 00:03]:
> > On Sun, Feb 1, 2015 at 11:18 PM, Mike Turquette
> > wrote:
> > > Quoting Tomeu Vizoso (2015-01-31 10:36:22)
> > >> On 31 January 2015 at 02:31, Stephen Boyd wrote:
&
Quoting Tony Lindgren (2015-02-02 12:44:02)
* Tero Kristo t-kri...@ti.com [150202 11:35]:
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
struct clk_hw still has a pointer to a struct clk, which
Quoting Stephen Boyd (2015-02-02 14:35:59)
On 02/02/15 13:31, Julia Lawall wrote:
On Mon, 2 Feb 2015, Stephen Boyd wrote:
Julia,
Is there a way we can write a coccinelle script to check for this? The
goal being to find all drivers that are comparing struct clk pointers or
Quoting Tony Lindgren (2015-02-02 08:12:37)
* Geert Uytterhoeven ge...@linux-m68k.org [150202 00:03]:
On Sun, Feb 1, 2015 at 11:18 PM, Mike Turquette mturque...@linaro.org
wrote:
Quoting Tomeu Vizoso (2015-01-31 10:36:22)
On 31 January 2015 at 02:31, Stephen Boyd sb...@codeaurora.org
Quoting Steven Rostedt (2015-02-02 08:00:33)
On Fri, 30 Jan 2015 16:16:11 -0800
Stephen Boyd sb...@codeaurora.org wrote:
It's useful to have tracepoints around operations that change the
hardware state so that we can debug clock hardware performance
and operations. Four basic types of
Quoting Tony Lindgren (2015-01-30 17:04:44)
> Hi all,
>
> Looks like commit cb75a8fcd14e ("clk: Add rate constraints to clocks")
> causes a regression on at least omaps where the serial console either
> does not show anything, or just prints garbage.
>
> Reverting cb75a8fcd14e makes things work
Quoting Tomeu Vizoso (2015-01-31 10:36:22)
> On 31 January 2015 at 02:31, Stephen Boyd wrote:
> > On 01/29, Stephen Boyd wrote:
> >> On 01/29/15 05:31, Geert Uytterhoeven wrote:
> >> > Hi Tomeu, Mike,
> >> >
> >> > On Fri, Jan 23, 2015 at 12:03 PM, Tomeu Vizoso
> >> > wrote:
> >> >> ---
1 - 100 of 1380 matches
Mail list logo