> > +&soc {
> > +/include/ "qoriq-tdm1.0.dtsi"
>
> Where is this file? Is there some dependency you've forgotten to mention?
>
> If this is meant to apply after
> http://patchwork.ozlabs.org/patch/457605/
> is that really QUICC engine TDM as described in the comment above?
>
> -Scott
Yes, it de
> > ---
> > v2: Integrated scott's comments.
>
> My comment was to add a binding for the QE TDM stuff, not to remove it.
>
> -Scott
QE TDM has not been upstream on any fsl-board, it needs QE TDM owner finish it
uniformly for those boards(p1021, p1025, t1040, t1024, etc) with binding.
_
On 09.04.15 12:52:55, Anton Blanchard wrote:
> We want to enable the hard lockup detector on ppc64, but right now
> that enables the oprofile NMI timer too.
>
> We'd prefer not to enable the oprofile NMI timer, it adds another
> element to our PMU testing and it requires us to increase our
> expor
On Thu, Apr 9, 2015 at 2:12 AM, Julian Calaby wrote:
> Hi Konstantin,
>
> On Thu, Apr 9, 2015 at 3:04 AM, Konstantin Khlebnikov
> wrote:
>> On 08.04.2015 19:59, Konstantin Khlebnikov wrote:
>>>
>>> Node 0 might be offline as well as any other numa node,
>>> in this case kernel cannot handle memor
On Thu, Apr 9, 2015 at 2:07 AM, Nishanth Aravamudan
wrote:
> On 08.04.2015 [20:04:04 +0300], Konstantin Khlebnikov wrote:
>> On 08.04.2015 19:59, Konstantin Khlebnikov wrote:
>> >Node 0 might be offline as well as any other numa node,
>> >in this case kernel cannot handle memory allocation and cra
Commit 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
converted uses of CONFIG_JUMP_LABEL to HAVE_JUMP_LABEL in
some assembly files.
HAVE_JUMP_LABEL is defined in linux/jump_label.h, so we need to
include this or we always get the non jump label fallback code.
Fixes: 1bc9e47aa8e4 ("powe
To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
so we select a fallback version if the toolchain does not support
them.
Modify linux/jump_label.h so it can be included by assembly files.
We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
Signed-off-by: Anton Blanchard
--
Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
Since these are kernel only headers, we don't need #ifdef __KERNEL__
so can simplify things a bit.
If an architecture wants to use jump labels in assembly, it
will still need to define a macro to create the __jump_table
entries (see AR
Commit 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
converted uses of CONFIG_JUMP_LABEL to HAVE_JUMP_LABEL in
some assembly files.
HAVE_JUMP_LABEL is defined in linux/jump_label.h, so we need to
include this or we always get the non jump label fallback code.
Fixes: 1bc9e47aa8e4 ("powe
To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
so we select a fallback version if the toolchain does not support
them.
Modify linux/jump_label.h so it can be included by assembly files.
We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
Signed-off-by: Anton Blanchard
--
Wrap asm/jump_label.h for all archs with #ifndef __ASSEMBLY__.
Since these are kernel only headers, we don't need #ifdef __KERNEL__
so can simplify things a bit.
If an architecture wants to use jump labels in assembly, it
will still need to define a macro to create the __jump_table
entries (see AR
On Thu, 2015-04-09 at 13:21 +1000, Alexey Kardashevskiy wrote:
> On 04/09/2015 01:43 AM, Alex Williamson wrote:
> > On Wed, 2015-04-08 at 13:22 +1000, Alexey Kardashevskiy wrote:
> >> On 04/03/2015 07:50 AM, Alex Williamson wrote:
> >>>
> >>> Should have sent this with the other comments, but found
On 04/09/2015 01:43 AM, Alex Williamson wrote:
On Wed, 2015-04-08 at 13:22 +1000, Alexey Kardashevskiy wrote:
On 04/03/2015 07:50 AM, Alex Williamson wrote:
Should have sent this with the other comments, but found it hiding on my
desktop...
On Sat, 2015-03-28 at 01:55 +1100, Alexey Kardashevs
Add a devicetree description for property nodes for the NX Coprocessor
in an IBM PowerPC processor.
Signed-off-by: Dan Streetman
---
Is this the right location/naming for this file?
And did I get the content format right?
Should this file be called "ibm-nx-opal.txt" instead of "ibm-nx-powernv.t
The hard lockup detector uses a PMU event as a periodic NMI to
detect if we are stuck (where stuck means no timer interrupts have
occurred).
Ben's rework of the ppc64 soft disable code has made ppc64 PMU
exceptions a partial NMI. They can get disabled if an external
interrupt comes in, but otherwi
We want to enable the hard lockup detector on ppc64, but right now
that enables the oprofile NMI timer too.
We'd prefer not to enable the oprofile NMI timer, it adds another
element to our PMU testing and it requires us to increase our
exported symbols (eg cpu_khz).
Modify the config entry for OP
Hi Konstantin,
On Thu, Apr 9, 2015 at 3:04 AM, Konstantin Khlebnikov
wrote:
> On 08.04.2015 19:59, Konstantin Khlebnikov wrote:
>>
>> Node 0 might be offline as well as any other numa node,
>> in this case kernel cannot handle memory allocation and crashes.
>
>
> Example:
>
> [0.027133] -
On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
> Anshuman Khandual wrote on 23.03.2015
> 11:34:30:
>
> > > With that in mind, do we have a way to set the top 32bits of the MSR
> > > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > > find anything like that in thi
On 08.04.2015 [20:04:04 +0300], Konstantin Khlebnikov wrote:
> On 08.04.2015 19:59, Konstantin Khlebnikov wrote:
> >Node 0 might be offline as well as any other numa node,
> >in this case kernel cannot handle memory allocation and crashes.
Isn't the bug that numa_node_id() returned an offline node
On Wed, 2015-04-08 at 18:46 +0800, Shengzhou Liu wrote:
> The T1024 SoC includes the following function and features:
> - Two 64-bit Power architecture e5500 cores, up to 1.4GHz
> - private 256KB L2 cache each core and shared 256KB CoreNet platform cache
> (CPC)
> - 32-/64-bit DDR3L/DDR4 SDRAM mem
On Wed, 2015-04-08 at 18:46 +0800, Shengzhou Liu wrote:
> T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC.
>
> T1024RDB board Overview
> ---
> - Processor: T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
> - Memory: 64-bit 4GB DDR3L UDIMM with
On Wed, 2015-04-08 at 18:46 +0800, Shengzhou Liu wrote:
> + clockgen: global-utilities@e1000 {
> + compatible = "fsl,t1023-clockgen", "fsl,qoriq-clockgen-2.0",
> +"fixed-clock";
> + reg = <0xe1000 0x1000>;
> + clock-output-name
On Wed, Apr 8, 2015 at 1:01 AM, Benjamin Herrenschmidt
wrote:
> Use a different flag to indicate the BAR policy or temporarily tweak a
> local copy of the resource flag during BAR assignment or whatever you
> prefer to fix the original problem but do *not* change the Linux overall
> view of that
On 08.04.2015 19:59, Konstantin Khlebnikov wrote:
Node 0 might be offline as well as any other numa node,
in this case kernel cannot handle memory allocation and crashes.
Example:
[0.027133] [ cut here ]
[0.027938] kernel BUG at include/linux/gfp.h:322!
[0.0
Node 0 might be offline as well as any other numa node,
in this case kernel cannot handle memory allocation and crashes.
Signed-off-by: Konstantin Khlebnikov
Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function")
---
drivers/of/base.c |2 +-
include/linux/of.h |5 -
On Wed, 2015-04-08 at 10:43 +0300, Igal.Liberman wrote:
> @@ -76,6 +77,52 @@ Required properties:
>
> Recommended properties:
> - clocks: Should be the phandle of input parent clock
> + For "fsl,fman-clk-mux" clock there are several options for parent
> + clock (clock provider), the par
Anshuman Khandual wrote on 23.03.2015
11:34:30:
> > With that in mind, do we have a way to set the top 32bits of the MSR
> > (which contain the TM bits) when ptracing 32 bit processes? I can't
> > find anything like that in this patch set.
>
> No, we dont have that yet. When ptracing in 32-bit m
On Wed, Apr 08, 2015 at 07:19:46PM +0200, Cédric Le Goater wrote:
> Hello !
>
> These patches extend the ibmpowernv driver to support the new OPAL firmware
> which now exposes in its device tree the Digital Temperature Sensors of
> a P8 system.
>
> They are based on Linux 4.0.0-rc7 + the initia
On 04/08/2015 07:32 PM, Guenter Roeck wrote:
> On Wed, Apr 08, 2015 at 07:19:46PM +0200, Cédric Le Goater wrote:
>> Hello !
>>
>> These patches extend the ibmpowernv driver to support the new OPAL firmware
>> which now exposes in its device tree the Digital Temperature Sensors of
>> a P8 system.
The new OPAL device tree for sensors has a different layout and uses new
property names, for the type and for the handler used to capture the
sensor data.
This patch modifies the ibmpowernv driver to support such a tree in a
way preserving compatibility with older OPAL firmwares.
This is achieved
Currently, sensors are only identified by their type and index.
The new OPAL device tree can expose extra properties to identify
some sensors by their name or location. This patch adds the creation
of a new hwmon *_label attribute when such properties are detected.
Signed-off-by: Cédric Le Goater
The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.
In the case of a cpu core sensor, the firmware exposes the physical
identifier of the core in the "ibm,pir" property. The driver
translates this identifier in a linux cpu number and print
This should shorten a bit the code necessary to create a hmwon attribute.
Signed-off-by: Cédric Le Goater
---
Changes since v1:
- fix alignment of create_hwmon_attr() prototype
drivers/hwmon/ibmpowernv.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff
Hello !
These patches extend the ibmpowernv driver to support the new OPAL firmware
which now exposes in its device tree the Digital Temperature Sensors of
a P8 system.
They are based on Linux 4.0.0-rc7 + the initial cleanup serie :
http://lists.lm-sensors.org/pipermail/lm-sensors/2015-Ma
On 04/08/2015 05:20 PM, Guenter Roeck wrote:
> On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree for sensors has a different layout and uses new
>> property names, for the type and for the handler used to capture the
>> sensor data.
>>
>> This patch modif
On Wed, 2015-04-08 at 13:22 +1000, Alexey Kardashevskiy wrote:
> On 04/03/2015 07:50 AM, Alex Williamson wrote:
> >
> > Should have sent this with the other comments, but found it hiding on my
> > desktop...
> >
> > On Sat, 2015-03-28 at 01:55 +1100, Alexey Kardashevskiy wrote:
> >> In order to sup
On Wed, Apr 08, 2015 at 03:42:07PM +0200, Cédric Le Goater wrote:
> The new OPAL device tree adds a few properties which can be used to add
> extra information on the sensor label.
>
> In the case of a cpu core sensor, the firmware exposes the physical
> identifier of the core in the "ibm,pir" pr
On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
> The new OPAL device tree for sensors has a different layout and uses new
> property names, for the type and for the handler used to capture the
> sensor data.
>
> This patch modifies the ibmpowernv driver to support such a tree in
On Wed, Apr 08, 2015 at 10:45:45AM -0400, Dan Streetman wrote:
>
> Ok I'll see if I can include a sw compression implementation.
That would be great!
> ah ok, so you mean it can still be a crypto_comp interface, just move
> its location and/or merge it into nx-842.c?
Oh yes of course. There is
On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu wrote:
> On Tue, Apr 07, 2015 at 01:34:30PM -0400, Dan Streetman wrote:
>> Add configurable module to perform self-tests on any crypto compression
>> driver.
>>
>> This allows testing any crypto compression driver with any input buffer,
>> at varying ali
On Wed, Apr 8, 2015 at 10:38 AM, Herbert Xu wrote:
> On Wed, Apr 08, 2015 at 10:28:23AM -0400, Dan Streetman wrote:
>>
>> So, the sw implementation is only for decompression; there's no sw
>> compression implementation in these patches.
>
> As a general rule we don't add any hardware implementatio
On Wed, Apr 08, 2015 at 10:28:23AM -0400, Dan Streetman wrote:
>
> So, the sw implementation is only for decompression; there's no sw
> compression implementation in these patches.
As a general rule we don't add any hardware implementation unless
there is a software implementation. The reason is
On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu wrote:
> On Tue, Apr 07, 2015 at 01:34:28PM -0400, Dan Streetman wrote:
>> Update the crypto 842 driver to no longer fallback to LZO if the 842
>> hardware is unavailable. Simplify the crpypto 842 driver to remove all
>> headers indicating 842/lzo.
>>
>
On Tue, Apr 07, 2015 at 01:34:30PM -0400, Dan Streetman wrote:
> Add configurable module to perform self-tests on any crypto compression
> driver.
>
> This allows testing any crypto compression driver with any input buffer,
> at varying alignments and lengths. It calculates the average bytes per
On Tue, Apr 07, 2015 at 01:34:28PM -0400, Dan Streetman wrote:
> Update the crypto 842 driver to no longer fallback to LZO if the 842
> hardware is unavailable. Simplify the crpypto 842 driver to remove all
> headers indicating 842/lzo.
>
> The crypto 842 driver should do 842-format compression a
The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.
In the case of a cpu core sensor, the firmware exposes the physical
identifier of the core in the "ibm,pir" property. The driver
translates this identifier in a linux cpu number and pri
On 04/08/2015 03:26 PM, Guenter Roeck wrote:
> On 04/08/2015 12:00 AM, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> In the case of a cpu core sensor, the firmware exposes the physical
>> identifier
On 04/08/2015 12:00 AM, Cédric Le Goater wrote:
The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.
In the case of a cpu core sensor, the firmware exposes the physical
identifier of the core in the "ibm,pir" property. The driver
translat
On Tue, Apr 07, 2015 at 05:34:59PM -0700, Sukadev Bhattiprolu wrote:
> @@ -1213,9 +1221,47 @@ static void update_event_count(struct perf_event
> *event, u64 now)
> static void h_24x7_event_read(struct perf_event *event)
> {
> u64 now;
> + struct h_24x7_hw *h24x7hw;
> + struct hv_24
On Tue, Apr 07, 2015 at 05:34:58PM -0700, Sukadev Bhattiprolu wrote:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 1ac99d1..a001582 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3644,6 +3644,33 @@ static void orphans_remove_work(struct work_struct
> *w
On Tue, Apr 07, 2015 at 05:34:57PM -0700, Sukadev Bhattiprolu wrote:
> perf_event_read_value() is mostly computing the event count and enabled/
> running times. Move the perf_event_read() into caller and rename
> perf_event_read_value() to perf_event_compute_values().
>
> Changelog[v2]
> Exp
On 4/3/2015 10:24 PM, Scott Wood wrote:
What are you using PPC_MPC8306 for in your custom board code?
Sorry for the late reply, I was a bit busy over the Easter weekend.
I'm not currently using it for anything, so I guess I could remove it
and just use PPC_MPC830x in my board code. However,
On Tue, Apr 07, 2015 at 05:34:55PM -0700, Sukadev Bhattiprolu wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 2b62198..4dc3d70 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -240,20 +240,27 @@ struct pmu {
>*
>
Hi Kumar.
Regards,
Igal Liberman.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Friday, February 27, 2015 6:02 PM
> To: Liberman Igal-B31950
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Medve Emilian-
> EMMEDVE1
> Subject: Re: [PATCH] clk: p
Le 07/04/2015 21:41, Peter Zijlstra a écrit :
> No, that's very much not the same. Even if it were dealing with hotplug
> it would still assume the cpu to return to the same node.
>
> But mostly people do not even bother to handle hotplug.
>
You said userspace assumes the cpu<->node relation is a
From: Igal Liberman
v2: Addressed feedback from Scott:
- Moved the "fman-clk-mux" clock provider details
under "clocks" property.
Signed-off-by: Igal Liberman
---
.../devicetree/bindings/clock/qoriq-clock.txt | 63 +++-
1 file changed, 61 insertions(+),
On Wed, Apr 08, 2015 at 12:32:01PM +0200, Brice Goglin wrote:
> Le 07/04/2015 21:41, Peter Zijlstra a écrit :
> > No, that's very much not the same. Even if it were dealing with hotplug
> > it would still assume the cpu to return to the same node.
> >
> > But mostly people do not even bother to han
T1023RDB is a Freescale Reference Design Board that hosts T1023 SoC.
T1023RDB board Overview
---
- T1023 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
prioritization and bandwidth allocation
- Memory
Add support for Freescale T1024/T1023 QorIQ Development System Board.
T1024QDS is a high-performance computing evaluation, development and
test platform for T1024 QorIQ Power Architecture processor.
T1024QDS board Overview
---
- T1024 SoC integrating two 64-bit e5500 cores up
The T1024 SoC includes the following function and features:
- Two 64-bit Power architecture e5500 cores, up to 1.4GHz
- private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC)
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
support
- Data Path Accel
T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC.
T1024RDB board Overview
---
- Processor: T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- Memory: 64-bit 4GB DDR3L UDIMM with ECC and interleaving support
- Ethernet: two 1G RGMII ports, one 2.5
On (04/08/15 18:30), Benjamin Herrenschmidt wrote:
>
> I'm happy with your last version, feel free to add my
>
> Acked-by: Benjamin Herrenschmidt
sounds good, I'll do this and rese a non-RFC version today.
Thanks for all the feedback - it was very useful to me, and
I'm much happier with the en
On 30 March 2015 at 16:46, Suman Tripathi wrote:
> This patch adds some quirks support to be read from fdt.
>
> Signed-off-by: Suman Tripathi
> ---
> drivers/mmc/host/sdhci-pltfm.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/
Hi Scott
Regards,
Igal Liberman.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, April 08, 2015 1:40 AM
> To: Liberman Igal-B31950
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] dt/bindings: qoriq-clock: Add binding for FMan clock
On Sun, 2015-04-05 at 07:49 -0400, Sowmini Varadhan wrote:
> Investigation of multithreaded iperf experiments on an ethernet
> interface show the iommu->lock as the hottest lock identified by
> lockstat, with something of the order of 21M contentions out of
> 27M acquisitions, and an average wait
On Tue, 2015-04-07 at 22:39 -0700, Yinghai Lu wrote:
> On Tue, Apr 7, 2015 at 8:49 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-04-07 at 17:24 -0700, Yinghai Lu wrote:
> >> For device resource PREF bit setting under bridge 64-bit pref resource,
> >> we need to make sure only set PREF for 6
The opal_{get,set}_param calls return internal error codes which need
to be translated in errnos in Linux.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/opal-sysparam.c | 12
arch/powerpc/platforms/powernv/opal.c |1 +
2 files changed, 9 insertio
The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.
In the case of a cpu core sensor, the firmware exposes the physical
identifier of the core in the "ibm,pir" property. The driver
translates this identifier in a linux cpu number and pri
68 matches
Mail list logo
