* [PATCH 13/46] davinci: support re-parenting a clock in the clock framework
@ 2009-08-31 10:18 Sekhar Nori
0 siblings, 0 replies; 5+ messages in thread
From: Sekhar Nori @ 2009-08-31 10:18 UTC (permalink / raw)
To: linux-arm-kernel
The clk_set_parent() API is implemented to enable re-parenting
clocks in the clock tree.
This is useful in DVFS and helps by shifting clocks to an asynchronous
domain where supported by hardware
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
arch/arm/mach-davinci/clock.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 09e0e1c..e7696fc 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -141,6 +141,33 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
}
EXPORT_SYMBOL(clk_set_rate);
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ unsigned long flags;
+
+ if (clk == NULL || IS_ERR(clk))
+ return -EINVAL;
+
+ /* Cannot change parent on enabled clock */
+ if (WARN_ON(clk->usecount))
+ return -EINVAL;
+
+ mutex_lock(&clocks_mutex);
+ clk->parent = parent;
+ list_del_init(&clk->childnode);
+ list_add(&clk->childnode, &clk->parent->children);
+ mutex_unlock(&clocks_mutex);
+
+ spin_lock_irqsave(&clockfw_lock, flags);
+ if (clk->recalc)
+ clk->rate = clk->recalc(clk);
+ propagate_rate(clk);
+ spin_unlock_irqrestore(&clockfw_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(clk_set_parent);
+
int clk_register(struct clk *clk)
{
if (clk == NULL || IS_ERR(clk))
--
1.6.4.3
>From bogus@does.not.exist.com Mon Aug 24 09:56:15 2009
From: bogus@does.not.exist.com ()
Date: Mon, 24 Aug 2009 13:56:15 -0000
Subject: No subject
Message-ID: <mailman.96.1256827883.2253.linux-arm-kernel@lists.infradead.org>
solution which may can be referenced and benefit the final result.
The problem with this driver I guess is that how other Marvell apps
depends on this, and it's currently unknown since the API and user-
space stuffs are not public at the moment. And apparently, the one
you posted has already included a link to the directfb usage.
Technically, these drivers are based on samilar ideas, I don't have
any preference. The real issue is that Marvell should have a look
into the directfb version, and evaluate if something is missing and
the effort of porting existing apps over to that driver because
eventually I'd like to see only one driver there. And vice versa
from the directfb POV.
Note I'm neutral on this, and this could be the chance both parties
look into the solution of the other one, and improve the final
result. (what I care only is good code ;-)
- eric
>From Jonathan Mon Aug 24 09:56:15 2009
From: Jonathan (Jonathan)
Date: Mon, 24 Aug 2009 13:56:15 -0000
Subject: No subject
Message-ID: <mailman.106.1257339474.2253.linux-arm-kernel@lists.infradead.org>
uk</a>><br>
Date: Sat, 4 Jul 2009 13:25:06 +0000<br>
Subject: [PATCH 02/10] ov7670: Temporary soc-camera support<br>
<br>
Signed-off-by: Jonathan Cameron <<a href=3D"mailto:jic23@cam.ac.uk">jic2=
3 at cam.ac.uk</a>><br>
---<br>
drivers/media/video/ov7670.c | 50 ++++++++++++++++++++++++++++=
++++++++++++++<br>
1 files changed, 50 insertions(+), 0 deletions(-)<br>
<br>
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c<br=
>
index 0e2184e..910a499 100644<br>
--- a/drivers/media/video/ov7670.c<br>
+++ b/drivers/media/video/ov7670.c<br>
@@ -19,6 +19,8 @@<br>
#include <media/v4l2-chip-ident.h><br>
#include <media/v4l2-i2c-drv.h><br>
<br>
+#include <media/soc_camera.h><br>
+#include <linux/autoconf.h><br>
<br>
MODULE_AUTHOR("Jonathan Corbet <<a href=3D"mailto:corbet@lwn.=
net">corbet at lwn.net</a>>");<br>
MODULE_DESCRIPTION("A low-level driver for OmniVision ov7670 sen=
sors");<br>
@@ -745,6 +747,10 @@ static int ov7670_s_fmt(struct v4l2_subdev *sd, struct=
v4l2_format *fmt)<br>
struct ov7670_info *info =3D to_state(sd);<br>
unsigned char com7, clkrc =3D 0;<br>
<br>
+ ret =3D ov7670_init(sd, 0);<br>
+ if (ret)<br>
+ return ret;<br>
+<br>
ret =3D ov7670_try_fmt_internal(sd, fmt, &o=
vfmt, &wsize);<br>
if (ret)<br>
return ret;<br>
@@ -1239,6 +1245,41 @@ static const struct v4l2_subdev_ops ov7670_ops =3D {=
<br>
};<br>
<br>
/* ------------------------------------------------------------------=
----- */<br>
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device *=
icd)<br>
+{<br>
+ struct soc_camera_link *icl =3D to_soc_camera_link(i=
cd);<br>
+<br>
+ unsigned long flags =3D SOCAM_PCLK_SAMPLE_RISING | S=
OCAM_MASTER |<br>
+ SOCAM_VSYNC_ACTIVE_HIGH =
| SOCAM_HSYNC_ACTIVE_HIGH |<br>
+ SOCAM_DATAWIDTH_8 | SOCA=
M_DATA_ACTIVE_HIGH;<br>
+<br>
+ return soc_camera_apply_sensor_flags(icl, flags);<br=
>
+}<br>
+<br>
+/* This device only supports one bus option */<br>
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,<br>
+ &nb=
sp; unsigned long flags)<br>
+{<br>
+ return 0;<br>
+}<br>
+<br>
+static struct soc_camera_ops ov7670_soc_ops =3D {<br>
+ .set_bus_param =3D ov7670_soc_set_bus_param,<br>
+ .query_bus_param =3D ov7670_soc_query_bus_param,<br>
+};<br>
+<br>
+#define SETFOURCC(type) .name =3D (#type), .fourcc =3D (V4L2_PIX_FMT_ ## t=
ype)<br>
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] =3D {<br=
>
+ {<br>
+ SETFOURCC(YUYV),<br>
+ .depth =3D 16,<br>
+ .colorspace =3D V4L2_COL=
ORSPACE_JPEG,<br>
+ }, {<br>
+ SETFOURCC(RGB565),<br>
+ .depth =3D 16,<br>
+ .colorspace =3D V4L2_COL=
ORSPACE_SRGB,<br>
+ },<br>
+};<br>
<br>
static int ov7670_probe(struct i2c_client *client,<br>
&nbs=
p; const struct i2c_device_id *id)<br>
@@ -1246,7 +1287,16 @@ static int ov7670_probe(struct i2c_client *client,<b=
r>
struct v4l2_subdev *sd;<br>
struct ov7670_info *info;<br>
int ret;<br>
+ struct soc_camera_device *icd =3D client->dev.pla=
tform_data;<br>
+<br>
+ if (!icd) {<br>
+ dev_err(&client->=
dev, "OV7670: missing soc-camera data!\n");<br>
+ return -EINVAL;<br>
+ }<br>
<br>
+ icd->ops =3D &ov7670_soc_ops;<br>
+ icd->formats =3D ov7670_soc_fmt_lists;<br>
+ icd->num_formats =3D ARRAY_SIZE(ov7670_soc_fmt_li=
sts);<br>
info =3D kzalloc(sizeof(struct ov7670_info), GF=
P_KERNEL);<br>
if (info =3D=3D NULL)<br>
return -ENOMEM;<br>
<font color=3D"#888888">--<br>
1.6.3.3<br>
<br>
<br>
<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>=D3=D0=CB=BD,=C9=
=FA=CF=A2=C2=D6=BB=D8=D5=DF=CE=AA=C9=FA<br>=D6=AA=CE=D2,=BF=C9=D0=D0=C4=E6=
=CC=EC=D5=DF=CE=AA=C1=E9<br>=D7=D4=CA=C0=C9=CF=C9=FA=C1=E9=D6=AA=D3=D0=CE=
=D2=CA=B1=C6=F0=A3=AC<br>=BC=B4=D6=AA=C7=F7=B1=DC=A3=AC<br>=D2=D4=C0=FB=CE=
=D2=D5=DF=CE=AA=C9=C6=A3=AC=D2=D4=BA=A6=CE=D2=D5=DF=CE=AA=B6=F1=A3=AC<br>=
=CB=B9=CE=AA=B6=C0=D3=FB=D6=AE=D0=C4=A3=AC=D2=E0=CA=C7=C3=C9=C3=C1=D4=B4=C1=
=F7=A1=A3<br>=BE=FD=D7=D3=B9=A4=D7=F7=CA=D2<br><a href=3D"http://www.junzij=
u.com.cn">www.junziju.com.cn</a><br>=D6=D0=B9=FA=B5=E7=D7=D3=C9=E8=BC=C6=C2=
=DB=CC=B3<br>
<a href=3D"http://www.eledsn.com">www.eledsn.com</a><br>
--001636e9087a46691e0477753ba4--
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 13/46] davinci: support re-parenting a clock in the clock framework
2009-10-16 19:09 ` [PATCH 12/46] davinci: support changing the clock rate in clock framework Kevin Hilman
@ 2009-10-16 19:09 ` Kevin Hilman
2009-10-19 14:05 ` Russell King - ARM Linux
0 siblings, 1 reply; 5+ messages in thread
From: Kevin Hilman @ 2009-10-16 19:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Sekhar Nori <nsekhar@ti.com>
The clk_set_parent() API is implemented to enable re-parenting
clocks in the clock tree.
This is useful in DVFS and helps by shifting clocks to an asynchronous
domain where supported by hardware
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
arch/arm/mach-davinci/clock.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 09e0e1c..12ceeea 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -141,6 +141,29 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
}
EXPORT_SYMBOL(clk_set_rate);
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ unsigned long flags;
+
+ if (clk == NULL || IS_ERR(clk))
+ return -EINVAL;
+
+ mutex_lock(&clocks_mutex);
+ clk->parent = parent;
+ list_del_init(&clk->childnode);
+ list_add(&clk->childnode, &clk->parent->children);
+ mutex_unlock(&clocks_mutex);
+
+ spin_lock_irqsave(&clockfw_lock, flags);
+ if (clk->recalc)
+ clk->rate = clk->recalc(clk);
+ propagate_rate(clk);
+ spin_unlock_irqrestore(&clockfw_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(clk_set_parent);
+
int clk_register(struct clk *clk)
{
if (clk == NULL || IS_ERR(clk))
--
1.6.4.3
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 13/46] davinci: support re-parenting a clock in the clock framework
2009-10-16 19:09 ` [PATCH 13/46] davinci: support re-parenting a clock in the " Kevin Hilman
@ 2009-10-19 14:05 ` Russell King - ARM Linux
2009-10-19 18:19 ` Kevin Hilman
2009-10-19 23:26 ` Kevin Hilman
0 siblings, 2 replies; 5+ messages in thread
From: Russell King - ARM Linux @ 2009-10-19 14:05 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 16, 2009 at 12:09:17PM -0700, Kevin Hilman wrote:
> From: Sekhar Nori <nsekhar@ti.com>
>
> The clk_set_parent() API is implemented to enable re-parenting
> clocks in the clock tree.
>
> This is useful in DVFS and helps by shifting clocks to an asynchronous
> domain where supported by hardware
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> arch/arm/mach-davinci/clock.c | 23 +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
> index 09e0e1c..12ceeea 100644
> --- a/arch/arm/mach-davinci/clock.c
> +++ b/arch/arm/mach-davinci/clock.c
> @@ -141,6 +141,29 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
> }
> EXPORT_SYMBOL(clk_set_rate);
>
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + unsigned long flags;
> +
> + if (clk == NULL || IS_ERR(clk))
> + return -EINVAL;
> +
> + mutex_lock(&clocks_mutex);
> + clk->parent = parent;
> + list_del_init(&clk->childnode);
> + list_add(&clk->childnode, &clk->parent->children);
> + mutex_unlock(&clocks_mutex);
This is bad, and is suffering from precisely the same problem which
OMAP suffered from:
1. it takes no notice of whether the clk is in use.
2. it takes no notice of whether the parent clocks are being used.
The result is that using clk_set_parent() on a clk_enable()'d clock,
you totally destroy the usecounting of the parent clocks, leading to
the clock tree usecount becoming totally buggered up.
Either refuse to change the parent of an already clk_enable()'d clock,
or do proper usecount fixups when changing the parent.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 13/46] davinci: support re-parenting a clock in the clock framework
2009-10-19 14:05 ` Russell King - ARM Linux
@ 2009-10-19 18:19 ` Kevin Hilman
2009-10-19 23:26 ` Kevin Hilman
1 sibling, 0 replies; 5+ messages in thread
From: Kevin Hilman @ 2009-10-19 18:19 UTC (permalink / raw)
To: linux-arm-kernel
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Fri, Oct 16, 2009 at 12:09:17PM -0700, Kevin Hilman wrote:
>> From: Sekhar Nori <nsekhar@ti.com>
>>
>> The clk_set_parent() API is implemented to enable re-parenting
>> clocks in the clock tree.
>>
>> This is useful in DVFS and helps by shifting clocks to an asynchronous
>> domain where supported by hardware
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>> ---
>> arch/arm/mach-davinci/clock.c | 23 +++++++++++++++++++++++
>> 1 files changed, 23 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
>> index 09e0e1c..12ceeea 100644
>> --- a/arch/arm/mach-davinci/clock.c
>> +++ b/arch/arm/mach-davinci/clock.c
>> @@ -141,6 +141,29 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
>> }
>> EXPORT_SYMBOL(clk_set_rate);
>>
>> +int clk_set_parent(struct clk *clk, struct clk *parent)
>> +{
>> + unsigned long flags;
>> +
>> + if (clk == NULL || IS_ERR(clk))
>> + return -EINVAL;
>> +
>> + mutex_lock(&clocks_mutex);
>> + clk->parent = parent;
>> + list_del_init(&clk->childnode);
>> + list_add(&clk->childnode, &clk->parent->children);
>> + mutex_unlock(&clocks_mutex);
>
> This is bad, and is suffering from precisely the same problem which
> OMAP suffered from:
>
> 1. it takes no notice of whether the clk is in use.
> 2. it takes no notice of whether the parent clocks are being used.
>
> The result is that using clk_set_parent() on a clk_enable()'d clock,
> you totally destroy the usecounting of the parent clocks, leading to
> the clock tree usecount becoming totally buggered up.
>
> Either refuse to change the parent of an already clk_enable()'d clock,
> or do proper usecount fixups when changing the parent.
On davinci, we only reparent during early init, so refusing to change
the parent of an enabled will suffice.
I've added a check (and warning) if the clock is already enabled as
well as a refusal to re-parent:
int clk_set_parent(struct clk *clk, struct clk *parent)
{
unsigned long flags;
if (clk == NULL || IS_ERR(clk))
return -EINVAL;
/* Cannot change parent on enabled clock */
if (WARN_ON(clk->usecount))
return -EINVAL;
mutex_lock(&clocks_mutex);
clk->parent = parent;
list_del_init(&clk->childnode);
list_add(&clk->childnode, &clk->parent->children);
mutex_unlock(&clocks_mutex);
spin_lock_irqsave(&clockfw_lock, flags);
if (clk->recalc)
clk->rate = clk->recalc(clk);
propagate_rate(clk);
spin_unlock_irqrestore(&clockfw_lock, flags);
return 0;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 13/46] davinci: support re-parenting a clock in the clock framework
2009-10-19 14:05 ` Russell King - ARM Linux
2009-10-19 18:19 ` Kevin Hilman
@ 2009-10-19 23:26 ` Kevin Hilman
1 sibling, 0 replies; 5+ messages in thread
From: Kevin Hilman @ 2009-10-19 23:26 UTC (permalink / raw)
To: linux-arm-kernel
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Fri, Oct 16, 2009 at 12:09:17PM -0700, Kevin Hilman wrote:
>> From: Sekhar Nori <nsekhar@ti.com>
>>
>> The clk_set_parent() API is implemented to enable re-parenting
>> clocks in the clock tree.
>>
>> This is useful in DVFS and helps by shifting clocks to an asynchronous
>> domain where supported by hardware
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>> ---
>> arch/arm/mach-davinci/clock.c | 23 +++++++++++++++++++++++
>> 1 files changed, 23 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
>> index 09e0e1c..12ceeea 100644
>> --- a/arch/arm/mach-davinci/clock.c
>> +++ b/arch/arm/mach-davinci/clock.c
>> @@ -141,6 +141,29 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
>> }
>> EXPORT_SYMBOL(clk_set_rate);
>>
>> +int clk_set_parent(struct clk *clk, struct clk *parent)
>> +{
>> + unsigned long flags;
>> +
>> + if (clk == NULL || IS_ERR(clk))
>> + return -EINVAL;
>> +
>> + mutex_lock(&clocks_mutex);
>> + clk->parent = parent;
>> + list_del_init(&clk->childnode);
>> + list_add(&clk->childnode, &clk->parent->children);
>> + mutex_unlock(&clocks_mutex);
>
> This is bad, and is suffering from precisely the same problem which
> OMAP suffered from:
>
> 1. it takes no notice of whether the clk is in use.
> 2. it takes no notice of whether the parent clocks are being used.
>
> The result is that using clk_set_parent() on a clk_enable()'d clock,
> you totally destroy the usecounting of the parent clocks, leading to
> the clock tree usecount becoming totally buggered up.
>
> Either refuse to change the parent of an already clk_enable()'d clock,
> or do proper usecount fixups when changing the parent.
Russell, thanks for the review.
Here's an updated version which refuses to reparent on an enabled
clock. This updated one is now part of davinci-next.
Kevin
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-10-19 23:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-31 10:18 [PATCH 13/46] davinci: support re-parenting a clock in the clock framework Sekhar Nori
-- strict thread matches above, loose matches on Subject: below --
2009-10-16 19:09 [PATCH 00/46] davinci updates for 2.6.33 Kevin Hilman
2009-10-16 19:09 ` Kevin Hilman
2009-10-16 19:09 ` [PATCH 01/46] DaVinci: DM365: SDIO interrupt resource correction Kevin Hilman
2009-10-16 19:09 ` [PATCH 02/46] DaVinci: DM365: Correct USB parent clock Kevin Hilman
2009-10-16 19:09 ` [PATCH 03/46] Davinci: DM365: Add platform device for McBSP Kevin Hilman
2009-10-16 19:09 ` [PATCH 04/46] davinci: Move DA8xx/OMAP-L13x emac register routine Kevin Hilman
2009-10-16 19:09 ` [PATCH 05/46] davinci: Change DA8xx/OMAP-L13x McASP registration routine name Kevin Hilman
2009-10-16 19:09 ` [PATCH 06/46] davinci: Add DA830/OMAP-L137 EVM specific pinmux setting for McASP1 Kevin Hilman
2009-10-16 19:09 ` [PATCH 07/46] davinci: DA8XX/OMAP-L1XX: It's SYSCFG not BOOT_CFG Kevin Hilman
2009-10-16 19:09 ` [PATCH 08/46] davinci: DA8XX/OMAP-L1XX: Avoid use of IO_ADDRESS for SYSCFG module Kevin Hilman
2009-10-16 19:09 ` [PATCH 09/46] davinci: DA8XX/OMAP-L1XX: JTAG ID register should offset from SYSCFG base Kevin Hilman
2009-10-16 19:09 ` [PATCH 10/46] davinci: enable easy top down traversal of clock tree Kevin Hilman
2009-10-16 19:09 ` [PATCH 11/46] davinci: make clock rate re-calculation easy Kevin Hilman
2009-10-16 19:09 ` [PATCH 12/46] davinci: support changing the clock rate in clock framework Kevin Hilman
2009-10-16 19:09 ` [PATCH 13/46] davinci: support re-parenting a clock in the " Kevin Hilman
2009-10-19 14:05 ` Russell King - ARM Linux
2009-10-19 18:19 ` Kevin Hilman
2009-10-19 23:26 ` Kevin Hilman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).