On Mon, 26 Nov 2007 15:41:19 -0600
Scott Wood wrote:
> Vitaly Bordug wrote:
> > perhaps I was not clear enough. That was a rough idea how to handle
> > the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> > case, but there can be other actions that may confuse CPM being
> > trigger
Vitaly Bordug wrote:
> perhaps I was not clear enough. That was a rough idea how to handle
> the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> case, but there can be other actions that may confuse CPM being
> triggered simultaneously or overlapping.
What kind of actions did you
On Mon, 26 Nov 2007 10:24:46 -0600
Scott Wood wrote:
> On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> > Even that might be not enough - we may have simultaneous call of
> > this func in non-smp case...
>
> Do you really think that every piece of code that uses spinlocks in
> the
On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> Even that might be not enough - we may have simultaneous call of this func
> in non-smp case...
Do you really think that every piece of code that uses spinlocks in the
kernel is broken on non-SMP?
> I was thinking of some kind of re
On Sat, 24 Nov 2007 18:53:34 +0100
Jochen Friedrich wrote:
> Hi Vitaly,
>
> >>> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> >>> + __FUNCTION__);
> >>> + return -EIO;
> >>>
> >> Do these need to be protected with a spin lock?
> >>
> > Even t
Hi Vitaly,
>>> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
>>> + __FUNCTION__);
>>> + return -EIO;
>>>
>> Do these need to be protected with a spin lock?
>>
> Even that might be not enough - we may have simultaneous call of this func in
> non
On Thu, 22 Nov 2007 11:36:29 -0700
Grant Likely wrote:
> > +int cpm_command(u32 command, u8 opcode)
> > +{
> > + int i;
> > +
> > + if (command & 0xff0f)
> > + return -EINVAL;
> > +
> > + out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode <<
> > 8));
> > +
On 11/22/07, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> This patch moves the CPM command handling into commproc.c
> for CPM1 and cpm2_common.c. This is yet another preparation
> to get rid of drivers accessing the CPM via the global cpmp.
>
> Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
>
This patch moves the CPM command handling into commproc.c
for CPM1 and cpm2_common.c. This is yet another preparation
to get rid of drivers accessing the CPM via the global cpmp.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/commproc.c | 20 +++
