On 11/05/2015 12:12 AM, Gavin Shan wrote:
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup() except those used by SRIOV VFs. The
function is called for once after PCI probing and resources
assignment is completed. So it isn't hotplug friendly.
This creates P
On 11/05/2015 12:12 AM, Gavin Shan wrote:
We're going to reserve/assign PEs when pcibios_setup_bridge() is
called. The function won't be called for root bus as it doesn't
have parent bridge. However, the root bus still needs a PE to be
covered.
This reserves PE numbers that are adjacent to the r
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In current implementation, the PEs that are allocated or picked
from the reserved list are identified by PE number. The PE instance
has to be picked according to the PE number eventually. We have
same issue when PE is released.
For pnv_ioda_pick_m64_pe()
On 11/17/2015 02:04 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 01:37:22PM +1100, Alexey Kardashevskiy wrote:
On 11/17/2015 12:42 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on
On Tue, 2015-11-17 at 14:04 +1100, Gavin Shan wrote:
>
> Sorry, you mean it's fine to break the code on P7IOC as it's going to be dead.
> But I'm curious when it's going happen, any idea about that?
Is it ? I think it's ok to not add support for M64, hotpug etc for
IODA1, but we can do that w
On Tue, Nov 17, 2015 at 01:37:22PM +1100, Alexey Kardashevskiy wrote:
>On 11/17/2015 12:42 PM, Gavin Shan wrote:
>>On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote:
>>>On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
On Tue, Nov 17, 2015 at 01:37:33PM +1100, Alexey Kardashevskiy wrote:
>On 11/17/2015 12:58 PM, Gavin Shan wrote:
>>On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
>>>Gavin Shan writes:
>>>
This introduces pnv_ioda_init_pe() to initialize the specified PE
instance (phb->ioda.
On Tue, Nov 17, 2015 at 01:11:56PM +1100, Alexey Kardashevskiy wrote:
>On 11/17/2015 12:38 PM, Gavin Shan wrote:
>>On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
>>>On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
On 11/17/2015 12:58 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
Gavin Shan writes:
This introduces pnv_ioda_init_pe() to initialize the specified PE
instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
and pnv_ioda_reserve_pe(). No logica
On 11/17/2015 12:42 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This 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
Hi,
Any response, please comment.
> -Original Message-
> From: Zhiqiang Hou [mailto:zhiqiang@freescale.com]
> Sent: 2015年11月5日 11:16
> To: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; b...@kernel.crashing.org; pau...@samba.org;
> m...@ellerman.id.au;
On 11/17/2015 12:38 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This 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
On Mon, 2015-11-16 at 11:26 -0600, Rob Herring wrote:
> +Sudeep
>
> On Mon, Oct 26, 2015 at 02:44:12PM +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng
> >
> > RCPM is the Run Control and Power Management module performs all
> > device-level tasks associated with device run control and powe
On Tue, Nov 17, 2015 at 12:54:04PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according
>>to their DMA32 weight. The PEs on the list are iterated to setup
>>their TCE32 tables at system booting time. The li
On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> This introduces pnv_ioda_init_pe() to initialize the specified PE
>> instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
>> and pnv_ioda_reserve_pe(). No logical changes introduced.
>>
>> Signed-
On Tue, Nov 17, 2015 at 11:29:26AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> Each PHB maintains an array helping to translate 2-bytes Request
>> ID (RID) to PE# with the assumption that PE# takes one byte, meaning
>> that we can't have more than 256 PEs. However, pci_dn->pe_number
>> al
On Tue, Nov 17, 2015 at 11:28:20AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> Similar to the mechanism tracking consumed IO/M32/M64 segments,
>> this introduces an array for each PHB to track the consumed DMA32
>> segments, which are going to be released on PCI unplugging time.
>> The in
On 11/05/2015 12:12 AM, Gavin Shan wrote:
PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according
to their DMA32 weight. The PEs on the list are iterated to setup
their TCE32 tables at system booting time. The list is used for
once and there is no good reason for it to survive.
From t
On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This 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# exclusivel
On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This 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# exclusivel
On Mon, Nov 16, 2015 at 07:01:46PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This 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# exclusivel
On Mon, Nov 16, 2015 at 07:01:43PM +1100, Alexey Kardashevskiy wrote:
>On 11/12/2015 03:55 PM, Gavin Shan wrote:
>>On Thu, Nov 12, 2015 at 02:30:27PM +1100, Daniel Axtens wrote:
>>>Hi Gavin,
>>>
>>>Sorry to have taken so long to resume these reviews!
>>>
>>
>>Thanks for your review, Daniel!
>>
On Mon, Nov 16, 2015 at 07:01:06PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>This renames the fields related to PE number in "struct pnv_phb"
>>for better reflecting of their usages as Alexey suggested. No
>>logical changes introduced.
>>
>>Signed-off-by: Gavin
On Mon, Nov 16, 2015 at 07:01:18PM +1100, Alexey Kardashevskiy wrote:
>On 11/06/2015 10:52 AM, Gavin Shan wrote:
>>On Fri, Nov 06, 2015 at 09:56:06AM +1100, Daniel Axtens wrote:
>>>Gavin Shan writes:
>>>
The original implementation of pnv_ioda_setup_pe_seg() configures
IO and M32 segments
On Mon, Nov 16, 2015 at 07:01:59PM +1100, Alexey Kardashevskiy wrote:
>On 11/05/2015 12:12 AM, Gavin Shan wrote:
>>As we track M32 segment consumption, this introduces an array to
>>the PHB to track the mapping between M64 segment and PE number.
>>The information is going to be used to find M64 seg
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In pnv_ioda_setup_dma(), it's unnecessary to calculate the DMA32
segments for PEs on PHB3 as the whole available DMA32 space can
be assigned to one specific PE on PHB3.
This splits pnv_ioda_setup_dma() to pnv_pci_ioda1_setup_dma() and
pnv_pci_ioda2_setup
Gavin Shan writes:
> This introduces pnv_ioda_init_pe() to initialize the specified PE
> instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
> and pnv_ioda_reserve_pe(). No logical changes introduced.
>
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c
Gavin Shan writes:
> Each PHB maintains an array helping to translate 2-bytes Request
> ID (RID) to PE# with the assumption that PE# takes one byte, meaning
> that we can't have more than 256 PEs. However, pci_dn->pe_number
> already had 4-bytes for the PE#.
>
> This extends the PE# capacity so t
Gavin Shan writes:
> Similar to the mechanism tracking consumed IO/M32/M64 segments,
> this introduces an array for each PHB to track the consumed DMA32
> segments, which are going to be released on PCI unplugging time.
> The index of the array is the DMA32 segment number while the value
> stored
On Mon, 2015-11-16 at 15:34 -0600, Suresh E. Warrier wrote:
> Hi Mike,
>
> The changes you proposed look nicer than what I have here.
> I will get that coded and tested and re=submit.
Thanks.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz
Hi,
> > +{
> > + if (val & (MSR_TM | MSR_TS_S | MSR_TS_T)) {
> > + printk(",TM[");
> > + printbits(val, msr_tm_bits, "");
> > + printk("]");
>
> I suspect all these individual printks are going to behave badly if
> we have multiple cpus crashing simultaneously. But
Hi Mike,
The changes you proposed look nicer than what I have here.
I will get that coded and tested and re=submit.
Thanks.
-suresh
On 11/15/2015 11:53 PM, Michael Ellerman wrote:
> Hi Suresh,
>
> On Thu, 2015-29-10 at 23:40:45 UTC, "Suresh E. Warrier" wrote:
>> This function supports IPI messa
+Sudeep
On Mon, Oct 26, 2015 at 02:44:12PM +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
>
> RCPM is the Run Control and Power Management module performs all
> device-level tasks associated with device run control and power
> management.
>
> Add this for freescale powerpc platform and lay
I've had these patches sitting in my randconfig branch for a while,
but have now gotten around to sending them. The first three are
bug fixes for harmless problems that have shown up recently,
so they should go into 4.4.
The other three are part of a cleanup that we've been meaning
to do for a whi
The NWP serial driver is no longer needed, as the two users of
this hardware have migrated to a much faster generation hardware,
see https://en.wikipedia.org/wiki/QPACE2 for the replacement.
Signed-off-by: Arnd Bergmann
Cc: Benjamin Krill
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/serial
On 11/13/15, Laura Abbott wrote:
> Hi,
>
> There seem to be section mismatches coming from head_64.S
>
> WARNING: vmlinux.o(.text+0x8994): Section mismatch in reference from the
> variable __boot_from_prom to the function .init.text:prom_init()
> The function __boot_from_prom() references
> the fu
On Fri, 2015-11-13 at 15:57 +1100, Michael Neuling wrote:
> Test the kernel's signal return code to ensure that it doesn't crash
> when both the transactional and suspend MSR bits are set in the signal
> context.
>
> Signed-off-by: Michael Neuling
> ---
> tools/testing/selftests/powerpc/tm/Make
On Mon, 2015-11-16 at 20:33 +1100, Michael Ellerman wrote:
> On Mon, 2015-11-16 at 20:23 +1100, Michael Neuling wrote:
> > On Mon, 2015-11-16 at 12:51 +0530, Anshuman Khandual wrote:
> > > On 11/13/2015 10:27 AM, Michael Neuling wrote:
> > > > Currently we can hit a scenario where we'll tm_reclaim(
On Fri, 2015-11-13 at 15:57 +1100, Michael Neuling wrote:
> Currently we allow both the MSR T and S bits to be set by userspace on
> a signal return. Unfortunately this is a reserved configuration and
> will cause a TM Bad Thing exception if attempted (via rfid).
>
> This patch checks for this c
On Fri, 2015-11-13 at 15:57 +1100, Michael Neuling wrote:
> get_tm_stackpointer() gets the userspace stack pointer which the
> signal frame will be written from pt_regs. To do this it performs a
> tm_reclaim to access the checkpointed stack pointer.
>
> Doing a tm_reclaim is an important operatio
On Mon, 2015-11-16 at 20:23 +1100, Michael Neuling wrote:
> On Mon, 2015-11-16 at 12:51 +0530, Anshuman Khandual wrote:
> > On 11/13/2015 10:27 AM, Michael Neuling wrote:
> > > Currently we can hit a scenario where we'll tm_reclaim() twice.
> > > This
> > > results in a TM bad thing exception bec
On Fri, 2015-11-13 at 15:57 +1100, Michael Neuling wrote:
> Print the MSR TM bits in oops messages. This appends them to the end
> like this:
> MSR: 800502823031
>
> You get the TM[] only if at least one TM MSR bit is set. Inside the
> TM[], E means Enabled (bit 32), S means Suspended (bi
On Mon, 2015-11-16 at 12:51 +0530, Anshuman Khandual wrote:
> On 11/13/2015 10:27 AM, Michael Neuling wrote:
> > Currently we can hit a scenario where we'll tm_reclaim() twice.
> > This
> > results in a TM bad thing exception because the second reclaim
> > occurs
> > when not in suspend mode.
> >
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This 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, every P7IOC PHB has 16 M64 BARs and ea
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This 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, every P7IOC PHB has 16 M64 BARs and ea
On 11/05/2015 12:12 AM, Gavin Shan wrote:
As we track M32 segment consumption, this introduces an array to
the PHB to track the mapping between M64 segment and PE number.
The information is going to be used to find M64 segment from the
PE number during PCI unplugging time in subsequent patches.
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This 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, every P7IOC PHB has 16 M64 BARs and ea
On 11/12/2015 03:55 PM, Gavin Shan wrote:
On Thu, Nov 12, 2015 at 02:30:27PM +1100, Daniel Axtens wrote:
Hi Gavin,
Sorry to have taken so long to resume these reviews!
Thanks for your review, Daniel!
Currently, the IO and M32 segments are mapped to the corresponding
PE based on the windows
On 11/06/2015 10:52 AM, Gavin Shan wrote:
On Fri, Nov 06, 2015 at 09:56:06AM +1100, Daniel Axtens wrote:
Gavin Shan writes:
The original implementation of pnv_ioda_setup_pe_seg() configures
IO and M32 segments by separate logics, which can be merged by
by caching @segmap, @seg_size, @win in a
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This renames the fields related to PE number in "struct pnv_phb"
for better reflecting of their usages as Alexey suggested. No
logical changes introduced.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
arch/powerp
50 matches
Mail list logo
