[PATCH 1/2] mfd/db8500-prcmu: rename init function

[PATCH 1/2] mfd/db8500-prcmu: rename init function

[Linus Walleij]

From: Linus Walleij <linus.walleij@linaro.org>

This renames the PRCMU clock force initialization function
to have a less generic name.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Patch made on Samuel Ortiz' request as a review comment on
"mfd/db8500-prcmu: initialize DB8500 PRCMU regs"
---
 drivers/mfd/db8500-prcmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 91a5e8c..98da431 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2154,7 +2154,7 @@ void __init db8500_prcmu_early_init(void)
 	}
 }
 
-static void __init init_prcm_registers(void)
+static void __init db8500_prcmu_init_clkforce(void)
 {
 	u32 val;
 
@@ -2412,7 +2412,7 @@ static int __init db8500_prcmu_probe(struct platform_device *pdev)
 	if (ux500_is_svp())
 		return -ENODEV;
 
-	init_prcm_registers();
+	db8500_prcmu_init_clkforce();
 
 	/* Clean up the mailbox interrupts after pre-kernel code. */
 	writel(ALL_MBOX_BITS, PRCM_ARM_IT1_CLR);
-- 
1.7.3.2

Re: [PATCH 1/2] mfd/db8500-prcmu: rename init function

[Linus Walleij]

On Wed, Oct 5, 2011 at 6:50 PM, Linus Walleij
<linus.walleij@stericsson.com> wrote:

> From: Linus Walleij <linus.walleij@linaro.org>
>
> This renames the PRCMU clock force initialization function
> to have a less generic name.

So these are fixing the review comments, if you prefer me to squash
them into the other patches just tell me.

I can also prepare a pull request for the stuff you want if it makes
things easier for you, just tell me what you want in it.

Yours,
Linus Walleij

Re: [PATCH 1/2] mfd/db8500-prcmu: rename init function

[Samuel Ortiz]

Hi Linus,

On Wed, Oct 05, 2011 at 06:59:01PM +0200, Linus Walleij wrote:
> On Wed, Oct 5, 2011 at 6:50 PM, Linus Walleij
> <linus.walleij@stericsson.com> wrote:
> 
> > From: Linus Walleij <linus.walleij@linaro.org>
> >
> > This renames the PRCMU clock force initialization function
> > to have a less generic name.
> 
> So these are fixing the review comments, if you prefer me to squash
> them into the other patches just tell me.
> 
> I can also prepare a pull request for the stuff you want if it makes
> things easier for you, just tell me what you want in it.
I took the first 12 patches plus your 2 review fixes. I indeed feel the rest
of the patchset would need some additional work. If there's really nothing we
can do about factorizing more of this code between 8500 and 5500, then I'll
look at it for the 3.3 merge window.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: [PATCH 1/2] mfd/db8500-prcmu: rename init function

[Linus Walleij]

On Mon, Oct 10, 2011 at 12:29 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:

>> I can also prepare a pull request for the stuff you want if it makes
>> things easier for you, just tell me what you want in it.
>
> I took the first 12 patches plus your 2 review fixes. I indeed feel the rest
> of the patchset would need some additional work. If there's really nothing we
> can do about factorizing more of this code between 8500 and 5500, then I'll
> look at it for the 3.3 merge window.

OK seems like a fair deal. I have different ideas, like for example
abstracting the MBOX parts into a new mailbox subsystem since
abstracting mailboxes has been discussed before. So maybe we can
break out all of that code into drivers/mbox and proceed from
there getting pure MFD arbiters in drivers/mfd.

Yours,
Linus Walleij

Re: [PATCH 1/2] mfd/db8500-prcmu: rename init function

[Samuel Ortiz]

Hi Linus,

On Mon, Oct 10, 2011 at 01:08:21PM +0200, Linus Walleij wrote:
> On Mon, Oct 10, 2011 at 12:29 PM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> 
> >> I can also prepare a pull request for the stuff you want if it makes
> >> things easier for you, just tell me what you want in it.
> >
> > I took the first 12 patches plus your 2 review fixes. I indeed feel the rest
> > of the patchset would need some additional work. If there's really nothing we
> > can do about factorizing more of this code between 8500 and 5500, then I'll
> > look at it for the 3.3 merge window.
> 
> OK seems like a fair deal. I have different ideas, like for example
> abstracting the MBOX parts into a new mailbox subsystem since
> abstracting mailboxes has been discussed before. 
Many subsystems and archs would benefit from that, i think.

> So maybe we can
> break out all of that code into drivers/mbox and proceed from
> there getting pure MFD arbiters in drivers/mfd.
Sounds good to me.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/