On Tue, 2012-06-26 at 15:54 -0400, Paul Gortmaker wrote:
> The SBC8260 support was dropped back when we moved from ppc to
> powerpc. We are now also dropping the support for the EOL SBC8560,
> so we can also delete this mapping support, as they were the only
> users of it.
>
> Cc: David Woodhouse
NAND on p2041 uses CS1 as chip select.
Signed-off-by: Shaohui Xie
---
arch/powerpc/boot/dts/p2041rdb.dts | 41 +++-
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/p2041rdb.dts
b/arch/powerpc/boot/dts/p2041rdb.dts
index 285
> -Original Message-
> From: Linuxppc-dev
> [mailto:linuxppc-dev-bounces+chenhui.zhao=freescale@lists.ozlabs.org] On
> Behalf
> Of Kumar Gala
> Sent: Friday, June 29, 2012 2:30 AM
> To: Zhao Chenhui-B35336
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org list;
> linux-ker...@vg
Marek Szyprowski wrote:
> +++ b/drivers/base/dma-mapping.c
> ...
> +int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size)
> +{
> + int ret = -ENXIO;
> + ...
> + if (dma_mmap_from_coherent(dev, vma, cpu_a
Hi,
On Friday, June 29, 2012 1:10 PM Clemens Ladisch wrote:
> Marek Szyprowski wrote:
> > +++ b/drivers/base/dma-mapping.c
> > ...
> > +int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> > + void *cpu_addr, dma_addr_t dma_addr, size_t size)
> > +{
> > + int ret
Marek Szyprowski wrote:
> On Friday, June 29, 2012 1:10 PM Clemens Ladisch wrote:
>> Marek Szyprowski wrote:
>>> +++ b/drivers/base/dma-mapping.c
>>> ...
>>> +int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>> + void *cpu_addr, dma_addr_t dma_addr, size_t size)
>>
On 12-06-29 04:29 AM, Artem Bityutskiy wrote:
> On Tue, 2012-06-26 at 15:54 -0400, Paul Gortmaker wrote:
>> The SBC8260 support was dropped back when we moved from ppc to
>> powerpc. We are now also dropping the support for the EOL SBC8560,
>> so we can also delete this mapping support, as they we
From: "Aneesh Kumar K.V"
Don't open code the same
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/cell/beat_htab.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/cell/beat_htab.c
b/arch/powerpc/platforms/cell/beat_htab.c
index 943c9d3.
From: "Aneesh Kumar K.V"
This is in preparation to the conversion of 64 bit powerpc virtual address
to the max 78 bits. Later patch will switch struct virt_addr to a struct
of virtual segment id and segment offset.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s.h |
Hi,
This patchset include patches for supporting 64TB with ppc64. I haven't booted
this on hardware with 64TB memory yet. But they boot fine on real hardware with
less memory. Changes extend VSID bits to 38 bits for a 256MB segment
and 26 bits for 1TB segments.
The patches are not for inclusion.
From: "Aneesh Kumar K.V"
This patch enables us to have 78 bit virtual address.
With 1TB segments we use 40 bits of virtual adress as segment offset and
the remaining 24 bits (of the current 64 bit virtual address) are used
to index the virtual segment. Out of the 24 bits we currently use 19 bits
From: "Aneesh Kumar K.V"
As we keep increasing PGTABLE_RANGE we need not increase the virual
map area for kernel.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/pgtable-ppc64.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgtable
From: "Aneesh Kumar K.V"
This patch simplify hpte_decode for easy switching of virtual address to
vsid and segment offset combination in the later patch
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/hash_native_64.c | 51 ++
1 file changed, 30 insert
From: "Aneesh Kumar K.V"
This patch makes the high psizes mask as an unsigned char array
so that we can have more than 16TB. Currently we support upto
64TB
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/mmu-hash64.h |7 ++-
arch/powerpc/include/asm/page_64.h|7 ++-
ar
From: "Aneesh Kumar K.V"
Increase the number of valid VSID bits in slbmte instruction.
We will use the new bits when we increase valid VSID bits.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/slb_low.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerp
From: "Aneesh Kumar K.V"
With larger vsid we need to track more bits of ESID in slb cache
for slb invalidate.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/paca.h |2 +-
arch/powerpc/mm/slb_low.S |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff -
From: "Aneesh Kumar K.V"
Increase max addressable range to 64TB. This is not tested on
real hardware yet.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/mmu-hash64.h|8
arch/powerpc/include/asm/pgtable-ppc64-4k.h |2 +-
arch/powerpc/include/asm/pgtable-p
On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>
> Signed-off-by: Zh
On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>
>
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Friday, June 29, 2012 12:31 AM
>> To: Jia Hongtao-B38951
>> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Li Yang-R58472;
>> ag...@suse.de; linuxppc-dev@lists.ozlabs.
On 06/29/2012 10:57 AM, Kumar Gala wrote:
>
> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>
>>
>>
>>> -Original Message-
>>> From: Wood Scott-B07421
>>> Sent: Friday, June 29, 2012 12:31 AM
>>> To: Jia Hongtao-B38951
>>> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Li Yang
On 06/29/2012 10:39 AM, Tabi Timur-B04825 wrote:
> On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
> wrote:
>> +static void mpc85xx_give_timebase(void)
>> +{
>> + unsigned long flags;
>> +
>> + local_irq_save(flags);
>> +
>> + while (!tb_req)
>> + barrier();
>
> I th
Scott Wood wrote:
>> I wonder if it's possible to dynamically generate the compatible
>> string by using the SOC name?
>
> Where are you going to get the SoC name from?
Well, that is why I said "I wonder". I'm disappointed that the "cpus"
node doesn't help much. You'd think the name of the CP
On Jun 29, 2012, at 11:01 AM, Scott Wood wrote:
> On 06/29/2012 10:57 AM, Kumar Gala wrote:
>>
>> On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote:
>>
>>>
>>>
-Original Message-
From: Wood Scott-B07421
Sent: Friday, June 29, 2012 12:31 AM
To: Jia Hongtao-B3895
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=freescale@lists.ozlabs.org] On Behalf Of Kumar Gala
> Sent: Friday, June 29, 2012 23:58 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472;
> ag...@su
On 06/29/2012 11:04 AM, Timur Tabi wrote:
> Scott Wood wrote:
>
>>> I wonder if it's possible to dynamically generate the compatible
>>> string by using the SOC name?
>>
>> Where are you going to get the SoC name from?
>
> Well, that is why I said "I wonder". I'm disappointed that the "cpus"
>
Scott Wood wrote:
> Why is this different from anywhere else where we have a list of
> compatibles to match, often based on various SoCs? Note that we
> explicitly want to match only certain SoCs here.
I was just hoping to find a way to avoid an ever increasing list of
compatible strings. Other
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, June 29, 2012 11:02 AM
> To: Kumar Gala
> Cc: Jia Hongtao-B38951; Wood Scott-B07421; Li Yang-R58472; ag...@suse.de;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt
> pl
Hi Paul,
On Thu, Jun 28, 2012 at 10:20 AM, Paul Mundt wrote:
> On Tue, Jun 26, 2012 at 10:06:27PM +0200, Geert Uytterhoeven wrote:
>> On Tue, Jun 26, 2012 at 9:59 PM, Geert Uytterhoeven
>> wrote:
>> > JFYI, when comparing v3.5-rc4 to v3.5-rc3[3], the summaries are:
>> > ??- build errors: +11/-21
On 06/29/2012 11:18 AM, Li Yang-R58472 wrote:
>
>
>> -Original Message- From: Wood Scott-B07421 Sent: Friday,
>> June 29, 2012 11:02 AM To: Kumar Gala Cc: Jia Hongtao-B38951; Wood
>> Scott-B07421; Li Yang-R58472; ag...@suse.de;
>> linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/3] po
On 06/29/2012 11:12 AM, Timur Tabi wrote:
> Scott Wood wrote:
>> Why is this different from anywhere else where we have a list of
>> compatibles to match, often based on various SoCs? Note that we
>> explicitly want to match only certain SoCs here.
>
> I was just hoping to find a way to avoid an
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 1c65a59..5ff936b 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -143,6 +143,10 @@ struct mmu_psize_def
unsigned long sllp; /* SLB L||LP (
On Mar 16, 2012, at 11:07 AM, Timur Tabi wrote:
> Kumar Gala wrote:
Haiying said it should be ok, but I haven't tried it yet. I'll try it on
Monday.
>
>> Did you ever test this?
>
> No, I forgot all about it. I'll try it today, assuming the lone 8323
> board in the board farm still
Kumar Gala wrote:
>
> On Mar 16, 2012, at 11:07 AM, Timur Tabi wrote:
>
>> Kumar Gala wrote:
> Haiying said it should be ok, but I haven't tried it yet. I'll try it on
> Monday.
>>
>>> Did you ever test this?
>>
>> No, I forgot all about it. I'll try it today, assuming the lone 8323
>>
On Sep 19, 2011, at 10:35 AM, Matias Garcia wrote:
>
> Here's the patch against 2.6.37:
>
> Change quirk_fsl_pcie_header from __init to __devinit.
>
> Signed-off-by: Matias Garcia
applied
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs
On Apr 13, 2012, at 5:26 PM, Kim Phillips wrote:
> At least for crypto/IPSec, doing so provides users with a better
> performance experience out of the box.
>
> Signed-off-by: Kim Phillips
> ---
> arch/powerpc/configs/corenet32_smp_defconfig |1 +
> arch/powerpc/configs/corenet64_smp_defconf
On Apr 26, 2012, at 10:01 PM, Shengzhou Liu wrote:
> Enable MTD/NOR/NAND options by default in mpc85xx_defconfig and
> mpc85xx_smp_defconfig to support NOR, NAND flash.
>
> Signed-off-by: Shengzhou Liu
> ---
> based on master branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l
On Apr 16, 2012, at 8:42 PM,
wrote:
> From: Jerry Huang
>
> Add the RTC support for p1022ds
>
> Signed-off-by: Jerry Huang
> ---
> arch/powerpc/boot/dts/p1022ds.dtsi |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
applied
- k
___
On May 9, 2012, at 2:53 PM, Sebastian Andrzej Siewior wrote:
> * Kumar Gala | 2012-03-31 09:48:18 [-0500]:
>
> Sorry for the delay Kumar, I though I allready done it.
>
>> Yes, please do.
> Here it comes.
>
>> From 5b3e09992615e5670fa8e432e50424466fa9ca1a Mon Sep 17 00:00:00 2001
> From: Sebas
On May 23, 2012, at 9:35 AM, Gustavo Zacarias wrote:
> Add EEPROM to the P1010RDB device tree.
> The 24c01 acts as a memory SPD so it shouldn't be overwritten without
> care.
> The 24c256 is a general purpose memory.
>
> Signed-off-by: Gustavo Zacarias
> ---
> arch/powerpc/boot/dts/p1010rdb.dts
On Jun 26, 2012, at 2:54 PM, Paul Gortmaker wrote:
> This reference board dates back to 2004, and is largely a legacy
> EOL product. The MPC8560 is a pre e500v2 CPU. The SBC8548 is
> a more modern, better e500v2 target for people to use as a
> reference board with today's kernels, should they r
On May 8, 2012, at 8:57 AM, Holger Brunck wrote:
> Signed-off-by: Holger Brunck
> cc: Heiko Schocher
> cc: Kumar Gala
> ---
> arch/powerpc/platforms/83xx/km83xx.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied
- k
___
Linuxppc
On May 8, 2012, at 8:57 AM, Holger Brunck wrote:
> From: Christian Herzig
>
> Fix RGMII workaround code in km83xx.c for MPC8360E and MPC8358E that it
> correctly identifes all affected SoC chip models and applies the
> workarounds appropriate for 2.0 and 2.1 revisions as per Freescale
> MPC8360
On May 8, 2012, at 8:57 AM, Holger Brunck wrote:
> Switch on UBIFS, HOTPLUG and TIPC and update the config to
> the latest kernel version.
>
> Signed-off-by: Holger Brunck
> cc: Heiko Schocher
> cc: Kumar Gala
> ---
> arch/powerpc/configs/83xx/kmeter1_defconfig | 22 --
>
On May 8, 2012, at 8:57 AM, Holger Brunck wrote:
> Add spi support for mgcoge into the platform code and the dts
> file. Additionaly SPIDEV is switched on in the defconfig and the
> updates for the newer kernel version are committed. The SPI
> interface is used to drive the Maxim DS3106 clock chi
On May 24, 2012, at 4:08 AM,
wrote:
> From: Tang Yuantian
>
> Signed-off-by: Jin Qing
> Signed-off-by: Li Yang
> Signed-off-by: Tang Yuantian
> ---
> arch/powerpc/boot/dts/p1024rdb.dtsi| 228
> arch/powerpc/boot/dts/p1024rdb_32b.dts | 87
On May 24, 2012, at 4:08 AM,
wrote:
> From: Tang Yuantian
>
> The p1024rdb has the similar feature as the p1020rdb. Therefore, p1024rdb use
> the same platform file as the p1/p2 rdb board.
> Overview of P2020RDB platform
> - DDR3 1G
> - NOR flash 16M
> - 3 Ethernet interfac
On Jun 29, 2012, at 4:41 AM, Shaohui Xie wrote:
> NAND on p2041 uses CS1 as chip select.
>
> Signed-off-by: Shaohui Xie
> ---
> arch/powerpc/boot/dts/p2041rdb.dts | 41 +++-
> 1 files changed, 40 insertions(+), 1 deletions(-)
applied
- k
__
As an alternative incremental starting point to Jia Hongtao's patchset,
get the FSL PCI init out of the board files, but do not yet convert to a
platform driver.
Rather than having each board supply a magic register offset for
determining the "primary" bus, we look for which PCI host bridge
contai
Hi Linus !
Here are a few powerpc fixes. Arguably some of this should have come to
you earlier but I'm only just catching up after my medical leave.
Mostly these fixes regressions, a couple are long standing bugs.
Cheers,
Ben.
The following changes since commit 9acc7bde23ebb19a704395f76490685e1
On Fri, 2012-06-29 at 19:47 +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> This is in preparation to the conversion of 64 bit powerpc virtual address
> to the max 78 bits. Later patch will switch struct virt_addr to a struct
> of virtual segment id and segment offset.
I'm not to h
On Fri, 2012-06-29 at 19:47 +0530, Aneesh Kumar K.V wrote:
>
> +/* 78 bit power virtual address */
> struct virt_addr {
> - unsigned long addr;
> + unsigned long vsid;
> + unsigned long seg_off;
> };
Do we really need to do that ? It's really nasty...
We are trying to add on
51 matches
Mail list logo
