Re: ibm_newemac tx problem with jumbo frame enabled
On Fri, Nov 25, 2011 at 10:55 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-11-18 at 10:33 +0530, Prashant Bhole wrote: Hi, I have been facing problem with ibm_newemac driver (v3.54). The board gets disconnected and can not be pinged in between some heavy network traffic. In my case I am running IOmeter All-in-One 8 threads on the iSCSI target. MTU is 4088. I found that after executing emac_full_tx_reset(), the board can be pinged again. Again after some heavy traffic of 5-6 seconds, traffic stops. This can be repeated after full tx reset. Is this a known issue? what could cause this? Any pointers would be greatly appreciated. Not that I know of. Can you check if any of the error reporting registers trip anything ? Could it just be a fifo overflow which we may not be handling properly in the driver ? Cheers, Ben. Still couldn't find anything like fifo overflow... I noticed one more thing, this problem happens only when mtu size on the initiator (the other end) is set to 4088, regardless of any mtu size set for EMAC. - Prashant ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
On 12/07/2011 08:34 AM, Benjamin Herrenschmidt wrote: On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote: This patch enables or updates support for the CC770 and AN82527 CAN controller on the TQM8548 and TQM8xx boards. I'm a bit confused by the net-next prefix here. Those patches seem to be only touching arch/powerpc and seem to be sent primarily toward netdev with a net-next prefix. These patches are part of a series implementing a new netdev CAN driver with device-tree support for CC770/i82527 CAN controllers. The device-tree support and bindings are properly documented and some DTS files have been updated accordingly. The relevant maintainers and mailing list have been addressed. Also there have been at least 3 versions in a couple of days already without comments nor indication of what was changed... Unfortunately, no response from those sub-system guys. Can you clarify things a bit please ? It looks like they really should go to linuxppc-dev (and you can probably drop a bunch of other lists) or am I missing an important piece of the puzzle ? (Such as patch 1/4 and 2/4 ...) I have not sent the whole series. The changes are documented in the cover-letter, which I have not sent for those patches. Well, I think it's better to sent the whole series to all parties instead? Let me know if I should just remove them from powerpc patchwork. Dave has already applied all patches. Sorry for the confusion. Any advice on how to handle multi subsystem series of patches properly is welcome. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On 11/30/11 20:11, Josh Boyer wrote: On Mon, Nov 28, 2011 at 5:59 PM, Scott Woodscottw...@freescale.com wrote: On 11/23/2011 10:47 AM, Josh Boyer wrote: On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulosesuz...@in.ibm.com wrote: The current implementation of CONFIG_RELOCATABLE in BookE is based on mapping the page aligned kernel load address to KERNELBASE. This approach however is not enough for platforms, where the TLB page size is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used currently in BookE to DYNAMIC_MEMSTART to reflect the actual method. Should reword the config help to make it clear what the alignment restriction is, or where to find the information for a particular platform. Someone reading page aligned without any context that we're talking about special large pages is going to think 4K -- and on e500, many large page sizes are supported, so the required alignment is found in Linux init code rather than a CPU manual. The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the dynamic relocations will be introduced in the later in the patch series. This change would allow the use of the old method of RELOCATABLE for platforms which can afford to enforce the page alignment (platforms with smaller TLB size). I'm OK with the general direction, but this touches a lot of non-4xx code. I'd prefer it if Ben took this directly on whatever final solution is done. I haven tested this change only on 440x. I don't have an FSL BookE to verify the changes there. Scott, Could you please test this patch on FSL and let me know the results ? Scott, did you ever get around to testing this? In my opinion, this shouldn't go in without a Tested-by: from someone that tried it on an FSL platform. Booted OK for me on e500v2 with RAM starting at 256M. Tested-by: Scott Woodscottw...@freescale.com We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for 64-bit. Then throughout almost the rest of the patch, all we're doing is duplicating what RELOCATABLE already did (e.g. if ! either thing). It works, but it is kind of ugly. Instead, could we define a helper config variable that can be used in place of that construct? Something like: config NONSTATIC_KERNEL (or whatever) bool default n ... config DYNAMIC_MEMSTART blah select NONSTATIC_KERNEL ... config RELOCATABLE blah select NONSTATIC_KERNEL I agree. Suzie do you think you could respin this patch with the suggested changes and include Scott's Tested-by? The rest of the series looks fine and I'd like to get it included in my next branch. Josh, I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU setup. However I am facing problems getting the my boards booted with the network cards (even without the patches). Here is what I see : Creating 2 MTD partitions on 1ff80.large-flash: 0x-0x0038 : fs 0x0038-0x0040 : firmware PPC 4xx OCP EMAC driver, version 3.54 mal0: failed to map interrupts ! ZMII /plb/opb/emac-zmii@4780 initialized /plb/opb/ethernet@4800: Timeout waiting for dependent devices /plb/opb/ethernet@4900: Timeout waiting for dependent devices TCP cubic registered NET: Registered protocol family 17 Root-NFS: no NFS server address VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device (null) or unknown-block(2,0) Please append a correct root= boot option; here are the available partitions: 1f00 512 mtdblock0 (driver?) 1f013584 mtdblock1 (driver?) 1f02 512 mtdblock2 (driver?) Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Have you come across this message ? Thanks Suzuki ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
On Wed, Dec 7, 2011 at 7:40 AM, Suzuki Poulose suz...@in.ibm.com wrote: Josh, I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU setup. However I am facing problems getting the my boards booted with the network cards (even without the patches). Here is what I see : Creating 2 MTD partitions on 1ff80.large-flash: 0x-0x0038 : fs 0x0038-0x0040 : firmware PPC 4xx OCP EMAC driver, version 3.54 mal0: failed to map interrupts ! That's the problem. There was a bogus commit that was added to the generic OF code that prevented the normal mapping that the MAL nodes do from working. It was later reverted after Benh told Linus it was bogus. I don't remember which -rc that wound up in, but if you move to 3.2-rc4 that should help. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [powerpc] boot up problem
This still needs a dts fix from Andy. - k On Dec 7, 2011, at 1:27 AM, Jia Hongtao-B38951 wrote: Is this the patch you mentioned? http://patchwork.ozlabs.org/patch/128806/ I applied this patch but the issue was still there. -Original Message- From: Tabi Timur-B04825 Sent: Friday, December 02, 2011 11:56 AM To: Jia Hongtao-B38951 Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Fleming Andy-AFLEMING Subject: Re: [linuxppc-release] [powerpc] boot up problem Jia Hongtao-B38951 wrote: Hi I just found that the 'next' branch you mentioned have problem to boot up. I test it in p1022ds and p1010rdb boards and the result are both the same. Note that for p1022ds I use make p1022ds.dtb to make the dtb file(36bit) with 36bit-uboot. And for p1010rdb I use all 32bit image. The problem list below: scsi0 : sata_fsl ata1: SATA max UDMA/133 irq 74 fsl-sata fffe19000.sata: Sata FSL Platform/CSB Driver init scsi1 : sata_fsl ata2: SATA max UDMA/133 irq 41 Fixed MDIO Bus: probed Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0451630 Oops: Kernel access of bad area, sig: 11 [#1] Andy has phy driver patch that fixes this. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [powerpc] boot up problem
On Dec 7, 2011, at 1:27 AM, Jia Hongtao-B38951 b38...@freescale.com wrote: Is this the patch you mentioned? http://patchwork.ozlabs.org/patch/128806/ I applied this patch but the issue was still there. This is not the patch I am talking about. Unfortunately, I can't find the right patch in patchwork anywhere. Andy, what about patch fsl_pq_mdio: Clean up tbi address configuration? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller
On 12/06/2011 09:16 PM, Liu Shengzhou-B36685 wrote:
+ out_be32(lbc-fbcr, 8);
+ elbc_fcm_ctrl-read_bytes = 8;
+ } else {
+ out_be32(lbc-fbcr, 256);
+ elbc_fcm_ctrl-read_bytes = 256;
+ }
Any harm in always using 256?
-Scott
[Shengzhou] For NAND_CMD_READID command, the total bytes of entire ID string
are 8, there are not 256 bytes so many, it's unnecessary and looks not so
well logically to always using 256, though it works.
It's not performance critical, and always using 256 keeps things
simpler, and more robust if the length of the ID string grows in the
future (we used to assume it was 5 bytes...).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
On 12/07/2011 12:30 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, December 07, 2011 1:16 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org; dw...@infradead.org; Gala Kumar-B11780 Subject: Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller On 12/06/2011 02:54 AM, Shengzhou Liu wrote: There was a bug for fmr initialization, which lead to fmr was always 0x100 in fsl_elbc_chip_init() and caused FCM command timeout before calling fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value and not relying on the setting of bootloader. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v2: make fmr not relying on the setting of bootloader. drivers/mtd/nand/fsl_elbc_nand.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index eedd8ee..4f405a0 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -659,9 +659,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd) if (chip-pagemask 0xff00) al++; - /* add to ECCM mode set in fsl_elbc_init */ - priv-fmr |= (12 FMR_CWTO_SHIFT) | /* Timeout 12 ms */ -(al FMR_AL_SHIFT); + priv-fmr |= al FMR_AL_SHIFT; dev_dbg(priv-dev, fsl_elbc_init: nand-numchips = %d\n, chip-numchips); @@ -764,8 +762,10 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv) priv-mtd.priv = chip; priv-mtd.owner = THIS_MODULE; - /* Set the ECCM according to the settings in bootloader.*/ - priv-fmr = in_be32(lbc-fmr) FMR_ECCM; + /* set timeout to maximum */ + priv-fmr = 15 FMR_CWTO_SHIFT; + if (in_be32(lbc-bank[priv-bank].or) OR_FCM_PGS) + priv-fmr |= FMR_ECCM; Please do not change the way ECCM is handled. We probably should have done it this way from the start, but at this point it breaks compatibility if you have a large page flash and the firmware didn't touch NAND. -Scott [Shengzhou] This patch doesn't change the way ECCM is handled, it's still same as before, just make sure CWTO timeout is set to maximum. It does change it. It used to use the existing value in FMR, and now it sets it based on ORn[PGS]. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix swiotlb ops for ppc64
We assumed before that alloc_coherent free_coherent ops would always
be direct because of 32-bit systems and how we utilize highmem lowmem.
However, on 64-bit systems we typically treat all memory as lowmem so
the same assumptions are not valid. We need to utilze the swiotlb
versions of alloc_coherent free_coherent on 64-bit systems.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/kernel/dma-swiotlb.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c
b/arch/powerpc/kernel/dma-swiotlb.c
index 1ebc918..5000fd4 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -40,15 +40,20 @@ static u64 swiotlb_powerpc_get_required(struct device *dev)
}
/*
- * At the moment, all platforms that use this code only require
- * swiotlb to be used if we're operating on HIGHMEM. Since
+ * We assume that 32-bit systems will utilize HIGHMEM and that we're
+ * able to DMA directly to anything in the LOWMEM region. Since
* we don't ever call anything other than map_sg, unmap_sg,
* map_page, and unmap_page on highmem, use normal dma_ops
* for everything else.
*/
struct dma_map_ops swiotlb_dma_ops = {
+#ifdef CONFIG_PPC64
+ .alloc_coherent = swiotlb_alloc_coherent,
+ .free_coherent = swiotlb_free_coherent,
+#else
.alloc_coherent = dma_direct_alloc_coherent,
.free_coherent = dma_direct_free_coherent,
+#endif
.map_sg = swiotlb_map_sg_attrs,
.unmap_sg = swiotlb_unmap_sg_attrs,
.dma_supported = swiotlb_dma_supported,
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
On Thu, 2011-12-01 at 15:50 +0530, K.Prasad wrote:
On Mon, Nov 28, 2011 at 02:11:11PM +1100, David Gibson wrote:
[snip]
On Wed, Oct 12, 2011 at 11:09:48PM +0530, K.Prasad wrote:
diff --git a/Documentation/powerpc/ptrace.txt
b/Documentation/powerpc/ptrace.txt
index f4a5499..f2a7a39 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
+- set a watchpoint in server processors (BookS)
+
+ p.version = 1;
+ p.trigger_type= PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr= (uint64_t) begin_range;
You should probably document the alignment constraint on the address
here, too.
Alignment constraints will be learnt by the user-space during runtime.
We provide that as part of 'struct ppc_debug_info' in
'data_bp_alignment' field.
While the alignment is always 8-bytes for BookS, I think userspace
should be left to learn it through PTRACE_PPC_GETHWDEBUGINFO.
Right. In particular, BookE doesn't have alignment constraints.
+ attr.bp_len = len;
+ ret = modify_user_hw_breakpoint(bp, attr);
+ if (ret) {
+ ptrace_put_breakpoints(child);
+ return ret;
+ }
If a bp already exists, you're modifying it. I thought the semantics
of the new interface meant that you shoul return ENOSPC in this case,
and a DEL would be necessary before adding another breakpoint.
I'm not too sure what would be the desired behaviour for this interface,
either way is fine with me. I'd like to hear from the GDB folks (copied
in this email) to know what would please them.
ENOSPC should be returned. The interface doesn't have provisions for
modifying breakpoints. The client should delete/create instead of trying
to modify.
Since PTRACE_PPC_GETHWDEBUGINFO returns the number of available
breakpoint registers, the client shouldn't (and GDB doesn't) try to set
more breakpoints than possible.
@@ -1426,10 +1488,24 @@ static long ppc_del_hwdebug(struct task_struct
*child, long addr, long data)
#else
if (data != 1)
return -EINVAL;
+
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) 0)
+ return -ESRCH;
+
+ bp = thread-ptrace_bps[0];
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread-ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
Shouldn't DEL return an error if there is no existing bp.
Same comment as above. We'd like to know what behaviour would help the
GDB use this interface better as there's no right or wrong way here.
GDB expects DEL to return ENOENT is there's no existing bp.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On 12/06/2011 09:55 PM, LiuShuo wrote:
于 2011年12月07日 08:09, Scott Wood 写道:
On 12/03/2011 10:31 PM, shuo@freescale.com wrote:
From: Liu Shuoshuo@freescale.com
Freescale FCM controller has a 2K size limitation of buffer RAM. In
order
to support the Nand flash chip whose page size is larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Signed-off-by: Liu Shuoshuo@freescale.com
---
v3:
-remove page_size of struct fsl_elbc_mtd.
-do a oob write by NAND_CMD_RNDIN.
drivers/mtd/nand/fsl_elbc_nand.c | 243
++
1 files changed, 218 insertions(+), 25 deletions(-)
What is the plan for bad block marker migration?
This patch has been ported to uboot now, I think we can make a special
uboot image for bad
block marker migration when first use the chip.
It should not be a special image, and there should be some way to mark
that the migration has happened. Even if we do the migration in U-Boot,
Linux could check for the marker and if absent, disallow access and tell
the user to run the migration tool.
@@ -473,13 +568,72 @@ static void fsl_elbc_cmdfunc(struct mtd_info
*mtd, unsigned int command,
* write so the HW generates the ECC.
*/
if (elbc_fcm_ctrl-oob || elbc_fcm_ctrl-column != 0 ||
-elbc_fcm_ctrl-index != mtd-writesize + mtd-oobsize)
-out_be32(lbc-fbcr,
-elbc_fcm_ctrl-index - elbc_fcm_ctrl-column);
-else
+elbc_fcm_ctrl-index != mtd-writesize + mtd-oobsize) {
+if (elbc_fcm_ctrl-oob mtd-writesize 2048) {
+out_be32(lbc-fbcr, 64);
+} else {
+out_be32(lbc-fbcr, elbc_fcm_ctrl-index
+- elbc_fcm_ctrl-column);
+}
We need to limit ourselves to the regions that have actually been
written to in the buffer. fbcr needs to be set separately for first and
last subpages, with intermediate subpages having 0, 64, or 2112 as
appropriate. Subpages that are entirely before column or entirely after
column + index should be skipped.
I have considered this case, but I don't think it is useful.
1.There isn't a 'length' parameter in driver interface, although we
can get it from 'index - column'.
Right. column is start, and index is end + 1. We have the bounds of
what has been written.
2.To see nand_do_write_oob() in nand_base.c, it fill '0xff' to
entire oob area first and write the user data by nand_fill_oob(), then
call ecc.write_oob (default is nand_write_oob_std()).
Do we really want to assume that that's what it will always do?
And if we do want to make such assumptions, we could rip out all usage
of index/column here, and just handle oob and full page cases.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pata_sl82c105 is unable to properly handle dma (indeed it try to use mwdma2)
On Wed, 07 Dec 2011 13:21:28 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2011-12-07 at 02:15 +0100, acrux...@libero.it wrote: New pata_sl82c105 is unable to properly handle dma (indeed it try to use mwdma2). Old ide driver instead worked fine. Tested on IBM 9114-275 where to use it i must boot with dma disabled i.e. with libata.dma=0 Adding the linux-ide list on CC. Can you also send a dmesg with the old IDE driver ? It might be useful to compare the values programmed by the 2 versions of the driver in the timing registers. hi Ben, booting with a CRUX PPC (64bit) 2.6 with kernel linux-2.6.32.3 with old sl82c105 ide driver. Here topic section from lspci -vvv :00:03.0 ISA bridge: Symphony Labs W83C553F/W83C554F (rev 10) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 :00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO]) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 72 (500ns min, 1ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 165 Region 0: I/O ports at f000 [size=8] Region 1: I/O ports at f010 [size=4] Region 2: I/O ports at f020 [size=8] Region 3: I/O ports at f030 [size=4] Region 4: I/O ports at f040 [size=16] Region 5: I/O ports at unassigned Kernel driver in use: W82C105_IDE An here it is the dmesg: [...] early_node_map[1] active PFN ranges 0: 0x - 0x0010 [boot]0015 Setup Done PERCPU: Embedded 12 pages/cpu @c0a0 s17480 r0 d31672 u524288 pcpu-alloc: s17480 r0 d31672 u524288 alloc=1*1048576 pcpu-alloc: [0] 0 1 Built 1 zonelists in Node order, mobility grouping on. Total pages: 1034240 Policy zone: DMA Kernel command line: root=/dev/hda ro console=ttyS0,9600 PID hash table entries: 4096 (order: 3, 32768 bytes) freeing bootmem node 0 Memory: 4033656k/4194304k available (7844k kernel code, 160648k reserved, 1308k) SLUB: Genslabs=14, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=256 Hierarchical RCU implementation. NR_IRQS:512 [boot]0020 XICS Init [boot]0021 XICS Done i8259 legacy interrupt controller initialized clocksource: timebase mult[160a04b] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Mount-cache hash table entries: 256 Processor 1 found. Brought up 2 CPUs NET: Registered protocol family 16 IBM eBus Device Driver PCI: Probing PCI hardware pci :00:02.0: PME# supported from D1 D2 D3hot pci :00:02.0: PME# disabled pci :00:02.2: PME# supported from D1 D2 D3hot pci :00:02.2: PME# disabled pci :00:02.4: PME# supported from D1 D2 D3hot pci :00:02.4: PME# disabled pci :00:02.6: PME# supported from D1 D2 D3hot pci :00:02.6: PME# disabled Using INTC for W82c105 IDE controller. IOMMU table initialized, virtual merging enabled pci :01:01.0: PME# supported from D1 D2 D3hot D3cold pci :01:01.0: PME# disabled pci :21:01.0: PME# supported from D0 D1 D2 D3hot D3cold pci :21:01.0: PME# disabled pci 0001:00:02.0: PME# supported from D1 D2 D3hot pci 0001:00:02.0: PME# disabled pci 0001:00:02.2: PME# supported from D1 D2 D3hot pci 0001:00:02.2: PME# disabled pci 0001:00:02.3: PME# supported from D1 D2 D3hot pci 0001:00:02.3: PME# disabled pci 0001:00:02.4: PME# supported from D1 D2 D3hot pci 0001:00:02.4: PME# disabled pci 0001:00:02.6: PME# supported from D1 D2 D3hot pci 0001:00:02.6: PME# disabled pci 0001:21:01.0: PME# supported from D0 D1 D2 D3hot pci 0001:21:01.0: PME# disabled pci 0001:31:01.0: PME# supported from D0 D1 D2 D3hot pci 0001:31:01.0: PME# disabled pci 0001:31:01.1: PME# supported from D0 D1 D2 D3hot pci 0001:31:01.1: PME# disabled pci 0001:41:01.0: PME# supported from D0 D3hot D3cold pci 0001:41:01.0: PME# disabled PCI: Cannot allocate resource region 2 of PCI bridge 1, will remap PCI: Cannot allocate resource region 2 of PCI bridge 33, will remap PCI: Cannot allocate resource region 2 of PCI bridge 65, will remap PCI: Cannot allocate resource region 2 of PCI bridge 97, will remap PCI: Cannot allocate resource region 2 of PCI bridge 1, will remap PCI: Cannot allocate resource region 2 of PCI bridge 33, will remap PCI: Cannot allocate resource region 2 of PCI bridge 49, will remap PCI: Cannot allocate resource region 2 of PCI bridge 65, will remap PCI: Cannot allocate resource region 2 of PCI bridge 97, will remap PCI: Cannot allocate resource region 0 of device :00:02.2, will remap PCI: Cannot allocate
[PATCH] powerpc: Add TBI PHY node to first MDIO bus
Systems which use the fsl_pq_mdio driver need to specify an
address for TBI PHY transactions such that the address does
not conflict with any PHYs on the bus (all transactions to
that address are directed to the onboard TBI PHY). The driver
used to scan for a free address if no address was specified,
however this ran into issues when the PHY Lib was fixed so
that all MDIO transactions were protected by a mutex. As it
is, the code was meant to serve as a transitional tool until
the device trees were all updated to specify the TBI address.
The best fix for the mutex issue was to remove the scanning code,
but it turns out some of the newer SoCs have started to omit
the tbi-phy node when SGMII is not being used. As such, these
devices will now fail unless we add a tbi-phy node to the first
mdio controller.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
This requires fsl_pq_mdio: Clean up tbi address configuration from
the net tree in order to achieve its full effect.
This needs to go into 3.2.
arch/powerpc/boot/dts/p1010rdb.dts|5 +
arch/powerpc/boot/dts/p1020rdb.dts|5 +
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |5 +
arch/powerpc/boot/dts/p1021mds.dts|4
arch/powerpc/boot/dts/p1022ds.dts |4
arch/powerpc/boot/dts/p2020rdb.dts|8 ++--
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |4
7 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb.dts
b/arch/powerpc/boot/dts/p1010rdb.dts
index d6c669c..e1f9683 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb.dts
@@ -193,6 +193,11 @@
interrupts = 2 1;
reg = 0x2;
};
+
+ tbi-phy@3 {
+ device-type = tbi-phy;
+ reg = 0x3;
+ };
};
enet0: ethernet@b {
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts
b/arch/powerpc/boot/dts/p1020rdb.dts
index d6a8ae4..72e4fc4 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -209,6 +209,11 @@
interrupts = 2 1;
reg = 0x1;
};
+
+ tbi-phy@2 {
+ device_type = tbi-phy;
+ reg = 0x2;
+ };
};
mdio@25000 {
diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
index f0bf7f4..ad805a1 100644
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
@@ -112,6 +112,11 @@
interrupts = 2 1;
reg = 0x1;
};
+
+ tbi-phy@2 {
+ device-type = tbi-phy;
+ reg = 0x2;
+ };
};
mdio@25000 {
diff --git a/arch/powerpc/boot/dts/p1021mds.dts
b/arch/powerpc/boot/dts/p1021mds.dts
index ad5b852..ba53b4b 100644
--- a/arch/powerpc/boot/dts/p1021mds.dts
+++ b/arch/powerpc/boot/dts/p1021mds.dts
@@ -338,6 +338,10 @@
interrupt-parent = mpic;
reg = 0x4;
};
+ tbi-phy@5 {
+ device_type = tbi-phy;
+ reg = 0x5;
+ };
};
mdio@25000 {
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boot/dts/p1022ds.dts
index 89ca93e..4bf382d 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -391,6 +391,10 @@
interrupts = 9 1 0 0;
reg = 0x2;
};
+ tbi-phy@2 {
+ device_type = tbi-phy;
+ reg = 0x2;
+ };
};
mdio@25000 {
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts
b/arch/powerpc/boot/dts/p2020rdb.dts
index 1d7a05f..9e4ae85 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -205,12 +205,16 @@
interrupt-parent = mpic;
interrupts = 3 1;
reg = 0x0;
- };
+ };
phy1: ethernet-phy@1 {
interrupt-parent = mpic;
interrupts = 3 1;
reg = 0x1;
- };
+ };
Re: [PATCH] powerpc: Add TBI PHY node to first MDIO bus
From: Andy Fleming aflem...@freescale.com Date: Wed, 7 Dec 2011 13:50:57 -0600 Systems which use the fsl_pq_mdio driver need to specify an address for TBI PHY transactions such that the address does not conflict with any PHYs on the bus (all transactions to that address are directed to the onboard TBI PHY). The driver used to scan for a free address if no address was specified, however this ran into issues when the PHY Lib was fixed so that all MDIO transactions were protected by a mutex. As it is, the code was meant to serve as a transitional tool until the device trees were all updated to specify the TBI address. The best fix for the mutex issue was to remove the scanning code, but it turns out some of the newer SoCs have started to omit the tbi-phy node when SGMII is not being used. As such, these devices will now fail unless we add a tbi-phy node to the first mdio controller. Signed-off-by: Andy Fleming aflem...@freescale.com --- This requires fsl_pq_mdio: Clean up tbi address configuration from the net tree in order to achieve its full effect. This needs to go into 3.2. I'm fine if the powerpc tree takes this one: Acked-by: David S. Miller da...@davemloft.net ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -resend 1/1] SPI: disable CONFIG_SPI_FSL_ESPI=m build
When spi_fsl_espi is chosen to be built as a module, there is a build error because we test only CONFIG_SPI_FSL_ESPI in declaration of struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h. Also some called functions are not exported. So we forbid CONFIG_SPI_FSL_ESPI to be tristate here. The error looks like: drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_bufs': drivers/spi/spi_fsl_espi.c:232: error: 'struct mpc8xxx_spi' has no member named 'len' ... Signed-off-by: Jiri Slaby jsl...@suse.cz Acked-by: Kumar Gala ga...@kernel.crashing.org Cc: Grant Likely grant.lik...@secretlab.ca --- Maybe Grant is back already? drivers/spi/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 9c90a7a..3d292be 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -198,7 +198,7 @@ config SPI_FSL_LIB depends on FSL_SOC config SPI_FSL_SPI - tristate Freescale SPI controller + bool Freescale SPI controller depends on FSL_SOC select SPI_FSL_LIB help @@ -207,7 +207,7 @@ config SPI_FSL_SPI MPC8569 uses the controller in QE mode, MPC8610 in cpu mode. config SPI_FSL_ESPI - tristate Freescale eSPI controller + bool Freescale eSPI controller depends on FSL_SOC select SPI_FSL_LIB help -- 1.7.7.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND] rapidio/tsi721: Fix mailbox resource reporting
Bug fix for Tsi721 RapidIO mport driver: Tsi721 supports four RapidIO mailboxes (MBOX0 - MBOX3) as defined by RapidIO specification. Mailbox resources has to be properly reported to allow use of all available mailboxes (initial version reports only MBOX0). This patch is applicable to kernel versions staring from 3.2-rc1. Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com --- [Resending this patch with updated commit comment] drivers/rapidio/devices/tsi721.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c index 514c28c..83ac8728 100644 --- a/drivers/rapidio/devices/tsi721.c +++ b/drivers/rapidio/devices/tsi721.c @@ -2107,8 +2107,8 @@ static int __devinit tsi721_setup_mport(struct tsi721_device *priv) INIT_LIST_HEAD(mport-dbells); rio_init_dbell_res(mport-riores[RIO_DOORBELL_RESOURCE], 0, 0x); - rio_init_mbox_res(mport-riores[RIO_INB_MBOX_RESOURCE], 0, 0); - rio_init_mbox_res(mport-riores[RIO_OUTB_MBOX_RESOURCE], 0, 0); + rio_init_mbox_res(mport-riores[RIO_INB_MBOX_RESOURCE], 0, 3); + rio_init_mbox_res(mport-riores[RIO_OUTB_MBOX_RESOURCE], 0, 3); strcpy(mport-name, Tsi721 mport); /* Hook up interrupt handler */ -- 1.7.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RESEND] rapidio/tsi721: modify PCIe capability settings
Modify initialization of PCIe capability registers in Tsi721 mport driver:
- change Completion Timeout value to avoid unexpected data transfer aborts
during intensive traffic.
- replace hardcoded offset of PCIe capability block by getting it using
the common function.
This patch is applicable to kernel versions starting from 3.2-rc1.
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
---
[Resending this patch with updated commit comment]
drivers/rapidio/devices/tsi721.c | 20 +++-
drivers/rapidio/devices/tsi721.h |2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 83ac8728..691b1ab 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -2154,7 +2154,7 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct tsi721_device *priv;
- int i;
+ int i, cap;
int err;
u32 regval;
@@ -2262,10 +2262,20 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
dev_info(pdev-dev, Unable to set consistent DMA
mask\n);
}
- /* Clear no snoop and relaxed ordering bits. */
- pci_read_config_dword(pdev, 0x40 + PCI_EXP_DEVCTL, regval);
- regval = ~(PCI_EXP_DEVCTL_RELAX_EN | PCI_EXP_DEVCTL_NOSNOOP_EN);
- pci_write_config_dword(pdev, 0x40 + PCI_EXP_DEVCTL, regval);
+ cap = pci_pcie_cap(pdev);
+ BUG_ON(cap == 0);
+
+ /* Clear no snoop and relaxed ordering bits, use default MRRS. */
+ pci_read_config_dword(pdev, cap + PCI_EXP_DEVCTL, regval);
+ regval = ~(PCI_EXP_DEVCTL_READRQ | PCI_EXP_DEVCTL_RELAX_EN |
+ PCI_EXP_DEVCTL_NOSNOOP_EN);
+ regval |= 0x2 MAX_READ_REQUEST_SZ_SHIFT;
+ pci_write_config_dword(pdev, cap + PCI_EXP_DEVCTL, regval);
+
+ /* Adjust PCIe completion timeout. */
+ pci_read_config_dword(pdev, cap + PCI_EXP_DEVCTL2, regval);
+ regval = ~(0x0f);
+ pci_write_config_dword(pdev, cap + PCI_EXP_DEVCTL2, regval | 0x2);
/*
* FIXUP: correct offsets of MSI-X tables in the MSI-X Capability Block
diff --git a/drivers/rapidio/devices/tsi721.h b/drivers/rapidio/devices/tsi721.h
index 58be4de..822e54c 100644
--- a/drivers/rapidio/devices/tsi721.h
+++ b/drivers/rapidio/devices/tsi721.h
@@ -72,6 +72,8 @@
#define TSI721_MSIXPBA_OFFSET 0x2a000
#define TSI721_PCIECFG_EPCTL 0x400
+#define MAX_READ_REQUEST_SZ_SHIFT 12
+
/*
* Event Management Registers
*/
--
1.7.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -resend 1/1] SPI: disable CONFIG_SPI_FSL_ESPI=m build
On Wed, Dec 07, 2011 at 09:18:16PM +0100, Jiri Slaby wrote: When spi_fsl_espi is chosen to be built as a module, there is a build error because we test only CONFIG_SPI_FSL_ESPI in declaration of struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h. Also some called functions are not exported. So we forbid CONFIG_SPI_FSL_ESPI to be tristate here. The error looks like: drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_bufs': drivers/spi/spi_fsl_espi.c:232: error: 'struct mpc8xxx_spi' has no member named 'len' ... Signed-off-by: Jiri Slaby jsl...@suse.cz Acked-by: Kumar Gala ga...@kernel.crashing.org Cc: Grant Likely grant.lik...@secretlab.ca --- Maybe Grant is back already? I just picked it up in the for-linus branch I am preparing while Grant is away. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Multi-OS on P1022RDK Failing
On 12/07/2011 08:57 AM, Arshad, Farrukh wrote: Core 0 kernel CONFIG_LOWMEM_SIZE = 0x1000 CONFIG_PHYSICAL_START = 0x Core 1 kernel CONFIG_LOWMEM_SIZE = 0x1000 CONFIG_PHYSICAL_START = 0x1000 Why are you messing with CONFIG_LOWMEM_SIZE? That adjusts the lowmem/highmem split, not the total amount of memory that this instance of Linux will use (though you may get that behavior as a side effect if highmem is disabled). U-boot should set the memory node in the device tree based on the bootm_low/bootm_size environment variables. # Boot from NFS setenv core0nfsbootargs root=/dev/nfs nfsroot=$serverip:/$core0rootfs ip=dev_ip::nfs_server_ip:::eth0:off rw debug console=$consoledev0,$baudrate maxcpus=1 setenv core1nfsbootargs root=/dev/nfs nfsroot=$serverip:/$core1rootfs ip=dev_ip_2::nfs_server_ip:::eth0:off rw debug console=$consoledev0,$baudrate maxcpus=1 maxcpus should be unnecessary -- there will only be one cpu in the device tree for each partition. My problem is Core 0 kernel is booting successfully but Core 1 kernel hangs after uncompressing kernel image, and after that I don’t see anything on the console. Any thoughts on what I am missing or doing incorrect? The cpu 1 release command should be using the address of the decompressed kernel (should be $bootm_low), not where the uImage was loaded. Also, the two serial ports you're using share an interrupt -- this shouldn't stop kernel message output, but it's going to be a problem for userspace usage of the port. You should remove the interrupts property from the serial node in both partitions, so Linux will poll instead. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add TBI PHY node to first MDIO bus
On Dec 7, 2011, at 2:02 PM, David Miller wrote: From: Andy Fleming aflem...@freescale.com Date: Wed, 7 Dec 2011 13:50:57 -0600 Systems which use the fsl_pq_mdio driver need to specify an address for TBI PHY transactions such that the address does not conflict with any PHYs on the bus (all transactions to that address are directed to the onboard TBI PHY). The driver used to scan for a free address if no address was specified, however this ran into issues when the PHY Lib was fixed so that all MDIO transactions were protected by a mutex. As it is, the code was meant to serve as a transitional tool until the device trees were all updated to specify the TBI address. The best fix for the mutex issue was to remove the scanning code, but it turns out some of the newer SoCs have started to omit the tbi-phy node when SGMII is not being used. As such, these devices will now fail unless we add a tbi-phy node to the first mdio controller. Signed-off-by: Andy Fleming aflem...@freescale.com --- This requires fsl_pq_mdio: Clean up tbi address configuration from the net tree in order to achieve its full effect. This needs to go into 3.2. I'm fine if the powerpc tree takes this one: Acked-by: David S. Miller da...@davemloft.net Will pull in via PPC tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
On Wed, 2011-12-07 at 09:25 +0100, Wolfgang Grandegger wrote: Also there have been at least 3 versions in a couple of days already without comments nor indication of what was changed... Unfortunately, no response from those sub-system guys. Can you clarify things a bit please ? It looks like they really should go to linuxppc-dev (and you can probably drop a bunch of other lists) or am I missing an important piece of the puzzle ? (Such as patch 1/4 and 2/4 ...) I have not sent the whole series. The changes are documented in the cover-letter, which I have not sent for those patches. Well, I think it's better to sent the whole series to all parties instead? Well at least for linuxppc-dev, don't bother now that I know what this is about :-) Let me know if I should just remove them from powerpc patchwork. Dave has already applied all patches. Sorry for the confusion. Any advice on how to handle multi subsystem series of patches properly is welcome. No specific advice. Ideally, if patchwork could track cover letters it would help but I don't see a non-nasty way to do it so ... :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ibm_newemac tx problem with jumbo frame enabled
On Wed, 2011-12-07 at 13:35 +0530, Prashant Bhole wrote: Still couldn't find anything like fifo overflow... I noticed one more thing, this problem happens only when mtu size on the initiator (the other end) is set to 4088, regardless of any mtu size set for EMAC. Did you check all the registers that may carry errors ? Nothing showed up ? Did you check that things like Pause frames were properly negociated on both sides ? Tried playing with the pause and FIFO thresholds ? Other than using the tx timeout to perform resets I don't see a good way to fix that problem. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] [v2] powerpc/85xx: p1022ds: disable the NOR flash node if video is enabled
The Freescale P1022 has a unique pin muxing feature where the DIU video
controller's video signals are muxed with 24 of the local bus address signals.
When the DIU is enabled, the bulk of the local bus is disabled, preventing
access to memory-mapped devices like NOR flash and the pixis FPGA.
Therefore, if the DIU is going to be enabled, then memory-mapped devices on
the localbus, like NOR flash, need to be disabled.
This also means that the localbus is not a 'simple-bus' any more, so remove
that string from the compatible node.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |6 ++-
arch/powerpc/platforms/85xx/p1022_ds.c | 71 +++
2 files changed, 76 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
index 16239b1..2a62edd 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
@@ -35,7 +35,11 @@
lbc {
#address-cells = 2;
#size-cells = 1;
- compatible = fsl,p1022-elbc, fsl,elbc, simple-bus;
+ /*
+* The localbus on the P1022 is not a simple-bus because of the eLBC
+* pin muxing when the DIU is enabled.
+*/
+ compatible = fsl,p1022-elbc, fsl,elbc;
interrupts = 19 2 0 0;
};
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 2ec39f4..6c9638c 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -360,6 +360,49 @@ void __init p1022_ds_pic_init(void)
void __init mpc85xx_smp_init(void);
#endif
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/*
+ * Disables a node in the device tree.
+ *
+ * This function is called before kmalloc() is available, so the 'new' object
+ * should be allocated in the global area. The easiest way is to do that is
+ * to allocate one static local variable for each call to this function.
+ */
+static void __init disable_one_node(struct device_node *np, struct property
*new)
+{
+ struct property *old;
+
+ old = of_find_property(np, new-name, NULL);
+ if (old)
+ prom_update_property(np, new, old);
+ else
+ prom_add_property(np, new);
+}
+
+/* TRUE if there is a video=fslfb command-line parameter. */
+static bool fslfb;
+
+/*
+ * Search for a video=fslfb command-line parameter, and set 'fslfb' to
+ * true if we find it.
+ *
+ * We need to use early_param() instead of __setup() because the normal
+ * __setup() gets called to late. However, early_param() gets called very
+ * early, before the device tree is unflattened, so all we can do now is set a
+ * global variable. Later on, p1022_ds_setup_arch() will use that variable
+ * to determine if we need to update the device tree.
+ */
+static int __init early_video_setup(char *options)
+{
+ fslfb = (strncmp(options, fslfb:, 6) == 0);
+
+ return 0;
+}
+early_param(video, early_video_setup);
+
+#endif
+
/*
* Setup the architecture
*/
@@ -397,6 +440,34 @@ static void __init p1022_ds_setup_arch(void)
diu_ops.set_monitor_port= p1022ds_set_monitor_port;
diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
diu_ops.valid_monitor_port = p1022ds_valid_monitor_port;
+
+ /*
+* Disable the NOR flash node if there is video=fslfb... command-line
+* parameter. When the DIU is active, NOR flash is unavailable, so we
+* have to delete the node before the MTD driver loads.
+*/
+ if (fslfb) {
+ struct device_node *np =
+ of_find_compatible_node(NULL, NULL, fsl,p1022-elbc);
+
+ if (np) {
+ np = of_find_compatible_node(np, NULL, cfi-flash);
+ if (np) {
+ static struct property nor_status = {
+ .name = status,
+ .value = disabled,
+ .length = sizeof(disabled),
+ };
+
+ pr_info(p1022ds: disabling %s node,
+ np-full_name);
+ disable_one_node(np, nor_status);
+ of_node_put(np);
+ }
+ }
+
+ }
+
#endif
#ifdef CONFIG_SMP
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx: create 32-bit DTS for the P1022DS
Create a 32-bit address space version of p1022ds.dts. To avoid confusion,
p1022ds.dts is renamed to p1022ds_36b.dts. We also create p1022ds.dtsi
to store some common nodes.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/boot/dts/p1022ds.dts | 270 -
arch/powerpc/boot/dts/p1022ds.dtsi| 112 ++
arch/powerpc/boot/dts/p1022ds_32b.dts | 218 ++
arch/powerpc/boot/dts/p1022ds_36b.dts | 218 ++
4 files changed, 548 insertions(+), 270 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/p1022ds.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds.dtsi
create mode 100644 arch/powerpc/boot/dts/p1022ds_32b.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds_36b.dts
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boot/dts/p1022ds.dts
deleted file mode 100644
index a54dd13..000
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ /dev/null
@@ -1,270 +0,0 @@
-/*
- * P1022 DS 36Bit Physical Address Map Device Tree Source
- *
- * Copyright 2010 Freescale Semiconductor, Inc.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed as is without any warranty of any
- * kind, whether express or implied.
- */
-
-/include/ fsl/p1022si-pre.dtsi
-/ {
- model = fsl,P1022DS;
- compatible = fsl,P1022DS;
-
- memory {
- device_type = memory;
- };
-
- lbc: localbus@fffe05000 {
- reg = 0xf 0xffe05000 0 0x1000;
- ranges = 0x0 0x0 0xf 0xe800 0x0800
- 0x1 0x0 0xf 0xe000 0x0800
- 0x2 0x0 0xf 0xff80 0x0004
- 0x3 0x0 0xf 0xffdf 0x8000;
-
- /*
-* This node is used to access the pixis via indirect mode,
-* which is done by writing the pixis register index to chip
-* select 0 and the value to/from chip select 1. Indirect
-* mode is the only way to access the pixis when DIU video
-* is enabled. Note that this assumes that the first column
-* of the 'ranges' property above is the chip select number.
-*/
- board-control@0,0 {
- compatible = fsl,p1022ds-indirect-pixis;
- reg = 0x0 0x0 1/* CS0 */
- 0x1 0x0 1; /* CS1 */
- };
-
- nor@0,0 {
- #address-cells = 1;
- #size-cells = 1;
- compatible = cfi-flash;
- reg = 0x0 0x0 0x800;
- bank-width = 2;
- device-width = 1;
-
- partition@0 {
- reg = 0x0 0x0300;
- label = ramdisk-nor;
- read-only;
- };
-
- partition@300 {
- reg = 0x0300 0x00e0;
- label = diagnostic-nor;
- read-only;
- };
-
- partition@3e0 {
- reg = 0x03e0 0x0020;
- label = dink-nor;
- read-only;
- };
-
- partition@400 {
- reg = 0x0400 0x0040;
- label = kernel-nor;
- read-only;
- };
-
- partition@440 {
- reg = 0x0440 0x03b0;
- label = jffs2-nor;
- };
-
- partition@7f0 {
- reg = 0x07f0 0x0008;
- label = dtb-nor;
- read-only;
- };
-
- partition@7f8 {
- reg = 0x07f8 0x0008;
- label = u-boot-nor;
- read-only;
- };
- };
-
- nand@2,0 {
- #address-cells = 1;
- #size-cells = 1;
- compatible = fsl,elbc-fcm-nand;
- reg = 0x2 0x0 0x4;
-
- partition@0 {
- reg = 0x0 0x0200;
- label = u-boot-nand;
- read-only;
- };
-
- partition@200 {
- reg = 0x0200 0x1000;
- label = jffs2-nand;
-
Re: [PATCH 2/2] powerpc/85xx: create 32-bit DTS for the P1022DS
On 12/07/2011 06:04 PM, Timur Tabi wrote:
+ /*
+ * This node is used to access the pixis via indirect mode,
+ * which is done by writing the pixis register index to chip
+ * select 0 and the value to/from chip select 1. Indirect
+ * mode is the only way to access the pixis when DIU video
+ * is enabled. Note that this assumes that the first column
+ * of the 'ranges' property above is the chip select number.
+ */
+ board-control@0,0 {
+ compatible = fsl,p1022ds-indirect-pixis;
+ reg = 0x0 0x0 1/* CS0 */
+0x1 0x0 1; /* CS1 */
+ };
[snip]
+ board-control@3,0 {
+ compatible = fsl,p1022ds-fpga, fsl,fpga-ngpixis;
+ reg = 3 0 0x30;
+ interrupt-parent = mpic;
+ /*
+ * IRQ8 is generated if the EVENT switch is pressed
+ * and PX_CTL[EVESEL] is set to 00.
+ */
+ interrupts = 8 8 0 0;
+ };
It's not new to this patch, but... what does 8 mean in the second cell
of an mpic interrupt specifier? And why does the indirect pixis node
not have the interrupt?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: create 32-bit DTS for the P1022DS
Scott Wood wrote: +interrupts =8 8 0 0; + }; It's not new to this patch, but... what does 8 mean in the second cell of an mpic interrupt specifier? I have no idea. And why does the indirect pixis node not have the interrupt? Hmmm... I suppose I could add it, but I don't know what good it would do. The code that's looking for the interrupt is probing on fsl,p1022ds-fpga. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller
Best Regards,
Shengzhou Liu
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, December 08, 2011 1:16 AM
To: Liu Shengzhou-B36685
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
m...@lists.infradead.org; dw...@infradead.org; Gala Kumar-B11780
Subject: Re: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND
controller
On 12/06/2011 09:16 PM, Liu Shengzhou-B36685 wrote:
+ out_be32(lbc-fbcr, 8);
+ elbc_fcm_ctrl-read_bytes = 8;
+ } else {
+ out_be32(lbc-fbcr, 256);
+ elbc_fcm_ctrl-read_bytes = 256;
+ }
Any harm in always using 256?
-Scott
[Shengzhou] For NAND_CMD_READID command, the total bytes of entire ID
string are 8, there are not 256 bytes so many, it's unnecessary and looks
not so well logically to always using 256, though it works.
It's not performance critical, and always using 256 keeps things simpler,
and more robust if the length of the ID string grows in the future (we
used to assume it was 5 bytes...).
-Scott
[Shengzhou] OK.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/16 v3] pmac_zilog: fix unexpected irq
On Wed, 2011-12-07 at 14:49 +1100, Finn Thain wrote:
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
Thanks. I'll test it on a powermac or two and will merge it via the
powerpc -next tree if it works out allright.
Cheers,
Ben.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC interrupts at the chip but doesn't
ack them. Then when a pmac_zilog port is used, the machine locks up with
unexpected interrupt.
This can happen in pmz_shutdown() since the irq is freed before the
channel interrupts are disabled.
Fix this by clearing interrupt enable bits before the handler is
uninstalled. Also move the interrupt control bit flipping into a separate
pmz_interrupt_control() routine. Replace all instances of these operations
with calls to this routine. Omit the zssync() calls that seem to serve no
purpose.
Signed-off-by: Finn Thain fth...@telegraphics.com.au
Acked-by: Alan Cox a...@linux.intel.com
---
Re-implemented as v2 using a simpler approach that avoids messing with the
Master Interrupt Enable bit. As well as the ifdef problem, it turns out
that v1 was not sufficient to entirely fix the problem.
v3 avoids needless changes to the logic and locking in the suspend and
shutdown code and tries to keep register writes closer to their original
sequence.
This patch has been tested on a PowerBook 520 but no PowerMacs yet.
Index: linux-git/drivers/tty/serial/pmac_zilog.c
===
--- linux-git.orig/drivers/tty/serial/pmac_zilog.c2011-12-07
12:36:32.0 +1100
+++ linux-git/drivers/tty/serial/pmac_zilog.c 2011-12-07 14:29:21.0
+1100
@@ -216,6 +216,18 @@ static void pmz_maybe_update_regs(struct
}
}
+static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
+{
+ if (enable) {
+ uap-curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
+ if (!ZS_IS_EXTCLK(uap))
+ uap-curregs[1] |= EXT_INT_ENAB;
+ } else {
+ uap-curregs[1] = ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
+ }
+ write_zsreg(uap, R1, uap-curregs[1]);
+}
+
static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
{
struct tty_struct *tty = NULL;
@@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
return tty;
flood:
- uap-curregs[R1] = ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap-curregs[R1]);
- zssync(uap);
+ pmz_interrupt_control(uap, 0);
pmz_error(pmz: rx irq flood !\n);
return tty;
}
@@ -990,12 +1000,9 @@ static int pmz_startup(struct uart_port
if (ZS_IS_IRDA(uap))
pmz_irda_reset(uap);
- /* Enable interrupts emission from the chip */
+ /* Enable interrupt requests for the channel */
spin_lock_irqsave(port-lock, flags);
- uap-curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap-curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap-curregs[R1]);
+ pmz_interrupt_control(uap, 1);
spin_unlock_irqrestore(port-lock, flags);
pmz_debug(pmz: startup() done.\n);
@@ -1015,6 +1022,25 @@ static void pmz_shutdown(struct uart_por
mutex_lock(pmz_irq_mutex);
+ spin_lock_irqsave(port-lock, flags);
+
+ if (!ZS_IS_ASLEEP(uap)) {
+ /* Disable interrupt requests for the channel */
+ pmz_interrupt_control(uap, 0);
+
+ if (!ZS_IS_CONS(uap)) {
+ /* Disable receiver and transmitter */
+ uap-curregs[R3] = ~RxENABLE;
+ uap-curregs[R5] = ~TxENABLE;
+
+ /* Disable break assertion */
+ uap-curregs[R5] = ~SND_BRK;
+ pmz_maybe_update_regs(uap);
+ }
+ }
+
+ spin_unlock_irqrestore(port-lock, flags);
+
/* Release interrupt handler */
free_irq(uap-port.irq, uap);
@@ -1025,29 +1051,8 @@ static void pmz_shutdown(struct uart_por
if (!ZS_IS_OPEN(uap-mate))
pmz_get_port_A(uap)-flags = ~PMACZILOG_FLAG_IS_IRQ_ON;
- /* Disable interrupts */
- if (!ZS_IS_ASLEEP(uap)) {
- uap-curregs[R1] = ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap-curregs[R1]);
- zssync(uap);
- }
-
- if (ZS_IS_CONS(uap) || ZS_IS_ASLEEP(uap)) {
- spin_unlock_irqrestore(port-lock, flags);
- mutex_unlock(pmz_irq_mutex);
- return;
- }
-
- /* Disable receiver and transmitter. */
- uap-curregs[R3] = ~RxENABLE;
- uap-curregs[R5] = ~TxENABLE;
-
- /* Disable all interrupts and BRK assertion. */
- uap-curregs[R5] = ~SND_BRK;
-
Re: [PATCH] powerpc: Fix swiotlb ops for ppc64
On Wed, 2011-12-07 at 11:19 -0600, Kumar Gala wrote:
struct dma_map_ops swiotlb_dma_ops = {
+#ifdef CONFIG_PPC64
+ .alloc_coherent = swiotlb_alloc_coherent,
+ .free_coherent = swiotlb_free_coherent,
+#else
.alloc_coherent = dma_direct_alloc_coherent,
.free_coherent = dma_direct_free_coherent,
+#endif
.map_sg = swiotlb_map_sg_attrs,
.unmap_sg = swiotlb_unmap_sg_attrs,
.dma_supported = swiotlb_dma_supported,
Do we really need the ifdef ? What happens if we use
swiotlb_alloc_coherent() on ppc32 ? Won't it allocate lowmem, realize
that it doesn't need bouncing and be happy ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
-Original Message- From: Wood Scott-B07421 Sent: Thursday, December 08, 2011 1:17 AM To: Liu Shengzhou-B36685 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux- m...@lists.infradead.org; dw...@infradead.org; Gala Kumar-B11780 Subject: Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller On 12/07/2011 12:30 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, December 07, 2011 1:16 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org; linux-...@lists.infradead.org; dw...@infradead.org; Gala Kumar-B11780 Subject: Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller On 12/06/2011 02:54 AM, Shengzhou Liu wrote: There was a bug for fmr initialization, which lead to fmr was always 0x100 in fsl_elbc_chip_init() and caused FCM command timeout before calling fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value and not relying on the setting of bootloader. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v2: make fmr not relying on the setting of bootloader. drivers/mtd/nand/fsl_elbc_nand.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index eedd8ee..4f405a0 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -659,9 +659,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd) if (chip-pagemask 0xff00) al++; - /* add to ECCM mode set in fsl_elbc_init */ - priv-fmr |= (12 FMR_CWTO_SHIFT) | /* Timeout 12 ms */ - (al FMR_AL_SHIFT); + priv-fmr |= al FMR_AL_SHIFT; dev_dbg(priv-dev, fsl_elbc_init: nand-numchips = %d\n, chip-numchips); @@ -764,8 +762,10 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv) priv-mtd.priv = chip; priv-mtd.owner = THIS_MODULE; - /* Set the ECCM according to the settings in bootloader.*/ - priv-fmr = in_be32(lbc-fmr) FMR_ECCM; + /* set timeout to maximum */ + priv-fmr = 15 FMR_CWTO_SHIFT; + if (in_be32(lbc-bank[priv-bank].or) OR_FCM_PGS) + priv-fmr |= FMR_ECCM; Please do not change the way ECCM is handled. We probably should have done it this way from the start, but at this point it breaks compatibility if you have a large page flash and the firmware didn't touch NAND. -Scott [Shengzhou] This patch doesn't change the way ECCM is handled, it's still same as before, just make sure CWTO timeout is set to maximum. It does change it. It used to use the existing value in FMR, and now it sets it based on ORn[PGS]. -Scott [Shengzhou] In u-boot: #ifdef CONFIG_FSL_ELBC_FMR priv-fmr = CONFIG_FSL_ELBC_FMR; #else priv-fmr = (15 FMR_CWTO_SHIFT) | (2 FMR_AL_SHIFT); or = in_be32(elbc_ctrl-regs-bank[priv-bank].or); if (or OR_FCM_PGS) priv-fmr |= FMR_ECCM; #endif In kernel: It used to be priv-fmr = in_be32(lbc-fmr) FMR_ECCM , so fmr was always 0x100(or 0,depend on ORn[PGS]), CWTO was 0(timeout was minimum). In this patch, for not relying on bootloader, fmr is initialized as what u-boot does, except FMR_AL_SHIFT is handled in fsl_elbc_chip_init_tail and without definition of CONFIG_FSL_ELBC_FMR. So, it doesn't change it. Do we still need CONFIG_FSL_ELBC_FMR in kernel? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/16 v3] pmac_zilog: fix unexpected irq
On Wed, 2011-12-07 at 14:49 +1100, Finn Thain wrote: On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be masked. This can be a problem when pmac_zilog starts up. For example, the serial debugging code in arch/m68k/kernel/head.S may be used beforehand. It disables the SCC interrupts at the chip but doesn't ack them. Then when a pmac_zilog port is used, the machine locks up with unexpected interrupt. This can happen in pmz_shutdown() since the irq is freed before the channel interrupts are disabled. Fix this by clearing interrupt enable bits before the handler is uninstalled. Also move the interrupt control bit flipping into a separate pmz_interrupt_control() routine. Replace all instances of these operations with calls to this routine. Omit the zssync() calls that seem to serve no purpose. Signed-off-by: Finn Thain fth...@telegraphics.com.au Acked-by: Alan Cox a...@linux.intel.com --- So basic operations seem to work, I've applied the patch to powerpc-next. However, the internal modem on my Pismo powerbook doesn't appear to survive suspend/resume. I'll dig into that and merge a fixup patch asap. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/16 v3] pmac_zilog: fix unexpected irq
On Thu, 2011-12-08 at 15:20 +1100, Benjamin Herrenschmidt wrote: So basic operations seem to work, I've applied the patch to powerpc-next. However, the internal modem on my Pismo powerbook doesn't appear to survive suspend/resume. I'll dig into that and merge a fixup patch asap. BTW. I applied anyway because suspend/resume was already broken (you spotted that we don't clear the suspended flag for example). Fixing the flag alone helps a bit. We can't use the modem if we suspend/resume with the open port, but closing and re-opening works. Lockdep also picked-up a A-B B-A between the port mutex and the pmz irq mutex on suspend. I'll try to fix all these, and will let you know (I may not have time today). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
Implement a POWER7 optimised copy_to_user/copy_from_user using VMX. For large aligned copies this new loop is over 10% faster, and for large unaligned copies it is over 200% faster. If we take a fault we fall back to the old version, this keeps things relatively simple and easy to verify. On POWER7 unaligned stores rarely slow down - they only flush when a store crosses a 4KB page boundary. Furthermore this flush is handled completely in hardware and should be 20-30 cycles. Unaligned loads on the other hand flush much more often - whenever crossing a 128 byte cache line, or a 32 byte sector if either sector is an L1 miss. Considering this information we really want to get the loads aligned and not worry about the alignment of the stores. Microbenchmarks confirm that this approach is much faster than the current unaligned copy loop that uses shifts and rotates to ensure both loads and stores are aligned. We also want to try and do the stores in cacheline aligned, cacheline sized chunks. If the store queue is unable to merge an entire cacheline of stores then the L2 cache will have to do a read/modify/write. Even worse, we will serialise this with the stores in the next iteration of the copy loop since both iterations hit the same cacheline. Based on this, the new loop does the following things: 1 - 127 bytes Get the source 8 byte aligned and use 8 byte loads and stores. Pretty boring and similar to how the current loop works. 128 - 4095 bytes Get the source 8 byte aligned and use 8 byte loads and stores, 1 cacheline at a time. We aren't doing the stores in cacheline aligned chunks so we will potentially serialise once per cacheline. Even so it is much better than the loop we have today. 4096 - bytes If both source and destination have the same alignment get them both 16 byte aligned, then get the destination cacheline aligned. Do cacheline sized loads and stores using VMX. If source and destination do not have the same alignment, we get the destination cacheline aligned, and use permute to do aligned loads. In both cases the VMX loop should be optimal - we always do aligned loads and stores and are always doing stores in cacheline aligned, cacheline sized chunks. To be able to use VMX we must be careful about interrupts and sleeping. We don't use the VMX loop when in an interrupt (which should be rare anyway) and we wrap the VMX loop in disable/enable_pagefault and fall back to the existing copy_tofrom_user loop if we do need to sleep. The VMX breakpoint of 4096 bytes was chosen using this microbenchmark: http://ozlabs.org/~anton/junkcode/copy_to_user.c Since we are using VMX and there is a cost to saving and restoring the user VMX state there are two broad cases we need to benchmark: - Best case - userspace never uses VMX - Worst case - userspace always uses VMX In reality a userspace process will sit somewhere between these two extremes. Since we need to test both aligned and unaligned copies we end up with 4 combinations. The point at which the VMX loop begins to win is: 0% VMX aligned 2048 bytes unaligned 2048 bytes 100% VMX aligned 16384 bytes unaligned 8192 bytes Considering this is a microbenchmark, the data is hot in cache and the VMX loop has better store queue merging properties we set the breakpoint to 4096 bytes, a little below the unaligned breakpoints. Some future optimisations we can look at: - Looking at the perf data, a significant part of the cost when a task is always using VMX is the extra exception we take to restore the VMX state. As such we should do something similar to the x86 optimisation that restores FPU state for heavy users. ie: /* * If the task has used fpu the last 5 timeslices, just do a full * restore of the math state immediately to avoid the trap; the * chances of needing FPU soon are obviously high now */ preload_fpu = tsk_used_math(next_p) next_p-fpu_counter 5; and /* * fpu_counter contains the number of consecutive context switches * that the FPU is used. If this is over a threshold, the lazy fpu * saving becomes unlazy to save the trap. This is an unsigned char * so that after 256 times the counter wraps and the behavior turns * lazy again; this to deal with bursty apps that only use FPU for * a short time */ - We could create a paca bit to mirror the VMX enabled MSR bit and check that first, avoiding multiple calls to calling enable_kernel_altivec. That should help with iovec based system calls like readv. - We could have two VMX breakpoints, one for when we know the user VMX state is loaded into the registers and one when it isn't. This could be a second bit in the paca so we can calculate the break points quickly. - One suggestion from Ben was to save and restore the VSX registers we use inline instead of using enable_kernel_altivec. Signed-off-by: Anton Blanchard
Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
On Dec 7, 2011, at 11:02 PM, Anton Blanchard wrote: Index: linux-build/arch/powerpc/include/asm/cputable.h === --- linux-build.orig/arch/powerpc/include/asm/cputable.h 2011-09-07 15:15:49.096458526 +1000 +++ linux-build/arch/powerpc/include/asm/cputable.h 2011-12-08 15:38:46.627313507 +1100 @@ -201,6 +201,7 @@ extern const char *powerpc_base_platform #define CPU_FTR_POPCNTB LONG_ASM_CONST(0x0400) #define CPU_FTR_POPCNTD LONG_ASM_CONST(0x0800) #define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000) +#define CPU_FTR_POWER7 LONG_ASM_CONST(0x2000) #ifndef __ASSEMBLY__ @@ -425,7 +426,7 @@ extern const char *powerpc_base_platform CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \ CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \ - CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE) + CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_POWER7) #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \ Index: linux-build/arch/powerpc/lib/copyuser_64.S === --- linux-build.orig/arch/powerpc/lib/copyuser_64.S 2011-09-07 15:15:49.146459439 +1000 +++ linux-build/arch/powerpc/lib/copyuser_64.S2011-12-08 15:38:42.491238635 +1100 @@ -11,6 +11,12 @@ .align 7 _GLOBAL(__copy_tofrom_user) +BEGIN_FTR_SECTION + nop +FTR_SECTION_ELSE + b __copy_tofrom_user_power7 +ALT_FTR_SECTION_END_IFCLR(CPU_FTR_POWER7) +_GLOBAL(__copy_tofrom_user_base) /* first check for a whole page copy on a page boundary */ cmpldi cr1,r5,16 cmpdi cr6,r5,4096 Can we find a means to do the fixup that does NOT require a FTR bit? I have the feeling FSL will want to have various optimized copy functions for our different cores and I hate to blow features bits just for this. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix swiotlb ops for ppc64
On Dec 7, 2011, at 9:23 PM, Benjamin Herrenschmidt wrote:
On Wed, 2011-12-07 at 11:19 -0600, Kumar Gala wrote:
struct dma_map_ops swiotlb_dma_ops = {
+#ifdef CONFIG_PPC64
+.alloc_coherent = swiotlb_alloc_coherent,
+.free_coherent = swiotlb_free_coherent,
+#else
.alloc_coherent = dma_direct_alloc_coherent,
.free_coherent = dma_direct_free_coherent,
+#endif
.map_sg = swiotlb_map_sg_attrs,
.unmap_sg = swiotlb_unmap_sg_attrs,
.dma_supported = swiotlb_dma_supported,
Do we really need the ifdef ? What happens if we use
swiotlb_alloc_coherent() on ppc32 ? Won't it allocate lowmem, realize
that it doesn't need bouncing and be happy ?
Cheers,
Ben.
Becky any comment?
I know its been a while, but wondering if you had any reason to not do what
Ben's suggesting ?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
snip +#define CPU_FTR_POWER7 = LONG_ASM_CONST(0x2000) snip Can we find a means to do the fixup that does NOT require a FTR bit? I have the feeling FSL will want to have various optimized copy functions for our different cores and I hate to blow features bits just for this. +1 I hate the idea of having a POWER7 FTR bit. Every loon will (and has tried to in the past) attach every POWER7 related thing to it, rather than thinking about what the feature really is for. What about other processors which could also benefit from this copy loop? Turning on CPU_FTR_POWER7 for them is gonna look a bit silly. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
Hi, I hate the idea of having a POWER7 FTR bit. Every loon will (and has tried to in the past) attach every POWER7 related thing to it, rather than thinking about what the feature really is for. What about other processors which could also benefit from this copy loop? Turning on CPU_FTR_POWER7 for them is gonna look a bit silly. As we discussed online, we could call it CPU_FTR_VMX_COPY and start thinking about a better way to solve the CPU feature bit mess. One idea would be to have a structure of function pointers for each CPU that gets runtime patched into the right places, similar to how we do some of the MMU fixups. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix compile error with 85xx/p1023_rds.c
Current linux-next compiled with mpc85xx_smp_defconfig causes this: arch/powerpc/platforms/85xx/p1023_rds.c: In function 'mpc85xx_rds_pic_init': arch/powerpc/platforms/85xx/p1023_rds.c:102:14: error: 'np' undeclared (first use in this function) arch/powerpc/platforms/85xx/p1023_rds.c:102:14: note: each undeclared identifier is reported only once for each function it appears in Introduced in: commit 996983b75cebb1bc1c2c545f20336f24ebfa17af Author: Kyle Moffett kyle.d.moff...@boeing.com Date: Fri Dec 2 06:28:02 2011 + powerpc/mpic: Search for open-pic device-tree node if NULL Signed-off-by: Michael Neuling mi...@neuling.org diff --git a/arch/powerpc/platforms/85xx/p1023_rds.c b/arch/powerpc/platforms/85xx/p1023_rds.c index e92a714..d951e70 100644 --- a/arch/powerpc/platforms/85xx/p1023_rds.c +++ b/arch/powerpc/platforms/85xx/p1023_rds.c @@ -99,7 +99,6 @@ static void __init mpc85xx_rds_pic_init(void) 0, 256, OpenPIC ); BUG_ON(mpic == NULL); - of_node_put(np); mpic_init(mpic); } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
Implement a POWER7 optimised copy_to_user/copy_from_user using VMX. For large aligned copies this new loop is over 10% faster, and for large unaligned copies it is over 200% faster. If we take a fault we fall back to the old version, this keeps things relatively simple and easy to verify. On POWER7 unaligned stores rarely slow down - they only flush when a store crosses a 4KB page boundary. Furthermore this flush is handled completely in hardware and should be 20-30 cycles. Unaligned loads on the other hand flush much more often - whenever crossing a 128 byte cache line, or a 32 byte sector if either sector is an L1 miss. Considering this information we really want to get the loads aligned and not worry about the alignment of the stores. Microbenchmarks confirm that this approach is much faster than the current unaligned copy loop that uses shifts and rotates to ensure both loads and stores are aligned. We also want to try and do the stores in cacheline aligned, cacheline sized chunks. If the store queue is unable to merge an entire cacheline of stores then the L2 cache will have to do a read/modify/write. Even worse, we will serialise this with the stores in the next iteration of the copy loop since both iterations hit the same cacheline. Based on this, the new loop does the following things: 1 - 127 bytes Get the source 8 byte aligned and use 8 byte loads and stores. Pretty boring and similar to how the current loop works. 128 - 4095 bytes Get the source 8 byte aligned and use 8 byte loads and stores, 1 cacheline at a time. We aren't doing the stores in cacheline aligned chunks so we will potentially serialise once per cacheline. Even so it is much better than the loop we have today. 4096 - bytes If both source and destination have the same alignment get them both 16 byte aligned, then get the destination cacheline aligned. Do cacheline sized loads and stores using VMX. If source and destination do not have the same alignment, we get the destination cacheline aligned, and use permute to do aligned loads. In both cases the VMX loop should be optimal - we always do aligned loads and stores and are always doing stores in cacheline aligned, cacheline sized chunks. To be able to use VMX we must be careful about interrupts and sleeping. We don't use the VMX loop when in an interrupt (which should be rare anyway) and we wrap the VMX loop in disable/enable_pagefault and fall back to the existing copy_tofrom_user loop if we do need to sleep. The VMX breakpoint of 4096 bytes was chosen using this microbenchmark: http://ozlabs.org/~anton/junkcode/copy_to_user.c Since we are using VMX and there is a cost to saving and restoring the user VMX state there are two broad cases we need to benchmark: - Best case - userspace never uses VMX - Worst case - userspace always uses VMX In reality a userspace process will sit somewhere between these two extremes. Since we need to test both aligned and unaligned copies we end up with 4 combinations. The point at which the VMX loop begins to win is: 0% VMX aligned 2048 bytes unaligned 2048 bytes 100% VMX aligned 16384 bytes unaligned 8192 bytes Considering this is a microbenchmark, the data is hot in cache and the VMX loop has better store queue merging properties we set the breakpoint to 4096 bytes, a little below the unaligned breakpoints. Some future optimisations we can look at: - Looking at the perf data, a significant part of the cost when a task is always using VMX is the extra exception we take to restore the VMX state. As such we should do something similar to the x86 optimisation that restores FPU state for heavy users. ie: /* * If the task has used fpu the last 5 timeslices, just do a full * restore of the math state immediately to avoid the trap; the * chances of needing FPU soon are obviously high now */ preload_fpu = tsk_used_math(next_p) next_p-fpu_counter 5; and /* * fpu_counter contains the number of consecutive context switches * that the FPU is used. If this is over a threshold, the lazy fpu * saving becomes unlazy to save the trap. This is an unsigned char * so that after 256 times the counter wraps and the behavior turns * lazy again; this to deal with bursty apps that only use FPU for * a short time */ - We could create a paca bit to mirror the VMX enabled MSR bit and check that first, avoiding multiple calls to calling enable_kernel_altivec. That should help with iovec based system calls like readv. - We could have two VMX breakpoints, one for when we know the user VMX state is loaded into the registers and one when it isn't. This could be a second bit in the paca so we can calculate the break points quickly. - One suggestion from Ben was to save and restore the VSX registers we use inline instead of using enable_kernel_altivec. Signed-off-by: Anton Blanchard
RE: Multi-OS on P1022RDK Failing
Thanks Scott. Fixing cpu 1 release address solved my problem. Also thanks for the CONFIG_LOWMEM_SIZE suggestions. Regards, Farrukh Arshad -Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Thursday, December 08, 2011 2:24 AM To: Arshad, Farrukh Cc: Linuxppc-dev@lists.ozlabs.org Subject: Re: Multi-OS on P1022RDK Failing On 12/07/2011 08:57 AM, Arshad, Farrukh wrote: Core 0 kernel CONFIG_LOWMEM_SIZE = 0x1000 CONFIG_PHYSICAL_START = 0x Core 1 kernel CONFIG_LOWMEM_SIZE = 0x1000 CONFIG_PHYSICAL_START = 0x1000 Why are you messing with CONFIG_LOWMEM_SIZE? That adjusts the lowmem/highmem split, not the total amount of memory that this instance of Linux will use (though you may get that behavior as a side effect if highmem is disabled). U-boot should set the memory node in the device tree based on the bootm_low/bootm_size environment variables. # Boot from NFS setenv core0nfsbootargs root=/dev/nfs nfsroot=$serverip:/$core0rootfs ip=dev_ip::nfs_server_ip:::eth0:off rw debug console=$consoledev0,$baudrate maxcpus=1 setenv core1nfsbootargs root=/dev/nfs nfsroot=$serverip:/$core1rootfs ip=dev_ip_2::nfs_server_ip:::eth0:off rw debug console=$consoledev0,$baudrate maxcpus=1 maxcpus should be unnecessary -- there will only be one cpu in the device tree for each partition. My problem is Core 0 kernel is booting successfully but Core 1 kernel hangs after uncompressing kernel image, and after that I don't see anything on the console. Any thoughts on what I am missing or doing incorrect? The cpu 1 release command should be using the address of the decompressed kernel (should be $bootm_low), not where the uImage was loaded. Also, the two serial ports you're using share an interrupt -- this shouldn't stop kernel message output, but it's going to be a problem for userspace usage of the port. You should remove the interrupts property from the serial node in both partitions, so Linux will poll instead. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl: update compatiable on fsl 16550 uart nodes
The Freescale serial port's are pretty much a 16550, however there are
some FSL specific bugs and features. Add a fsl,ns16550 compatiable
string to allow code to handle those FSL specific issues.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/asp834x-redboot.dts|4 ++--
arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi |4 ++--
arch/powerpc/boot/dts/fsl/qoriq-duart-0.dtsi |4 ++--
arch/powerpc/boot/dts/fsl/qoriq-duart-1.dtsi |4 ++--
arch/powerpc/boot/dts/gef_ppc9a.dts |4 ++--
arch/powerpc/boot/dts/gef_sbc310.dts |4 ++--
arch/powerpc/boot/dts/gef_sbc610.dts |4 ++--
arch/powerpc/boot/dts/kmeter1.dts|2 +-
arch/powerpc/boot/dts/kuroboxHD.dts |4 ++--
arch/powerpc/boot/dts/kuroboxHG.dts |4 ++--
arch/powerpc/boot/dts/mpc8308_p1m.dts|4 ++--
arch/powerpc/boot/dts/mpc8308rdb.dts |4 ++--
arch/powerpc/boot/dts/mpc8313erdb.dts|4 ++--
arch/powerpc/boot/dts/mpc8315erdb.dts|4 ++--
arch/powerpc/boot/dts/mpc832x_mds.dts|4 ++--
arch/powerpc/boot/dts/mpc832x_rdb.dts|4 ++--
arch/powerpc/boot/dts/mpc8349emitx.dts |4 ++--
arch/powerpc/boot/dts/mpc8349emitxgp.dts |4 ++--
arch/powerpc/boot/dts/mpc834x_mds.dts|4 ++--
arch/powerpc/boot/dts/mpc836x_mds.dts|4 ++--
arch/powerpc/boot/dts/mpc836x_rdk.dts|4 ++--
arch/powerpc/boot/dts/mpc8377_mds.dts|4 ++--
arch/powerpc/boot/dts/mpc8377_rdb.dts|4 ++--
arch/powerpc/boot/dts/mpc8377_wlan.dts |4 ++--
arch/powerpc/boot/dts/mpc8378_mds.dts|4 ++--
arch/powerpc/boot/dts/mpc8378_rdb.dts|4 ++--
arch/powerpc/boot/dts/mpc8379_mds.dts|4 ++--
arch/powerpc/boot/dts/mpc8379_rdb.dts|4 ++--
arch/powerpc/boot/dts/mpc8540ads.dts |4 ++--
arch/powerpc/boot/dts/mpc8541cds.dts |4 ++--
arch/powerpc/boot/dts/mpc8555cds.dts |4 ++--
arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++--
arch/powerpc/boot/dts/mpc8641_hpcn.dts |4 ++--
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts |4 ++--
arch/powerpc/boot/dts/sbc8349.dts|4 ++--
arch/powerpc/boot/dts/sbc8548.dts|4 ++--
arch/powerpc/boot/dts/sbc8641d.dts |4 ++--
arch/powerpc/boot/dts/socrates.dts |4 ++--
arch/powerpc/boot/dts/storcenter.dts |4 ++--
arch/powerpc/boot/dts/stxssa8555.dts |4 ++--
arch/powerpc/boot/dts/tqm8540.dts|4 ++--
arch/powerpc/boot/dts/tqm8541.dts|4 ++--
arch/powerpc/boot/dts/tqm8548-bigflash.dts |4 ++--
arch/powerpc/boot/dts/tqm8548.dts|4 ++--
arch/powerpc/boot/dts/tqm8555.dts|4 ++--
arch/powerpc/boot/dts/xcalibur1501.dts |4 ++--
arch/powerpc/boot/dts/xpedite5200.dts|4 ++--
arch/powerpc/boot/dts/xpedite5200_xmon.dts |4 ++--
arch/powerpc/boot/dts/xpedite5301.dts|4 ++--
arch/powerpc/boot/dts/xpedite5330.dts|4 ++--
arch/powerpc/boot/dts/xpedite5370.dts|4 ++--
51 files changed, 101 insertions(+), 101 deletions(-)
diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts
b/arch/powerpc/boot/dts/asp834x-redboot.dts
index 261d10c..227290d 100644
--- a/arch/powerpc/boot/dts/asp834x-redboot.dts
+++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
@@ -256,7 +256,7 @@
serial0: serial@4500 {
cell-index = 0;
device_type = serial;
- compatible = ns16550;
+ compatible = fsl,ns16550, ns16550;
reg = 0x4500 0x100;
clock-frequency = 4;
interrupts = 9 0x8;
@@ -266,7 +266,7 @@
serial1: serial@4600 {
cell-index = 1;
device_type = serial;
- compatible = ns16550;
+ compatible = fsl,ns16550, ns16550;
reg = 0x4600 0x100;
clock-frequency = 4;
interrupts = 10 0x8;
diff --git a/arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi
index 00fa1fd..5e268fd 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi
@@ -35,7 +35,7 @@
serial0: serial@4500 {
cell-index = 0;
device_type = serial;
- compatible = ns16550;
+ compatible = fsl,ns16550, ns16550;
reg = 0x4500 0x100;
clock-frequency = 0;
interrupts = 42 2 0 0;
@@ -44,7 +44,7 @@ serial0: serial@4500 {
serial1: serial@4600 {
cell-index = 1;
device_type = serial;
- compatible = ns16550;
+ compatible = fsl,ns16550, ns16550;
reg = 0x4600 0x100;
[PATCH] PPC: Add __SANE_USERSPACE_TYPES__ to asm/types.h for LL64
PPC64 uses long long for u64 in the kernel, but powerpc's asm/types.h prevents 64-bit userland from seeing this definition, instead defaulting to u64 == long in userspace. Some user programs (e.g. kvmtool) may actually want LL64, so this patch adds a check for __SANE_USERSPACE_TYPES__ so that, if defined, int-ll64.h is included instead. Signed-off-by: Matt Evans m...@ozlabs.org --- arch/powerpc/include/asm/types.h |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h index 8947b98..d82e94e 100644 --- a/arch/powerpc/include/asm/types.h +++ b/arch/powerpc/include/asm/types.h @@ -5,8 +5,11 @@ * This is here because we used to use l64 for 64bit powerpc * and we don't want to impact user mode with our change to ll64 * in the kernel. + * + * However, some user programs are fine with this. They can + * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here. */ -#if defined(__powerpc64__) !defined(__KERNEL__) +#if !defined(__SANE_USERSPACE_TYPES__) defined(__powerpc64__) !defined(__KERNEL__) # include asm-generic/int-l64.h #else # include asm-generic/int-ll64.h -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl: Update defconfigs to enable some standard FSL HW features
corenet64_smp_defconfig: - enabled rapidio corenet32_smp_defconfig: - enabled hugetlbfs, rapidio mpc85xx_smp_defconfig: - enabled P1010RDB, hugetlbfs, SPI, SDHC, Crypto/CAAM mpc85xx_smp_defconfig: - enabled hugetlbfs, SPI, SDHC, Crypto/CAAM Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/configs/corenet32_smp_defconfig | 10 ++ arch/powerpc/configs/corenet64_smp_defconfig |3 ++- arch/powerpc/configs/mpc85xx_defconfig | 17 - arch/powerpc/configs/mpc85xx_smp_defconfig | 18 +- 4 files changed, 33 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index f087de6..c398779 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -37,6 +37,8 @@ CONFIG_FSL_LBC=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y # CONFIG_PCIEASPM is not set +CONFIG_RAPIDIO=y +CONFIG_FSL_RIO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -94,12 +96,11 @@ CONFIG_SATA_SIL24=y CONFIG_SATA_SIL=y CONFIG_PATA_SIL680=y CONFIG_NETDEVICES=y -CONFIG_VITESSE_PHY=y -CONFIG_FIXED_PHY=y -CONFIG_NET_ETHERNET=y +CONFIG_FSL_PQ_MDIO=y CONFIG_E1000=y CONFIG_E1000E=y -CONFIG_FSL_PQ_MDIO=y +CONFIG_VITESSE_PHY=y +CONFIG_FIXED_PHY=y # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set @@ -155,6 +156,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y +CONFIG_HUGETLBFS=y CONFIG_JFFS2_FS=y CONFIG_CRAMFS=y CONFIG_NFS_FS=y diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 782822c..006bd94 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -23,6 +23,8 @@ CONFIG_P5020_DS=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BINFMT_MISC=m +CONFIG_RAPIDIO=y +CONFIG_FSL_RIO=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -57,7 +59,6 @@ CONFIG_MISC_DEVICES=y CONFIG_EEPROM_LEGACY=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y -CONFIG_NET_ETHERNET=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index a1e5a17..f37a2ab 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -1,5 +1,4 @@ CONFIG_PPC_85xx=y -CONFIG_PHYS_64BIT=y CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y @@ -93,15 +92,14 @@ CONFIG_SATA_FSL=y CONFIG_PATA_ALI=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y +CONFIG_FS_ENET=y +CONFIG_UCC_GETH=y +CONFIG_GIANFAR=y CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y CONFIG_FIXED_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_FS_ENET=y -CONFIG_GIANFAR=y -CONFIG_UCC_GETH=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set @@ -120,6 +118,9 @@ CONFIG_NVRAM=y CONFIG_I2C=y CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y +CONFIG_SPI=y +CONFIG_SPI_FSL_SPI=y +CONFIG_SPI_FSL_ESPI=y CONFIG_GPIO_MPC8XXX=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y @@ -163,6 +164,10 @@ CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PPC_OF_BE=y CONFIG_USB_OHCI_HCD_PPC_OF_LE=y CONFIG_USB_STORAGE=y +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_RTC_CLASS=y @@ -182,6 +187,7 @@ CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y +CONFIG_HUGETLBFS=y CONFIG_ADFS_FS=m CONFIG_AFFS_FS=m CONFIG_HFS_FS=m @@ -213,4 +219,5 @@ CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_ANSI_CPRNG is not set +CONFIG_CRYPTO_DEV_FSL_CAAM=y CONFIG_CRYPTO_DEV_TALITOS=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index dd1e413..abdcd31 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -1,5 +1,4 @@ CONFIG_PPC_85xx=y -CONFIG_PHYS_64BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_EXPERIMENTAL=y @@ -26,6 +25,7 @@ CONFIG_MPC85xx_MDS=y CONFIG_MPC8536_DS=y CONFIG_MPC85xx_DS=y CONFIG_MPC85xx_RDB=y +CONFIG_P1010_RDB=y CONFIG_P1022_DS=y CONFIG_P1023_RDS=y CONFIG_SOCRATES=y @@ -94,15 +94,14 @@ CONFIG_SATA_FSL=y CONFIG_PATA_ALI=y CONFIG_NETDEVICES=y CONFIG_DUMMY=y +CONFIG_FS_ENET=y +CONFIG_UCC_GETH=y +CONFIG_GIANFAR=y CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y CONFIG_FIXED_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_FS_ENET=y -CONFIG_GIANFAR=y -CONFIG_UCC_GETH=y CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set @@ -121,6 +120,9 @@ CONFIG_NVRAM=y CONFIG_I2C=y CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y +CONFIG_SPI=y +CONFIG_SPI_FSL_SPI=y +CONFIG_SPI_FSL_ESPI=y CONFIG_GPIO_MPC8XXX=y #
Re: [PATCH] powerpc: Add TBI PHY node to first MDIO bus
On Dec 7, 2011, at 1:50 PM, Andy Fleming wrote: Systems which use the fsl_pq_mdio driver need to specify an address for TBI PHY transactions such that the address does not conflict with any PHYs on the bus (all transactions to that address are directed to the onboard TBI PHY). The driver used to scan for a free address if no address was specified, however this ran into issues when the PHY Lib was fixed so that all MDIO transactions were protected by a mutex. As it is, the code was meant to serve as a transitional tool until the device trees were all updated to specify the TBI address. The best fix for the mutex issue was to remove the scanning code, but it turns out some of the newer SoCs have started to omit the tbi-phy node when SGMII is not being used. As such, these devices will now fail unless we add a tbi-phy node to the first mdio controller. Signed-off-by: Andy Fleming aflem...@freescale.com --- This requires fsl_pq_mdio: Clean up tbi address configuration from the net tree in order to achieve its full effect. This needs to go into 3.2. arch/powerpc/boot/dts/p1010rdb.dts|5 + arch/powerpc/boot/dts/p1020rdb.dts|5 + arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |5 + arch/powerpc/boot/dts/p1021mds.dts|4 arch/powerpc/boot/dts/p1022ds.dts |4 arch/powerpc/boot/dts/p2020rdb.dts|8 ++-- arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |4 7 files changed, 33 insertions(+), 2 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-pci: Allow 64-bit PCIe devices to DMA to any memory address
On Dec 1, 2011, at 12:03 AM, Kumar Gala wrote: There is an issue on FSL-BookE 64-bit devices (P5020) in which PCIe devices that are capable of doing 64-bit DMAs (like an Intel e1000) do not function and crash the kernel if we have 4G of memory in the system. The reason is that the existing code only sets up one inbound window for access to system memory across PCIe. That window is limited to a 32-bit address space. So on systems we'll end up utilizing SWIOTLB for dma mappings. However SWIOTLB dma ops implement dma_alloc_coherent() as dma_direct_alloc_coherent(). Thus we can end up with dma addresses that are not accessible because of the inbound window limitation. We could possibly set the SWIOTLB alloc_coherent op to swiotlb_alloc_coherent() however that does not address the issue since the swiotlb_alloc_coherent() will behave almost identical to dma_direct_alloc_coherent() since the devices coherent_dma_mask will be greater than any address allocated by swiotlb_alloc_coherent() and thus we'll never bounce buffer it into a range that would be dma-able. The easiest and best solution is to just make it so that a 64-bit capable device is able to DMA to any internal system address. We accomplish this by opening up a second inbound window that maps all of memory above the internal SoC address width so we can set it up to access all of the internal SoC address space if needed. We than fixup the dma_ops and dma_offset for PCIe devices with a dma mask greater than the maximum internal SoC address. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/sysdev/fsl_pci.c | 55 + 1 files changed, 55 insertions(+), 0 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sbc834x: put full compat string in board match check
On Dec 5, 2011, at 10:41 AM, Paul Gortmaker wrote: The commit 883c2cfc8bcc0fd00c5d9f596fb8870f481b5bda: fix of_flat_dt_is_compatible() to match the full compatible string causes silent boot death on the sbc8349 board because it was just looking for 8349 and not 8349E -- as originally there were non-E (no SEC/encryption) chips available. Just add the E to the board detection string since all boards I've seen were manufactured with the E versions. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: Update defconfigs to enable some standard FSL HW features
On Dec 8, 2011, at 1:11 AM, Kumar Gala wrote: corenet64_smp_defconfig: - enabled rapidio corenet32_smp_defconfig: - enabled hugetlbfs, rapidio mpc85xx_smp_defconfig: - enabled P1010RDB, hugetlbfs, SPI, SDHC, Crypto/CAAM mpc85xx_smp_defconfig: - enabled hugetlbfs, SPI, SDHC, Crypto/CAAM Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/configs/corenet32_smp_defconfig | 10 ++ arch/powerpc/configs/corenet64_smp_defconfig |3 ++- arch/powerpc/configs/mpc85xx_defconfig | 17 - arch/powerpc/configs/mpc85xx_smp_defconfig | 18 +- 4 files changed, 33 insertions(+), 15 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
[ some bugfixes defconfig updates for 3.2] The following changes since commit 49e44064d7e3f24f874a51dd513b83ef9994aa8a: powerpc/44x: Add mtd ndfc to the ppx44x defconfig (2011-11-25 10:06:00 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge Andy Fleming (1): powerpc: Add TBI PHY node to first MDIO bus Kumar Gala (2): powerpc/fsl-pci: Allow 64-bit PCIe devices to DMA to any memory address powerpc/fsl: Update defconfigs to enable some standard FSL HW features Paul Gortmaker (1): sbc834x: put full compat string in board match check arch/powerpc/boot/dts/p1010rdb.dts|5 ++ arch/powerpc/boot/dts/p1020rdb.dts|5 ++ arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |5 ++ arch/powerpc/boot/dts/p1021mds.dts|4 ++ arch/powerpc/boot/dts/p1022ds.dts |4 ++ arch/powerpc/boot/dts/p2020rdb.dts|8 +++- arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |4 ++ arch/powerpc/configs/corenet32_smp_defconfig | 10 +++-- arch/powerpc/configs/corenet64_smp_defconfig |3 +- arch/powerpc/configs/mpc85xx_defconfig| 17 +-- arch/powerpc/configs/mpc85xx_smp_defconfig| 18 ++-- arch/powerpc/platforms/83xx/sbc834x.c |4 +- arch/powerpc/sysdev/fsl_pci.c | 55 + 13 files changed, 123 insertions(+), 19 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [powerpc] boot up problem
On Dec 7, 2011, at 9:13 AM, Timur Tabi wrote: On Dec 7, 2011, at 1:27 AM, Jia Hongtao-B38951 b38...@freescale.com wrote: Is this the patch you mentioned? http://patchwork.ozlabs.org/patch/128806/ I applied this patch but the issue was still there. This is not the patch I am talking about. Unfortunately, I can't find the right patch in patchwork anywhere. Andy, what about patch fsl_pq_mdio: Clean up tbi address configuration? I've pulled things into my 'test' branch of powerpc.git. This should have the fixes to allow things to boot again. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
