headers
Stephen Boyd | 1 May 2012 04:17

[PATCH] ARM: msm: fix compilation flags for MSM_SCM (part 2)

eca55f4 (ARM: msm: fix compilation flags for MSM_SCM, 2011-11-08)
added the correct assembler directive for the first smc instance
but missed the second instance in scm_get_version(). Add it so we
can compile this file with newer binutils.

Cc: Marc Zyngier <marc.zyngier <at> arm.com>
Signed-off-by: Stephen Boyd <sboyd <at> codeaurora.org>
---
 arch/arm/mach-msm/scm.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-msm/scm.c b/arch/arm/mach-msm/scm.c
index bafabb5..c536fd6 100644
--- a/arch/arm/mach-msm/scm.c
+++ b/arch/arm/mach-msm/scm.c
 <at>  <at>  -282,6 +282,9  <at>  <at>  u32 scm_get_version(void)
 			__asmeq("%1", "r1")
 			__asmeq("%2", "r0")
 			__asmeq("%3", "r1")
+#ifdef REQUIRES_SEC
+			".arch_extension sec\n"
+#endif
 			"smc	#0	 <at>  switch to secure world\n"
 			: "=r" (r0), "=r" (r1)
 			: "r" (r0), "r" (r1)
--

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shawn Guo | 1 May 2012 10:11
Favicon

Re: [PATCH] clk: Use a separate struct for holding init data.

On Mon, Apr 30, 2012 at 03:46:49PM -0700, Saravana Kannan wrote:
> I'm still hoping a Ack/Nack for the general idea from the others.
> 
I believe that I have Acked the idea when you proposed it at the first
time.  What I really hoped is you can post the patch at least 1 week
earlier.  Basically I share the same frustration that Sascha has, the
platform porting have been delayed by flowing changes on the core code.
It's been -rc5, but we have not got a stable core base to have platform
porting expose on linux-next.

Anyway, since I agree this is the right direction for the long run, I
will revisit my platform porting one more time once Mike applies the
patch.

--

-- 
Regards,
Shawn
Permalink | Reply | 11 comments |
headers
Andrew Lunn | 1 May 2012 11:13
Picon

Re: [PATCH] clk: Use a separate struct for holding init data.

On Tue, May 01, 2012 at 04:11:05PM +0800, Shawn Guo wrote:
> On Mon, Apr 30, 2012 at 03:46:49PM -0700, Saravana Kannan wrote:
> > I'm still hoping a Ack/Nack for the general idea from the others.
> > 
> I believe that I have Acked the idea when you proposed it at the first
> time.  What I really hoped is you can post the patch at least 1 week
> earlier.  Basically I share the same frustration that Sascha has, the
> platform porting have been delayed by flowing changes on the core code.
> It's been -rc5, but we have not got a stable core base to have platform
> porting expose on linux-next.

Hi folks

I agree with you as well, it is frustrating. Could we agree, that once
this patch is in, we freeze the core until the start of the next
cycle. We use the remainder of this cycle for porting platforms to the
generic clock framework.

	  Andrew
Permalink | Reply | 10 comments |
headers
Mark Brown | 1 May 2012 19:00
Favicon
Gravatar

Re: [PATCH] clk: Use a separate struct for holding init data.

On Tue, May 01, 2012 at 11:13:34AM +0200, Andrew Lunn wrote:

> I agree with you as well, it is frustrating. Could we agree, that once
> this patch is in, we freeze the core until the start of the next
> cycle. We use the remainder of this cycle for porting platforms to the
> generic clock framework.

Or merge the platforms then do framework changes incrementally, updating
the platforms as we go (which is the normal pattern for maintaining a
framework...).  I see we've already got SPEAr merged.
Permalink | Reply | 9 comments |
headers
Andrew Lunn | 1 May 2012 20:04
Picon

Re: [PATCH] clk: Use a separate struct for holding init data.

> Or merge the platforms then do framework changes incrementally, updating
> the platforms as we go (which is the normal pattern for maintaining a
> framework...).  I see we've already got SPEAr merged.

I'm not too sure SPEAr has been really merged. As far as i understand,
its dependencies have not been fulfilled, so it does not compile. This
to me is another indication of the problems we have at the moment...

   Andrew
Permalink | Reply | 0 comments |
headers
Mark Brown | 1 May 2012 20:19
Favicon
Gravatar

Re: [PATCH] clk: Use a separate struct for holding init data.

On Tue, May 01, 2012 at 11:03:57AM -0700, Saravana Kannan wrote:

> Sorry for the annoyance I seem to have caused. I too have been
> trying to get this in for a while before the other platforms started
> using the new framework. Not everyone was free at the same time and
> it's taken longer that I would have wished for.

> I did my best to limit the changes that would be needed without
> making my patch useless. Appreciate your understanding.

To be honest it doesn't look like your patch is a particular issue here
- there's wider process problems, for example we've managed to go
through most of the release cycle and so far the only changes showing up
in -next are:

Viresh Kumar (6):
      SPEAr: clk: Add VCO-PLL Synthesizer clock
      SPEAr: clk: Add Auxiliary Synthesizer clock
      SPEAr: clk: Add Fractional Synthesizer clock
      SPEAr: clk: Add General Purpose Timer Synthesizer clock
      SPEAr: Switch to common clock framework
      SPEAr13xx: Add common clock framework support

Mark Brown (1):
      ARM: 7376/1: clkdev: Implement managed clk_get()

Sascha Hauer (1):
      clk: add a fixed factor clock

viresh kumar (1):
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mike Turquette | 2 May 2012 03:56
Picon
Favicon

Re: [PATCH] clk: Use a separate struct for holding init data.

On 20120501-19:19, Mark Brown wrote:
> On Tue, May 01, 2012 at 11:03:57AM -0700, Saravana Kannan wrote:
> 
> > Sorry for the annoyance I seem to have caused. I too have been
> > trying to get this in for a while before the other platforms started
> > using the new framework. Not everyone was free at the same time and
> > it's taken longer that I would have wished for.
> 
> > I did my best to limit the changes that would be needed without
> > making my patch useless. Appreciate your understanding.
> 
> To be honest it doesn't look like your patch is a particular issue here
> - there's wider process problems, for example we've managed to go
> through most of the release cycle and so far the only changes showing up
> in -next are:

I think that "wider process problems" is probably a euphemism, and I'll
take responsibility for that.  This has been a learning process for me
and I underestimated the percentage of my time that would be consumed by
common clk maintenance.  I'm trying to rectify that problem now.

> 
> Viresh Kumar (6):
>       SPEAr: clk: Add VCO-PLL Synthesizer clock
>       SPEAr: clk: Add Auxiliary Synthesizer clock
>       SPEAr: clk: Add Fractional Synthesizer clock
>       SPEAr: clk: Add General Purpose Timer Synthesizer clock
>       SPEAr: Switch to common clock framework
>       SPEAr13xx: Add common clock framework support
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Shawn Guo | 2 May 2012 04:14
Favicon

Re: [PATCH] clk: Use a separate struct for holding init data.

On Tue, May 01, 2012 at 06:56:50PM -0700, Mike Turquette wrote:
> I could use some suggestions on the best way to resolve the merge issues
> we have currently.  It appears that we have three bases that platforms
> need to port over the common clk framework:
> 
> Russell's clkdev
> Arnd's arm-soc
> My clk-next branch
> 
> I was happy to push my changes to Linus directly (as discussed in
> previous mails) but I'm starting to think that maybe having Arnd absorb
> the clk-next branch as part of arm-soc would be the fastest way to
> assist platforms that are porting over.
> 
> Do the platform folks agree?  Is this suggestion sane?
> 
As one of the people who are working on platform porting, I'm not
concerned about the path that clk core goes to Linus, but the time
when we have a stable clk core branch appears on arm-soc either as
a dependency or a downstream tree.  Once we have stable branches for
both rmk's clkdev and clk core appear on arm-soc, we can start asking
Arnd to pull platform porting.

--

-- 
Regards,
Shawn
Permalink | Reply | 0 comments |
headers
Saravana Kannan | 2 May 2012 06:42

Re: [PATCH] clk: Use a separate struct for holding init data.

On 05/01/2012 07:04 PM, Mike Turquette wrote:
> On 20120425-22:58, Saravana Kannan wrote:
>> Create a struct clk_init_data to hold all data that needs to be passed from
>> the platfrom specific driver to the common clock framework during clock
>> registration. Add a pointer to this struct inside clk_hw.
>>
>> This has several advantages:
>> * Completely hides struct clk from many clock platform drivers and static
>>    clock initialization code that don't care for static initialization of
>>    the struct clks.
>> * For platforms that want to do complete static initialization, it removed
>>    the need to directly mess with the struct clk's fields while still
>>    allowing to statically allocate struct clk. This keeps the code more
>>    future proof even if they include clk-private.h.
>> * Simplifies the generic clk_register() function and allows adding optional
>>    fields in the future without modifying the function signature.
>> * Simplifies the static initialization of clocks on all platforms by
>>    removing the need for forward delcarations or convoluted macros.
>>
>> Signed-off-by: Saravana Kannan<skannan <at> codeaurora.org>
>
> Hi Saravana,
>
> Thanks for the patch.  I've taken it into my clk-next but I have two
> points:

Yayyy!! Finally I can get rid of having to know about struct clk.

> 1) I'm surprised that you abandoned the approach of exposing the
> less-private members of struct clk via struct clk_hw.  Your original
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sascha Hauer | 2 May 2012 11:58
Picon
Favicon

Re: [PATCH] clk: Use a separate struct for holding init data.

On Wed, Apr 25, 2012 at 10:58:56PM -0700, Saravana Kannan wrote:
> Create a struct clk_init_data to hold all data that needs to be passed from
> the platfrom specific driver to the common clock framework during clock
> registration. Add a pointer to this struct inside clk_hw.
> 
> This has several advantages:
> * Completely hides struct clk from many clock platform drivers and static
>   clock initialization code that don't care for static initialization of
>   the struct clks.
> * For platforms that want to do complete static initialization, it removed
>   the need to directly mess with the struct clk's fields while still
>   allowing to statically allocate struct clk. This keeps the code more
>   future proof even if they include clk-private.h.
> * Simplifies the generic clk_register() function and allows adding optional
>   fields in the future without modifying the function signature.
> * Simplifies the static initialization of clocks on all platforms by
>   removing the need for forward delcarations or convoluted macros.
> 
> Signed-off-by: Saravana Kannan <skannan <at> codeaurora.org>
> Cc: Mike Turquette <mturquette <at> linaro.org>
> Cc: Andrew Lunn <andrew <at> lunn.ch>
> Cc: Rob Herring <rob.herring <at> calxeda.com>
> Cc: Russell King <linux <at> arm.linux.org.uk>
> Cc: Jeremy Kerr <jeremy.kerr <at> canonical.com>
> Cc: Thomas Gleixner <tglx <at> linutronix.de>
> Cc: Arnd Bergman <arnd.bergmann <at> linaro.org>
> Cc: Paul Walmsley <paul <at> pwsan.com>
> Cc: Shawn Guo <shawn.guo <at> freescale.com>
> Cc: Sascha Hauer <s.hauer <at> pengutronix.de>
> Cc: Jamie Iles <jamie <at> jamieiles.com>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane