Create the dts files for each core and splits the devices between the two cores
for P1020RDB.
Core0 has core0 to have memory, l2, i2c, spi, gpio, tdm, dma, usb, eth1, eth2,
sdhc, crypto, global-util, message, pci0, pci1, msi.
Core1 has l2, eth0, crypto.
MPIC is shared between two cores but each c
D3-cold state indicates removal of the clock and power. however auxiliary (AUX)
Power may remain available even after the main power rails are powered down.
wakeup from D3-cold state requires full context restore. Other things are taken
care in pci-driver except ATMUs.
ATMU windows needs to be sav
On (Wed) 27 Apr 2011 [17:09:34], Greg KH wrote:
> On Wed, Apr 27, 2011 at 12:01:47PM +0530, Amit Shah wrote:
> > On (Wed) 27 Apr 2011 [14:31:29], Rusty Russell wrote:
> > > On Wed, 20 Apr 2011 22:36:10 +0530, Amit Shah
> > > wrote:
> > > > On (Wed) 20 Apr 2011 [07:34:35], Greg KH wrote:
> > > > >
Hi Michał,
On Wed, 27 Apr 2011 12:36:22 +0200 Michał Mirosław
wrote:
>
> Please test the following patch. It's just a blind guess, as this error
> is not descriptive.
>
> Best Regards,
> Michał Mirosław
>
> ---
>
> net: ibmveth: force reconfiguring checksum settings on startup
>
> Commit b93
On Wed, Apr 27, 2011 at 12:01:47PM +0530, Amit Shah wrote:
> On (Wed) 27 Apr 2011 [14:31:29], Rusty Russell wrote:
> > On Wed, 20 Apr 2011 22:36:10 +0530, Amit Shah wrote:
> > > On (Wed) 20 Apr 2011 [07:34:35], Greg KH wrote:
> > > > Care to either create this patch, or resend your original one, i
On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote:
>> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote:
>>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote:
I'm getting an error message when trying to talk to some cust
Powerpc and Arm select breakpoint support ability only if
Perf is built. This is not necessary anymore now that we
enable perf once breakpoints support is selected.
Signed-off-by: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
---
arch/arm/K
Migrate conditional hw_breakpoint code compilation under
the new config to prepare for letting the user chose whether
or not to build this feature
Signed-off-by: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
---
arch/arm/include/asm/hw_brea
On 04/26/2011 07:39 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-04-26 at 09:38 -0400, Steven A. Falco wrote:
>> On 04/25/2011 08:01 PM, Benjamin Herrenschmidt wrote:
>>> On Mon, 2011-04-25 at 16:10 -0400, Steven A. Falco wrote:
I'm getting an error message when trying to talk to some cust
On Wed, 2011-04-27 at 08:40 +0100, David Laight wrote:
> I keep telling Eric that the code below is incorrect
> modulo arithimetic...
His previous versions were wrong yes. This one should be limping along
afaik. But I tend to agree, testing delta is the way to go.
Eric idea was to not test the si
On Wed, 27 Apr 2011, David Laight wrote:
>
> > prev and val are both 64 bit variables holding 32 bit numbers, we do
> not
> > accumulate in either, they are both replaced by values directly from
> the
> > registers.
> > So prev > val will not always be true.
>
> The code seems to be:
> prev
> prev and val are both 64 bit variables holding 32 bit numbers, we do
not
> accumulate in either, they are both replaced by values directly from
the
> registers.
> So prev > val will not always be true.
The code seems to be:
prev = local64_read(&event->hw.prev_count);
val = read_pmc(eve
On Wed, 27 Apr 2011, David Laight wrote:
>
> > + if (prev > val && (prev - val) < 256)
> > + delta = 0;
> > +
> > + return delta;
>
> Also, 'prev' is a true 64bit value, but 'val' is only ever 32bits.
> So once the 64bit 'prev' exceeds 2^32+256 both 'prev > val'
> and 'prev - val'
> On Wed, 27 Apr 2011, David Laight wrote:
>
> > > But it isn't, and it doesn't have trouble with 2^32 - 1.
> >
> > what about:
> > prev = 0x0001
> > val = 0x
>
> Result is 0xfffe and we are fine.
'delta' will be 0xfffe, but you need the function to
return zero - since
On Wed, 27 Apr 2011, David Laight wrote:
> > But it isn't, and it doesn't have trouble with 2^32 - 1.
>
> what about:
> prev = 0x0001
> val = 0x
Result is 0xfffe and we are fine.
>
> David
>
>
signature.asc
Description: Digital signature
> + if (prev > val && (prev - val) < 256)
> + delta = 0;
> +
> + return delta;
Also, 'prev' is a true 64bit value, but 'val' is only ever 32bits.
So once the 64bit 'prev' exceeds 2^32+256 both 'prev > val'
and 'prev - val' are true regardless of the value of 'val'.
This will
> But it isn't, and it doesn't have trouble with 2^32 - 1.
what about:
prev = 0x0001
val = 0x
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 27 Apr 2011, David Laight wrote:
> I keep telling Eric that the code below is incorrect
> modulo arithimetic...
But it isn't, and it doesn't have trouble with 2^32 - 1. Here is one done by
hand:
Counter is at 0x and is rolled over to 0x101 (258 counted items so
that we miss the
On Wed, Apr 27, 2011 at 02:49:01PM +1000, Stephen Rothwell wrote:
> For the last couple of days, linux-next booting on a few of our Power
> partitions (but not all) have produced this error (over and over):
>
> ibmveth 300b: eth0: tx: h_send_logical_lan failed with rc=-4
>
> Linus' tree seems
I keep telling Eric that the code below is incorrect
modulo arithimetic...
> +static u64 check_and_compute_delta(u64 prev, u64 val)
> +{
> + u64 delta = (val - prev) & 0xul;
> +
> + /*
> + * POWER7 can roll back counter values, if the new value is
smaller
> + * than the p
20 matches
Mail list logo
