On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi wrote:
[cut]
> +static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, unsigned
> long iova)
> +{
> + u32 win_cnt = dma_domain->win_cnt;
> + struct dma_window *win_ptr =
> + &dma_domain->win_arr[0]
On 28/02/13 05:19, Srivatsa S. Bhat wrote:
> On 02/27/2013 06:03 AM, Lai Jiangshan wrote:
>> On Wed, Feb 27, 2013 at 3:30 AM, Srivatsa S. Bhat
>> wrote:
>>> On 02/26/2013 09:55 PM, Lai Jiangshan wrote:
On Tue, Feb 26, 2013 at 10:22 PM, Srivatsa S. Bhat
wrote:
>
> Hi Lai,
>
>
>From c63f2be9a4cf7106a521dda169a0e14f8e4f7e3b Mon Sep 17 00:00:00 2001
From: Lai Jiangshan
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
Current lglock is not read-preference, so it can't be used on some cases
which read-preference rwlock
On 03/01/2013 11:23 PM, Tejun Heo wrote:
> Hey, guys and Oleg (yes, I'm singling you out ;p because you're that
> awesome.)
>
> On Sat, Mar 02, 2013 at 01:44:02AM +0800, Lai Jiangshan wrote:
>> Performance:
>> We only focus on the performance of the read site. this read site's fast path
>> is just
Hi Tejun,
On 03/01/2013 11:40 PM, Tejun Heo wrote:
> Hello, Srivatsa.
>
> On Thu, Feb 28, 2013 at 02:49:53AM +0530, Srivatsa S. Bhat wrote:
>> Don't get me wrong - I'll whole-heartedly acknowledge and appreciate if
>> _your_ code is better than mine. I just don't like the idea of somebody
>> plag
On 03/01/2013 11:20 PM, Lai Jiangshan wrote:
> On 28/02/13 05:19, Srivatsa S. Bhat wrote:
>> On 02/27/2013 06:03 AM, Lai Jiangshan wrote:
>>> On Wed, Feb 27, 2013 at 3:30 AM, Srivatsa S. Bhat
>>> wrote:
On 02/26/2013 09:55 PM, Lai Jiangshan wrote:
> On Tue, Feb 26, 2013 at 10:22 PM, Sriva
Lai, I didn't read this discussion except the code posted by Michel.
I'll try to read this patch carefully later, but I'd like to ask
a couple of questions.
This version looks more complex than Michel's, why? Just curious, I
am trying to understand what I missed. See
http://marc.info/?l=linux-kern
Hello, Srivatsa.
On Thu, Feb 28, 2013 at 02:49:53AM +0530, Srivatsa S. Bhat wrote:
> Don't get me wrong - I'll whole-heartedly acknowledge and appreciate if
> _your_ code is better than mine. I just don't like the idea of somebody
> plagiarizing my ideas/code (or even others' ideas for that matter
Hey, guys and Oleg (yes, I'm singling you out ;p because you're that
awesome.)
On Sat, Mar 02, 2013 at 01:44:02AM +0800, Lai Jiangshan wrote:
> Performance:
> We only focus on the performance of the read site. this read site's fast path
> is just preempt_disable() + __this_cpu_read/inc() + arch_sp
> -Original Message-
> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> Sent: Friday, March 01, 2013 4:07 AM
> To: Sethi Varun-B16395
> Cc: Kumar Gala; Benjamin Herrenschmidt; io...@lists.linux-foundation.org;
> linuxppc-dev@lists.ozlabs.org
> list; linux-ker...@vger.kernel.org list;
The patch adds the backend to enable or disable EEH functionality
for the specified PE. The backend is also used to enable MMIO or
DMA path for the problematic PE. It's notable that all PEs on
PowerNV platform support EEH functionality by default, and we
disallow to disable EEH for the specific PE.
The patch adds the I/O chip backend to do PE reset. For now, we
focus on PCI bus dependent PE. If PHB PE has been put into error
state, the PHB will take complete reset. Besides, the root bridge
will take fundamental or hot reset accordingly if the indicated
PE locates at the toppest of PCI hierarc
The EEH error interrupts should have been exported by firmware
through device tree. The OS already installed the interrupt
handler (opal_interrupt()) for them. The patch checks if we have
any existing EEH errors and wakes the kernel thread up to process
that if possible.
Signed-off-by: Gavin Shan
For EEH on PowerNV platform, the overall architecture is a bit
different from that on pSeries platform. In order to support multiple
I/O chips in future, we split EEH to 3 layers for PowerNV platform:
EEH core, platform layer, I/O layer. It would give EEH implementation
on PowerNV much more flexibi
On PowerNV platform, the EEH event is produced either by detect
on accessing config or I/O registers, or by interrupts dedicated
for EEH report. The patch adds support to process the interrupts
dedicated for EEH report.
Firstly, the kernel thread will be waken up to process incoming
interrupt. The
The post initialization (struct eeh_ops::post_init) is called after
the EEH probe is done. On the other hand, the EEH core post initialization
is designed to call platform and then I/O chip backend on PowerNV
platform.
The patch adds the backend for I/O chip to notify the platform
the specific PHB
The patch enables EEH check and let EEH core to process the EEH
errors for PowerNV platform while accessing config space. Originally,
the implementation already had mechanism to check EEH errors and
tried to recover from them. However, we never let EEH core to handle
the EEH errors.
Signed-off-by:
The patch adds EEH backends for PowerNV platform. It's notable that
part of those EEH backends call to the I/O chip dependent backends.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/Makefile |2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c | 373 ++
The patch initializes EEH for PowerNV platform. Because the OPAL
APIs requires HUB ID, we need trace that through struct pnv_phb.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 +++--
arch/powerpc/platforms/powernv/pci-p5ioc2.c |6 --
2 files cha
The patch adds backends to retrieve error log and configure p2p
bridges for the indicated PE.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 57 -
1 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/power
The patch adds I/O chip backend to retrieve the state for the
indicated PE. While the PE state is temperarily unavailable,
we return the default wait time (1000ms).
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 104 -
1 files changed, 103
The patch synchronizes OPAL APIs between kernel and firmware.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/opal.h| 110 +++
arch/powerpc/platforms/powernv/opal-wrappers.S |2 +
2 files changed, 93 insertions(+), 19 deletions(-)
diff --git a/arc
The EEH event is usually produced because of 0xFF's returned from
PCI config or I/O registers. PowerNV platform also can produce EEH
event through interrupts. The patch differentiates the EEH events
produced for different cases in order to process them differently
in future.
Signed-off-by: Gavin S
While doing EEH recovery, the PCI devices of the problematic PE
should be removed and then added to the system again. During the
so-called hotplug event, the PCI devices of the problematic PE
will be probed through early/late phase. We would delay EEH probe
on late point for PowerNV platform since
The patch changes the criteria used to judge if the PE has been
resetted successfully. We needn't the PE status is equal to the
combo: (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE).
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/pseries/eeh.c |4 ++--
1 files changed, 2 insertions(+),
Under some special circumstances, the EEH device doesn't have the
associated device tree node or PCI device. It is caused by the
PCI device corresponding to the device tree node can't support
EEH function.
The patch enhances converting EEH device to device tree node or
PCI device accordingly to av
Initially, the series of patches is built based on 3.8+
The series of patches intends to support EEH for PowerNV platform. The EEH
core already supports multiple probe methods: device tree nodes and PCI
devices. For EEH on PowerNV, we're using PCI devices to do EEH probe, which
is different from t
The patch adds new EEH operation post_init. It's used to notify
the platform that EEH core has completed the EEH probe. Through
that, PowerNV will enable EEH eventually.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h |1 +
arch/powerpc/platforms/pseries/eeh.c | 11 +
While processing EEH event caused by interrupt sent from P7IOC,
we need function to retrieve the PE according to the indicated
EEH device.
The patch makes function eeh_pe_get() public so that other source
files can call it. Also, the patch fixes referring to wrong BDF
(Bus/Device/Function) address
For EEH on PowerNV platform, the PCI devices will be probed to
check if they support EEH functionality. Different from the case
of EEH for pSeries platform, we will probe real PCI device instead
of device tree node for EEH capability on PowerNV platform.
The patch introduces function eeh_pci_dev_t
There're several types of PEs can be supported for now: PHB, Bus
Device. For PCI bus dependent PE, tracing the corresponding PCI
bus from PE (struct eeh_pe) would make the code more efficient.
The patch also enables the retrieval of PCI bus based on the
PCI device dependent PE.
Signed-off-by: Gav
While processing EEH event caused by interrupt sent from P7IOC,
we need function to retrieve the PE according to the indicated
PCI host controller (struct pci_controller).
The patch makes function eeh_phb_pe_get() public so that other
source files can call it.
Signed-off-by: Gavin Shan
---
arch
For EEH on PowerNV platform, we will do EEH probe based on the
real PCI devices. The PCI devices are available after PCI probe.
So we have to call eeh_init() explicitly on PowerNV platform
after PCI probe.
The patch also enables eeh_init() to do EEH probe for PowerNV
platform.
Signed-off-by: Gavi
Hi Srivatsa,
I have run some tests with genload on my ARM platform but even with
the mainline the cpu_down is quite short and stable ( around 4ms )
with 5 or 2 online cores. The duration is similar with your patches
I have maybe not used the right option for genload ? I have used
genload -m 10 w
btw the device struct already has a pointer to its iommu_group, and the
iommu_group struct itself has a pointer void *iommu_data which you could
use for anything you want (iommu_group_get_iommudata(),
iommu_group_set_iommudata()).
By design you are expected to add iommu groups to a domain but
Thanks for the clarification Alexey.
Kumar,
We are using this new field (for PAMU) to store the iommu domain (for iommu
API) information for a device.
Regards
Varun
> -Original Message-
> From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru]
> Sent: Friday, March 01, 2013 6:55 AM
> To: Kum
36 matches
Mail list logo
