Hi,
On 09/22/2011 05:26 PM, Mike Turquette wrote:
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 3530927..c53ed59 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -5,3 +5,6 @@ config CLKDEV_LOOKUP
>
> config HAVE_MACH_CLKDEV
> bool
> +
> +config GENERI
On Sun, Oct 23, 2011 at 5:55 AM, Shawn Guo wrote:
> Hi Mike,
>
> Some random comments/nits ...
Thanks for reviewing Shawn. Will roll changes into V3.
Regards,
Mike
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailma
Hi Mike,
Some random comments/nits ...
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> +struct clk *clk_register(const struct clk_hw_ops *ops, struct clk_hw *hw,
> + const char *name)
> +{
> + struct clk *clk;
> +
> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> +/* For USE_COMMON_STRUCT_CLK, these are provided in clk.c, but not exported
> + * through other headers; we don't want them used anywhere but here. */
> +#ifdef CONFIG_USE_COMMON_STRUCT_CLK
change to CONFIG_GENERIC_CLK?
> +extern in
On Sun, Oct 16, 2011 at 02:17:29PM -0700, Turquette, Mike wrote:
> On Fri, Oct 14, 2011 at 7:24 PM, Richard Zhao wrote:
> > On Fri, Oct 14, 2011 at 11:14:19AM -0700, Turquette, Mike wrote:
> >> On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
> >> unsigned long omap_recalc_rate(struct clk_h
On Mon, Oct 17, 2011 at 01:05:39PM +0200, Sascha Hauer wrote:
> It's not a problem to associate multiple clocks to a device, we can do
> this now already. What a driver can't do now is
> give-me-all-clocks-I-need(dev),
> but this problem should not be solved at clock core level but at the
> clkdev
On Mon, Oct 17, 2011 at 06:53:03PM +0800, Richard Zhao wrote:
> On Mon, Oct 17, 2011 at 10:20:28AM +0100, Mark Brown wrote:
> > On Mon, Oct 17, 2011 at 04:48:52PM +0800, Richard Zhao wrote:
> >
> > > For example, devices that possible access to on-chip RAM, depend on OCRAM
> > > clock.
> > > On
On Mon, Oct 17, 2011 at 10:20:28AM +0100, Mark Brown wrote:
> On Mon, Oct 17, 2011 at 04:48:52PM +0800, Richard Zhao wrote:
>
> > For example, devices that possible access to on-chip RAM, depend on OCRAM
> > clock.
> > On imx53, VPU depends on OCRAM clock, even when VPU does not use OCRAM.
>
>
On Mon, Oct 17, 2011 at 04:48:52PM +0800, Richard Zhao wrote:
> For example, devices that possible access to on-chip RAM, depend on OCRAM
> clock.
> On imx53, VPU depends on OCRAM clock, even when VPU does not use OCRAM.
So if the VPU depends on OCRAM the VPU should be enabling the OCRAM
clock.
On Sun, Oct 16, 2011 at 07:55:21PM +0200, Sascha Hauer wrote:
> On Fri, Oct 14, 2011 at 06:32:33PM +0800, Richard Zhao wrote:
> > On Fri, Oct 14, 2011 at 11:05:04AM +0100, Mark Brown wrote:
> > > On Fri, Oct 14, 2011 at 04:10:26PM +0800, Richard Zhao wrote:
> > > > On Thu, Sep 22, 2011 at 03:26:56P
On Fri, Oct 14, 2011 at 7:24 PM, Richard Zhao wrote:
> On Fri, Oct 14, 2011 at 11:14:19AM -0700, Turquette, Mike wrote:
>> On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
>> unsigned long omap_recalc_rate(struct clk_hw *hw)
>> {
>> struct clk *parent;
>> struct clk_hw_omap
On Fri, Oct 14, 2011 at 06:32:33PM +0800, Richard Zhao wrote:
> On Fri, Oct 14, 2011 at 11:05:04AM +0100, Mark Brown wrote:
> > On Fri, Oct 14, 2011 at 04:10:26PM +0800, Richard Zhao wrote:
> > > On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> >
> > snip essentially Mike's entire
> - When I define a clk array, I don't need to find another place to store
> .ops.
^
remove "don't". sorry for that.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listin
On Fri, Oct 14, 2011 at 11:14:19AM -0700, Turquette, Mike wrote:
> On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
> > From: Jeremy Kerr
> > struct clk_hw_ops {
> > int (*prepare)(struct clk_hw *);
> > void (*unprepare)(struct clk_hw *);
> > int
On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
> From: Jeremy Kerr
> struct clk_hw_ops {
> int (*prepare)(struct clk_hw *);
> void (*unprepare)(struct clk_hw *);
> int (*enable)(struct clk_hw *);
> void (*disable)(
On Fri, Oct 14, 2011 at 11:05:04AM +0100, Mark Brown wrote:
> On Fri, Oct 14, 2011 at 04:10:26PM +0800, Richard Zhao wrote:
> > On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
>
> snip essentially Mike's entire mail - *please* delete irrelevant quotes
> from your replies, it makes
On Fri, Oct 14, 2011 at 04:10:26PM +0800, Richard Zhao wrote:
> On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
snip essentially Mike's entire mail - *please* delete irrelevant quotes
from your replies, it makes it very much easier to find the new text in
your mail and is much more
Hi Mike,
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> From: Jeremy Kerr
>
> We currently have ~21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sou
On Thu, Oct 13, 2011 at 7:44 AM, Russell King - ARM Linux
wrote:
> On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
>> struct clk_hw_ops {
>> int (*prepare)(struct clk_hw *);
>> void (*unprepare)(struct clk_hw *);
>> int (*enabl
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> struct clk_hw_ops {
> int (*prepare)(struct clk_hw *);
> void(*unprepare)(struct clk_hw *);
> int (*enable)(struct clk_hw *);
> void(*disable)(struct clk_hw *)
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> From: Jeremy Kerr
>
> We currently have ~21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sources witho
On Wed, Oct 5, 2011 at 6:17 PM, Saravana Kannan wrote:
> On 09/22/2011 03:26 PM, Mike Turquette wrote:
>> + unsigned long (*recalc_rate)(struct clk_hw *);
>> + long (*round_rate)(struct clk_hw *, unsigned long);
>> + struct clk * (*get_parent)(struct clk_hw *);
>>
On 09/22/2011 03:26 PM, Mike Turquette wrote:
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 1d37f42..d6ae10b 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
+#ifdef CONFIG_GENERIC_CLK
+
+struct clk_hw {
+ struct clk *clk;
+};
+
+/**
+ * struct clk_hw_ops - Callbac
On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
> > + /* Query the hardware for parent and initial rate */
> > +
> > + if (clk->ops->get_parent)
> > + /* We don't to lock against prepare/enable here, as
> > +* th
On Mon, Oct 3, 2011 at 3:02 PM, Rob Herring wrote:
> Mike,
>
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
>
>> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
>> index 6db161f..e2a9719 100644
>> --- a/drivers/clk/clkdev.c
>> +++ b/drivers/clk/clkdev.c
>> @@ -23,6 +23,13 @@
>> static L
Mike,
On 09/22/2011 05:26 PM, Mike Turquette wrote:
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 6db161f..e2a9719 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -23,6 +23,13 @@
> static LIST_HEAD(clocks);
> static DEFINE_MUTEX(clocks_mutex);
>
> +/
On Mon, Oct 03, 2011 at 05:43:09PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 03, 2011 at 05:31:08PM +0100, Mark Brown wrote:
[Not being many off-SoC clocks]
> > I dunno, I get the impression that some of this is due to the current
> > limitations of the clock API rather than due to a la
On Mon, Oct 03, 2011 at 05:31:08PM +0100, Mark Brown wrote:
> I dunno, I get the impression that some of this is due to the current
> limitations of the clock API rather than due to a lack of clocks -
> perhaps that's specific to the applications I look at, though.
> applications
The clk API per-
On Mon, Oct 03, 2011 at 10:24:52AM -0500, Rob Herring wrote:
> On 10/03/2011 09:25 AM, Mark Brown wrote:
> > This isn't in any way specific to clocks, right now the likely solution
> > looks to be Grant's changes for retrying probe() as new devices come on
> > line. With that devices can return a
On 10/03/2011 09:25 AM, Mark Brown wrote:
> On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
>> On 09/22/2011 05:26 PM, Mike Turquette wrote:
>
> A lot of stuff that should really have been cut plus...
>
>>> + if (clk->ops->get_parent)
>>> + /* We don't to lock against pre
On Mon, Oct 03, 2011 at 09:17:30AM -0500, Rob Herring wrote:
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
A lot of stuff that should really have been cut plus...
> > + if (clk->ops->get_parent)
> > + /* We don't to lock against prepare/enable here, as
> > +* the clock i
On 09/22/2011 05:26 PM, Mike Turquette wrote:
> From: Jeremy Kerr
>
> We currently have ~21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sources without making
> assump
On Sat, Sep 24, 2011 at 8:55 PM, Grant Likely wrote:
> On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
>> From: Jeremy Kerr
>>
>> We currently have ~21 definitions of struct clk in the ARM architecture,
>> each defined on a per-platform basis. This makes it difficult to define
>>
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> From: Jeremy Kerr
>
> We currently have ~21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sources witho
From: Jeremy Kerr
We currently have ~21 definitions of struct clk in the ARM architecture,
each defined on a per-platform basis. This makes it difficult to define
platform- (or architecture-) independent clock sources without making
assumptions about struct clk, and impossible to compile two
plat
35 matches
Mail list logo
