On Mon, 2015-03-23 at 19:19 -0400, Sowmini Varadhan wrote:
What I've tried to do is to have a bool large_pool arg passed
to iommu_tbl_pool_init. In my observation (instrumented for scsi, ixgbe),
we never allocate more than 4 pages at a time, so I pass in
large_pool == false for all the
On Mon, 2015-03-23 at 21:44 -0400, David Miller wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Tue, 24 Mar 2015 09:21:05 +1100
Dave, what's your feeling there ? Does anybody around still have
some HW that we can test with ?
I don't see what the actual problem
/bt8xx: Remove old powerpc cruft
The powerpc arch code enables PCI_COMMAND_MEMORY (and has done so for
more than 10 years at least !) on pci_enable_device() and the hackery
on the MMIO accessor is useless as well, our writel does everything
this driver should need.
Signed-off-by: Benjamin
On Sun, 2015-03-22 at 20:36 +0100, Arnd Bergmann wrote:
How does this relate to the ARM implementation? There is currently
an effort going on to make that one shared with ARM64 and possibly
x86. Has anyone looked at both the PowerPC and ARM ways of doing the
allocation to see if we could pick
On Sun, 2015-03-22 at 18:07 -0400, Sowmini Varadhan wrote:
On (03/23/15 09:02), Benjamin Herrenschmidt wrote:
How does this relate to the ARM implementation? There is currently
an effort going on to make that one shared with ARM64 and possibly
x86. Has anyone looked at both the PowerPC
On Sun, 2015-03-22 at 15:22 -0400, Sowmini Varadhan wrote:
Follows up on the feedback in the thread at
http://www.spinics.net/lists/sparclinux/msg13493.html
- removed -cookie_to_index and -demap indirection from the iommu_tbl_ops
The caller needs to call these functions as needed, before
The sdc node is missing the ranges property, it needs to be treated
as having an empty one otherwise translation fails for its children.
Tested-by: Steven Rostedt rost...@goodmis.org
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/of/address.c | 11 ---
1 file
On Mon, 2015-03-23 at 14:50 +1100, Michael Ellerman wrote:
On Mon, 2015-23-03 at 03:16:38 UTC, Benjamin Herrenschmidt wrote:
The sdc node is missing the ranges property, it needs to be treated
as having an empty one otherwise translation fails for its children.
Tested-by: Steven Rostedt
On Fri, 2015-03-20 at 09:34 -0500, Bjorn Helgaas wrote:
On Fri, Mar 20, 2015 at 12:43 AM, Gavin Shan gws...@linux.vnet.ibm.com
wrote:
On Fri, Mar 20, 2015 at 11:06:16AM +0800, Wei Yang wrote:
[snip]
---
v14:
* call ppc_md.pcibios_fixup_sriov() in pcibios_add_device
* add more
On Fri, 2015-03-20 at 16:16 -0500, Bjorn Helgaas wrote:
The other option is you put the generic changes in a topic branch
which
both of us merge and I take care of the rest.
Yeah, I chatted with Wei this morning, and he reminded me that there's
really not very much drivers/pci content
On Wed, 2015-03-18 at 19:49 +0530, Aneesh Kumar K.V wrote:
Why not do it also for DMA32 as below. We call limit_zone_pfn() only
for few
platforms. They can select ZONE_DMA32. Everywhere else ZONE_DMA32 is
same as ZONE_NORMAL ? So instead of having confusing output for
show_mem(), we now have
On Wed, 2015-03-18 at 22:25 -0400, David Miller wrote:
PowerPC folks, we're trying to kill the locking contention in our
IOMMU allocators and noticed that you guys have a nice solution to
this in your IOMMU code.
Sowmini put together a patch series that tries to extract out the
generic
On Wed, 2015-03-18 at 22:25 -0400, David Miller wrote:
PowerPC folks, we're trying to kill the locking contention in our
IOMMU allocators and noticed that you guys have a nice solution to
this in your IOMMU code.
.../...
Adding Alexei too who is currently doing some changes to our iommu
code
Hi folks !
My -next branch has been somewhat dormant lately. Now that we have that
new two-headed maintainership model, I'll change the way it works.
I'm going to merge patches in topic branches exclusively. One per series
and a next-misc for random other stuff.
next itself will just be an
On Mon, 2015-03-16 at 09:59 +1100, Tony Breeds wrote:
On Fri, Mar 13, 2015 at 05:38:46PM +1100, Michael Ellerman wrote:
According to Paul there are no working implementations of LE on 32-bit
cpus, so
the syscall doesn't really make sense there.
Ummm that doesn't sound right. I don't
On Fri, 2015-03-13 at 14:09 +0800, Kevin Hao wrote:
On Thu, Mar 12, 2015 at 04:24:10PM +0100, Torsten Duwe wrote:
But generally, which platforms would benefit most from this change?
In theory, the more cpus the platform has, the more serious the thundering
herd problem is. So the latest
On Fri, 2015-03-13 at 18:09 +1100, Michael Ellerman wrote:
On Thu, 2015-03-12 at 22:13 +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-03-12 at 18:55 +0800, Kevin Hao wrote:
I know Torsten Duwe has tried to add the ticket spinlock for powerpc
one year ago [1]. But it make no progress
On Thu, 2015-03-12 at 18:55 +0800, Kevin Hao wrote:
I know Torsten Duwe has tried to add the ticket spinlock for powerpc
one year ago [1]. But it make no progress due to the conflict between
PPC_SPLPAR and lockref. We still don't find a better way to handle
this. But instead of waiting forever
On Wed, 2015-03-11 at 08:50 +0100, Thomas Huth wrote:
- Graphic cards should get the display device_type ... I guess
that's
missing now?
At least the code for qemu-vga does it
- pci bus nodes (like bridges) should get the pci device_type
according to the Open Firmware PCI binding, is
On Wed, 2015-03-11 at 19:54 +1100, Alexey Kardashevskiy wrote:
+/* Page size flags for ibm,query-pe-dma-window */
+#define DDW_PGSIZE_4K 0x01
+#define DDW_PGSIZE_64K 0x02
+#define DDW_PGSIZE_16M 0x04
+#define DDW_PGSIZE_32M 0x08
+#define
On Tue, 2015-03-10 at 18:36 +1100, Michael Ellerman wrote:
We currently have a special syscall for switching endianness. This is
syscall number 0x1ebe, which is handled explicitly in the 64-bit syscall
exception entry.
That has a few problems, firstly the syscall number is outside of the
On Wed, 2015-03-11 at 11:08 +0530, Anshuman Khandual wrote:
On 03/10/2015 04:25 PM, Michael Ellerman wrote:
On Tue, 2015-03-10 at 20:34 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2015-03-10 at 18:36 +1100, Michael Ellerman wrote:
We currently have a special syscall for switching
On Tue, 2015-03-10 at 22:43 +0530, Neelesh Gupta wrote:
I tested the i2c opal driver after updating the patch as below.
Basically I think we can also support write-then-{read/write}
for the number of messages = 2.
Ben, any issues if we support both write plus read/write in the
opal driver ?
On Tue, 2015-03-10 at 17:03 -0600, Alex Williamson wrote:
return (PAGE_SHIFT + compound_order(compound_head(page) = page_shift);
This won't be bool though.
Yes, it will.
Don't you have your parenthesis in the wrong place, Alex ? :-)
This will (I'll do this)
shift = PAGE_SHIFT
On Sat, 2015-03-07 at 19:19 +0800, Kevin Hao wrote:
It makes no sense to use a variant lock token on a platform which
doesn't support for shared-processor logical partitions. Actually we
can eliminate a memory load by using a fixed lock token on these
platforms.
Does this provide an actual
On Mon, 2015-03-09 at 09:13 +0800, Kevin Hao wrote:
On Sun, Mar 08, 2015 at 08:13:26PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2015-03-07 at 19:14 +0800, Kevin Hao wrote:
All the cache line size of the current book3e 64bit SoCs are 64 bytes.
So we should use this size to align
On Sat, 2015-03-07 at 19:14 +0800, Kevin Hao wrote:
All the cache line size of the current book3e 64bit SoCs are 64 bytes.
So we should use this size to align the member of paca_struct.
With this change we save 192 bytes. Also change it to __aligned(size)
since it is preferred over
On Fri, 2015-03-06 at 16:16 -0800, Alex Perez wrote:
I will of course ultimately defer to Olof, but PASemi hasn’t existed
for years, and there is no entity which could possibly update the DT
for these reference PASemi development boards, unless Olof has source,
which I’m pretty sure he does
On Fri, 2015-03-06 at 15:50 -0800, Olof Johansson wrote:
On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
On Fri, 06 Mar 2015 15:18:42 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote
On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
On Fri, 06 Mar 2015 15:18:42 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
Can you shoot me the DT (/proc/device-tree in a tarball) ?
Attached.
This is indeed a bug in their DT. We might want to add quirks
f8010010 f821ff91 6000 6000 3d220003
39296870 a86d0038 e9290010 7c0004ac 7c004c2c 0c00 4c00012c 5463103a
---[ end trace 40e864a431826b26 ]---
I kicked off a ktest bisect, and it came down to this commit:
commit 746c9e9f92dde2789908e51a354ba90a1962a2eb
Author: Benjamin
On Mon, 2015-03-02 at 15:50 +0800, Wei Yang wrote:
Is there a hotplug remove path where we should also be calling
iommu_free_table()?
When VF is not introduced, no one calls this on powernv platform.
Each PCI bus is a PE and it has its own iommu table, even a device is
hotpluged, the
On Fri, 2015-02-27 at 09:28 +0200, Purcareata Bogdan wrote:
Ping?
What is the ping for ?
Ben.
On 18.02.2015 10:16, Bogdan Purcareata wrote:
Add the missing pieces in order to enable SECCOMP_FILTER on PowerPC
architectures, and enable this support.
Testing has been pursued using
in the current kernel.
Replace it with PPC.
Signed-off-by: Kevin Hao haoke...@gmail.com
For this and generally the whole series,
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Which tree do we expect this to go through ?
Cheers,
Ben.
---
drivers/video/fbdev/aty/aty128fb.c | 4
CONFIG_BLK_DEV_SD, SR, ... are needed for pretty much any SATA or USB
storage device (corenet32_defconfig has them) and modern any with
systemd needs the CGROUPS gunk.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig
b
On Fri, 2015-02-27 at 09:05 +0800, Kevin Hao wrote:
On Fri, Feb 27, 2015 at 11:11:15AM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2015-01-31 at 21:47 +0800, Kevin Hao wrote:
The PPC_OF is a ppc specific option which is used to mean that the
firmware device tree access functions
On Fri, 2015-02-27 at 14:39 +1100, Michael Ellerman wrote:
On Thu, 2015-02-26 at 17:38 +1100, Michael Ellerman wrote:
On Fri, 2015-20-02 at 08:35:44 UTC, Benjamin Herrenschmidt wrote:
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index e24e0ae..6306d4e 100644
, Benjamin Herrenschmidt
+ * Copyright (C) 2003, 2004, 2015
+ * Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt, Thomas Haschka
*
* Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
* http://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
@@ -45,8 +46,10
On Tue, 2015-02-24 at 10:37 -0600, Suresh E. Warrier wrote:
On 02/23/2015 09:38 PM, Benjamin Herrenschmidt wrote:
On Mon, 2015-02-23 at 18:10 -0600, Suresh E. Warrier wrote:
Export __spin_yield so that the arch_spin_unlock() function
can be invoked from a module.
Make
On Tue, 2015-02-24 at 14:34 -0600, Scott Wood wrote:
On Fri, 2015-02-20 at 19:35 +1100, Benjamin Herrenschmidt wrote:
@@ -149,14 +141,13 @@ static void dma_direct_unmap_sg(struct device *dev,
struct scatterlist *sg,
static int dma_direct_dma_supported(struct device *dev, u64 mask
On Tue, 2015-02-24 at 02:13 -0600, Bjorn Helgaas wrote:
Ah, yes, now I see the problem. I don't really like having to export
pci_iov_virtfn_bus() and pci_iov_virtfn_devfn(), but it's probably not
worth the hassle of changing it, and I think adding more pcibios
interfaces
would be even
*
- * Copyright (C) 2003, 2004 Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt
+ * Copyright (C) 2003, 2004, 2015
+ * Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt, Thomas Haschka
*
* Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
* http://www.onsemi.com
On Mon, 2015-02-23 at 18:10 -0600, Suresh E. Warrier wrote:
Export __spin_yield so that the arch_spin_unlock() function
can be invoked from a module.
Make it EXPORT_SYMBOL_GPL. Also explain why a module might need it
Signed-off-by: Suresh Warrier warr...@linux.vnet.ibm.com
---
On Sun, 2015-02-22 at 23:13 +0100, Frederic Weisbecker wrote:
Yes that should work. After all self-IPI is an oxymoron. One would
expect an IPI to be triggered by an irq controller but if such
operation isn't supported with the current CPU being both source and
destination, anything triggering
On Fri, 2014-11-28 at 11:11 +1100, Michael Ellerman wrote:
On Wed, 2014-26-11 at 04:10:04 UTC, Benjamin Herrenschmidt wrote:
This adds files in debugfs that can be used to retrieve the
OPALv3 firmware live binary traces which can then be parsed
using a userspace tool.
Mostly from Rusty
On Sat, 2015-02-21 at 19:26 +0800, Kevin Hao wrote:
On Fri, Feb 20, 2015 at 07:35:25PM +1100, Benjamin Herrenschmidt wrote:
We do this for consistency and also in order to support the use of a
consistent mask smaller than the dma mask in subsequent patches.
Signed-off-by: Benjamin
for these. This should
work since the rest of the code in the direct DMA ops assume this
is true anyway.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/pgtable.h |1 +
arch/powerpc/kernel/dma.c | 21 ++---
arch/powerpc/mm/mem.c
We don't initialize it, we don't use it, remove it.
We can bring it back if we ever wish to have support for devices
who have smaller than 32-bit DMA limitations but I don't think
we care much anymore.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/Kconfig
We do this for consistency and also in order to support the use of a
consistent mask smaller than the dma mask in subsequent patches.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/dma-swiotlb.c | 3 ---
arch/powerpc/mm/mem.c | 6 ++
2
On Thu, 2015-02-19 at 18:56 -0600, Bjorn Helgaas wrote:
So there are the two windows of CPU address space that are routed to the
PHB. And the PHB contains one M32 window and sixteen M64 windows. What
happens if the PHB receives an access to something that was in one of the
two CPU address
On Wed, 2015-02-18 at 08:30 -0600, Bjorn Helgaas wrote:
So the hypervisor call that removes the device from the partition will
fail if there are any translations that reference the memory of the
device.
Let me go through this in excruciating detail to see if I understand
what's going on:
On Wed, 2015-02-18 at 11:16 +1100, Gavin Shan wrote:
What is vm_unmap_aliases() for? I see this is probably copied from
rpaphp_core.c, where it was added by b4a26be9f6f8 (powerpc/pseries:
Flush
lazy kernel mappings after unplug operations).
But I don't know whether:
- this is
On Mon, 2015-02-16 at 11:08 +1100, Michael Ellerman wrote:
On Fri, 2015-02-13 at 13:38 -0600, Paul Clarke wrote:
implement arch_irq_work_has_interrupt() for powerpc
Commit 9b01f5bf3 introduced a dependency on IRQ work self-IPIs for
full dynamic ticks to be enabled, by expecting
On Thu, 2015-02-12 at 15:23 +0530, Vasant Hegde wrote:
Present code checks for update_flash_data in opal_flash_term_callback().
update_flash_data has been statically initialized to zero, and that
is the value of FLASH_IMG_READY. Also code update initialization happens
during subsys init.
On Wed, 2015-02-11 at 08:53 +0100, leroy christophe wrote:
In powerpc32 architecture there is a function called cacheable_memcpy()
which does same thing as memcpy() but using dcbz/dcbt instructions for
an optimised copy (just like __copy_tofrom_user())
What seems strange is that it is almost
On Tue, 2015-02-10 at 20:15 +0800, Jeremy Kerr wrote:
We use r6 and r7 for epapr boot, but the current pre-C init will clobber
both of these.
This change does a simple replacement, of r6 - r12 and r7 - r13, so
that we hit platform init with these registers intact.
Signed-off-by: Jeremy
-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/boot/libfdt_env.h | 14 --
arch/powerpc/boot/of.h |8
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/libfdt_env.h b/arch/powerpc/boot/libfdt_env.h
index
On Wed, 2015-02-11 at 10:16 +0800, Jeremy Kerr wrote:
Hi Ben,
We'll likely be entering the zImage.epapr as BE, so include the pseries
implementation of _zimage_start, which adds the endian fixup magic.
Wont that break embedded epapr stuff ?
How so? This will just give us the endian
On Tue, 2015-02-10 at 20:15 +0800, Jeremy Kerr wrote:
We'll likely be entering the zImage.epapr as BE, so include the pseries
implementation of _zimage_start, which adds the endian fixup magic.
Wont that break embedded epapr stuff ?
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
On Tue, 2015-02-10 at 20:15 +0800, Jeremy Kerr wrote:
Currently, a 64-bit little-endian zImage.epapr won't boot in epapr mode,
as as we never return from platform_init.
Before entering C, we initialise our stack by setting r1 16 bytes below
the end of the _bss_stack:
stwu
On Tue, 2015-02-10 at 00:00 -0800, Dave Olson wrote:
OK, now that I understand that's the case, I'll have to go back and
re-do the patch to handle both cache-size and d-cache-size for the
L2 cache (using whichever is present).
I notice that you also didn't modify all the other properties, I
On Tue, 2015-02-10 at 14:25 +0800, Wei Yang wrote:
PF's resource will be assigned first, including normal BARs and IOV
BARs.
Then PF's driver will create VFs, in virtfn_add(). In this function,
VF's
resources is calculated from its PF's IOV BAR.
If you reset VF's resource as PFs, no one
On Tue, 2015-02-10 at 08:55 -0800, Dave Olson wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Tue, 2015-02-10 at 00:00 -0800, Dave Olson wrote:
OK, now that I understand that's the case, I'll have to go back and
re-do the patch to handle both cache-size and d-cache
On Wed, 2015-02-11 at 12:27 +0800, Jeremy Kerr wrote:
Hi Ben,
You might want to also remove the use of r8 and r9 which are supposed
to contain the OPAL entry and base for debugging purposes. We would also
have to restore them before booting the kernel.
I'd prefer that to be a separate
On Tue, 2015-02-10 at 09:35 +0800, Wei Yang wrote:
Don't we want pcibios_sriov_enable() to be able to crop the number
of VFs or do we think any resource limits have been applied
already ?
The second parameter initial is the number of VFs will be enabled.
Arch
dependent function will check
On Tue, 2015-02-10 at 13:26 +1100, Stewart Smith wrote:
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1481,9 +1481,9 @@ int pnv_phb_to_cxl(struct pci_dev *dev)
pe_info(pe, Switching PHB to CXL\n);
- rc =
On Tue, 2015-02-10 at 09:51 +0800, Wei Yang wrote:
On Tue, Feb 10, 2015 at 11:36:24AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
+ if ((retval = pcibios_sriov_enable(dev, initial))) {
+ dev_err(dev-dev, Failure %d from
pcibios_sriov_setup()\n,
+ retval);
+ return retval;
+ }
+
Don't we want
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
The alignment of PF's IOV BAR is designed to be the individual size of a
VF's BAR size. This works fine for many platforms, but on PowerNV platform
it needs some change.
The original alignment works, since at sizing and assigning stage the
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't
On Wed, 2015-02-04 at 17:44 -0600, Bjorn Helgaas wrote:
diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.txt
b/Documentation/powerpc/pci_iov_resource_on_powernv.txt
new file mode 100644
index 000..10d4ac2
--- /dev/null
+++
On Mon, 2015-02-09 at 15:43 -0800, Dave Olson wrote:
Michael Ellerman m...@ellerman.id.au wrote:
On Mon, 2015-02-09 at 14:14 -0800, Dave Olson wrote:
From: Dave Olson ol...@cumulusnetworks.com
Fix missing L2 cache size in
/sys/devices/system/cpu/cpu0/cache/index2/size
This
On Wed, 2015-02-04 at 17:44 -0600, Bjorn Helgaas wrote:
Ben, I know you chimed in earlier to help explain PEs. Are you or
another powerpc maintainer planning to ack all this?
I'll get through it in the next day or so.
Cheers,
Ben.
___
Linuxppc-dev
On Fri, 2015-01-30 at 19:08 +0700, Arseny Solokha wrote:
MMU_NO_CONTEXT is conditionally defined as 0 or (unsigned int)-1. However,
in __flush_tlb_page() a corresponding variable is only tested for open
coded 0, which can cause NULL pointer dereference if `mm' argument was
legitimately passed
On Tue, 2015-01-27 at 16:58 -0600, Brian King wrote:
I'd argue we are our own worst enemy here really. The new user is EEH
code.
I don't see a huge reason that code would need to use this exact same
API.
In fact, even with IPR and the existing call, how do you wait for
the link to come
On Mon, 2015-01-26 at 17:36 -0600, Brian King wrote:
To set some context, this function is only used by ipr for some old
broken adapters. These are adapters that are not supported on p8,
so will never show up under OPAL, only PowerVM. I'm fine with looking
at alternatives for the future, but I
On Fri, 2015-01-23 at 14:50 +1100, Gavin Shan wrote:
Messages from Brian for reference:
| The API has changed. I wrote the pci_set_pcie_reset_state API originally.
| When this API was put in place initially, it was perfectly legal to call it
| from an atomic context. Can you clarify why we
On Mon, 2015-01-19 at 09:47 +1100, Gavin Shan wrote:
On pseries platform, the EEH reset backend pseries_eeh_reset() can
be called in atomic context as follows. For this case, we should
call udelay() instead of msleep() to avoid context switching.
On Wed, 2015-01-07 at 11:04 -0600, Scott Wood wrote:
On Wed, 2015-01-07 at 15:44 +0100, Benjamin Herrenschmidt wrote:
On Mon, 2015-01-05 at 12:10 -0600, Scott Wood wrote:
It would have been nice if a code comment explained why it was doing the
readback... I don't see any particular need
On Mon, 2015-01-05 at 18:46 +0100, Andreas Mohr wrote:
Hi,
I was curious why the mpic_cpu_read(MPIC_INFO(CPU_WHOAMI)) was there in
the first place and if it's still needed. If it's still required, I
guess a better approach is to eliminate the call only if the kernel is
running on the
On Mon, 2015-01-05 at 12:10 -0600, Scott Wood wrote:
It would have been nice if a code comment explained why it was doing the
readback... I don't see any particular need to wait for EOI completion
here (unlike when masking).
The EOI is what causes the MPIC to drop it's EE output to the CPU,
On Mon, 2015-01-05 at 16:14 +0200, Purcareata Bogdan wrote:
Hello,
While doing some performance testing of a KVM guest on a PPC platform, I
noticed that there's a read of the CPU_WHOAMI register after each MPIC
EOI [1]. This has been present since the initial implementation of the
MPIC
On Tue, 2014-12-23 at 12:00 +1100, Michael Ellerman wrote:
On Mon, 2014-12-22 at 14:38 +0800, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
Kernel cannot bring up Non-boot cpus always get Processor xx is stuck.
this issue bring by
On Wed, 2014-12-17 at 11:53 +0100, Arnd Bergmann wrote:
On Wednesday 17 December 2014 11:52:36 Benjamin Herrenschmidt wrote:
On Tue, 2014-12-16 at 18:47 +0200, Michael S. Tsirkin wrote:
On Sun, Dec 14, 2014 at 06:52:51PM +0200, Michael S. Tsirkin wrote:
virtio wants to read bitwise types
On Tue, 2014-12-16 at 18:47 +0200, Michael S. Tsirkin wrote:
On Sun, Dec 14, 2014 at 06:52:51PM +0200, Michael S. Tsirkin wrote:
virtio wants to read bitwise types from userspace using get_user. At the
moment this triggers sparse errors, since the value is passed through an
integer.
On Sun, 2014-12-14 at 18:52 +0200, Michael S. Tsirkin wrote:
virtio wants to read bitwise types from userspace using get_user. At the
moment this triggers sparse errors, since the value is passed through an
integer.
Fix that up using __force.
You mean bitfields ? Argh ... we should just
On Mon, 2014-12-15 at 11:05 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2014-12-14 at 18:52 +0200, Michael S. Tsirkin wrote:
virtio wants to read bitwise types from userspace using get_user. At the
moment this triggers sparse errors, since the value is passed through an
integer.
Fix
On Thu, 2014-12-11 at 17:00 +1100, Gavin Shan wrote:
The callback (ppc_md.pci_probe_mode()) is used to determine if the
child PCI devices of the indicated PCI bus should be probed from
device-tree or hardware. On PowerNV platform, we always expect
probing PCI devices from hardware, which is
On Tue, 2014-12-09 at 09:54 +0100, Wolfram Sang wrote:
Oh, I thought we agreed that you take it via powerpc. I still think this
is the best solution.
I threatened to do that :-) I don't remember you replying, did I miss
it ?
It is here:
On Tue, 2014-12-09 at 21:06 +1100, Michael Ellerman wrote:
On Mon, 2014-08-12 at 14:16:29 UTC, LEROY Christophe wrote:
Compilation with #define STRICT_MM_TYPECHECKS in
arch/powerpc/include/asm/page.h
fails due to missing use of pgprot_val() when using pgprot_t objects.
Any idea when
On Tue, 2014-12-09 at 20:45 +1100, Michael Ellerman wrote:
On Mon, 2014-08-12 at 06:36:16 UTC, Neelesh Gupta wrote:
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the
On Mon, 2014-12-08 at 09:21 -0600, Nathan Fontenot wrote:
Oh I was hoping you would not say that :(
Heh! hint taken. I won't cc you.
Seriously? Parsing binary blobs from userspace? Don't do that, you
know better.
Yes, not ideal. One thing to note here is that the code to parse
of existing bus and device drivers, so a
very pervasive change, and which will be visible to user space, which
means that drivers will need to continue supporting the old way at
least for a while anyway...
Ben.
Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com
Signed-off-by: Benjamin
On Mon, 2014-12-08 at 21:55 +0100, Wolfram Sang wrote:
On Tue, Dec 09, 2014 at 07:13:15AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2014-12-08 at 12:06 +0530, Neelesh Gupta wrote:
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus
On Thu, 2014-12-04 at 16:48 +, Yokoyama, Caz wrote:
Thank you for the report.
Have you tried to compile on x86_64? Which rhel do you use? Rhel6.X?
MIC card is expected to work with x86_64 host, not with ppc64. We have never
compiled on ppc host while our primary development platform was
Newer versions of OPAL will provide this, so let's expose it to user
space so tools like perf can use it to properly decode samples in
firmware space.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms
Newer versions of OPAL will provide this, so let's expose it to user
space so tools like perf can use it to properly decode samples in
firmware space.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2. Use memory_read_from_buffer()
diff --git a/arch/powerpc/platforms/powernv
On Fri, 2014-12-05 at 10:01 +0530, Mahesh J Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting
partial invalidation of TLBs which is not right. This patch fixes that
by passing IS=0xc00 to
On Wed, 2014-12-03 at 15:52 +, Mel Gorman wrote:
It's implied but can I assume it passed? If so, Ben and Paul, can I
consider the series to be acked by you other than the minor comment
updates?
Yes. Assuming it passed :-)
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Cheers
On Tue, 2014-12-02 at 12:57 +0530, Aneesh Kumar K.V wrote:
Now, hash_preload can possibly insert an hpte in hash page table even if
the access is not allowed by the pte permissions. But i guess even that
is ok. because we will fault again, end-up calling hash_page_mm where we
handle that part
1301 - 1400 of 7203 matches
Mail list logo
