Benjamin Herrenschmidt writes:
> On Wed, 2014-08-06 at 20:16 +0530, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V" writes:
>>
>> > If we know that user address space has never executed on other cpus
>> > we could use tlbiel.
>> >
>> > Signed-off-by: Aneesh Kumar K.V
>>
>> Now checking against
Similar to the previous commit which described why we need to add a
barrier to arch_spin_is_locked(), we have a similar problem with
spin_unlock_wait().
We need a barrier on entry to ensure any spinlock we have previously
taken is visibly locked prior to the load of lock->slock.
It's also not cle
The kernel defines the function spin_is_locked(), which can be used to
check if a spinlock is currently locked.
Using spin_is_locked() on a lock you don't hold is obviously racy. That
is, even though you may observe that the lock is unlocked, it may become
locked at any time.
There is (at least)
Hi Linus !
First an apology ... a lot of the stuff in there was only very recently
committed. This is not the normal process. I'm at fault here, my only
excuse is having been insanely swamped with other things. That's one of
the reasons for co-opting Michael as co-maintainer, to help with
avoiding
About the title, please follow the old pattern:
ASoC: fsl_esai: Refine
You can get the history from 'git log --oneline sound/soc/fsl/fsl_esai.c'
On Wed, Aug 06, 2014 at 06:23:03PM +0800, Shengjiu Wang wrote:
> Add parameter for slots, and caculate the number of TX/RX pins and bclk with
> slo
Fix warnings like the following using upper_32_bits(), discussed after mail with
someone on kernelnewbies
arch/powerpc/boot/addnote.c:183:3: warning: right shift count >= width of type
arch/powerpc/boot/addnote.c:188:3: warning: right shift count >= width of type
arch/powerpc/boot/addnote.c:206:3:
The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:
CC [M] drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/
The function is used by VFIO driver, which might be built as a
dynamic module. So it should be exported.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/eeh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
From: Alexey Kardashevskiy
The existing vfio_pci_open() fails upon error returned from
vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
support which this patch brings back.
The patch fixes the issue by dropping the return value of
vfio_spapr_pci_eeh_open().
Signed-off-by: Alexey Kar
The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.
Alexey Kardashevskiy (2):
drivers/vfio: Allow EEH to be built as module
drivers/vfio: Enable VFIO if EEH is not su
From: Alexey Kardashevskiy
This adds necessary declarations to the SPAPR VFIO EEH module,
otherwise multiple dynamic linker errors reported:
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_rese
The patch adds one warning message in eeh_dev_open() in case the
PCI device can't be marked as passed through.
Suggested-by: Alexey Kardashevskiy
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/eeh.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/e
On Thu, Aug 07, 2014 at 12:10:07PM +1000, Gavin Shan wrote:
>On Wed, Aug 06, 2014 at 11:05:43PM +1000, Alexey Kardashevskiy wrote:
>>On 08/06/2014 10:50 PM, Alex Williamson wrote:
>>> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
From: Alexey Kardashevskiy
The existing vfio_p
On Wed, Aug 06, 2014 at 11:05:43PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2014 10:50 PM, Alex Williamson wrote:
>> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
>>> From: Alexey Kardashevskiy
>>>
>>> The existing vfio_pci_open() fails upon error returned from
>>> vfio_spapr_pci_eeh_op
On Wed, Aug 6, 2014 at 9:55 PM, Kamal Mostafa wrote:
>
> On Wed, 2014-08-06 at 14:30 -0700, Davidlohr Bueso wrote:
>> Well 3.13.y.z isn't an Ubuntu kernel, its upstream, and those archs
>> *are* supported.
>
> Davidlohr's answer is correct: This is not an "Ubuntu kernel".
>
> 3.13.y.z is an "exten
On Wed, Aug 6, 2014 at 3:12 PM, Michael Ellerman wrote:
> We have been a bit slack about updating the CPU_FTRS_POSSIBLE and
> CPU_FTRS_ALWAYS masks. When we added POWER8, and also POWER8E we forgot
> to update the ALWAYS mask. And when we added POWER8_DD1 we forgot to
> update both the POSSIBLE an
> On Wed, 2014-08-06 at 17:25 -0400, Andev wrote:
> > On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa wrote:
> > > This is a note to let you know that I have just added a patch titled
> > >
> > > locking/mutex: Disable optimistic spinning on some architectures
> > >
> > > to the linux-3.13.y-qu
On Wed, 2014-08-06 at 15:42 +1000, Michael Ellerman wrote:
> We have been a bit slack about updating the CPU_FTRS_POSSIBLE and
> CPU_FTRS_ALWAYS masks. When we added POWER8, and also POWER8E we forgot
> to update the ALWAYS mask. And when we added POWER8_DD1 we forgot to
> update both the POSSIBLE
On Wed, 2014-08-06 at 20:16 +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V" writes:
>
> > If we know that user address space has never executed on other cpus
> > we could use tlbiel.
> >
> > Signed-off-by: Aneesh Kumar K.V
>
> Now checking against flush_hash_page, I am wondering whether I n
On Wed, 6 Aug 2014, Andev wrote:
> On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa wrote:
> > This is a note to let you know that I have just added a patch titled
> >
> > locking/mutex: Disable optimistic spinning on some architectures
> >
> > to the linux-3.13.y-queue branch of the 3.13.y.z
On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa wrote:
> This is a note to let you know that I have just added a patch titled
>
> locking/mutex: Disable optimistic spinning on some architectures
>
> to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree
> which can be found at:
>
This is a note to let you know that I have just added a patch titled
locking/mutex: Disable optimistic spinning on some architectures
to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=r
On Wed, 2014-08-06 at 17:25 -0400, Andev wrote:
> On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa wrote:
> > This is a note to let you know that I have just added a patch titled
> >
> > locking/mutex: Disable optimistic spinning on some architectures
> >
> > to the linux-3.13.y-queue branch of t
On Wed, 2014-08-06 at 15:09 -0500, Scott Wood wrote:
> BTW, is there a particular reason why we need to use
> memblock_enforce_memory_limit() on FSL_BOOK3E, rather than relying on
> memblock_set_current_limit()? I see that when
> memblock_enforce_memory_limit() was added to __early_init_mmu(),
> m
On Wed, 2014-08-06 at 20:16 +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V" writes:
>
> > If we know that user address space has never executed on other cpus
> > we could use tlbiel.
> >
> > Signed-off-by: Aneesh Kumar K.V
>
> Now checking against flush_hash_page, I am wondering whether I n
On Wed, 2014-08-06 at 03:53 -0500, Zhao Qiang-B45475 wrote:
> On Wed, Jul 30, 2014 at 08:19 AM, Wood Scott wrote:
>
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, July 30, 2014 8:19 AM
> > To: Zhao Qiang-B45475
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B
On Wed, Aug 06, 2014 at 10:42:37AM +0800, Nicolin Chen wrote:
> On Tue, Aug 05, 2014 at 04:44:29PM +0530, Varka Bhadram wrote:
> > Reading comfortably is important for us... :-)
> > see
> > this:http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt#L
On Wed, 2014-08-06 at 14:58 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2014-08-05 at 19:48 -0500, Scott Wood wrote:
> > I'll do s/mmu_allcpus/this_mmu/ but early_init_mmu() needs to do things
> > both before and after early_init_mmu_common(). Do you want two new
> > functions (before and after
ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.
The e6500 core shares TLBs between hardware threads. Without tlb write
conditional instruction, the Linux kernel uses per core mech
"Aneesh Kumar K.V" writes:
> If we know that user address space has never executed on other cpus
> we could use tlbiel.
>
> Signed-off-by: Aneesh Kumar K.V
Now checking against flush_hash_page, I am wondering whether I need to handle
transcational memory in case of tlbiel ? Michael, can you let
On 08/06/2014 10:50 PM, Alex Williamson wrote:
> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
>> From: Alexey Kardashevskiy
>>
>> The existing vfio_pci_open() fails upon error returned from
>> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
>> support which this patch brings ba
On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
> From: Alexey Kardashevskiy
>
> The existing vfio_pci_open() fails upon error returned from
> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
> support which this patch brings back.
>
> The patch fixes the issue by dropping the re
This reverts commit a603c8ee526f5ea9ad9b40710308766299ad8a69.
fsl_asoc_xlate_tdm_slot_mask() will invert the mask, which isn't fit for
esai. The default function snd_soc_xlate_tdm_slot_mask() is ok for esai.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig|1 -
sound/soc/fsl/fsl_e
refine esai for tdm support.
Shengjiu Wang (2):
ASoC: fsl: esai: refine esai for tdm support
Revert "ASoC: fsl-esai: Add .xlate_tdm_slot_mask() support."
sound/soc/fsl/Kconfig|1 -
sound/soc/fsl/fsl_esai.c | 12 +++-
sound/soc/fsl/fsl_esai.h |8
3 files changed
Add parameter for slots, and caculate the number of TX/RX pins and bclk with
slots. Then driver will be compatible with slots > 2 in TDM mode.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 10 +++---
sound/soc/fsl/fsl_esai.h |8
2 files changed, 11 insertions(+),
"Aneesh Kumar K.V" writes:
> We now support TASK_SIZE of 16TB, hence the array should be 8.
>
> Fixes the below crash:
>
> Unable to handle kernel paging request for data at address 0x000100bd
> Faulting instruction address: 0xc004f914
> cpu 0x13: Vector: 300 (Data Access) at [c00fea7
On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote:
> > -#define pmd_mknonnuma pmd_mknonnuma
> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd)
> > +/*
> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist
> > + * which was inherited from x86. For the purposes of
The function is used by VFIO driver, which might be built as a
dynamic module. So it should be exported.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/eeh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
From: Alexey Kardashevskiy
The existing vfio_pci_open() fails upon error returned from
vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
support which this patch brings back.
The patch fixes the issue by dropping the return value of
vfio_spapr_pci_eeh_open().
Signed-off-by: Alexey Kar
The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:
CC [M] drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/
The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.
Alexey Kardashevskiy (2):
drivers/vfio: Allow EEH to be built as module
drivers/vfio: Enable VFIO if EEH is not sup
From: Alexey Kardashevskiy
This adds necessary declarations to the SPAPR VFIO EEH module,
otherwise multiple dynamic linker errors reported:
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_rese
"Helps debug funky firmware issues".
After:
Starting Linux PPC64 #108 SMP Wed Aug 6 19:04:51 EST 2014
-
ppc64_pft_size= 0x1a
phys_mem_size = 0x2
cpu_features = 0x17fc7a6c18500249
possible= 0x1fff1870
At boot we display a bunch of low level settings which can be useful to
know, and can help to spot bugs when things are fundamentally
misconfigured.
At the moment they are very widely spaced, so that we can accommodate
the line:
ppc64_caches.dcache_line_size = 0xYY
But we only print that line
On Wed, Jul 30, 2014 at 08:19 AM, Wood Scott wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 30, 2014 8:19 AM
> To: Zhao Qiang-B45475
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061
> Subject: Re: qe: move qe from arch/powerpc to dri
Though SPE/AltiVec shares interrupts numbers on BookE cores, use distinct
defines to identify these numbers. This improves code readability especially
in KVM.
Revert c58ce397 and 6b310fc5 patches that added common defines.
Signed-off-by: Mihai Caraman
---
arch/powerpc/kernel/exceptions-64e.S |
SPE exception handlers are now defined for 32-bit e500mc cores even though
SPE unit is not present and CONFIG_SPE is undefined.
Restrict SPE exception handlers to e200/e500 cores adding CONFIG_SPE_POSSIBLE
and consequently guard __stup_ivors and __setup_cpu functions.
Signed-off-by: Mihai Caraman
In commit fb5a515704d7 "Remove platforms/wsp and associated pieces" we
removed the last user of CPU_FTRS_A2, so we should remove it too.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/cputable.h | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerp
We potentially clear CPU_FTR_HVMODE at runtime in __init_hvmode_206(),
so we must make sure it's not set in CPU_FTRS_ALWAYS.
This doesn't hurt us in practice at the moment, because we don't support
compiling only for CPUs that support CPU_FTR_HVMODE.
Signed-off-by: Michael Ellerman
---
arch/pow
Mel Gorman writes:
> From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001
> From: Mel Gorman
> Date: Tue, 5 Aug 2014 12:06:50 +0100
> Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE
>
> ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented
> _P
The called function iommu_del_device() checks if the device has
attached IOMMU group, we needn't check it again in the parent
function call tce_iommu_bus_notifier().
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletion
When we take full hotplug to recover from EEH errors, PCI buses
could be involved. For the case, the child devices of involved
PCI buses can't be attached to IOMMU group properly, which is
caused by commit 3f28c5a ("powerpc/powernv: Reduce multi-hit of
iommu_add_device()").
When adding the PCI dev
This patch disables the branch target address CAM which under specific
circumstances may cause the processor to skip execution of 1-4
instructions. This fixes IBM Erratum #47.
Signed-off-by: Alistair Popple
---
arch/powerpc/kernel/head_44x.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(
53 matches
Mail list logo
