Resending, as there were some problems with delivering this message.
Original Message
Subject: Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
Date: Thu, 16 Apr 2015 13:34:17 +0200
From: Jacek Anaszewski
To: Vasant Hegde
CC: linuxppc-dev@lists.ozlabs.org, linu
On Sun, 2015-04-19 at 22:17 -0700, Guenter Roeck wrote:
> Hi Michael,
Hi Guenter,
> On 04/19/2015 08:01 PM, Michael Ellerman wrote:
>
> > Someone needs to be doing s390/alpha builds with that enabled anyway,
> > because
> > otherwise a clash between generic code and s390/alpha won't be caught.
The following series implements LED driver for PowerNV platform.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system
From: Anshuman Khandual
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of various individual
LEDs on the system at any given location code which is passed throu
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particula
This patch adds paltform devices for leds. Also export LED related
OPAL API's so that led driver can use these APIs.
Signed-off-by: Vasant Hegde
Signed-off-by: Anshuman Khandual
Acked-by: Stewart Smith
Tested-by: Stewart Smith
---
Since this is the split of origianal LED patch, I have retained
On 04/20/2015 10:32 AM, Shreyas B. Prabhu wrote:
> Fastsleep is one of the idle state which cpuidle subsystem currently
> uses on power8 machines. In this state L2 cache is brought down to a
> threshold voltage. Therefore when the core is in fastsleep, the
> communication between L2 and L3 needs to
Currently tm_orig_msr is getting used during process context switch only.
Then there is ckpt_regs which saves the checkpointed userspace context
The MSR slot contained in ckpt_regs structure can be used during process
context switch instead of tm_orig_msr, thus allowing us to drop it from
thread_st
On Mon, Apr 20, 2015 at 01:57:39PM +0800, Baolin Wang wrote:
> @@ -911,18 +907,14 @@ retry:
> return -EINVAL;
>
> kc = clockid_to_kclock(timr->it_clock);
> - if (WARN_ON_ONCE(!kc || (!kc->timer_set && !kc->timer_set64))) {
> + if (WARN_ON_ONCE(!kc || !kc->timer_set64)
Regards,
Igal Liberman.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Thursday, March 12, 2015 5:57 PM
> To: Liberman Igal-B31950
> Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Wood Scott-B07421
> Subject
On 20 April 2015 at 16:42, Richard Cochran wrote:
> On Mon, Apr 20, 2015 at 01:57:39PM +0800, Baolin Wang wrote:
>
> > @@ -911,18 +907,14 @@ retry:
> > return -EINVAL;
> >
> > kc = clockid_to_kclock(timr->it_clock);
> > - if (WARN_ON_ONCE(!kc || (!kc->timer_set && !kc->tim
Hello.
On 4/20/2015 8:57 AM, Baolin Wang wrote:
This patch introduces the 'struct itimerspec64' for 64bit to replace itimerspec,
and also introduces the conversion methods: itimerspec64_to_itimerspec() and
itimerspec_to_itimerspec64(), that makes itimerspec to ready for 2038 year.
"To" not
On 10.04.2015 02:53, Scott Wood wrote:
On Thu, 2015-04-09 at 10:44 +0300, Purcareata Bogdan wrote:
So at this point I was getting kinda frustrated so I decided to measure
the time spend in kvm_mpic_write and kvm_mpic_read. I assumed these were
the main entry points in the in-kernel MPIC and were
Regards,
Igal Liberman.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, April 17, 2015 8:41 AM
> To: Liberman Igal-B31950
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
>
> On Th
Regards,
Igal Liberman.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, April 17, 2015 8:42 AM
> To: Liberman Igal-B31950
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/dts: Move pll0/1-div4 index
>
> On Thu, 2015-04-16 at 1
Regards,
Igal Liberman.
> -Original Message-
> From: Liberman Igal-B31950
> Sent: Monday, April 20, 2015 2:07 PM
> To: Wood Scott-B07421
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [v3] dt/bindings: qoriq-clock: Add binding for FMan clock mux
>
>
>
>
From: Christophe Leroy
> Sent: 20 April 2015 06:27
> Having a macro will help keep clear code.
...
> * We have to use the MD_xxx registers for the tablewalk because the
> * equivalent MI_xxx registers only perform the attribute functions.
> */
> +
> +#ifdef CONFIG_8xx_CPU15
> +#define DO_8xx_
Le 20/04/2015 13:40, David Laight a écrit :
From: Christophe Leroy
Sent: 20 April 2015 06:27
Having a macro will help keep clear code.
...
* We have to use the MD_xxx registers for the tablewalk because the
* equivalent MI_xxx registers only perform the attribute functions.
*/
+
+#i
Hi Vasant,
I'd like to clarify some details regarding your explanation.
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
[...]
In Power Systems LEDs are overloaded (meaning same LED is used for identify and
fault depending on their state --- blinking = identify and solid = fault).
Hence here appe
On 20 April 2015 at 17:49, Sergei Shtylyov <
sergei.shtyl...@cogentembedded.com> wrote:
> Hello.
>
> On 4/20/2015 8:57 AM, Baolin Wang wrote:
>
> This patch introduces the 'struct itimerspec64' for 64bit to replace
>> itimerspec,
>> and also introduces the conversion methods: itimerspec64_to_itim
Anshuman Khandual wrote on 13.04.2015
10:48:57:
> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
> > - You provide checkpointed FPR and VMX registers, but there doesn't
seem
> > to be any way to get at the checkpointed *VSX* registers (i.e. the
part
> > that is neither covered by FPR or VMX, co
On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>
> I'd like to clarify some details regarding your explanation.
>
> On 04/15/2015 12:15 PM, Vasant Hegde wrote:
> [...]
In Power Systems LEDs are overloaded (meaning same LED is used for
identify and
fault dependin
Hello!
This patchset enables "perf kvm stat record/report" on powerpc,
which can be used to analyze certain KVM events : KVM exits and
hypervisor calls. The statistics can be shown individually for
each running VM in the host and hence, can be useful in giving
an idea of the performance of a VM on
To analyze the kvm exits with perf, we will need to map the exit codes
with the exit reasons. Such a mapping exists today in
trace_book3s.h. But its not exported to tools like perf.
This patch moves these kvm exit reasons and their mapping from
"arch/powerpc/kvm/trace_book3s.h" to
"arch/powerpc/in
This patch adds an exit reason "RETURN_TO_HOST" for the return code
0x0.
Signed-off-by: Hemant Kumar
---
arch/powerpc/include/uapi/asm/trace_book3s.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/uapi/asm/trace_book3s.h
b/arch/powerpc/include/uapi/asm/trace_book3s.h
i
From: Srikar Dronamraju
This patch adds KVM exit event analysis support to perf for powerpc.
- Trace KVM events :
perf kvm stat record
If many guests are running, we can track for a specific guest by using
--pid as in : perf kvm stat record --pid
- Show the results :
perf kvm stat re
For tools like perf to analyze the KVM events like hcalls, we need the
hypervisor calls and their codes to be exported through uapi.
This patch moves most of the pSeries hcall codes from
arch/powerpc/include/asm/hvcall.h to
arch/powerpc/include/uapi/asm/hcall_codes.h.
It also moves the mapping fr
This patch adds KVM hypervisor call analysis to perf for powerpc.
- Trace hcall events :
perf kvm stat record
- Show the results :
perf kvm stat report --event=hcall
The results show the number of hypervisor calls from the guest grouped
into their respective reasons displayed with the frequ
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 04/15/2015 12:15 PM, Vasant Hegde wrote:
[...]
In Power Systems LEDs are overloaded (meaning same LED is used for identify an
Hi Vasant, Anshuman,
Thanks for the update.
On 04/20/2015 09:59 AM, Vasant Hegde wrote:
From: Anshuman Khandual
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the sta
Hi Vasant,
Thanks for the update.
On 04/20/2015 10:01 AM, Vasant Hegde wrote:
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system
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 04/15/2015 12:15 PM, Vasant Hegde wrote:
>>> [...]
>>
>
On 04/20/2015 08:51 PM, Jacek Anaszewski wrote:
> Hi Vasant, Anshuman,
>
Jacek,
.../...
>> +
>> +/* LED location */
>> +#define LED_LOC_ENCLOSURE"enclosure"
>> +#define LED_LOC_DESCENDENT"descendent"
>
> These macros should also have POWERNV_LED prefix.
Oh yeah.. I should fix this as
From: Guenter Roeck
Date: Sun, 19 Apr 2015 22:17:21 -0700
> The debug option is intended for all _other_ architectures, to
> ensure that changes made for those don't break alpha/s390
> builds. alpha/s390 have ARCH_NEEDS_WEAK_PER_CPU and don't need the
> debug option.
Ironically this would not cr
On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller wrote:
> From: Guenter Roeck
> Date: Sun, 19 Apr 2015 22:17:21 -0700
>
> > The debug option is intended for all _other_ architectures, to
> > ensure that changes made for those don't break alpha/s390
> > builds. alpha/s390 have ARCH_NEEDS_WEA
From: Guenter Roeck
Date: Mon, 20 Apr 2015 09:44:31 -0700
> On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller wrote:
>> From: Guenter Roeck
>> Date: Sun, 19 Apr 2015 22:17:21 -0700
>>
>> > The debug option is intended for all _other_ architectures, to
>> > ensure that changes made for thos
On Mon, 2015-04-20 at 06:10 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, April 17, 2015 8:42 AM
> > To: Liberman Igal-B31950
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> >
On Mon, 20 Apr 2015, Baolin Wang wrote:
> This patch introduces hrtimer_get_res64() function to get the timer resolution
> with timespec64 type, and moves the hrtimer_get_res() function into
FYI, That function is about to go away, but it's not a big deal to
sort that out once I applied the hrtimer
On Mon, 20 Apr 2015, Baolin Wang wrote:
> This patch introduces the 'struct itimerspec64' for 64bit to replace
> itimerspec,
> and also introduces the conversion methods: itimerspec64_to_itimerspec() and
> itimerspec_to_itimerspec64(), that makes itimerspec to ready for 2038 year.
>
> Signed-off-
On Mon, 20 Apr 2015, Thomas Gleixner wrote:
> On Mon, 20 Apr 2015, Baolin Wang wrote:
> > This patch introduces the 'struct itimerspec64' for 64bit to replace
> > itimerspec,
> > and also introduces the conversion methods: itimerspec64_to_itimerspec() and
> > itimerspec_to_itimerspec64(), that mak
On Sat, 2015-04-18 at 08:46 -0500, Timur Tabi wrote:
> On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote:
>
> > Have just sent out a patch considering the previous discussion.
> > http://patchwork.ozlabs.org/patch/462249/
> > [PATCH] powerpc/defconfig: new way of writing defconfig
>
> The abilit
On Mon, 20 Apr 2015, Baolin Wang wrote:
> @@ -771,6 +771,7 @@ SYSCALL_DEFINE2(timer_gettime, timer_t, timer_id,
> struct itimerspec __user *, setting)
> {
> struct itimerspec cur_setting;
> + struct itimerspec64 cur_setting64;
> struct k_itimer *timr;
> struct k
On Mon, 20 Apr 2015, Baolin Wang wrote:
> /* Set clock_realtime */
> static int posix_clock_realtime_set(const clockid_t which_clock,
> - const struct timespec *tp)
> + const struct timespec64 *tp)
> {
> - return do_sys_settimeo
On Mon, 20 Apr 2015, Baolin Wang wrote:
> This patch introduces some functions for converting cputime to timespec64 and
> back,
> that repalce the timespec type with timespec64 type, as well as for arch/s390
> and
> arch/powerpc architecture.
No. We want a patch which adds the functions and the
On Mon, 2015-04-20 at 03:58 -0500, Liberman Igal-B31950 wrote:
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> > Sent: Thursday, March 12, 2015 5:57 PM
> > To: Liberman Igal-B31950
> > Cc: linuxppc-dev@lists.ozlabs.org; net.
-Original Message-
From: Wolfram Sang
Quoted from the opensuse-ppc mailing list
>I'm Wolfram Sang, maintainer of the I2C subsystem of the Linux Kernel. I
>want to get rid of an ancient mechanism in the I2C core which was used in the
>2.4 era. There are only two users left; drivers for o
On Mon, 2015-04-20 at 06:40 -0500, Liberman Igal-B31950 wrote:
>
>
> Regards,
> Igal Liberman.
>
> > -Original Message-
> > From: Liberman Igal-B31950
> > Sent: Monday, April 20, 2015 2:07 PM
> > To: Wood Scott-B07421
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> >
On Mon, 2015-04-20 at 13:53 +0300, Purcareata Bogdan wrote:
> On 10.04.2015 02:53, Scott Wood wrote:
> > On Thu, 2015-04-09 at 10:44 +0300, Purcareata Bogdan wrote:
> >> So at this point I was getting kinda frustrated so I decided to measure
> >> the time spend in kvm_mpic_write and kvm_mpic_read.
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
On Mon, 2015-04-20 at 12:50 -0400, David Miller wrote:
> From: Guenter Roeck
> Date: Mon, 20 Apr 2015 09:44:31 -0700
>
> > On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller wrote:
> >> From: Guenter Roeck
> >> Date: Sun, 19 Apr 2015 22:17:21 -0700
> >>
> >> > The debug option is intended f
On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote:
>
>
> The ability to merge configs is already there. We're just talking about
> using that functionality.
Why do you need a powerpc-specific way to use merge_config.sh? Other
architectures have the same problem with defconfigs.
Besides, wouldn
On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote:
> On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote:
> >
> >
> > The ability to merge configs is already there. We're just talking about
> > using that functionality.
>
> Why do you need a powerpc-specific way to use merge_config.sh? Other
>
On 04/20/2015 06:54 PM, Michael Ellerman wrote:
On Mon, 2015-04-20 at 12:50 -0400, David Miller wrote:
From: Guenter Roeck
Date: Mon, 20 Apr 2015 09:44:31 -0700
On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller wrote:
From: Guenter Roeck
Date: Sun, 19 Apr 2015 22:17:21 -0700
The debu
On Mon, 2015-04-20 at 19:32 -0700, Guenter Roeck wrote:
> On 04/20/2015 06:54 PM, Michael Ellerman wrote:
> > On Mon, 2015-04-20 at 12:50 -0400, David Miller wrote:
> >> From: Guenter Roeck
> >> Date: Mon, 20 Apr 2015 09:44:31 -0700
> >>
> >>> On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller
On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote:
> On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote:
> >
> >
> > The ability to merge configs is already there. We're just talking about
> > using that functionality.
>
> Why do you need a powerpc-specific way to use merge_config.sh? Other
>
Scott Wood wrote:
>
>Why do you need a powerpc-specific way to use merge_config.sh? Other
>architectures have the same problem with defconfigs.
What are you perceiving as "powerpc-specific" about what we're
proposing?
Well, there's the subject of this thread, which is "new way of writing
d
On 04/20/2015 05:57 PM, Ulrich Weigand wrote:
> Anshuman Khandual wrote on 13.04.2015
> 10:48:57:
>> On 04/10/2015 04:03 PM, Ulrich Weigand wrote:
>>> - You provide checkpointed FPR and VMX registers, but there doesn't
> seem
>>> to be any way to get at the checkpointed *VSX* registers (i.e. the
On Mon, 2015-04-20 at 22:42 -0500, Timur Tabi wrote:
> Scott Wood wrote:
> >> >
> >> >Why do you need a powerpc-specific way to use merge_config.sh? Other
> >> >architectures have the same problem with defconfigs.
>
> > What are you perceiving as "powerpc-specific" about what we're
> > proposing?
On 04/20/2015 08:57 PM, Jacek Anaszewski wrote:
> Hi Vasant,
>
Jacek,
Thanks for the review.
> Thanks for the update.
>
> On 04/20/2015 10:01 AM, Vasant Hegde wrote:
>> This patch implements LED driver for PowerNV platform using the existing
>> generic LED class framework.
>>
>> PowerNV platfo
On Sat, 2015-18-04 at 04:47:21 UTC, Lijun Pan wrote:
> It is always a headache dealing with different defconfigs
> though they only differ in few places. Hence we are proposing a new
> way of writing defconfig:
So on the whole this is looking promising, some comments ...
> 1. Define a basic defco
60 matches
Mail list logo
