Stephane Eranian [eran...@google.com] wrote:
| > Further, in the above REM_CCE1 case, Power7 can also identify if the data
came
| > from the L2 or L3 cache of another core on the same chip. To describe this
to
| > user space, we propose to set ->mem_lvl to:
| >
| > PERF_MEM_LVL_REM_CCE1|P
On 06/10/2013 12:07:43 PM, Michael Guntsche wrote:
Good evening,
On Mon, Jun 10, 2013 at 1:41 PM, Rojhalat Ibrahim
wrote:
> Hi Mike,
>
> could you please try this patch:
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-May/106624.html
> http://patchwork.ozlabs.org/patch/244515/
>
>
Anshuman Khandual [khand...@linux.vnet.ibm.com] wrote:
| > The former approach seems less confusing and this patch uses that approach.
| >
|
| Yeah, the former approach is simpler and makes sense.
Ok. Seems to make sense at least on Power.
| > + * We use the table, dcache_src_map, to map this
On Mon, 2013-06-10 at 21:14 +1000, Erik de Castro Lopo wrote:
> Benjamin Herrenschmidt wrote:
>
> > No, this loads a 32-bit value (16-bit would be lhz).
>
> My understanding so far (which may be wrong) is that it loads a
> 32 bit value but it loads it from a memory location that needs
> to be wit
Commit 37f02195b (powerpc/pci: fix PCI-e devices rescan issue on powerpc
platform) fixes a problem with interrupt and DMA initialization on hot
plugged devices. With this commit, interrupt and DMA initialization for
hot plugged devices is handled in the pci device enable function.
This approach ha
Good evening,
On Mon, Jun 10, 2013 at 1:41 PM, Rojhalat Ibrahim wrote:
> Hi Mike,
>
> could you please try this patch:
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-May/106624.html
> http://patchwork.ozlabs.org/patch/244515/
>
>Rojhalat
>
>
> On Saturday 08 June 2013 21:39:37 Michael
On Mon, Jun 10, 2013 at 4:37 PM, Anca Emanuel wrote:
> The relevant maintainers do not get a copy of this.
I do hope the PPC maintainers do read linuxppc-dev@lists.ozlabs.org.
> On Mon, Jun 10, 2013 at 10:25 AM, Geert Uytterhoeven
> wrote:
>> On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
>>> J
The relevant maintainers do not get a copy of this.
On Mon, Jun 10, 2013 at 10:25 AM, Geert Uytterhoeven
wrote:
> On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
>> JFYI, when comparing v3.10-rc5 to v3.10-rc4[3], the summaries are:
>> - build errors: +19/-10
>> [1] http://kisskb.ellerman.id.au/
> > Note: It's more readable if you use the register names, ie:
> >
> > lwz %r30, .label - (1b)(%r31)
> >
> > The form of lwz is
> >
> > lwz dest_reg, offset(address_reg)
> >
> > So it will load a 32-bit value from memory at the address contained in
> > r31 offset by ".label - 1b" w
Hi Mike,
could you please try this patch:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-May/106624.html
http://patchwork.ozlabs.org/patch/244515/
Rojhalat
On Saturday 08 June 2013 21:39:37 Michael Guntsche wrote:
> After bisecting I found the responsible commit.
>
> 50d8f87d2b3: powe
Benjamin Herrenschmidt wrote:
> No, this loads a 32-bit value (16-bit would be lhz).
My understanding so far (which may be wrong) is that it loads a
32 bit value but it loads it from a memory location that needs
to be within +/- 32k of the instriction doing the load.
The reason I think this is b
On Mon, Jun 10, 2013 at 8:40 AM, Linus Walleij wrote:
> On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely wrote:
>
>> This is an RFC patch to convert the versatile FPGA irq controller driver
>> to use generic irq chip. It builds on the series that extends the
>> generic chip code to allow a linear ir
On Mon, Jun 10, 2013 at 10:03 AM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 01:49:22AM +0100, Grant Likely wrote:
>> This is an RFC patch to convert the versatile FPGA irq controller driver
>> to use generic irq chip. It builds on the series that extends the
>> generic chip code to
On Mon, Jun 10, 2013 at 01:49:22AM +0100, Grant Likely wrote:
> This is an RFC patch to convert the versatile FPGA irq controller driver
> to use generic irq chip. It builds on the series that extends the
> generic chip code to allow a linear irq domain to contain one or more
> generic irq chips so
Only part of MPC5125 reset module is like as MPC5121.
In detail, RCWH register doesn't contain informations about:
- PCI arbiter
- NAND flash page size
- NAND flash port size
For this reason, in device tree, this module has a different name then
MPC5121 reset module but use the same "struct mpc512
>
> AFAICT, Power7 supports one extra level in the cache-hierarchy, so we propose
> to add a new cache level, REM_CCE3 shown above.
>
> To maintain consistency in terminology (i.e 2-hops = remote, 3-hops =
> distant),
> I propose leaving the REM_MEM1 unused and adding another level, REM_MEM3.
>
On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely wrote:
> This is an RFC patch to convert the versatile FPGA irq controller driver
> to use generic irq chip. It builds on the series that extends the
> generic chip code to allow a linear irq domain to contain one or more
> generic irq chips so that e
On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.10-rc5 to v3.10-rc4[3], the summaries are:
> - build errors: +19/-10
> [1] http://kisskb.ellerman.id.au/kisskb/head/6308/ (all 120 configs)
+ arch/powerpc/kernel/cacheinfo.c: error: 'associativity' may be used
uninitializ
18 matches
Mail list logo
