On Tue, 28 Jul 2015 15:28:40 +1000
Daniel Axtens d...@axtens.net wrote:
If the driver doesn't participate in EEH, the AFUs will be removed
by cxl_remove, which will be invoked by EEH.
If the driver does particpate in EEH, the vPHB needs to stick around
so that the it can particpate.
In
This fixes the wrapper functions kvm_umap_hva_hv and the function
kvm_unmap_hav_range_hv to return the return value of the function
kvm_handle_hva or kvm_handle_hva_range that they are wrapped to
call internally rather then always making the caller of these
wrapper functions think they always run
On Mon, 2015-08-10 at 10:23 +0800, Huang, Yuanjie wrote:
Hi Scott,
On 08/08/2015 10:29 AM, Scott Wood wrote:
[Please wrap commit messages at around 74 columns]
Ok, I will when sending a new version.
On Fri, Aug 07, 2015 at 02:58:10PM +0800, Yuanjie Huang wrote:
PowerPC Book3E
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is not allocated ;)
It conflicts with the fact that M64 segments are
assigned in same order. In order to avoid the
On Fri, 2015-08-07 at 07:49 +0530, Madhavan Srinivasan wrote:
On Thursday 06 August 2015 06:35 PM, Anshuman Khandual wrote:
This patch just replaces hard coded values with existing
Please drop This patch just and start with Replace hard ...
On Sun, 2015-08-09 at 22:18 +0300, Ran Shalit wrote:
On Sun, Aug 9, 2015 at 9:27 AM, Ran Shalit ransha...@gmail.com wrote:
Hi ,
I reboot the board, with the new device tree localbus, but I don't
have any new /dev/mtdX entry for the NOR flash.
There is no HW issue, becuase we can R/W
On Mon, Aug 10, 2015 at 04:30:09PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Different from PHB3 where 16 M64 BARs are supported and each
of them can be owned by one particular PE# exclusively
On Mon, Aug 10, 2015 at 04:05:40PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The series of patches intend to support PCI slot for PowerPC PowerNV platform,
which is running on top of skiboot firmware. The patchset requires
corresponding
changes from skiboot
On 8/5/2015 9:11 PM, Gavin Shan wrote:
This introduces one more argument to of_fdt_unflatten_tree()
to specify the root node for the FDT blob, which is going to be
unflattened. In the result, the function can be used to unflatten
FDT blob, which represents device sub-tree in PowerNV hotplug
On 8/5/2015 9:11 PM, Gavin Shan wrote:
This changes of_fdt_unflatten_tree() so that it returns the allocated
memory chunk for unflattened device-tree, which can be released once
it's obsoleted.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
drivers/of/fdt.c | 11 ++-
On Mon, Aug 10, 2015 at 05:16:40PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what is that
all about? Also, there was no
On Mon, Aug 10, 2015 at 05:40:08PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable windows which happen
to be IO, 32bit and 64bit windows but
On Tue, 28 Jul 2015 15:28:34 +1000
Daniel Axtens d...@axtens.net wrote:
If the PCI channel has gone down, don't attempt to poke the hardware.
We need to guard every time cxl_whatever_(read|write) is called. This
is because a call to those functions will dereference an offset into an
mmio
On Tue, 28 Jul 2015 15:28:35 +1000
Daniel Axtens d...@axtens.net wrote:
Previously the SPA was allocated and freed upon entering and leaving
AFU-directed mode. This causes some issues for error recovery - contexts
hold a pointer inside the SPA, and they may persist after the AFU has
been
On Tue, 28 Jul 2015 15:28:36 +1000
Daniel Axtens d...@axtens.net wrote:
Check if an IRQ is mapped before releasing it.
This will simplify future EEH code by allowing unconditional unmapping
of IRQs.
Acked-by: Cyril Bur cyril...@gmail.com
Signed-off-by: Daniel Axtens d...@axtens.net
---
On Tue, Aug 11, 2015 at 5:29 AM, Scott Wood scottw...@freescale.com wrote:
On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit ransha...@gmail.com wrote:
Hello,
MPC8349 has general IRQ numbered 0-7,
It is required to bind these IRQs with some
On Tue, 2015-08-11 at 06:45 +0300, Ran Shalit wrote:
On Tue, Aug 11, 2015 at 5:29 AM, Scott Wood scottw...@freescale.com wrote:
On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit ransha...@gmail.com
wrote:
Hello,
MPC8349 has
On Tue, 28 Jul 2015 15:28:37 +1000
Daniel Axtens d...@axtens.net wrote:
- MMIO pointer unmapping is guarded by a null pointer check.
However, iounmap doesn't null the pointer, just invalidate it.
Therefore, explicitly null the pointer after unmapping.
- afu_desc_mmio also needs to
On Tue, 28 Jul 2015 15:28:43 +1000
Daniel Axtens d...@axtens.net wrote:
CONFIG_CXL_EEH is for CXL's EEH related code.
As well as the EEH callbacks, it should guard sysfs and
kernel API changes that are only required for CXL EEH.
We now have all the pieces in place, so add it now.
On Tue, 28 Jul 2015 15:28:39 +1000
Daniel Axtens d...@axtens.net wrote:
As with an adapter, some aspects of initialisation are done only once
in the lifetime of an AFU: for example, allocating memory, or setting
up sysfs/debugfs files.
However, we may want to be able to do some parts of the
Hey Daniel, keeping in mind I can't exactly test it, and that I don't know the
ins and outs of CAPI, the code looks nice and it makes sence to me.
Thanks!
Some very minor points,
Otherwise
Acked-by: Cyril Bur cyril...@gmail.com
+static inline bool cxl_adapter_link_ok(struct
On Tue, 2015-08-11 at 13:42 +1000, Cyril Bur wrote:
On Tue, 28 Jul 2015 15:28:35 +1000
Daniel Axtens d...@axtens.net wrote:
Previously the SPA was allocated and freed upon entering and leaving
AFU-directed mode. This causes some issues for error recovery - contexts
hold a pointer inside
Hello David,
Thank you for your feedback.
I understand your concerns regarding the FMan driver, we've come a long way
from where we started but still there are issues.
The community support is critical for getting the code to the desired quality
level and I appreciate the support I receive
On 08/11/2015 09:45 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 04:30:09PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Different from PHB3 where 16 M64 BARs are supported and each
of them
On 08/11/2015 10:03 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:16:40PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what
On Mon, 2015-08-10 at 13:40 +0300, Ran Shalit wrote:
On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit ransha...@gmail.com wrote:
Hello,
MPC8349 has general IRQ numbered 0-7,
It is required to bind these IRQs with some routine , i.e. they are
not used with any specific driver.
- Should
On 08/11/2015 10:12 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:40:08PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable windows
On 08/11/2015 10:29 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 07:31:11PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The
On 08/11/2015 10:38 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 07:53:02PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't
On 08/11/2015 10:43 AM, Gavin Shan wrote:
On Tue, Aug 11, 2015 at 12:39:02AM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is
On Mon, Aug 10, 2015 at 06:07:27PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
behavioural changes:
* Rename various fields in struct pnv_phb and struct pnv_ioda_pe
as 32-bits DMA should be
On Mon, Aug 10, 2015 at 08:02:20PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Several functions used to configure PE take pe_number to indentify
PE instance. As the pe_number is included in PE instance after it
is reserved or allocated. It's convienent for those
On Mon, Aug 10, 2015 at 07:53:02PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't have more than 256 PEs. However,
On Mon, Aug 10, 2015 at 03:42:32PM -0700, Frank Rowand wrote:
On 8/5/2015 9:11 PM, Gavin Shan wrote:
Frank, thanks for your comments. All of them will be included
in next revision.
Thanks,
Gavin
This changes of_fdt_unflatten_tree() so that it returns the allocated
memory chunk for unflattened
On Mon, Aug 10, 2015 at 07:31:11PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The function was designed to be called during PHB fixup
On Mon, Aug 10, 2015 at 07:43:48PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
On P7IOC, the whole DMA32 space is divided evenly to 256MB segments.
Each PE can consume one or multiple DMA32 segments. Current code
doesn't trace the available DMA32 segments and those
On Tue, Aug 11, 2015 at 12:21:16AM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
This renames the fields related to PE# in struct pnv_phb for
better reflecting of their usages as Alexey suggested. It doesn't
introduce behavioural changes.
Signed-off-by: Gavin Shan
On Tue, Aug 11, 2015 at 12:39:02AM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is not allocated ;)
Yeah, will correct it.
It
On Mon, Aug 10, 2015 at 03:42:13PM -0700, Frank Rowand wrote:
On 8/5/2015 9:11 PM, Gavin Shan wrote:
This introduces one more argument to of_fdt_unflatten_tree()
to specify the root node for the FDT blob, which is going to be
unflattened. In the result, the function can be used to unflatten
Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com writes:
Also, do we export this information via sysfs somewhere? It would seem
to want to go along with other cpufreq/cpu info there.
No we don't export the throttling status of the cpu via sysfs. Since the
throttling state is common across the
On 08/06/2015 02:11 PM, Gavin Shan wrote:
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is divided evenly into 256MB segments. The number
of continuous segments assigned to one particular PE depends on
the PE's DMA weight that is calculated based on the type of each
On Tue, 2015-04-08 at 11:18:56 UTC, Mahesh Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Invoke new opal_cec_reboot2() call with reboot type
OPAL_REBOOT_PLATFORM_ERROR (for unrecoverable HMI interrupts) to inform
BMC/OCC about this error, so that BMC can collect
On Wed, 2015-29-07 at 04:07:22 UTC, Daniel Axtens wrote:
Previously, when attaching a context in dedicated mode, we ignored
the result of add_process_element, which could potentially fail.
If add_process_element returns and error, pass it back to the caller.
Signed-off-by: Daniel Axtens
On Fri, 2015-12-06 at 02:26:37 UTC, Kevin Hao wrote:
Use %pR to simplify the debug code. This also make the debug info more
readable.
Signed-off-by: Kevin Hao haoke...@gmail.com
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ae2a84b4074cff81957b
cheers
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The function was designed to be called during PHB fixup time.
When configuring PE's DMA32 space in pcibios_setup_bridge(), in
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't have more than 256 PEs. However, pci_dn-pe_number
already had 4-bytes for the PE#.
The patch extends the PE#
On Fri, 2015-24-04 at 08:54:44 UTC, Naveen N. Rao wrote:
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
On Fri, 2015-31-07 at 12:14:20 UTC, Paul Bolle wrote:
wf_find_control(), wf_find_sensor(), and wf_is_overtemp() are exported
but unused. Remove these three functions.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Applied to powerpc next, thanks.
On Mon, 2015-29-06 at 21:30:39 UTC, Joe Perches wrote:
break; break; isn't useful.
Remove one.
Signed-off-by: Joe Perches j...@perches.com
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a825ac078b50266fb091
cheers
___
On Fri, 2015-31-07 at 12:12:20 UTC, Paul Bolle wrote:
wf_critical_overtemp() is exported. But nothing uses that export.
That's unsurprising because there's no header that defines it. Stop
exporting that function and make it static.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Applied to
On Fri, 2015-31-07 at 15:54:38 UTC, Mahesh Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
On non-recoverable MCE errors in kernel space, Linux kernel panics
and system reboots. On BMC based system opal-prd runs as a daemon
in the host. Hence, kernel crash may prevent
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
behavioural changes:
* Rename various fields in struct pnv_phb and struct pnv_ioda_pe
as 32-bits DMA should be related to DMA, not TCE.
s/dma_weight/dma32_weight/ is ok (does
Hi Michael,
Back in the olden days we added support for using 64K pages to map the
SPU (Synergistic Processing Unit) local store on Cell, when the main
kernel was using 4K pages.
This was useful at the time because distros were using 4K pages, but
using 64K pages on the SPUs could reduce
On Tue, 2015-05-05 at 08:05:43 UTC, Mahesh Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
In the event of unrecovered HMI the existing code panics as soon as
it receives the first unrecovered HMI event. This makes host to report
partial information about HMIs before
On Thu, 2015-16-04 at 12:18:50 UTC, weiyj...@163.com wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the functions platform_get_resource() and kmalloc()
returns NULL not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
On Tue, 2015-05-05 at 08:04:58 UTC, Mahesh Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
The V2 version of HMI event now carries additional information for
Malfunction Alert. It now contains error information about CORE and NX
checkstop. This patch checks and displays
On Fri, 2015-31-07 at 12:08:58 UTC, Paul Bolle wrote:
wf_unregister_client() increments the client count when a client
unregisters. That is obviously incorrect. Decrement that client count
instead.
Fixes: 75722d3992f5 ([PATCH] ppc64: Thermal control for SMU based machines)
Signed-off-by:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
On P7IOC, the whole DMA32 space is divided evenly to 256MB segments.
Each PE can consume one or multiple DMA32 segments. Current code
doesn't trace the available DMA32 segments and those consumed by
one particular PE. It's conflicting with PCI hotplug.
From: Viresh Kumar viresh.ku...@linaro.org
Migrate powerpc driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.
This also enables us to implement callbacks for new states of clockevent
devices, for example:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable windows which
happen to be IO, 32bit and 64bit windows but this has nothing to do with
the M32/M64 BAR registers in
On 08/06/2015 02:11 PM, Gavin Shan wrote:
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is divided evenly into 256MB segments. The number
of continuous segments assigned to one particular PE depends on
the PE's DMA weight that is calculated based on the type of each
Hello,
MPC8349 has general IRQ numbered 0-7,
It is required to bind these IRQs with some routine , i.e. they are
not used with any specific driver.
- Should they be configured as gpios in device tree so that we can use
the gpio as irq in linux ? Is there any example ?
- After configuration, can
On 10-08-15, 13:21, Shilpasri G Bhat wrote:
Okay will change the messages.
This series is already applied by Rafael. So send a new patch if there
is any code change. Else, just let it go :)
--
viresh
___
Linuxppc-dev mailing list
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The series of patches intend to support PCI slot for PowerPC PowerNV platform,
which is running on top of skiboot firmware. The patchset requires corresponding
changes from skiboot firmware, which is sent to skib...@lists.ozlabs.org
for review. The PCI
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Different from PHB3 where 16 M64 BARs are supported and each
of them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, each P7IOC PHB has 16 M64 BARs
On Sun, 2015-09-08 at 00:51:35 UTC, Paul Gortmaker wrote:
The Kconfig currently controlling compilation of this code is:
drivers/tty/hvc/Kconfig:config HVC_DRIVER
drivers/tty/hvc/Kconfig:bool
...meaning that it currently is not being built as a module by anyone.
Lets remove the
Hi Stewart,
On 08/10/2015 05:53 AM, Stewart Smith wrote:
Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com writes:
Add OPAL_MSG_OCC message definition to opal_message_type to receive
OCC events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles
On 08/10/2015 07:11 AM, Stewart Smith wrote:
Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com writes:
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index d0c18c9..a634199 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what is
that all about? Also, there was no m64_segmap, now there is, needs an
explanation may be.
the consumed
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Several functions used to configure PE take pe_number to indentify
PE instance. As the pe_number is included in PE instance after it
is reserved or allocated. It's convienent for those functions to
return PE instance which includes the required
On Mon, Aug 10, 2015 at 10:48 AM, Ran Shalit ransha...@gmail.com wrote:
Hello,
MPC8349 has general IRQ numbered 0-7,
It is required to bind these IRQs with some routine , i.e. they are
not used with any specific driver.
- Should they be configured as gpios in device tree so that we can use
From: Hou Zhiqiang b48...@freescale.com
The c293pcie board is an endpoint device and it doesn't need PM,
so remove hooks pcibios_fixup_phb and pcibios_fixup_bus.
Signed-off-by: Hou Zhiqiang b48...@freescale.com
---
Test on c293pcie board:
V2:
Rename the title of this patch.
Remove
-Original Message-
From: Wood Scott-B07421
Sent: 2015年8月1日 1:24
To: Hou Zhiqiang-B48286
Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Hu Mingkai-
B21284; Wang Dongsheng-B40534
Subject: Re: [PATCH] c293/pci: remove hook pcibios_fixup_phb
On Fri, 2015-07-31 at
On 08/06/2015 02:11 PM, Gavin Shan wrote:
This renames the fields related to PE# in struct pnv_phb for
better reflecting of their usages as Alexey suggested. It doesn't
introduce behavioural changes.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Makes sense to move this to the
74 matches
Mail list logo
