nice DMA controllers) one could go one step further and implement a generic
DMA-through-mmap access to QSPI flash.
Mike.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefa
clock enable_cnt prepare_cntrate
> accuracy phase
>
> ref27002700
> 0 0
> ...
>
&g
l fail. Thus, change the API to return a
> ERR_PTR value in an error case, and change all the users of this API to
> check against IS_ERR instead.
>
> Signed-off-by: Tero Kristo
> Cc: Michael Turquette
Looks good to me.
Regards,
Mike
> ---
> drivers/clk/ti/apll.c |5 +
r has to handle an error from
> the second clk_get() call as meaning "no external clock
> specified". Let's use that logic even with clk lookups to
> simplify the code and remove the struct clk pointer comparisons
> which may not work in the future when clk_get() returns un
On Tue, Feb 3, 2015 at 11:04 AM, Tony Lindgren wrote:
> * Arnd Bergmann [150203 09:03]:
>> On Thursday 08 January 2015, Tony Lindgren wrote:
>>
>> > Great, hopefully this will finally allow Mike to make the
>> > generic struct clk private to drivers/clk :)
>&g
we don't currently
> have and I would wonder why clock consumers even care to compare such
> pointers in the first place.
Ack. Is there precedent for a "Don't do that" kind of response?
Regards,
Mike
>
> --
> Qualcomm Innovation Center, Inc. is a m
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 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:
&
raints patch (with a separate email thread).
Regards,
Mike
>
> Regards,
>
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
e this index.
See how the pointers are populated in ti_clk_register_dpll:
dd->clk_ref = of_clk_get(node, 0);
dd->clk_bypass = of_clk_get(node, 1);
Tony, the same problem affects the FAPLL code which copy/pastes some of
the DPLL code.
Thoughts?
Regards,
Mike
--
To unsubscribe f
Quoting Tero Kristo (2015-01-30 07:20:36)
> On 01/30/2015 02:42 AM, Mike Turquette wrote:
> > Quoting Tero Kristo (2015-01-29 12:19:29)
> >> On 01/08/2015 01:00 AM, Tony Lindgren wrote:
> >>> * Tero Kristo [141216 08:22]:
> >>>> Hi,
> >>>&g
it should be possible to get rid of
> >> clk-private.h (long pending project for Mike.)
> >>
> >> Testing done (on top of 3.18-rc1):
> >>
> >> omap3-beagle: boot / suspend-resume (ret/off) / cpuidle (ret/off)
> >> omap3-beagle-xm: boot upto fs
Quoting Mike Turquette (2015-01-14 14:06:49)
> Quoting Tony Lindgren (2015-01-13 14:51:26)
> > Hi all,
> >
> > Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x
> > which is a omap variant.
>
> Tony,
>
> Patches look fine to me.
quot;flying adder pll" is a pretty badass pll name.
Regards,
Mike
>
> Regards,
>
> Tony
>
>
> Tony Lindgren (2):
> clk: ti: Add support for FAPLL on dm816x
> clk: ti: Initialize clocks for dm816x
>
> .../devicetree/bindin
etely agree that the interfaces and abstractions in the clock
framework do not scale well. As an example, there could be much more
reuse if callbacks such as .get_best_div() existed and the large variety
of .round_rate() implementations could be replaced by a single generic
one.
Easier mixing an
Quoting Tero Kristo (2014-09-30 01:48:49)
> On 09/30/2014 10:07 AM, Mike Turquette wrote:
> > Quoting Tero Kristo (2014-09-29 01:09:24)
> >> On 09/27/2014 02:24 AM, Mike Turquette wrote:
> >>> Quoting Tero Kristo (2014-09-26 00:18:55)
> >>>> On 09/26/
Quoting Tero Kristo (2014-09-29 01:09:24)
> On 09/27/2014 02:24 AM, Mike Turquette wrote:
> > Quoting Tero Kristo (2014-09-26 00:18:55)
> >> On 09/26/2014 04:35 AM, Stephen Boyd wrote:
> >>> On 09/23/14 06:38, Tero Kristo wrote:
> >>>> On 09/22/2014 1
Quoting Tero Kristo (2014-09-29 09:13:09)
> Hi Mike,
>
> The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
>
>Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
>
> are available in the git repository at:
>
>g...@github.com:t-kristo/li
like a generic one to me.
> >
> > Like thread: https://lkml.org/lkml/2014/9/5/284 ?
>
> Right, I should've read the earlier versions before making any smart
> comments =).
No supporters cropped up for the generic gpio clock, but the design is
common enough to merit a c
Quoting Jyri Sarha (2014-09-11 01:44:24)
> On 09/10/2014 01:14 AM, Mike Turquette wrote:
> > Quoting Jyri Sarha (2014-09-05 05:21:34)
> >> The added gpio-gate-clock is a basic clock that can be enabled and
> >> disabled trough a gpio output. The DT binding document for t
gt; clock first without programming the M+N first.
I took a quick look and it still seems to me that the OMAP DPLLs are
still not modeled properly as mux clocks. Is this correct?
This issue has been lingering for a long time and we can't use
determine_rate unless that clock has multiple parent
for drivers which
> use the module_platform_driver API, as this is overriden in
> platform_driver_register anyway."
>
> Signed-off-by: Kiran Padwal
Applied to clk-next.
Regards,
Mike
> ---
> drivers/clk/clk-axi-clkgen.c |1 -
> drivers/clk/clk-max77686.
> specific clocks.
>
I searched through my archives and found a post from January. You Cc'd
me as "". Note that the address is wrapped in
chevrons but there is no name string (e.g. "Mike Turquette").
My mailer doesn't parse this well it was not flagged as to:me in
ds through device tree. Clock sources as such include for
> >> example twl-6030 / twl-6040 chips and variants which can be used to clock
> >> for example audio / WLAN chips.
> >
> > Just one question to Mike and Tero:
> > would it be possible to have generic binding
> http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.
>
> Signed-off-by: Tero Kristo
> To: Mike Turquette
> Reported-by: Nishanth Menon
Applied to clk-fixes.
Thanks!
Mike
> ---
> drivers/clk/clk.c |7 ++-
> 1 file changed, 6 insertions(+),
Quoting Tero Kristo (2014-07-30 05:27:07)
> On 07/30/2014 08:53 AM, Peter Ujfalusi wrote:
> > On 07/29/2014 07:12 PM, Mike Turquette wrote:
> >>> Oh yea, seems this got lost into the myriad of branches I have. I can push
> >>> this on top of my for-v3.17/ti-clk-d
On Tue, Jul 29, 2014 at 1:23 AM, Tero Kristo wrote:
> On 07/29/2014 09:27 AM, Mike Turquette wrote:
>>
>> Quoting Peter Ujfalusi (2014-07-14 03:10:28)
>>>
>>> On 05/06/2014 04:39 PM, Peter Ujfalusi wrote:
>>>>>>
>>>>>
; getting
> >> default rate/parent support through DT. I would like a comment from Mike
> >> about
> >> the estimate when this can get in, and whether we should merge intermediate
> >> solutions still like this.
Tero,
On May 19 you said, "Thanks, q
s
> to certain board specific functionality. The basic idea of this set is to
> introduce clk_features struct which contains any SoC specific data / flags
> within it, and this is used runtime instead of the current cpu_is_? checks.
Reviewed-by: Mike Turquette
>
> There are also a cou
s.
> >
> > did you skip a few -rcs by any chance? Looks like this could've been
> > merged on v3.16-rc3... Just checking.
>
> This goes through Mike's clk tree, so there is extra latency there. Not
> sure when he plans to send next pull-req for clk-fixes to linu
Quoting Peter Ujfalusi (2014-06-26 23:01:09)
> Hi Mike,
>
> This is a resend of the v2 version of the palmas clock driver which seamingly
> missed the 3.16 merge window. I have added Nishanth's Reviewed-by tag to the
> patches.
Thanks for the resend. Applied to clk-
gned long palmas_clks_recalc_rate(struct clk_hw *hw,
> >> +unsigned long parent_rate)
> >> +{
> >> + return 32768;
> >> +}
> >
> > I see that other clock drivers using a constant rate return 0 if the
> &g
e target rate requested.
I agree that the behavior of clk_round_rate needs to be defined once and
for all. I also think that clk_round_ceil, clk_round_floor and
clk_round_exact aren't terrible ideas either.
I'll kick off a thread on this topic shortly, and we can hopefully gain
some co
nk...).
The point is to get the rate you ask for when you call clk_set_rate. The
method by which the PLL achieves that rate isn't really important, so
long as you have glitchless clocks (which OMAP's PRCM does).
Regards,
Mike
>
> .Tero
>
--
To unsubscribe from this list: send t
_rate) the
CLK_SET_RATE_NO_REPARENT flag was applied to all affected users to
maintain prior behavior and prevent regressions.
I have some local patches to improve documentation around these areas
for 3.17.
Regards,
Mike
>
> > This is a rather dangerous default, and causes problems on
Quoting Tomi Valkeinen (2014-05-15 05:25:37)
> On 15/05/14 09:08, Mike Turquette wrote:
> > Quoting Tomi Valkeinen (2014-05-12 05:13:51)
> >> On 12/05/14 15:02, Tero Kristo wrote:
> >>> On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
> >>>> The current D
On Mon, May 19, 2014 at 6:20 AM, Tero Kristo wrote:
> On 05/05/2014 10:49 AM, Tero Kristo wrote:
>>
>> On 05/01/2014 10:00 PM, Mike Turquette wrote:
>>>
>>> Quoting Tero Kristo (2014-04-29 07:51:14)
>>>>
>>>> On 04/29/2014 05:15 PM, Sourav
efclk_ext
> >>>>>> in PRCM is useless.
> >>>>>
> >>>>> I think what Nishant meant is that if "refclk_ext" is provided it means
> >>>>> that the driver
> >>>>> should use that over "dpll_
me
> boundary case survival.
DCC also exists in OMAP4. In some cases customers used it, in other
cases we just ran the PLL way out of spec and the mpu_clk would divide
by 2.
Is this broken for OMAP4 as well?
Regards,
Mike
>
> Verified on the following impacted platforms using 3
omain. Other IPs can
> use the ATL generated clock as their functional clock (McASPs for example)
> and external components like audio codecs can also use the very same clock
> as their MCLK.
>
> The ATL IP in DRA7 contains 4 ATL instences.
>
> Signed-off-by: Peter Ujfalusi
Look
Quoting Sourav Poddar (2014-04-29 01:34:20)
> tbclk does not need to be a composite clock, we can simply
> use gate clock for this purpose.
>
> Signed-off-by: Sourav Poddar
Looks good.
Regards,
Mike
> ---
> v1->v2:
> change compatible string according to mainline.
>
with respect to the API
definition. Has anyone tried making the new flag as the default behavior
and seeing if anything breaks?
For those users of the omapconf tool I enjoy doing something like the
following:
omapconf dump prcm > old
omapconf dump prcm > new
diff -u old new
This s
: Sourav Poddar
>
> Acked-by: Tero Kristo
Looks good to me.
Tero, just to be clear, are you planning on batching up OMAPish clock
patches and sending a pull request (once they have been reviewed on the
list)?
Thanks,
Mike
>
>
> > ---
> > v2->v3
> >
Quoting Tero Kristo (2014-03-05 05:10:17)
> Ping.
>
> Mike, any feedback on this?
Hi Tero,
Have you seen Sylwester's approach[1]? I prefer it since it is more
device-oriented and less "centralized". The clock consumer enumerates
the default parent or rate of a consumed
premature
given that the level of discussion around those features never hit
critical mass.
So the ratio thing is sensible, but it would be the first
constraint-like mechanism in the clock framework so what that looks like
bares careful consideration.
> >
> Mike,
> Any suggestions
Quoting Tomi Valkeinen (2014-03-17 05:53:03)
> On 27/02/14 04:25, Mike Turquette wrote:
> > Quoting Tero Kristo (2014-02-14 05:45:22)
> >> On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
> >>> clk-divider.c does not calculate the rates consistently at the moment.
>
declared structure representing the sub-unit. Some
variations on that theme:
int pm_runtime_set_rate(struct perf_domain *perfdm, unsigned long rate);
or,
int pm_runtime_set_rate(struct generic_power_domain *gpd,
unsigned long rate);
or whatever that sub-unit looks like. The gpd thing might b
rounding, the result is that the
> > clock is set to the rate of 10800, not 123428571 returned by the
> > clk_round_rate.
> >
> > This patch changes the clk-divider.c to use DIV_ROUND_UP when
> > calculating the rate. This gives the following behavior w
Quoting Roger Quadros (2014-02-25 01:32:19)
> Hi Mike,
>
> On 02/25/2014 10:43 AM, Mike Turquette wrote:
> > Quoting Roger Quadros (2014-02-20 03:40:01)
> >> The OMAP USB Host MFD driver no longer expects these non-existing
> >> clocks from the OMAP3 platform, s
vices on the bus being lost in the La La Land.
>
> It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
> can fail gracefully.
>
> Signed-off-by: Florian Vaussard
Looks good to me.
Regards,
Mike
> ---
> drivers/clk/ti/clk-44xx.c | 1 -
> drivers/clk/t
Quoting Roger Quadros (2014-02-20 03:40:01)
> The OMAP USB Host MFD driver no longer expects these non-existing
> clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Regards,
Mike
>
> CC: Tero Kristo
> CC: Mike Turquette
> Signed-off-by: Roger Quadros
Quoting Nishanth Menon (2014-01-29 10:19:16)
> cpu0 clock node has no functionality, since cpufreq-cpu0 is already
> capable of picking up the clock from dts.
>
> Signed-off-by: Nishanth Menon
Taken into clk-next!
Regards,
Mike
> ---
> drivers/clk/ti/clk-33xx.c |1 -
&g
Quoting Nishanth Menon (2014-02-18 12:32:18)
> From: Mike Turquette
>
> This patch provides helper functions for drivers that wish to scale
> voltage through the clock rate-change notifiers. The approach taken
> is that the user-driver(cpufreq/devfreq) do not care about the
>
On Sat, Jan 18, 2014 at 9:50 AM, Tony Lindgren wrote:
> * Mike Turquette [140117 13:39]:
>> Quoting Tero Kristo (2014-01-17 12:25:37)
>> > Hi,
>> >
>> > Quick emergency band-aid for the build breakages introduced in clk-next
>> > by Mike. I did
Quoting Tero Kristo (2014-01-17 12:25:37)
> Hi,
>
> Quick emergency band-aid for the build breakages introduced in clk-next
> by Mike. I didn't have time to test this out (Nishanth will provide some
> logs) and I will leave the decision whether/how to use these patches or
Quoting Tero Kristo (2014-01-17 10:11:06)
> On 01/17/2014 07:53 PM, Tony Lindgren wrote:
> > * Kevin Hilman [140117 09:48]:
> >> Mike Turquette writes:
> >>
> >> [...]
> >>
> >>> I took Tony's advice and fast-forwarded clk-next to
Quoting Mike Turquette (2014-01-14 19:16:32)
> Quoting Felipe Balbi (2014-01-14 18:04:21)
> > Hi,
> >
> > On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
> > > > Felipe, care to run your randconfig magic for this?
> > >
> > > This
to handle the missing
AM35xx dtsi data? It can always go as a separate fix after this stuff
gets merged which, ironically, is how that file was created in the first
place.
Regards,
Mike
>
> cheers
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
term, this means the patch set shrank in
> size from 49 patches to 40 (first 9 patches were dropped).
> - Copy pasted implementation for clk-divider and clk-mux from drivers/clk
> to drivers/clk/ti, and made the modifications needed to the TI version
> of the clock drivers only (b
Quoting Tero Kristo (2013-12-16 00:13:08)
> On 12/15/2013 06:23 AM, Mike Turquette wrote:
> > Quoting Tero Kristo (2013-11-26 00:05:51)
> >> Some OMAP clocks require knowledge about their parent clockdomain for
> >> book keeping purposes. This patch crea
that approach dumps crap into struct clk_hw which is bad.
Anyways if you decide against regmap for V11 then the whole issue is
avoided.
Regards,
Mike
[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/273742
[2] http://article.gmane.org/gmane.linux.ports.arm.kernel/273744
> - dropped
common clock binding
but that this binding definition does not define any new clocks or clock
controllers in the way that a typical clock binding would.
This code uses the 'clocks' property the same way that any other
consumer binding definition would, such as an MMC controller or UART.
T
Quoting Rajendra Nayak (2013-12-12 03:38:29)
> With support to parse clock data from DT, move all main and optional
> clock information from hwmod to DT.
>
> We still retain clocks in hwmod for devices which do not have a DT node.
>
> Signed-off-by: Rajendra Nayak
Reviewed-
e
> functions to return status
>
> Testing done:
> - omap3-beagle : boot + suspend/resume
> - omap3-beagle-xm : boot (thanks to Nishanth)
> - omap4-panda-es : boot + suspend/resume
A quick note in testing: trace_clk_div_ck ends up as an orphan clock on
my Panda ES.
Regards
not needed in that case?
Regards,
Mike
> ---
> drivers/clk/clk.c| 68
> ++
> include/linux/clk-provider.h | 15 +-
> 2 files changed, 75 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/
the SPL is written. Like the omap2 solution, the docg4
driver can be loaded with a special module parameter that enables writing the
SPL partition in this mode.
The docg4 is kind of a special case, though, because it is a nand flash wrapped
inside a proprietary non-standard flash controller.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ss CM registers directly.
> >
> > Signed-off-by: Tero Kristo
>
> Thanks, queued. Please coordinate with Mike to get
> allow_idle/deny_idle-type interfaces into the Common Clock Framework, so
> these can be replaced with standard CCF-type allow_idle() & deny_idle()
> functions.
Quoting Tero Kristo (2013-09-25 01:48:06)
> Hi all,
>
> Version 7 contains following high level changes:
> - Dropped support for basic bindings from Mike Turquette, instead using
> vendor specific bindings for all clocks
> - Mux clock + divider clock vendor specific bindi
epare for these PLLs
which might take some time to lock? The code there doesn't sleep or
schedule, but it does poll for some time while under a spinlock.
Something to think about for a future patch.
Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
I wonder if that's valid in a case where a previous OS or
> bootloader may have programmed the DPLL.
Well it used to be that calling clk_set_rate(dpll, bypass_rate) would
put it in bypass, I don't know if that is still the case. But you are
right that having the implicit assu
On Tue, Sep 17, 2013 at 3:02 AM, Tomi Valkeinen wrote:
> On 17/09/13 12:38, Mike Turquette wrote:
>> Quoting Archit Taneja (2013-09-17 00:06:28)
>>> HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
>>> existing PLL functions from ti_hdmi_4xxx_ip
libraries.
>
> Signed-off-by: Archit Taneja
Would be cool to see this convert to the common clock framework
implementation (include/linux/clk-provider.h). It appears that this PLL
only needs to support .enable, .disable and .recalc_rate callbacks at
first glance.
Regards,
Mike
> ---
ct clk *' but
> > argument is of type 'struct clk_hw_omap *'
>
> Yea sorry about that, I just quickly hacked the patch together without
> testing it at all. :P
>
> >
> > I then changed it (not 100% sure if correctly) to this version:
> >
> > +
= &omap2_init_dpll_parent,
> + .recalc_rate= &omap3_dpll_recalc,
> + .set_rate = &omap3_noncore_dpll_set_rate,
> + .round_rate = &omap2_dpll_round_rate,
> +};
> +
> +static const struct clk_ops omap3_dpll_per_ck_ops = {
> + .i
On Tue, Sep 10, 2013 at 2:17 PM, Mike Turquette wrote:
> Quoting Tero Kristo (2013-09-10 06:17:45)
>> On 09/10/2013 03:40 PM, Tomi Valkeinen wrote:
>> > On 10/09/13 15:24, Tero Kristo wrote:
>> >> On 09/10/2013 03:19 PM, Tomi Valkeinen wrote:
>> >
gt; -
> - v = __raw_readl(dd->control_reg) & dd->enable_mask;
> - v >>= __ffs(dd->enable_mask);
> - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd->flags & DPLL_J_TYPE))
> + if ((dd->flags & DPLL_J_TYPE) ||
> + __clk_get_rat
well we'll be able to maintain support for that in
> >>> future if it requires other platform code to use now, and we're not sure
> >>> how the domains themselves will be represented in dt.
> >>
> >> Hmm so, should I add a stub representation
ight now the DPLL implementation sort of
manages the mux bits behind the clock framework's back, right?
Regards,
Mike
> ---
> arch/arm/mach-omap2/cclock44xx_data.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/ccloc
clocks. That means that your driver could probably remove the clock
setup code completely.
Regards,
Mike
> +
> goto out;
>
> out_free:
> --
> 1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v rate 1920
>> [ 21.592726] > clk_change_rate best_parent_rate 0
>
> or because we reach:
> if (clk->ops->set_rate)
> clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
>
> with clk->new_rate == 0.
Hmm, I&
ust McASP -> DDRRAM. Especially since the McASP has a
built-in 256 byte FIFO buffer on both channels. In all my measurements,
using the IRAM ping-pong only made things worse in terms of overruns and
underruns, not better.
Anyone who know why the ping-pong was implemented and what kind
ples, this
invariably fails on the current driver, with or without the ping-ping.
Using the cyclic DMA I had no problem using such small periods.
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
Mo
is no longer needed.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/cclock7xx_data.c | 93
> ++
> 1 file changed, 93 insertions(+)
> create mode 100644 arch/arm/mach-omap2/cclock7xx_data.c
Why not drivers/clk/omap/clk-dra7xx.c?
p2/cclock54xx_data.c
> b/arch/arm/mach-omap2/cclock54xx_data.c
> new file mode 100644
Why not drivers/clk/omap/clk-omap54xx.c?
Regards,
Mike
> index 000..f23f44e
> --- /dev/null
> +++ b/arch/arm/mach-omap2/cclock54xx_data.c
> @@ -0,0 +1,74 @@
> +/*
> + * OMAP54xx C
8) bit_idx,
clk_gate_flags, NULL);
Thanks,
Mike
>
> Signed-off-by: Tero Kristo
> ---
> drivers/clk/clk-divider.c |4 ++--
> drivers/clk/clk-gate.c|4 ++--
> drivers/clk/clk-mux.c |4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
&
-clock, divider-clock, fixed-clock, fixed-factor and
(unpublished) gate-clock bindings in my local repo, but it is not
currently booting. I wanted to get this early preview out regardless.
[1] http://article.gmane.org/gmane.linux.kernel/1501216
Mike Turquette (3):
clk: omap: introduce clock driver
: Paul Walmsley
Cc: Tony Lindgren
Signed-off-by: Mike Turquette
---
arch/arm/mach-omap2/cclock44xx_data.c | 54 ---
1 file changed, 6 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index
arly and often to see what others think of this approach.
Cc: Benoit Cousson
Cc: Rajendra Nayak
Cc: Joel A Fernandes
Cc: Nishanth Menon
Cc: Paul Walmsley
Cc: Tony Lindgren
Signed-off-by: Mike Turquette
---
arch/arm/boot/dts/omap4-clocks.dtsi | 128
arch/arm/
Cc: Joel A Fernandes
Cc: Nishanth Menon
Cc: Paul Walmsley
Cc: Tony Lindgren
Signed-off-by: Mike Turquette
---
This driver simply matches the basic bindings (so far). Eventually it
would match omap-specific bindings for DPLLs, CLKOUTX2 and strange leaf
clocks as well. This doesn't scale
;
>
> Thanks!
> Will fix them and add your ack to it?
Great, thanks! Don't worry about the Ack. I'll take the patch
through the clk tree so it will have my SoB.
Regards,
Mike
>
>
>> Regards,
>> Mike
>>
>>> Currently if the value read is grea
is done and everything looks good then please add:
Acked-by: Mike Turquette
>
> Index: b/arch/arm/mach-omap2/clock36xx.c
> ===
> --- a/arch/arm/mach-omap2/clock36xx.c
> +++ b/arch/arm/mach-omap2/clock36xx.c
> @@ -39
out reentrantly calling clk_set_rate here to achieve the same
effect?
/* kick parent's clksel register after toggling PWRDN bit */
struct clk *parent = clk_get_parent(clk->clk);
unsigned long parent_rate = clk_get_rate(parent);
clk_set_rate(parent, parent_rat
e accessible by of_clk_get.
>
FYI, I'm working on moving the OMAP clocks over to DT which is a better
alternative than this patch. I'll share what I have on the list,
hopefully next week.
Regards,
Mike
> Based on discussion contributions from Roger Quadros, Grygorii Strashko
e accessible by of_clk_get.
>
> Based on discussion contributions from Roger Quadros, Grygorii Strashko
> and others.
>
> Cc: Kevin Hilman
> Cc: Mike Turquette
> Cc: Paul Walmsley
> [t...@atomide.com: co-developed]
> Signed-off-by: Tony Lindgren
> Signed-off-by:
lot to understand why regulator chaining is a
requirement for this to work properly.
Thanks,
Mike
>
>
> This simple model will be extended to handle AVS as a part of the chain.
> smps123 regulator may be changed to VP/VC regulator.
>
> Following example is from integration branch, w
Quoting Andrii Tseglytskyi (2013-04-15 06:28:10)
> Cc: Mike Turquette
>
> Signed-off-by: Andrii.Tseglytskyi
> Signed-off-by: Mike Turquette
It is very strange to Cc me and include my Signed-off-by. Go ahead and
drop my SoB. I'll review these patches this week but I don&#
AR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
Please use clk-provider.h. Otherwise this looks like an OK transitional
solution. Hopefully this will be replaced with a more legitimate clock
driver for 3.11.
Regards,
Mike
--
To unsubscri
d on the binding etc.
> I did try to have an implementation for cpufreq using clock nodes.
> unfortunately, device tree wont let me have arguments of strings :(
> So, I am unable to do clock = <&clk mpu_dpll>;
> instead, I am forced to do clock = <&clk 249>;
>
S
1 - 100 of 546 matches
Mail list logo
