On Mon, 2013-05-27 at 11:57 +0530, Priyanka Jain wrote:
> Add instruction to load TI_FLAGS in r8
>
> While returning from exception handling in case of PREEMPT enabled,
> _TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of
> current
> task. Only if this bit is set, it should con
On 05/27/2013 02:55 PM, Jain Priyanka-B32167 wrote:
If we go some more lines up in the same file, the code is
resume_kernel:
/* check current_thread_info, _TIF_EMULATE_STACK_STORE */
CURRENT_THREAD_INFO(r9, r1)
lwz r8,TI_FLAGS(r9)
andis. r8,r8,_TIF_EMULA
Yes,
Ben is also pointing to same thing.
I will send another patch with changes suggested (with both subject and
description modified) which will supersede this patch.
Regards
Priyanka
> -Original Message-
> From: tiejun.chen [mailto:tiejun.c...@windriver.com]
> Sent: Monday, May 27, 201
While returning from exception handling in case of PREEMPT enabled,
_TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
task. Only if this bit is set, it should continue with the process of
calling preempt_schedule_irq() to schedule highest priority task if
available.
Cu
> > So it seems the NOR write break the signal Integrity of SATA.
> > I don't have schematic and board right now, could you please measure
> > signals related to NOR write to see if anything abnormal? Is the board
> > use FPGA or CPLD to control signal?
>
> I'll have to pass these questions on to
From: Sebastian Hesselbarth
Date: Sun, 26 May 2013 22:06:58 +0200
> good you mention it. I added Grant on Cc and will give a short
> sum-up why I casted the const from property->value away here.
>
> Maybe I overlooked the API for modifying the DT property but as
> far as I've seen - there is no
On Sun, 2013-05-26 at 17:31 +0300, Michael S. Tsirkin wrote:
> The only reason uaccess routines might sleep
> is if they fault. Make this explicit.
>
> Arnd Bergmann suggested that the following code
> if (!is_kernel_addr((unsigned long)__pu_addr))
> might_fault();
> can be fur
On Sun, 2013-05-26 at 22:06 +0200, Sebastian Hesselbarth wrote:
> good you mention it. I added Grant on Cc and will give a short
> sum-up why I casted the const from property->value away here.
>
> Maybe I overlooked the API for modifying the DT property but as
> far as I've seen - there is no API
On Mon, 2013-05-27 at 02:23 -0700, David Miller wrote:
> Sparc has an of_set_property(), it needs to become generic.
There is an of_update_property(), we could change the name though, yours
is nicer :-)
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linux
Hello Maintainers:
Please help check this patch whether is OK, when you have time.
Thanks.
On 05/21/2013 05:20 PM, Chen Gang wrote:
>
> When error occurs, need return the related error code to let upper
> caller know about it.
>
> ppc_md.nvram_size() can return the error code (e.g. core99_nvra
On 05/22/2013 02:29 PM, Anshuman Khandual wrote:
>>
>> Your description from patch 0 should be here.
> Does it sound better ?
>
>>
>>> - if ((br_privilege != 7) && (br_privilege != 0))
>>> - return -1;
>>> +
>>> + if (br_privilege)
>>> + pr_info("BHRB privilege state filter
On 05/27/13 11:39, Benjamin Herrenschmidt wrote:
On Mon, 2013-05-27 at 02:23 -0700, David Miller wrote:
Sparc has an of_set_property(), it needs to become generic.
There is an of_update_property(), we could change the name though, yours
is nicer :-)
Ben, David,
I had a quick look at sparc's
Il 21/05/2013 05:06, Alexey Kardashevskiy ha scritto:
> This adds real mode handlers for the H_PUT_TCE_INDIRECT and
> H_STUFF_TCE hypercalls for QEMU emulated devices such as virtio
> devices or emulated PCI.
Do you mean vio? virtio (without getting into whether that's good or
bad) will bypass th
Il 25/05/2013 04:45, David Gibson ha scritto:
>> >+ case KVM_CREATE_SPAPR_TCE_IOMMU: {
>> >+ struct kvm_create_spapr_tce_iommu create_tce_iommu;
>> >+ struct kvm *kvm = filp->private_data;
>> >+
>> >+ r = -EFAULT;
>> >+ if (copy_from_user(&create_tce_iommu,
On Mon, 2013-05-27 at 12:24 +0200, Sebastian Hesselbarth wrote:
> > There is an of_update_property(), we could change the name though,
> yours
> > is nicer :-)
>
> Ben, David,
>
> I had a quick look at sparc's of_set_property. Nothing special except
> it
> depends on OF_DYNAMIC at some place. Usi
Here is a set of small independent patches that clean up or fix minor things
across DMA slave drivers.
Andy Shevchenko (12):
imx-sdma: remove useless variable
mxs-dma: remove useless variable
edma: no need to assign residue to 0 explicitly
ep93xx_dma: remove useless use of lock
fsldma: r
Accordingly to dma_cookie_status() description locking is not required.
Signed-off-by: Andy Shevchenko
Cc: Li Yang
Cc: Zhang Wei
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/dma/fsldma.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drive
For MPC831x the bus probing function also needs the fixup to assign
addresses to the PCI devices as it was for MPC85xx and MPC86xx.
The fixup of the bridge vendor and device ID should be done early in
PCI probing. Else the bridge is not detected as FIXUP_HEADER is called
too late.
Signed-off-by: S
On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote:
> However, that wouldn't help much with the allocation/leak problem,
> though at least it would be easier to use. It could also *try* to re-use
> the current allocation if the new content is of smaller or equal size.
I thought that dtc t
On 05/27/2013 08:23 PM, Paolo Bonzini wrote:
> Il 25/05/2013 04:45, David Gibson ha scritto:
+ case KVM_CREATE_SPAPR_TCE_IOMMU: {
+ struct kvm_create_spapr_tce_iommu create_tce_iommu;
+ struct kvm *kvm = filp->private_data;
+
+ r = -EFAULT;
On 05/27/2013 08:08 PM, Paolo Bonzini wrote:
> Il 21/05/2013 05:06, Alexey Kardashevskiy ha scritto:
>> This adds real mode handlers for the H_PUT_TCE_INDIRECT and
>> H_STUFF_TCE hypercalls for QEMU emulated devices such as virtio
>> devices or emulated PCI.
>
> Do you mean vio? virtio (without g
Il 27/05/2013 16:26, Alexey Kardashevskiy ha scritto:
> On 05/27/2013 08:23 PM, Paolo Bonzini wrote:
>> Il 25/05/2013 04:45, David Gibson ha scritto:
> + case KVM_CREATE_SPAPR_TCE_IOMMU: {
> + struct kvm_create_spapr_tce_iommu create_tce_iommu;
> + struct kvm *kvm = filp
From: Benjamin Herrenschmidt
Date: Mon, 27 May 2013 21:50:04 +1000
> It would be handy to be able to just do something like
>
> of_set_property(node, name, ptr, len);
>
> However, that wouldn't help much with the allocation/leak problem,
> though at least it would be easier to use. It cou
On Mon, 2013-05-27 at 14:47 +0200, Arnd Bergmann wrote:
> On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote:
> > However, that wouldn't help much with the allocation/leak problem,
> > though at least it would be easier to use. It could also *try* to re-use
> > the current allocation if th
On 05/27/2013 11:50 PM, Benjamin Herrenschmidt wrote:
On Mon, 2013-05-27 at 14:47 +0200, Arnd Bergmann wrote:
On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote:
However, that wouldn't help much with the allocation/leak problem,
though at least it would be easier to use. It could also
From: Benjamin Herrenschmidt
Date: Tue, 28 May 2013 07:50:06 +1000
> On Mon, 2013-05-27 at 14:47 +0200, Arnd Bergmann wrote:
>> On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote:
>> > However, that wouldn't help much with the allocation/leak problem,
>> > though at least it would be eas
On Mon, 2013-05-27 at 13:18 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Mon, 27 May 2013 21:50:04 +1000
>
> > It would be handy to be able to just do something like
> >
> > of_set_property(node, name, ptr, len);
> >
> > However, that wouldn't help much with the alloc
Anshuman Khandual wrote:
> On 05/22/2013 02:29 PM, Anshuman Khandual wrote:
> >>
> >> Your description from patch 0 should be here.
> > Does it sound better ?
> >
> >>
> >>> - if ((br_privilege != 7) && (br_privilege != 0))
> >>> - return -1;
> >>> +
> >>> + if (br_privilege)
> >>> +
Shaohio --
Once again, thanks for the reply.
Xie Shaohui-B21989 writes:
> it seems [recovery or lack of recovery is] not due to speed limiting
> code, 1.5Gbps is still used to recover link.
Right, I noticed this in my later email on this topic.
> for the speed limit issue, I checked 3.4.rc7 k
When the task moves around the system, the corresponding cpuhw
per cpu strcuture should be popullated with the BHRB filter
request value so that PMU could be configured appropriately with
that during the next call into power_pmu_enable().
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/co
Completely ignore BHRB privilege state filter request as we are
already configuring that with privilege state filtering attribute
for the accompanying PMU event. This would help achieve cleaner
user space interaction for BHRB.
This patch fixes a situation like this
Before patch:-
./p
(1) The first patch fixes a situation like this
Before patch:-
./perf record -j any -e branch-misses:k ls
Error:
The sys_perf_event_open() syscall returned with 95 (Operation not supported)
for event (branch-misses:k).
/bin/dmesg may provide additional information.
No CONFIG_PERF_EV
32 matches
Mail list logo
