On Thu, Apr 04, 2013 at 11:55:56AM +0530, Viresh Kumar wrote:
> On 3 April 2013 16:00, Benjamin Herrenschmidt
> wrote:
> > On Wed, 2013-04-03 at 15:00 +0530, Viresh Kumar wrote:
> >> On 31 March 2013 09:33, Viresh Kumar wrote:
>
> >> > Benjamin/Paul/Olof,
> >> >
> >> > Any comments on this?
> >
On 11 April 2013 12:29, Olof Johansson wrote:
> That's not very nice this late in the staging cycle. Give the powerpc
> guys a little more time than a single day to come back with test results,
> please.
Yes we are waiting indefinitely for an Ack from powerpc guys.. If we can
get a Ack soon, we w
On Thu, Apr 04, 2013 at 11:27:42AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> This make one PMD cover 16MB range. That helps in easier implementation of THP
> on power. THP core code make use of one pmd entry to track the hugepage and
> the range mapped by a single pmd entry sh
David Gibson writes:
> On Thu, Apr 04, 2013 at 11:27:55AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> We now have pmd entries covering to 16MB range. To implement THP on powerpc,
>> we double the size of PMD. The second half is used to deposit the pgtable
>> (PTE page).
>>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, April 11, 2013 5:52 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood Scott-
> B07421; Li Yang-R58472; Jia Hongtao-B38951
> Subject: Re: [PATCH V5] powerpc/85xx: Add machine che
A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
goes down. when the link goes down, Non-posted transactions issued
via the ATMU requiring completion result in an instruction stall.
At the same time a machine-check exception is generated to the core
to allow further processing b
Le 04/11/13 11:29, Sebastian Hesselbarth a écrit :
With introduction of common clock framework and the ability to provide
gated clocks, mv643xx_eth required calls to get and enable these clock
gates on some platforms. Back then, common clock framework api wasn't
safe for architectures without sup
MMU registers were exposed to user-space using sregs interface. Add them
to ONE_REG interface using kvmppc_get_one_reg/kvmppc_set_one_reg delegation
mechanism.
Signed-off-by: Mihai Caraman
---
v3:
- Fix case breaks
v2:
- Restrict set_one_reg operation for MMU registers to HW values
Document
Add support for TLBnPS registers available in MMU Architecture Version
(MAV) 2.0.
Signed-off-by: Mihai Caraman
---
v3:
- Add vcpu_ftr enum
v2:
- Add vcpu generic function has_feature()
Documentation/virtual/kvm/api.txt |4
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerp
Vcpu's MMU default configuration and geometry update logic was buried in
a chunk of code. Move them to dedicated functions to add more clarity.
Signed-off-by: Mihai Caraman
---
v3:
- No change
v2:
- Add better patch description
arch/powerpc/kvm/e500_mmu.c | 60 +++--
Enable basic support for Freescale e6500 core, adding MAV 2.0 support.
Validated on T4240QDS platfrom. Altivec, Multithreading and HW Tablewalk
are not addressed by this patchset.
Mihai Caraman (8):
KVM: PPC: Book3E: Refactor ONE_REG ioctl implementation
KVM: PPC: e500: Expose MMU registers vi
Refactor Book3E ONE_REG ioctl implementation to use kvmppc_get_one_reg/
kvmppc_set_one_reg delegation interface introduced by Book3S. This is
necessary for MMU SPRs which are platform specifics.
Get rid of useless case braces in the process.
Signed-off-by: Mihai Caraman
---
v3:
- Split ONE_REG
EPTCFG register defined by E.PT is accessed unconditionally by Linux guests
in the presence of MAV 2.0. Emulate it now.
Signed-off-by: Mihai Caraman
---
v3:
- Initialize EPTCFG to 0 since E.PT is not supported now
Documentation/virtual/kvm/api.txt |1 +
arch/powerpc/include/asm/kvm_host.
Embedded.Page Table (E.PT) category is not supported yet in e6500 kernel.
Configure TLBnCFG to remove E.PT and E.HV.LRAT categories from VCPUs.
Signed-off-by: Mihai Caraman
---
v3:
- No change
arch/powerpc/kvm/e500_mmu.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Add e6500 core to Kconfig description.
Signed-off-by: Mihai Caraman
---
v3:
- No change
arch/powerpc/kvm/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 63c67ec..4489520 100644
--- a/arch/powerpc/kv
Extend processor compatibility names to e6500 cores.
Signed-off-by: Mihai Caraman
Reviewed-by: Alexander Graf
---
v3:
- No change
arch/powerpc/kvm/e500mc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index ab0
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform this
detection and a hook to perform dynamic adding of the function only for
pseries.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/include/asm/mac
After all the comments in the last patch series, I did a refactoring of what I
was proposing and came up with this. Basically, now:
1. max_bus_speed is used to set the device to gen2 speeds
2. on power there's no longer a conflict between the pseries call and other
architectures, because the
Hi,
On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
>
> Signed-off-by: Soeren Moch
> Signed-off-by: Sebastian Hesselbarth
> ---
> Cc: "David S. Miller"
> Cc:
On Apr 10, 2013, at 8:32 PM, Kevin Hao wrote:
> Hi,
>
> With the rework of the lazy EE, it seems that 64bit kernel works pretty
> well on mpc85xx 64bit boards with lazy EE enabled. So this patch series
> tries to enable the coreint for these boards by default. This passed
> the ltp test on a t42
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
Signed-off-by: David Howells
cc: Li Yang
cc: Felipe Balbi
cc: Greg Kroah-Hartman
cc: linux-...@vger.kernel.org
cc: linuxppc-dev@lists.ozlabs.org
---
drivers/usb/gadget/fsl_udc_co
On Apr 10, 2013, at 10:43 PM, Vakul Garg wrote:
> Removing qoriq-sec4.1-0.dtsi as it is not used by any soc anymore.
>
> Signed-off-by: Vakul Garg
> ---
> arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi | 109 -
> 1 files changed, 0 insertions(+), 109 deletions(-)
> delete
On Apr 10, 2013, at 10:45 PM, Vakul Garg wrote:
> The crypto node now contains a new property 'fsl,sec-era'.
> This is required so that applications can retrieve era info without
> having to be able to read SEC's register space.
>
> Signed-off-by: Vakul Garg
> ---
> Changelog:
>
> v2: Ad
On Apr 10, 2013, at 5:40 PM, Scott Wood wrote:
> From: Roy ZANG
>
> Some 85xx board, for example, P1020RDB-PC has on board silicon image
> PCIe to SATA controller and when booting up, the filesystem will auto mount
> to the SATA disk. So enable silicon image 3132 pcie to sata controller
> by de
On Apr 10, 2013, at 4:58 PM, Kim Phillips wrote:
> From: Kumar Gala
>
> The localbus node should be in at 0xfffe05000 not 0xffe05000. Also
> fixed the names of the localbus and pci nodes to reflect the addresses
> they are actually at.
>
> Signed-off-by: Kumar Gala
> Signed-off-by: Kim Phill
On Apr 11, 2013, at 3:36 AM, Jia Hongtao wrote:
> A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
> goes down. when the link goes down, Non-posted transactions issued
> via the ATMU requiring completion result in an instruction stall.
> At the same time a machine-check except
On 04/11/2013 04:14:51 AM, Jia Hongtao-B38951 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, April 11, 2013 5:52 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood
Scott-
> B07421; Li Yang-R58472; Jia Hongtao-B389
Hi Sebastian,
On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> I did some simple tests on Dove/Cubox with 'netperf -cCD' and
> gso/gro/lro options on
> mv643xx_eth. The tests may not be sufficient, as I am not that into
> net performance testing.
In fact the difference onl
On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> I don't have a strong opinion on whether Soeren's or your proposal should
> be submitted. But I insist on having one of them in, as GRO significantly
> improves the common use case, is enabled by default, and not as
> constrai
Hi all,
We've got a powerpc system that uses u-boot. In our environment on
bootup u-boot does a DHCP to get networking info, then uses TFTP to get
the kernel, which then does DHCP again and NFS-mounts the initial root
filesystem.
What's the standard practice for this sort of thing when usi
On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves t
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
>
> Signed-off-by: Soeren Moch
> Signed-off-by: Sebastian Hesselbarth
> ---
> Cc: "David S. Miller"
> Cc: Lennert Buy
On Thu, Apr 11, 2013 at 08:54:35AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > > I don't have a strong opinion on whether Soeren's or your proposal should
> > > be submitted. But
On Thu, 2013-04-11 at 18:02 +0200, Willy Tarreau wrote:
> OK, that makes sense indeed, I didn't think about this case. All
> I remember was that the old call achieved a higher packet rate
> than napi_gro_receive, but it was on an older kernel and I can't
> be more specifics after several months :-
On Thu, Apr 11, 2013 at 06:59:11PM +0200, Sebastian Hesselbarth wrote:
> On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau wrote:
> > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> >> I don't have a strong opinion on whether Soeren's or your proposal should
> >> be submitted
From: Sebastian Hesselbarth
Date: Thu, 11 Apr 2013 17:27:03 +0200
> On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau wrote:
>> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>>> the initial
>>> patch
On Thu, 2013-04-11 at 13:31 -0400, David Miller wrote:
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.
This would be awesome.
AFAIK current LRO users are :
drivers/infiniband/hw/nes/nes_hw.c
drivers/n
On Thu, Apr 11, 2013 at 01:31:19PM -0400, David Miller wrote:
> From: Sebastian Hesselbarth
> Date: Thu, 11 Apr 2013 17:27:03 +0200
>
> > On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau wrote:
> >> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
> >>> I tried todays net-nex
On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
> Eric provided me with one such experimental patch in the past for this
> driver. It worked for me but we never tried to clean it up to propose
> it for inclusion.
>
> If anyone is interested, I might still have it in experimental shape.
W
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
The inet_lro support should be removed at the same time; inet_lro is now
deprecated and there should be no need to keep
On Thu, Apr 11, 2013 at 10:59:15AM -0700, Eric Dumazet wrote:
> On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
>
> > Eric provided me with one such experimental patch in the past for this
> > driver. It worked for me but we never tried to clean it up to propose
> > it for inclusion.
> >
On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
>
> Hi all,
>
> We've got a powerpc system that uses u-boot. In our environment on bootup
> u-boot does a DHCP to get networking info, then uses TFTP to get the kernel,
> which then does DHCP again and NFS-mounts the initial root filesystem.
On Mar 28, 2013, at 2:53 PM, Varun Sethi wrote:
> Add an iommu domain pointer to device (powerpc) archdata. Devices
> are attached to iommu domains and this pointer provides a mechanism
> to correlate between a device and the associated iommu domain. This
> field is set when a device is attache
On Apr 5, 2013, at 2:53 AM, Bhushan Bharat-R65777 wrote:
> Hi Kumar/Benh,
>
> After further looking into the code I think that if we correct the vector
> range below in DebugDebug handler then we do not need the change I provided
> in this patch.
>
> Here is the snapshot for 32 bit (head_book
On Thu, Apr 11, 2013 at 1:33 PM, Kumar Gala wrote:
>
> On Apr 5, 2013, at 2:53 AM, Bhushan Bharat-R65777 wrote:
>
>> Hi Kumar/Benh,
>>
>> After further looking into the code I think that if we correct the vector
>> range below in DebugDebug handler then we do not need the change I provided
>> in
On 04/11/2013 12:12 PM, Kumar Gala wrote:
On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
Hi all,
We've got a powerpc system that uses u-boot. In our environment on
bootup u-boot does a DHCP to get networking info, then uses TFTP to
get the kernel, which then does DHCP again and NFS-moun
So the patch should look something like this (on a 3.8 kernel):
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 5f051ee..92b675a 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -286,13 +286,13 @@ label:
andis.
On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
> With recent support for GRO, there is no need to keep both LRO and
> GRO. This patch therefore removes the deprecated inet_lro support
> from mv643xx_eth. This is work is based on an experimental patch
> provided by Eric Dumazet and
On Thu, Apr 11, 2013 at 12:39:00PM -0600, Chris Friesen wrote:
> On 04/11/2013 12:12 PM, Kumar Gala wrote:
> >
> > On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
> >
> >>
> >> Hi all,
> >>
> >> We've got a powerpc system that uses u-boot. In our environment on
> >> bootup u-boot does a DHCP to
On 04/11/2013 01:50 PM, Ira W. Snyder wrote:
I use a hardware setup which sounds similar to yours. The DHCP server
controls which file is sent to each card.
I use the FIT image format to combine a kernel, dtb, and initrd in one
package.
I used the U-Boot doc/uImage.FIT/*.its examples to get
From: Sebastian Hesselbarth
Date: Thu, 11 Apr 2013 11:29:32 +0200
> With introduction of common clock framework and the ability to provide
> gated clocks, mv643xx_eth required calls to get and enable these clock
> gates on some platforms. Back then, common clock framework api wasn't
> safe for ar
From: Sebastian Hesselbarth
Date: Thu, 11 Apr 2013 14:40:23 +0200
> This patch adds GRO support to mv643xx_eth by making it invoke
> napi_gro_receive instead of netif_receive_skb.
>
> Signed-off-by: Soeren Moch
> Signed-off-by: Sebastian Hesselbarth
Applied.
__
On Thursday, April 11, 2013 12:32:50 PM Viresh Kumar wrote:
> On 11 April 2013 12:29, Olof Johansson wrote:
> > That's not very nice this late in the staging cycle. Give the powerpc
> > guys a little more time than a single day to come back with test results,
> > please.
>
> Yes we are waiting in
On 04/11/2013 08:21:24 AM, Kumar Gala wrote:
On Apr 10, 2013, at 8:32 PM, Kevin Hao wrote:
> Hi,
>
> With the rework of the lazy EE, it seems that 64bit kernel works
pretty
> well on mpc85xx 64bit boards with lazy EE enabled. So this patch
series
> tries to enable the coreint for these boa
On Mon, Mar 18, 2013 at 08:26:48AM +1100, Paul Mackerras wrote:
> On Sat, Mar 16, 2013 at 12:50:49AM +0800, Lai Jiangshan wrote:
> > At the point of up_out label in kvmppc_hv_setup_htab_rma(),
> > srcu read lock is still held.
> >
> > We have to release it before return.
> >
> > Signed-off-by: La
Hi,
I'm looking at user_enable_block_step() in current kernels and it has
the following:
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
task->thread.dbcr0 &= ~DBCR0_IC;
task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
regs->msr |= MSR_DE;
Should it be as follows?
Hi all,
Sorry for the bunch of emails, I'm working on some new stuff and running
into issues.
For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP
but not DBCR0_BRT. Is that just because none of the code paths
currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?
With introduction of common clock framework and the ability to provide
gated clocks, mv643xx_eth required calls to get and enable these clock
gates on some platforms. Back then, common clock framework api wasn't
safe for architectures without support for common clocks. This has
changed now and ther
This patch adds an optional shared block clock to avoid lockups on
clock gated controllers. Besides the new clock, clock handling for
existing clocks is cleaned up and moved to devm_clk_get. Device
tree binding documentation is updated for the new clocks property.
Signed-off-by: Sebastian Hesselba
This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.
Signed-off-by: Sebastian Hesselbarth
---
Changes from v1:
- replaced EADDRNOTAVAIL with ENOMEM on failing ioremap (Reported by
Sergei Shtylyov)
Cc: Grant Likely
Cc: Rob H
This patch adds GRO support to mv643xx_eth by making it invoke
napi_gro_receive instead of netif_receive_skb.
Signed-off-by: Soeren Moch
Signed-off-by: Sebastian Hesselbarth
---
Cc: "David S. Miller"
Cc: Lennert Buytenhek
Cc: Andrew Lunn
Cc: Jason Cooper
Cc: Florian Fainelli
Cc: Benjamin He
When using recent udev, the /dev node mount requires CONFIG_DEVTMPFS_MOUNT
is enabled in Kernel. The patch enables the option in defconfig of Freescale
QorIQ targets.
Changed defconfig list:
arch/powerpc/configs/85xx/p1023rds_defconfig
arch/powerpc/configs/corenet32_smp_defconfig
arch/pow
On Thu, Apr 11, 2013 at 3:13 PM, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote:
>> This patch adds GRO support to mv643xx_eth by making it invoke
>> napi_gro_receive instead of netif_receive_skb.
>>
>> Signed-off-by: Soeren Moch
>> Signed-off-by: Seb
On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote:
>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with
>> the initial
>> patch (Soeren) and your proposed patch (Willy). The results show that
>> both pa
On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
>> I don't have a strong opinion on whether Soeren's or your proposal should
>> be submitted. But I insist on having one of them in, as GRO significantly
>> improves the c
On 04/11/2013 07:55 PM, Ben Hutchings wrote:
On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote:
This patch adds GRO support to mv643xx_eth by making it invoke
napi_gro_receive instead of netif_receive_skb.
The inet_lro support should be removed at the same time; inet_lro is now
de
With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.
Signed-off-by: Sebastian Hesselbarth
Based-on-patch-by:
On 04/11/2013 09:46 PM, Eric Dumazet wrote:
On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimen
On Thu, Apr 11, 2013 at 01:10:29PM +0530, Aneesh Kumar K.V wrote:
> David Gibson writes:
>
> > On Thu, Apr 04, 2013 at 11:27:55AM +0530, Aneesh Kumar K.V wrote:
> >> From: "Aneesh Kumar K.V"
> >>
> >> We now have pmd entries covering to 16MB range. To implement THP on
> >> powerpc,
> >> we dou
On Thu, Apr 04, 2013 at 11:27:59AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/perf/callchain.c | 32 +---
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/perf
On Thu, Apr 04, 2013 at 11:27:57AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> HUGETLB clear the top bit of PMD entries and use that to indicate
> a HUGETLB page directory. Since we store pfns in PMDs for THP,
> we would have the top bit cleared by default. Add the top bit mask
On Thu, Apr 04, 2013 at 11:28:00AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> handle large pages for get_user_pages_fast. Also take care of large page
> splitting.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/mm/gup.c | 84
> ++
Hi Michael,
Here is the updated version, could you please help to review it again?
As you suggested, this version didn't copy the code, but splitted
the logic into a helper function, so both kernel_map_linear_page() and
__hash_page_huge() can use.
Also patch #1 moves some unnecessary code ou
Move the logical trying to insert hpte in __hash_page_huge() to an helper
function, so it could also be used by others.
Signed-off-by: Li Zhong
---
arch/powerpc/mm/hash_utils_64.c | 35 ++
arch/powerpc/mm/hugetlbpage-hash64.c | 31 ++--
It seems that rflags don't get changed in the repeating loop, so move
it out of the loop.
Signed-off-by: Li Zhong
---
arch/powerpc/mm/hugetlbpage-hash64.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c
b/arch/powerpc/mm/huget
It seems that in kernel_unmap_linear_page(), it only checks whether there
is a map in the linear_map_hash_slots array, so seems we don't need bolt
the hpte.
Signed-off-by: Li Zhong
---
arch/powerpc/mm/hash_utils_64.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/pow
This patch tries to fix following issue when CONFIG_DEBUG_PAGEALLOC
is enabled:
[ 543.075675] [ cut here ]
[ 543.075701] kernel BUG at arch/powerpc/mm/hash_utils_64.c:1239!
[ 543.075714] Oops: Exception in kernel mode, sig: 5 [#1]
[ 543.075722] PREEMPT SMP NR_CPUS=16 DE
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Thursday, April 11, 2013 9:47 PM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
> Subject: Re: [PATCH V6] powerpc/85xx: Add machine check handler to fix
> PCI
Hi Kumar,
Scott reviewed this patch and MSI errata patch for weeks.
Here is the link for MSI errata patch:
http://patchwork.ozlabs.org/patch/233211/
Could you please have a review and ACK them if they
look good to you too?
Thanks.
- Hongtao
> -Original Message-
> From: Jia Hongtao-B389
On Thu, Apr 04, 2013 at 11:27:58AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> We now have pmd entries covering to 16MB range. To implement THP on powerpc,
> we double the size of PMD. The second half is used to deposit the pgtable
> (PTE page).
> We also use the depoisted PTE
On Thu, Apr 04, 2013 at 11:28:02AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> Hugepage invalidate involves invalidating multiple hpte entries.
> Optimize the operation using H_BULK_REMOVE on lpar platforms.
> On native, reduce the number of tlb flush.
>
> Signed-off-by: Aneesh
David Gibson writes:
> On Thu, Apr 04, 2013 at 11:27:59AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>> arch/powerpc/perf/callchain.c | 32 +---
>> 1 file changed, 21 insertions(+), 11 deletions(-)
>>
David Gibson writes:
> On Thu, Apr 11, 2013 at 01:10:29PM +0530, Aneesh Kumar K.V wrote:
>> David Gibson writes:
>>
>> > On Thu, Apr 04, 2013 at 11:27:55AM +0530, Aneesh Kumar K.V wrote:
>> >> From: "Aneesh Kumar K.V"
>> >>
>> >> We now have pmd entries covering to 16MB range. To implement TH
On Fri, Apr 12, 2013 at 10:36:58AM +0530, Aneesh Kumar K.V wrote:
> David Gibson writes:
>
> > On Thu, Apr 11, 2013 at 01:10:29PM +0530, Aneesh Kumar K.V wrote:
> >> David Gibson writes:
> >>
> >> > On Thu, Apr 04, 2013 at 11:27:55AM +0530, Aneesh Kumar K.V wrote:
> >> >> From: "Aneesh Kumar K.
85 matches
Mail list logo
