Add a new powerpc-specific trace clock using the timebase register,
similar to x86-tsc. This gives us
- a fast, monotonic, hardware clock source for trace entries, and
- a clock that can be used to correlate events across cpus as well as across
hypervisor and guests.
Signed-off-by: Naveen N. Rao
On 04/23/2015 03:15 AM, Jacek Anaszewski wrote:
> Hi Vasant,
>
Hi Jacek,
.../...
>>
>>>
>>> From what I can see from the driver code the LEDs are set with:
>>>
>>> opal_leds_set_ind(token, loc_code, led_mask, led_value,
>>> &max_led_type);
>>>
>>> and their state can be read with:
>>>
>>> opa
On 2015/04/23 01:14PM, Michael Ellerman wrote:
> On Wed, 2015-04-22 at 10:48 +0530, Naveen N. Rao wrote:
> > On 2015/04/21 09:25AM, Steven Rostedt wrote:
> > > On Tue, 21 Apr 2015 16:33:36 +0530
> > > "Naveen N. Rao" wrote:
> > >
> > > > Add a new powerpc-specific trace clock using the timebase r
On 04/23/2015 03:15 AM, Jacek Anaszewski wrote:
>> On 21.04.2015 07:50, Vasant Hegde wrote:
>> On 04/20/2015 08:57 PM, Jacek Anaszewski wrote:
>>> Hi Vasant,
>>>
>>
Jacek,
.../...
All the system LEDs can be found in the same regular
path /sys/class/leds/. We don't use LED colors.
AFAIK the PAPR document which defines the virtual device interface used by
the ibmveth driver doesn't specify a specific maximum MTU. So, in the
ibmveth driver, the maximum allowed MTU is determined by the maximum
allocated buffer size of 64k (corresponding to one page in the common case)
minus th
Any suggestions on this?
On Thursday 16 April 2015 04:28 PM, Shreyas B. Prabhu wrote:
> kvm_no_guest function calls power7_wakeup_loss to put the thread into
> the deepest supported idle state. power7_wakeup_loss is defined in
> arch/powerpc/kernel/idle_power7.S, which is compiled only when PPC_P7
On Thu, 2015-04-23 at 13:06 +1000, Stephen Rothwell wrote:
> Hi Michael,
>
> On Wed, 22 Apr 2015 15:40:36 +1000 Michael Ellerman
> wrote:
> >
> > diff --git a/arch/powerpc/include/asm/vdso.h
> > b/arch/powerpc/include/asm/vdso.h
> > index c53f5f6d1761..f455adb471e7 100644
> > --- a/arch/powerpc
On Wed, 2015-04-22 at 10:48 +0530, Naveen N. Rao wrote:
> On 2015/04/21 09:25AM, Steven Rostedt wrote:
> > On Tue, 21 Apr 2015 16:33:36 +0530
> > "Naveen N. Rao" wrote:
> >
> > > Add a new powerpc-specific trace clock using the timebase register,
> > > similar to x86-tsc. This gives us a fast, mo
Hi Michael,
On Wed, 22 Apr 2015 15:40:36 +1000 Michael Ellerman wrote:
>
> diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
> index c53f5f6d1761..f455adb471e7 100644
> --- a/arch/powerpc/include/asm/vdso.h
> +++ b/arch/powerpc/include/asm/vdso.h
> @@ -19,6 +19,7 @@
>
On Wed, 2015-04-22 at 12:06 +0200, Christophe Leroy wrote:
> diff --git a/arch/powerpc/include/asm/mmu-8xx.h
> b/arch/powerpc/include/asm/mmu-8xx.h
> index d41200c..1407034 100644
> --- a/arch/powerpc/include/asm/mmu-8xx.h
> +++ b/arch/powerpc/include/asm/mmu-8xx.h
> @@ -27,6 +27,19 @@
> #define
On Wed, 2015-04-22 at 15:06 +0300, Purcareata Bogdan wrote:
> On 21.04.2015 03:52, Scott Wood wrote:
> > On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
> >> There was a weird situation for .kvmppc_mpic_set_epr - its corresponding
> >> inner
> >> function is kvmppc_set_epr, which is a
> On 21.04.2015 07:50, Vasant Hegde wrote:
> On 04/20/2015 08:57 PM, Jacek Anaszewski wrote:
>> Hi Vasant,
>>
>
> Jacek,
>
> Thanks for the review.
You are welcome.
>> Thanks for the update.
>>
>> On 04/20/2015 10:01 AM, Vasant Hegde wrote:
>>> This patch implements LED driver for PowerNV platf
Hi Vasant,
On 20.04.2015 17:53, Vasant Hegde wrote:
> On 04/20/2015 08:50 PM, Jacek Anaszewski wrote:
>> On 04/20/2015 02:34 PM, Vasant Hegde wrote:
>>> On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
Hi Vasant,
I'd like to clarify some details regarding your explanation.
On Wed, Apr 22, 2015 at 10:46 PM, Jonas Gorski wrote:
>> ---
>> v2: Use devm_ioremap_resource() instead of_iomap()
>
> Your subject and commitlog still talk about using of_iomap(), you need
> to update them too.
Hmm I didn't see the V3. Ignore this comment (the other one still applies).
Regards
Hi Christophe,
On Wed, Apr 22, 2015 at 4:17 PM, Christophe Leroy
wrote:
> On CPM2, the SPI parameter RAM is dynamically allocated in the
> dualport RAM whereas in CPM1, it is statically allocated to a default
> address with capability to relocate it somewhere else via the use of
> CPM micropatch.
Hi (again),
as usual you only see issues *after* sending the email ...
On Wed, Apr 22, 2015 at 4:17 PM, Christophe Leroy
wrote:
> On CPM2, the SPI parameter RAM is dynamically allocated in the
> dualport RAM whereas in CPM1, it is statically allocated to a default
> address with capability to re
On Wed, Apr 22, 2015 at 03:50:45PM +0200, Arnd Bergmann wrote:
> On Wednesday 22 April 2015 13:07:44 Arnd Bergmann wrote:
...
> select, old_selct, pselect6: deprecated
Small, copy&paste error here for pselect6.
Luc
___
Linuxppc-dev mailing list
Linuxpp
On 04/20/2015 08:07 PM, David Gibson wrote:
> AFAIK the PAPR document which defines the virtual device interface used by
> the ibmveth driver doesn't specify a specific maximum MTU. So, in the
> ibmveth driver, the maximum allowed MTU is determined by the maximum
> allocated buffer size of 64k (co
On Wed, Apr 22, 2015 at 04:28:20PM +0200, Christophe Leroy wrote:
> On CPM2, the SPI parameter RAM is dynamically allocated in the
> dualport RAM whereas in CPM1, it is statically allocated to a default
> address with capability to relocate it somewhere else via the use of
> CPM micropatch. The add
OCC is an On-Chip-Controller which takes care of power and thermal
safety of the chip. During runtime due to power failure or
overtemperature the OCC may throttle the frequencies of the CPUs to
remain within the power budget.
We want the cpufreq driver to be aware of such situations to be able
to
Add OPAL_MSG_OCC message definition to opal_message_type to notify OCC
events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles the max Pstate.
We can register to opal_message_notifier to receive OPAL_MSG_OCC type
of message.
The reset and load OCC
On Wed, Apr 22, Olaf Hering wrote:
> I will see which commit leads to the failure that exists since v3.19-rc4.
c2c2f6cb79141ca22f84c36887fd867373c35c4e +
c7e873f85fb60b1af589ac1b0c62353cfe0bbb29 leads to this output:
[ 47.367618] nouveau [ DEVICE][:0a:00.0] BOOT0 : 0x043100a4
[ 47.367
On Mon, Mar 30, Olaf Hering wrote:
> On Sat, Mar 28, Olaf Hering wrote:
>
> > On Sat, Mar 28, Olaf Hering wrote:
> >
> > > I just updated the kernel from some 3.18 based state to 4.0-rc5+. The
> >
> > 3.19 is already broken, will bisect next week.
>
> After a first run I was able to boot prior
On Wednesday 22 April 2015 16:54:32 Richard Cochran wrote:
> On Wed, Apr 22, 2015 at 03:50:45PM +0200, Arnd Bergmann wrote:
> > time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> > getitimer, setitimer:
> > all deprecated => wontfix
>
> If adjtimex is deprecated, what will replace it
On Wednesday 22 April 2015 17:14:47 Luc Van Oostenryck wrote:
> On Wed, Apr 22, 2015 at 03:50:45PM +0200, Arnd Bergmann wrote:
> > On Wednesday 22 April 2015 13:07:44 Arnd Bergmann wrote:
> ...
> > select, old_selct, pselect6: deprecated
>
> Small, copy&paste error here for pselect6.
>
Right, th
On Wed, Apr 22, 2015 at 03:50:45PM +0200, Arnd Bergmann wrote:
> time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> getitimer, setitimer:
> all deprecated => wontfix
If adjtimex is deprecated, what will replace it? It is really
important for ntp.
Thanks,
Richard
__
On CPM2, the SPI parameter RAM is dynamically allocated in the
dualport RAM whereas in CPM1, it is statically allocated to a default
address with capability to relocate it somewhere else via the use of
CPM micropatch. The address of the parameter RAM is given by the boot
loader and expected to be m
On CPM2, the SPI parameter RAM is dynamically allocated in the
dualport RAM whereas in CPM1, it is statically allocated to a default
address with capability to relocate it somewhere else via the use of
CPM micropatch. The address of the parameter RAM is given by the boot
loader and expected to be m
On Wednesday 22 April 2015 13:07:44 Arnd Bergmann wrote:
>
> I've started a list of affected syscalls at
> https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T_0YiQwis/edit?usp=sharing
>
> Still adding more calls and description, let me know if you want edit
> permissions.
On Wed, 22 Apr 2015, Arnd Bergmann wrote:
> On Wednesday 22 April 2015 10:45:23 Thomas Gleixner wrote:
> > On Tue, 21 Apr 2015, Thomas Gleixner wrote:
>
> > So we could save one translation step if we implement new syscalls
> > which have a scalar nsec interface instead of the timespec/timeval
> >
On 21.04.2015 03:52, Scott Wood wrote:
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
There was a weird situation for .kvmppc_mpic_set_epr - its corresponding inner
function is kvmppc_set_epr, which is a static inline. Removing the static inline
yields a compiler crash (Segmentation
On Wednesday 22 April 2015 10:45:23 Thomas Gleixner wrote:
> On Tue, 21 Apr 2015, Thomas Gleixner wrote:
> So we could save one translation step if we implement new syscalls
> which have a scalar nsec interface instead of the timespec/timeval
> cruft and let user space do the translation to whatev
With the addition of 64-bit BARS and increase in the mmio address
space, the code was hitting this limit. The memory of pci devices
across the bridges were not accessible due to which the drivers
failed.
Signed-off-by: Nikunj A Dadhania
---
board-qemu/slof/pci-phb.fs | 3 ++-
1 file changed, 2 i
PCI Enumeration has been part of SLOF. Now with hotplug code addition
in Qemu, it makes more sense to have this code a one place, i.e. Qemu.
Adding routines to walk through the device nodes created by Qemu. SLOF
will configure the device/bridges and program the BARs for
communicating with the devi
Regards,
Igal Liberman.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, April 21, 2015 3:52 AM
> To: Liberman Igal-B31950
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Tang
> Yuantian-B29983
> Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for
From: Thomas Gleixner
> Sent: 22 April 2015 09:45
> On Tue, 21 Apr 2015, Thomas Gleixner wrote:
> > On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> > > I know there are concerns about this, in particular because C11 and
> > > POSIX both require tv_nsec to be 'long', unlike timeval->tv_usec,
> > > which
On Wed, Apr 22, 2015 at 10:45:23AM +0200, Thomas Gleixner wrote:
> So we could save one translation step if we implement new syscalls
> which have a scalar nsec interface instead of the timespec/timeval
> cruft and let user space do the translation to whatever it wants.
+1
> I personally would we
This patchset implements execute protection on the 8xx.
It also simplifies the handling of PAGE_USER and PAGE_RO,
and adds a small fix to the kernel pages definition.
This patchset goes on to of my previous patchset named
"[v5] powerpc8xx: Further optimisation of TLB handling"
Christophe Leroy (3
This patch implements PAGE_EXEC capability on the 8xx.
All pages PP exec bits are set to 000, which means Execute for
Supervisor and no Execute for User.
Then we use the APG to say whether accesses are according to Page
rules, "all Supervisor" rules (Exec for all) and
"all User" rules (Exec for no
Use of APG for handling PAGE_USER.
All pages PP exec bits are set to either 000 or 011, which means
respectively RW for Supervisor and no access for User, or RO for
Supervisor and no access for user.
Then we use the APG to say whether accesses are according to
Page rules or "all Supervisor" rules
All kernel pages have to be marked as shared in order to not perform
CASID verification.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/pte-8xx.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h
b/arch/powerpc/include/asm
On 04/21/2015 08:11 PM, Ulrich Weigand wrote:
> Anshuman Khandual wrote on 21.04.2015
> 06:55:24:
>
>> Changed ELF core note sections
>> --
>> These core note sections need to be changed to accommodate the in
>> transaction ptrace requests when the running/current valu
On Tue, 21 Apr 2015, Thomas Gleixner wrote:
> On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> > I know there are concerns about this, in particular because C11 and
> > POSIX both require tv_nsec to be 'long', unlike timeval->tv_usec,
> > which is a 'suseconds_t' and can be defined as 'long long'.
> >
>
43 matches
Mail list logo
