[PATCH] ARM: S3C64XX: Define some additional always off clocks

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Mark Brown]

Add entries to clocks_off for some additional clocks which are not
currently used by any mainline drivers. They default on at power up
but are never actually used so

If these blocks are actually supported some of these bindings would need
to be redone properly, for example hooking up to the muxes that use them,
but that can be done incrementally.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 arch/arm/mach-s3c64xx/clock.c |  101 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 378ccdb..d79986f 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -216,6 +216,107 @@ static struct clk init_clocks_off[] = {
 		.parent		= &clk_h,
 		.enable		= s3c64xx_hclk_ctrl,
 		.ctrlbit	= S3C_CLKCON_HCLK_DMA1,
+	}, {
+		.name		= "3dse",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_3DSE,
+	}, {
+		.name		= "hclk_secur",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_SECUR,
+	}, {
+		.name		= "sdma1",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_SDMA1,
+	}, {
+		.name		= "sdma0",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_SDMA0,
+	}, {
+		.name		= "hclk_jpeg",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_JPEG,
+	}, {
+		.name		= "camif",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_CAMIF,
+	}, {
+		.name		= "hclk_scaler",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_SCALER,
+	}, {
+		.name		= "2d",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_2D,
+	}, {
+		.name		= "tv",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_TV,
+	}, {
+		.name		= "post0",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_POST0,
+	}, {
+		.name		= "rot",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_ROT,
+	}, {
+		.name		= "hclk_mfc",
+		.parent		= &clk_h,
+		.enable		= s3c64xx_hclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_HCLK_MFC,
+	}, {
+		.name		= "pclk_mfc",
+		.parent		= &clk_p,
+		.enable		= s3c64xx_pclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_PCLK_MFC,
+	}, {
+		.name		= "dac27",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_DAC27,
+	}, {
+		.name		= "tv27",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_TV27,
+	}, {
+		.name		= "scaler27",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_SCALER27,
+	}, {
+		.name		= "sclk_scaler",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_SCALER,
+	}, {
+		.name		= "post0_27",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_POST0_27,
+	}, {
+		.name		= "secur",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_SECUR,
+	}, {
+		.name		= "sclk_mfc",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_MFC,
+	}, {
+		.name		= "cam",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_CAM,
+	}, {
+		.name		= "sclk_jpeg",
+		.enable		= s3c64xx_sclk_ctrl,
+		.ctrlbit	= S3C_CLKCON_SCLK_JPEG,
 	},
 };
 
-- 
1.7.7.3

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Tomasz Figa]

Hi Mark,

On Friday 02 of December 2011 15:57:48 Mark Brown wrote:
> Add entries to clocks_off for some additional clocks which are not
> currently used by any mainline drivers. They default on at power up
> but are never actually used so
> 
> If these blocks are actually supported some of these bindings would need
> to be redone properly, for example hooking up to the muxes that use them,
> but that can be done incrementally.

I have already done all the work needed to support the whole range of clocks 
on S3C6410, but I can't find time to create and submit all the patches.

(See: https://github.com/tom3q/spica-3.0/commits/android-
s3c64xx/arch/arm/mach-s3c64xx/clock.c if you are interested.)

Best regards,
Tom

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Mark Brown]

On Fri, Dec 02, 2011 at 08:16:53PM +0100, Tomasz Figa wrote:

> I have already done all the work needed to support the whole range of clocks 
> on S3C6410, but I can't find time to create and submit all the patches.

> (See: https://github.com/tom3q/spica-3.0/commits/android-
> s3c64xx/arch/arm/mach-s3c64xx/clock.c if you are interested.)

A lot of good stuff in there - it's a bit of a shame you've not signed
off any of the patches there.

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Tomasz Figa]

On Friday 02 of December 2011 19:37:48 Mark Brown wrote:
> On Fri, Dec 02, 2011 at 08:16:53PM +0100, Tomasz Figa wrote:
> > I have already done all the work needed to support the whole range of
> > clocks on S3C6410, but I can't find time to create and submit all the
> > patches.
> > 
> > (See: https://github.com/tom3q/spica-3.0/commits/android-
> > s3c64xx/arch/arm/mach-s3c64xx/clock.c if you are interested.)
> 
> A lot of good stuff in there - it's a bit of a shame you've not signed
> off any of the patches there.

Well, it's just an internal tree, not to be submitted right away. Some changes 
would need to be splitted into smaller ones, some joined. Probably some 
cleaning and rebasing would be also needed.

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Mark Brown]

On Fri, Dec 02, 2011 at 08:45:24PM +0100, Tomasz Figa wrote:

> Well, it's just an internal tree, not to be submitted right away. Some changes 
> would need to be splitted into smaller ones, some joined. Probably some 
> cleaning and rebasing would be also needed.

Yeah, I appreciate that you don't actually want to submit some of that
stuff right away but it makes it much easier for people to cherry pick
the work over into mainline if they need it and are inspired to do the
required cleanup.

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Tomasz Figa]

On Friday 02 of December 2011 21:13:15 Mark Brown wrote:
> On Fri, Dec 02, 2011 at 08:45:24PM +0100, Tomasz Figa wrote:
> > Well, it's just an internal tree, not to be submitted right away. Some
> > changes would need to be splitted into smaller ones, some joined.
> > Probably some cleaning and rebasing would be also needed.
> 
> Yeah, I appreciate that you don't actually want to submit some of that
> stuff right away but it makes it much easier for people to cherry pick
> the work over into mainline if they need it and are inspired to do the
> required cleanup.

OK, I will start adding sign offs from now on. I'm not experienced in 
submitting patches to mainline and I didn't know about importance of them.

I have much more things that I should have submitted already long time ago, 
it's a shame that I can't find time to do that. The whole tree is dedicated to 
features and fixes needed to run Linux on mobile devices with S3C6410 (Samsung 
Galaxy Spica GT-i5700 in particular), but I work on it in my free time, which 
usually is pretty limited.

[PATCH] ARM: S3C64XX: Define some additional always off clocks

[Mark Brown]

On Fri, Dec 02, 2011 at 10:31:26PM +0100, Tomasz Figa wrote:

> OK, I will start adding sign offs from now on. I'm not experienced in 
> submitting patches to mainline and I didn't know about importance of them.

Yeah, basically Signed-off-by is a purely legal thing - it means that
you're saying that you know where the code came from and that there's no
legal issue submitting it (see the full text in SubmittingPatches before
you start doing this!) so if someone else takes your work they should
keep your signoff.

> I have much more things that I should have submitted already long time ago, 
> it's a shame that I can't find time to do that. The whole tree is dedicated to 
> features and fixes needed to run Linux on mobile devices with S3C6410 (Samsung 
> Galaxy Spica GT-i5700 in particular), but I work on it in my free time, which 
> usually is pretty limited.

Hopefully other people can help you out there - it's great having the
code at all.  I know I saw a few things that might be interesting for my
systems.