Re: [2.6.30-rc3] powerpc: compilation error of mace module
From: Rogério Brito rbr...@ime.usp.br Date: Sun, 26 Apr 2009 12:57:09 -0300 I am attempting to compile a new kernel for my OldWorld ppc box and I'm having some problems. The first one that appears to happen is the following: Turn on CONFIG_COMPAT_NET_DEV_OPS in your kernel config. There was no reason for you to turn that off, and you had to have done it explicitly I think :-) Or, if you're bored, feel free to convert the mace driver over to netdev_ops :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Kumar,
Kumar Gala wrote:
[...]
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
b/arch/powerpc/platforms/83xx/kmeter1.c
new file mode 100644
index 000..99cf5c6
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/kmeter1.c
@@ -0,0 +1,170 @@
+/*
[...]
+np = of_find_compatible_node(NULL, network, ucc_geth);
+if (np != NULL) {
+uint svid;
+
+/* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+svid = mfspr(SPRN_SVR);
+if (svid == 0x80480021) {
+void __iomem *immap;
+
+immap = ioremap(get_immrbase() + 0x14a8, 8);
we should add a proper device node to cover whatever register space this
is.
What if we do something like the following:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
soc8...@e000 {
[...]
errata {
device_type = errata;
compatible = fsl,mpc83xx_errata;
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
};
};
[...]
};
2) we add in arch/powerpc/sysdev/fsl_soc.c a
static int __init mpc83xx_errata_init(void)
function, which holds the code for the errata
If you agree with that, I can make a patch ...
Hmm.. Is it OK, if I first sent a v2 of the 83xx: add support for
the kmeter1 board. with the QE_ENET10 errata in kmeter1.c (as it is
also for the mpc836x_mds board), and then send a seperate patch, which
removes this errata from the two boards?
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [MTD] ofpart: Partitions at same address cannot have the same name v3
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,9 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, name, len);
- if (strcmp(partname, partition) != 0) {
+ if ((strcmp(partname, partition) != 0)
+ (of_device_is_compatible(pp, partition) != 1))
+ {
nr_parts--;
continue;
}
If this is the way, how to go, you get my ack.
Acked-by: Benjamin Krill b...@codiert.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Sat, Apr 25, 2009 at 2:35 AM, Ira Snyder i...@ovro.caltech.edu wrote: By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI bridge was between the devices trying to communicate. A simple test driver showed an increase from 4MB/sec to 116MB/sec when performing DMA over the PCI bus. Using DMA to transfer between blocks of local SDRAM showed no change in performance with this patch. The dmatest driver was also used to verify the correctness of the transfers, and showed no errors. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu Acked-by: Li Yang le...@freescale.com Thanks, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Fri, 2009-04-24 at 10:51 +0100, Mel Gorman wrote: I'm seeing some tests with sysbench+postgres+large pages fail on ppc64 although a very clear pattern is not forming as to what exactly is causing it. However, the libhugetlbfs regression tests (make make func) are triggering the following oops when calling mlock() and so are likely related. This would be a spurrious WARN_ON().. the test I added in there should not apply to huge pages. However, I don't see that causing a functional problem with sysbench+postgres Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] fsldma: use PCI Read Multiple command
By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. IIRC, the default for 83xx DMA controller uses the PCI mem read command, not mem read line. You are assuming the PCI memory space is prefetchable( no side effect) for DMA. Is it possible that DMA is from non-prefetchable memory space? The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI bridge was between the devices trying to communicate. A simple test driver showed an increase from 4MB/sec to 116MB/sec when performing DMA over the PCI bus. Using DMA to transfer between blocks of local SDRAM showed no change in performance with this patch. The dmatest driver was also used to verify the correctness of the transfers, and showed no errors. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/13] OF device tree handling of PHY drivers
From: Grant Likely grant.lik...@secretlab.ca Date: Sat, 25 Apr 2009 16:52:34 -0600 This series adds common code for reading PHY connection data out of the OpenFirmware device tree. This simplifies the network drivers which use the device tree and which currently implement their own solutions for reading the PHY data out of the device tree directly. I would like to see this series, or at least the core changes (1-4) plus the tested drivers (5-8 12, but #12 is a new driver and it may need more review), go into -next for 2.6.31. Due to dependencies, I think it is easiest if all of them go in via the same tree. David, are you willing to merge them via yours? Four of the patches are outside of drivers/net (patches 1 and 4 touch drivers/of/, and patches 9 10 touch arch/powerpc), but I personally have no issues if those changes go through you. I just need to double check with BenH. I've applied all of these patches to net-next-2.6, thanks. git://git.secretlab.ca/git/linux-2.6 next-net You know, if you had actually based this tree on net-next-2.6 I could have pulled from it. I actually tried, and I got a lot of upstream stuff I wasn't ready to get in that tree just yet :-/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Mon, Apr 27, 2009 at 5:09 PM, Liu Dave-R63238 dave...@freescale.com wrote: By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. IIRC, the default for 83xx DMA controller uses the PCI mem read command, not mem read line. You are assuming the PCI memory space is prefetchable( no side effect) for DMA. Is it possible that DMA is from non-prefetchable memory space? I guess it's not reasonable to use DMA from non-prefetchable memory. So it's up to the driver which uses the DMA engine to prevent from using DMA API on non-prefetchable memory. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: convert mace to netdev_ops (was: Re: [2.6.30-rc3] powerpc: compilation error of mace module)
Hi, Dave.
On Apr 26 2009, David Miller wrote:
Or, if you're bored, feel free to convert the mace driver over
to netdev_ops :-)
Is this anything close to what needs to be done? It's not without
failures, because the function mace_set_timeout receives a pointer to a
struct net_device, but is marked inline and is used by mace_tx_timeout,
which receives an unsigned long (which calls mace_set_timeout).
Perhaps it would be a case of removing the inline hint to the compiler?
I guess that BenH or Paul could comment here better...
Signed-off-by: Rogério Brito rbr...@ime.usp.br
---
--- a/drivers/net/mace.c2008-12-29 15:25:15.0 -0200
+++ b/drivers/net/mace.c2009-04-27 08:54:16.0 -0300
@@ -89,6 +89,16 @@ static inline void dbdma_reset(volatile
static inline void mace_clean_rings(struct mace_data *mp);
static void __mace_set_address(struct net_device *dev, void *addr);
+/* Conversion to netdev_ops. */
+static const struct net_device_ops mace_netdev_ops = {
+ .ndo_open = mace_open,
+ .ndo_stop = mace_close,
+ .ndo_start_xmit = mace_xmit_start,
+ .ndo_tx_timeout = mace_set_timeout,
+ .ndo_set_multicast_list = mace_set_multicast,
+ .ndo_set_mac_address= mace_set_address,
+};
+
/*
* If we can't get a skbuff when we need it, we use this area for DMA.
*/
@@ -208,11 +217,7 @@ static int __devinit mace_probe(struct m
}
}
- dev-open = mace_open;
- dev-stop = mace_close;
- dev-hard_start_xmit = mace_xmit_start;
- dev-set_multicast_list = mace_set_multicast;
- dev-set_mac_address = mace_set_address;
+ dev-netdev_ops = mace_netdev_ops;
/*
* Most of what is below could be moved to mace_open()
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: convert mace to netdev_ops
From: Rogério Brito rbr...@ime.usp.br Date: Mon, 27 Apr 2009 09:16:33 -0300 Is this anything close to what needs to be done? It's not without failures, because the function mace_set_timeout receives a pointer to a struct net_device, but is marked inline and is used by mace_tx_timeout, which receives an unsigned long (which calls mace_set_timeout). Perhaps it would be a case of removing the inline hint to the compiler? I guess that BenH or Paul could comment here better... Signed-off-by: Rogério Brito rbr...@ime.usp.br You can fix the mace_set_timeout() function arguments by having a helper function that simply wraps around it and provides the second expection of argument types. Your patch is also wrong, it's missing a lot of netdev_ops entries that are implicitly obtained via alloc_etherdev(), namely: .ndo_change_mtu = eth_change_mtu, .ndo_set_mac_address= eth_mac_addr, .ndo_validate_addr = eth_validate_addr, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
On Fri, 2009-04-24 at 13:01 +0200, Arnd Bergmann wrote: I just said in another email thread that we would need a CONFIG_DCR option that DCR using drivers should depend on, if it ever happened outside of powerpc. Well, apparently this happened earlier than I expected. Sadly... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Machine check in 4xx NAND driver
Hi, I've got the following error on custom board based on AMCC 405EXr running 2.6.27 kernel, with ndfc driver back ported from 2.6.29 (to support OF partitions on NAND). This happened once, right after reboot. I was unable to reproduce this. The NAND device is Samsung K9K8G08U0B, 1GB with 2k page. Oops: Machine check, sig: 7 [#1] Modules linked in: NIP: c0155bd0 LR: c014ff30 CTR: 003b REGS: dfffdf50 TRAP: 0202 Not tainted (2.6.27) MSR: 00029030 EE,ME,IR,DR CR: 44024084 XER: TASK = df82c000[1] 'swapper' THREAD: df82a000 GPR00: 82bfe51c df82bb90 df82c000 c02c7ae0 dfade884 00fc 01fe 006b GPR08: e1018000 c02c7ad8 0040 ffef c024c3b0 GPR16: 003f dfade870 c02aa7f4 0003 GPR24: df824040 df824000 0100 0008 c02c7ae0 df824000 c02c7b9c dfade870 NIP [c0155bd0] ndfc_read_buf+0x30/0x5c LR [c014ff30] nand_read_page_hwecc+0x70/0x174 Call Trace: [df82bb90] [c014fff8] nand_read_page_hwecc+0x138/0x174 (unreliable) [df82bbd0] [c0152e74] nand_do_read_ops+0x15c/0x3dc [df82bc30] [c01534bc] nand_read+0xa8/0xe4 [df82bc60] [c014800c] part_read+0x5c/0xe4 [df82bc70] [c00f2154] jffs2_flash_read+0x68/0x258 [df82bca0] [c00ebbc0] jffs2_fill_scan_buf+0x34/0x64 [df82bcc0] [c00ec0a0] jffs2_scan_medium+0x4b0/0x1204 [df82bd40] [c00eed00] jffs2_do_mount_fs+0x178/0x6c8 [df82bd80] [c00f11f8] jffs2_do_fill_super+0xc4/0x258 [df82bda0] [c00f18a0] jffs2_fill_super+0xc0/0xd4 [df82bdc0] [c0147128] get_sb_mtd_aux+0xa0/0xf0 [df82bdf0] [c0147280] get_sb_mtd+0x84/0x1c8 [df82be30] [c00f1670] jffs2_get_sb+0x1c/0x2c [df82be40] [c0072230] vfs_kern_mount+0x58/0xe0 [df82be60] [c0072308] do_kern_mount+0x40/0xf8 [df82be80] [c008b740] do_new_mount+0x88/0xb8 [df82bea0] [c008b8f4] do_mount+0x184/0x1d4 [df82bf20] [c008b9d4] sys_mount+0x90/0xe0 [df82bf50] [c0274a04] do_mount_root+0x30/0xb8 [df82bf60] [c0274c78] mount_block_root+0xac/0x244 [df82bfb0] [c02750ac] prepare_namespace+0x18c/0x218 [df82bfd0] [c02741bc] kernel_init+0xc8/0xf4 [df82bff0] [c000dd5c] kernel_thread+0x44/0x60 Instruction dump: 7cab2b79 4c810020 38a5fffc 396b 2f85fffd 556bf0be 3d20c02c 396b0001 39497ad8 7d6903a6 419c0028 812a0004 7c0004ac 80090008 0c00 4c00012c Any hints what could be the problem are much appreciated. Thanks. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/13] OF device tree handling of PHY drivers
On Mon, Apr 27, 2009 at 3:54 AM, David Miller da...@davemloft.net wrote: From: Grant Likely grant.lik...@secretlab.ca Date: Sat, 25 Apr 2009 16:52:34 -0600 This series adds common code for reading PHY connection data out of the OpenFirmware device tree. This simplifies the network drivers which use the device tree and which currently implement their own solutions for reading the PHY data out of the device tree directly. I would like to see this series, or at least the core changes (1-4) plus the tested drivers (5-8 12, but #12 is a new driver and it may need more review), go into -next for 2.6.31. Due to dependencies, I think it is easiest if all of them go in via the same tree. David, are you willing to merge them via yours? Four of the patches are outside of drivers/net (patches 1 and 4 touch drivers/of/, and patches 9 10 touch arch/powerpc), but I personally have no issues if those changes go through you. I just need to double check with BenH. I've applied all of these patches to net-next-2.6, thanks. git://git.secretlab.ca/git/linux-2.6 next-net You know, if you had actually based this tree on net-next-2.6 I could have pulled from it. I actually tried, and I got a lot of upstream stuff I wasn't ready to get in that tree just yet :-/ I know, but the tree I based it on was what I actually tested against. When it came to publishing, I wasn't going to rebase and push out something untested. I hadn't expected it to get pulled so quickly! Thanks! g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
On Thu, 2009-04-23 at 16:27 -0600, Gary Thomas wrote: I don't think any of this matters. It turns out that even the 2.6.26 kernel fails on an identical board with a newer revision of the 8347 chip. I'm sure that the problem is that the Coral-P fails when mapped to 0 (PCI relative). There are macro that the PCI code uses to define the min address to assign to devices but it's broken for us as it doesn't account for the kind of remapping we do... I've been wanting to fix those for some time but didn't get a chance yet, that would sort this out. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Enable Serial Management Controller (SMC) in MPC8265
Hello Scott,
Thank you for your support.
After struggling for several days with this issue we have finally
taken a different approach to solve our problem. We wanted to interface
our CPU (MPC8265) with a FPGA through a serial connection. Now, we are
using a parallel interface through the data bus (defining a new memory
region in uboot -an additional chip select).
We tried enabling SCC's and SMC's through the kernel configuration
in ltib, but we were always getting the same tty devices device under
/dev. No matter how many SCC's or SMC's we enable we were always
getting only /dev/ttyCPM0 and /dev/ttyCPM1. To answer your question,
when I said it did not allow me to configure a tty port through minicom,
I meant it complained because the device was not found.
However, as I said before, we managed to enable it in uboot using
SMC2 as console. The problem we found was that for some reason in uboot
the code is organized in several places to enable either SCC or SMC (but
only as console). We could not find any configuration option to enable
SCC1 as console and SMC2 as serial port at the same time. We tried going
through the uboot code to enable both, but their configuration is
exclusive in several places (only one of them can be enabled at the same
time).
Due to time constraints, we decided to change our design approach as
stated before (parallel interface).
Thank you again for your help.
--
Andres F Marquez
EdgeAccess
Development
amarq...@edgeaccess.net
On Fri, 2009-04-24 at 11:02 -0500, Scott Wood wrote:
On Thu, Apr 23, 2009 at 07:50:25PM -0400, Andres F Marquez wrote:
I am working with a MPC8265 processor for which I am compiling a
Kernel using LTIB.
Please contact Freescale support for issues with BSPs. Around here
you'll be told to upgrade to the latest upstream kernel. :-)
I enabled SCC1 (for the console) and SMC2 through the Kernel
(2.6.25) configuration tool using LTIB. I am able to run my system and
execute minicom to try to configure the needed serial port. I have not
been able to find the tty port that refers to either one of the two SMC
ports.
All CPM serial ports (whether SCC or SMC) will be /dev/ttyCPMn.
I have tried all the tty's that I get when I do ls /dev/tty* but
none of them seem to work. Below, I provide the list of tty's that I am
getting. ttyCPM0 is being used for the console. ttyCPM1 is the only one
that I am allowed to configure through minicom (for the rest it says
device not found).
Not allowed? Don't you have root access to your board?
After doing some research online, I added an entry in my
mpc8272ads.dts file for the smc serial controller. Below, I provide the
entries for the serial ports (one SCC1 and one SMC2):
ser...@11a00 {
device_type = serial;
compatible = fsl,mpc8280-scc-uart,
fsl,cpm2-scc-uart;
reg = 11a00 20 8000 100;
interrupts = 28 8;
interrupt-parent = PIC;
fsl,cpm-brg = 2;
fsl,cpm-command = 0080;
};
ser...@11a92 {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a92 20 88fc 2;
interrupts = 5 8;
interrupt-parent = PIC;
fsl,cpm-brg = 2;
fsl,cpm-command = 2120;
};
Do you really have both ports on the same BRG?
Change 11a92 to 11a90 -- it's the address of the register block, not the
first register within the block.
You should also change 8280 to 8265, though nothing currently cares.
Finally, I think 2.6.25 is too old to support automatic allocation of SMC
parameter RAM. Unless they've backported something in the BSP, you'll
have to manually allocate some space, remove that chunk from the muram
node, program SMC2_BASE yourself, and put the address of the actual
parameter RAM in the device tree. Or, upgrade to the latest upstream
kernel, or complain to Freescale sales and/or support that the BSP kernel
is too old for your desired use.
For some reason in uboot, it seems like the configurations for SCC1 and
SMC2 are exclusive. They depend on where the console is configured
(SCC1 or SMC2). Either one can be configured, but not both at the same
time (at least based on uboot configuration definitions. They are
within if's and elif's...). As I said before, both of them are able to
run the console.
I don't see any obvious pin conflict
Re: microblaze: Statically linking device tree blobs into the kernel
On Sun, Apr 26, 2009 at 10:24 PM, John Williams john.willi...@petalogix.com wrote: To MicroBlazers and other interested parties: Currently the MicroBlaze kernel boot-time ABI requires r7 to point to a valid DTB, whereupon in early kernel setup the DTB is copied to a statically allocated 16k memory region inside the kernel. From there it is later queried by the platform startup code. For simple boot scenarios the ability to statically bind a DTB into the kernel image would clearly be useful. In PPC land, this is achieved through the simpleboot bootloader that lives in arch/powerpc/boot. The DTB becomes part of the simpleboot payload, and is passed to the kernel through the normal means. I'm not convinced duplicating this for MicroBlaze is a good idea, I think it would be overkill. However, the make syntax that PPC uses to achieve DTB binding is quite nice: $ make simpleImage.board which binds arch/powerpc/boot/dts/board.dts into the boot payload. My feeling is that we should make use of the fact that the DTB region is statically allocated in the MicroBlaze kernel anyway. From arch/microblaze/kernel/vmlinux.lds.S: . = ALIGN (4) ; _fdt_start = . ; /* place for fdt blob */ . = . + 0x4000; _fdt_end = . ; and in head.S, the DTB at r7 is copied into place at _fdt_start /* save fdt to kernel location */ /* r7 stores pointer to fdt blob */ beqi r7, no_fdt_arg or r11, r0, r0 /* incremment */ ori r4, r0, TOPHYS(_fdt_start) /* save bram context */ ori r3, r0, (0x4000 - 4) _copy_fdt: simple copy loop no_fdt_arg: Since this memory is already allocated in the kernel image but is normally just zeros, to bind a DTB to the kernel we could just store it in-situ. This way, if a non-zero r7 is passed in at boot time, head.S will naturally overwrite (and thus override) the default DTB that was inside the kernel image. What I'm not so sure about is how best to achieve this in the kbuild sequence. I see two options: (a) use .incbin in a .S file, similar to how the initramfs gets linked in in /usr/Makefile etc, or (b) use objcopy to manipulate vmlinux after final link, by directly inserting the DTB into the appropriate ELF section. (a) seems nice because it means that our standard make targets, such as linux.bin etc, would still work unchanged. (b) seems to go a bit against the grain of kbuild, but maybe I'm wrong there. I've hacked around with (a) a bit, part of the problem is that it seems arch/microblaze/Makefile would need something like I'm partial to (a)too , but I don't know how to achieve it in Kbuild. Using the linker means that even large .dtb files will get handled gracefully. core-y += arch/microblaze/boot because the DTB object file must be ready before final vmlinux link. Which works fine with the .dtb list is in the list of default targets, but is harder for miscellaneous 'make simpleimage.board' usage. You could I suppose duplicate the vmlinux target as simpleimage.% (or whatever name makes sense) and have the kernel be relinked for each target provided. In fact, this might be the only way to do (a). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V1 3/3] Rename exports in mpc5200_dma.c
On Sun, Apr 26, 2009 at 10:27 PM, Jon Smirl jonsm...@gmail.com wrote:
On Mon, Apr 27, 2009 at 12:08 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Sun, Apr 26, 2009 at 1:53 PM, Jon Smirl jonsm...@gmail.com wrote:
Rename the public DMA exports into the global name space so that the DMA
code can be built as a module.
Signed-off-by: Jon Smirl jonsm...@gmail.com
Nack. mpc5200_dma is too generic for the global namespace... (in
fact, I should also relook at the previous patch; I might need to nack
my ack). Some variant of 'mpc5200_psc_snd_dma' would be more
appropriate. Even mpc5200_psc_dma is too generic because other
non-sound PSC modes can use DMA also.
I'll change it to mpc5200_audio_dma and resend this to the series to
the alsa list.
Does your stuff still work with these patches? I want to get these
mechanical changes in so we can focus on the real changes in my later
patches.
The project changed and I haven't fired up my target in quite a long time. :-(
g.
g.
---
sound/soc/fsl/mpc5200_dma.c | 18 --
sound/soc/fsl/mpc5200_dma.h | 10 +-
sound/soc/fsl/mpc5200_psc_i2s.c | 14 +++---
3 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index c82ef75..df73755 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -113,7 +113,7 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void
*_psc_dma_stream)
* If this is the first stream open, then grab the IRQ and program most of
* the PSC registers.
*/
-int psc_dma_startup(struct snd_pcm_substream *substream,
+int mpc5200_dma_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -145,13 +145,16 @@ int psc_dma_startup(struct snd_pcm_substream
*substream,
return 0;
}
+EXPORT_SYMBOL_GPL(mpc5200_dma_startup);
-int psc_dma_hw_free(struct snd_pcm_substream *substream,
+int mpc5200_dma_hw_free(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
snd_pcm_set_runtime_buffer(substream, NULL);
return 0;
}
+EXPORT_SYMBOL_GPL(mpc5200_dma_hw_free);
+
/**
* psc_dma_trigger: start and stop the DMA transfer.
@@ -159,7 +162,7 @@ int psc_dma_hw_free(struct snd_pcm_substream *substream,
* This function is called by ALSA to start, stop, pause, and resume the DMA
* transfer of data.
*/
-int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
+int mpc5200_dma_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -269,13 +272,15 @@ int psc_dma_trigger(struct snd_pcm_substream
*substream, int cmd,
return 0;
}
+EXPORT_SYMBOL_GPL(mpc5200_dma_trigger);
+
/**
* psc_dma_shutdown: shutdown the data transfer on a stream
*
* Shutdown the PSC if there are no other substreams open.
*/
-void psc_dma_shutdown(struct snd_pcm_substream *substream,
+void mpc5200_dma_shutdown(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -303,6 +308,7 @@ void psc_dma_shutdown(struct snd_pcm_substream
*substream,
free_irq(psc_dma-playback.irq, psc_dma-playback);
}
}
+EXPORT_SYMBOL_GPL(mpc5200_dma_shutdown);
/* -
* The PSC DMA 'ASoC platform' driver
@@ -448,10 +454,10 @@ static void psc_dma_pcm_free(struct snd_pcm *pcm)
}
}
-struct snd_soc_platform psc_dma_pcm_soc_platform = {
+struct snd_soc_platform mpc5200_dma_platform = {
.name = mpc5200-psc-audio,
.pcm_ops = psc_dma_pcm_ops,
.pcm_new = psc_dma_pcm_new,
.pcm_free = psc_dma_pcm_free,
};
-
+EXPORT_SYMBOL_GPL(mpc5200_dma_platform);
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index a33232c..e52b90e 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -64,18 +64,18 @@ struct psc_dma {
};
-int psc_dma_startup(struct snd_pcm_substream *substream,
+int mpc5200_dma_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai);
-int psc_dma_hw_free(struct snd_pcm_substream *substream,
+int mpc5200_dma_hw_free(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai);
-void psc_dma_shutdown(struct snd_pcm_substream *substream,
+void mpc5200_dma_shutdown(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai);
-int psc_dma_trigger(struct snd_pcm_substream *substream, int cmd,
+int mpc5200_dma_trigger(struct snd_pcm_substream *substream, int cmd,
Re: [PATCH] powerpc/86xx: clean up smp init code
On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote: Kumar Gala wrote: Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c and just moved the defines it cared about into there. Also fixed up the ioremap to only map the one 4k page we need access to and to iounmap when we are done. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/include/asm/mpc86xx.h | 33 arch/powerpc/platforms/86xx/gef_ppc9a.c|1 - arch/powerpc/platforms/86xx/gef_sbc310.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |1 - arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 - arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |1 - arch/powerpc/platforms/86xx/mpc86xx_smp.c |8 ++- arch/powerpc/platforms/86xx/sbc8641d.c |1 - 8 files changed, 7 insertions(+), 40 deletions(-) delete mode 100644 arch/powerpc/include/asm/mpc86xx.h I assume this patch relies on one of the other patches posted? Just applying this patch to my development tree (based on your main branch) resulted in the following on a PPC9A: mpic: requesting IPIs ... __ioremap(): phys addr 0x0 is RAM lr c041e5c8 Unable to handle kernel paging request for data at address 0x0010 Faulting instruction address: 0xc041e5cc Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=2 GE Fanuc PPC9A Modules linked in: NIP: c041e5cc LR: c041e5c8 CTR: c0013d90 REGS: ef841ea0 TRAP: 0300 Not tainted (2.6.30-rc3-00016-gabae74f) MSR: 1032 ME,IR,DR CR: 2422 XER: DAR: 0010, DSISR: 4000 TASK = ef83f980[1] 'swapper' THREAD: ef84 CPU: 0 GPR00: c041e5c8 ef841f50 ef83f980 1032 c048 4000 GPR08: c0441a4c ef84 c044 2242 dfff 0ff50d00 0001 GPR16: c044 c048 c048 c0468000 c044 c0442838 GPR24: 0002 c048 c048 7d5043a6 9032 0004 0001 c350 NIP [c041e5cc] smp_86xx_kick_cpu+0x70/0x11c LR [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c Call Trace: [ef841f50] [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c (unreliable) [ef841f70] [c0435010] __cpu_up+0xa4/0x1b0 [ef841f90] [c04355ec] cpu_up+0x104/0x1cc [ef841fd0] [c0412368] kernel_init+0x1d8/0x1f0 [ef841ff0] [c0012cb8] kernel_thread+0x4c/0x68 Instruction dump: 3c80c000 61290100 38a1 7d234b78 38843464 8369 4bbfa7f9 4bbfcb21 38801000 38631000 4bbf91ad 7c0004ac 81230010 0c09 4c00012c 3801 ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds.. I'm not able to reproduce this failure. It seems like either ioremap is returning 0 or you are getting 0 from get_immrbase().. either way I don't see how my change would cause what you are seeing on your board. Are you running w/CONFIG_PHYS_64BIT=y? - k - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: convert mace to netdev_ops
Hi, Dave.
On Apr 27 2009, David Miller wrote:
You can fix the mace_set_timeout() function arguments by having a
helper function that simply wraps around it and provides the second
expection of argument types.
Hummm, this means that I'm not that bad... The wrapper function was the
first thing that came to my mind, but I just wanted to be as least
disruptive as possible.
Your patch is also wrong, it's missing a lot of netdev_ops
entries that are implicitly obtained via alloc_etherdev(),
namely:
Thanks for pointing those out. I didn't find the documentation about
netdev_ops under Documentation (a simple grep didn't turn any results).
.ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address= eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
Nice. I will incorporate such things.
Thanks, Rogério Brito.
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/86xx: clean up smp init code
Kumar Gala wrote: On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote: Kumar Gala wrote: Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c and just moved the defines it cared about into there. Also fixed up the ioremap to only map the one 4k page we need access to and to iounmap when we are done. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/include/asm/mpc86xx.h | 33 arch/powerpc/platforms/86xx/gef_ppc9a.c|1 - arch/powerpc/platforms/86xx/gef_sbc310.c |1 - arch/powerpc/platforms/86xx/gef_sbc610.c |1 - arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 - arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |1 - arch/powerpc/platforms/86xx/mpc86xx_smp.c |8 ++- arch/powerpc/platforms/86xx/sbc8641d.c |1 - 8 files changed, 7 insertions(+), 40 deletions(-) delete mode 100644 arch/powerpc/include/asm/mpc86xx.h I assume this patch relies on one of the other patches posted? Just applying this patch to my development tree (based on your main branch) resulted in the following on a PPC9A: mpic: requesting IPIs ... __ioremap(): phys addr 0x0 is RAM lr c041e5c8 Unable to handle kernel paging request for data at address 0x0010 Faulting instruction address: 0xc041e5cc Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=2 GE Fanuc PPC9A Modules linked in: NIP: c041e5cc LR: c041e5c8 CTR: c0013d90 REGS: ef841ea0 TRAP: 0300 Not tainted (2.6.30-rc3-00016-gabae74f) MSR: 1032 ME,IR,DR CR: 2422 XER: DAR: 0010, DSISR: 4000 TASK = ef83f980[1] 'swapper' THREAD: ef84 CPU: 0 GPR00: c041e5c8 ef841f50 ef83f980 1032 c048 4000 GPR08: c0441a4c ef84 c044 2242 dfff 0ff50d00 0001 GPR16: c044 c048 c048 c0468000 c044 c0442838 GPR24: 0002 c048 c048 7d5043a6 9032 0004 0001 c350 NIP [c041e5cc] smp_86xx_kick_cpu+0x70/0x11c LR [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c Call Trace: [ef841f50] [c041e5c8] smp_86xx_kick_cpu+0x6c/0x11c (unreliable) [ef841f70] [c0435010] __cpu_up+0xa4/0x1b0 [ef841f90] [c04355ec] cpu_up+0x104/0x1cc [ef841fd0] [c0412368] kernel_init+0x1d8/0x1f0 [ef841ff0] [c0012cb8] kernel_thread+0x4c/0x68 Instruction dump: 3c80c000 61290100 38a1 7d234b78 38843464 8369 4bbfa7f9 4bbfcb21 38801000 38631000 4bbf91ad 7c0004ac 81230010 0c09 4c00012c 3801 ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds.. I'm not able to reproduce this failure. It seems like either ioremap is returning 0 or you are getting 0 from get_immrbase().. either way I don't see how my change would cause what you are seeing on your board. I've just built the kernel with no local patches in case they were causing the problem and adding this patch causes the above problem. Are you running w/CONFIG_PHYS_64BIT=y? I am using the config in the kernel (arch/powerpc/configs/68xx/gef_ppc9a_defconfig) as is, ditto for the DTS. CONFIG_PHYS_64BIT is not set. However, looking into it a bit further 'device_type = soc;' is missing from the DTS file, so I assume get_immrbase() is returning -1. That might explain some other weird errors I recently noticed that I haven't managed to find the time to track down yet... Martyn ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Enable Serial Management Controller (SMC) in MPC8265
Andres F Marquez wrote: After struggling for several days with this issue we have finally taken a different approach to solve our problem. We wanted to interface our CPU (MPC8265) with a FPGA through a serial connection. Now, we are using a parallel interface through the data bus (defining a new memory region in uboot -an additional chip select). That sounds much better. We tried enabling SCC's and SMC's through the kernel configuration in ltib, LTIB doesn't alter device trees AFAIK... Unless you have more than two CPM serial nodes, you won't get more than ttyCPM0 and ttyCPM1. but we were always getting the same tty devices device under /dev. No matter how many SCC's or SMC's we enable we were always getting only /dev/ttyCPM0 and /dev/ttyCPM1. Do you have a static /dev, or are you running mdev or udev? If the latter, then any changes in the kernel or device tree are not going to automatically show up in /dev. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] net: Fix ucc_geth.c handling of phy 'interface' property.
From: Grant Likely grant.lik...@secretlab.ca
Previous rework to ucc_geth.c to add of_mdio support (net: Rework
ucc_geth driver to use of_mdio infrastructure) added a block of
code which broke older openfirmware device trees which use an
'interface' property in the phy node to describe the connection
between the MAC and the PHY. This patch removes the offending blurb.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/ucc_geth.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 195b490..d805d60 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3639,9 +3639,6 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
prop = of_get_property(np, phy-connection-type, NULL);
if (!prop) {
/* handle interface property present in old trees */
- if (!phy)
- return -ENODEV;
-
prop = of_get_property(phy, interface, NULL);
if (prop != NULL) {
phy_interface = enet_to_phy_interface[*prop];
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 09/13] net: Rework ucc_geth driver to use of_mdio infrastructure
On Sun, Apr 26, 2009 at 3:00 AM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
Change in fixed link case, see inline.
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Andy Fleming aflem...@freescale.com
---
drivers/net/ucc_geth.c | 47
---
drivers/net/ucc_geth.h | 2 +-
2 files changed, 13 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d3f39e8..195b490 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -27,6 +27,7 @@
#include linux/mii.h
#include linux/phy.h
#include linux/workqueue.h
+#include linux/of_mdio.h
#include linux/of_platform.h
#include asm/uaccess.h
@@ -1542,12 +1543,14 @@ static int init_phy(struct net_device *dev)
priv-oldspeed = 0;
priv-oldduplex = -1;
- phydev = phy_connect(dev, ug_info-phy_bus_id, adjust_link, 0,
- priv-phy_interface);
+ if (!ug_info-phy_node)
+ return 0;
- if (IS_ERR(phydev)) {
+ phydev = of_phy_connect(dev, ug_info-phy_node, adjust_link, 0,
+ priv-phy_interface);
+ if (!phydev) {
printk(%s: Could not attach to PHY\n, dev-name);
- return PTR_ERR(phydev);
+ return -ENODEV;
}
phydev-supported = (ADVERTISED_10baseT_Half |
@@ -3519,14 +3522,12 @@ static int ucc_geth_probe(struct of_device*
ofdev, const struct of_device_id *ma
{
struct device *device = ofdev-dev;
struct device_node *np = ofdev-node;
- struct device_node *mdio;
struct net_device *dev = NULL;
struct ucc_geth_private *ugeth = NULL;
struct ucc_geth_info *ug_info;
struct resource res;
struct device_node *phy;
int err, ucc_num, max_speed = 0;
- const phandle *ph;
const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
@@ -3626,45 +3627,21 @@ static int ucc_geth_probe(struct of_device*
ofdev, const struct of_device_id *ma
ug_info-uf_info.irq = irq_of_parse_and_map(np, 0);
fixed_link = of_get_property(np, fixed-link, NULL);
if (fixed_link) {
- snprintf(ug_info-phy_bus_id, sizeof(ug_info-phy_bus_id),
- PHY_ID_FMT, 0, fixed_link[0]);
phy = NULL;
phy assigned to NULL ...
} else {
- char bus_name[MII_BUS_ID_SIZE];
-
- ph = of_get_property(np, phy-handle, NULL);
- phy = of_find_node_by_phandle(*ph);
-
+ phy = of_parse_phandle(np, phy-handle, 0);
if (phy == NULL)
return -ENODEV;
-
- /* set the PHY address */
- prop = of_get_property(phy, reg, NULL);
- if (prop == NULL)
- return -1;
-
- /* Set the bus id */
- mdio = of_get_parent(phy);
-
- if (mdio == NULL)
- return -ENODEV;
-
- err = of_address_to_resource(mdio, 0, res);
-
- if (err) {
- of_node_put(mdio);
- return err;
- }
- fsl_pq_mdio_bus_name(bus_name, mdio);
- of_node_put(mdio);
- snprintf(ug_info-phy_bus_id, sizeof(ug_info-phy_bus_id),
- %s:%02x, bus_name, *prop);
}
+ ug_info-phy_node = phy;
/* get the phy interface type, or default to MII */
prop = of_get_property(np, phy-connection-type, NULL);
if (!prop) {
/* handle interface property present in old trees */
+ if (!phy)
+ return -ENODEV;
.. here an error is returned. Is this intentional?
Yes, I did that intentionally because it looked like a bug to me
because of_get_property() is passed the phy value. However, I suppose
that if phy is null then of_get_property will just return NULL, so I
think I made a mistake. I'll post a patch to remove these two lines.
g.
+
prop = of_get_property(phy, interface, NULL);
if (prop != NULL) {
phy_interface = enet_to_phy_interface[*prop];
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 2f8ee7c..bc31975 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1100,7 +1100,7 @@ struct ucc_geth_info {
u32 eventRegMask;
u16 pausePeriod;
u16 extensionField;
- char phy_bus_id[BUS_ID_SIZE];
+ struct device_node *phy_node;
u8 weightfactor[NUM_TX_QUEUES];
u8 interruptcoalescingmaxvalue[NUM_RX_QUEUES];
u8 l2qt[UCC_GETH_VLAN_PRIORITY_MAX];
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/86xx: clean up smp init code
On Apr 27, 2009, at 10:06 AM, Martyn Welch wrote: I am using the config in the kernel (arch/powerpc/configs/68xx/ gef_ppc9a_defconfig) as is, ditto for the DTS. CONFIG_PHYS_64BIT is not set. However, looking into it a bit further 'device_type = soc;' is missing from the DTS file, so I assume get_immrbase() is returning -1. That might explain some other weird errors I recently noticed that I haven't managed to find the time to track down yet... I'm amazed this ever worked. If you want to send me a patch for the .dts to add device_type = soc for your various .dts I'll get that into 2.6.30 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc adjust oprofile_cpu_type version 3
Oprofile is changing the naming it is using for the compatibility modes.
Instead of having compat-powerx, oprofile will go to family naming
convention and use ibm-compat-vx. Currently only ibm-compat-v1 will
be defined.
The notion of compatibility events just started with POWER6. So there is
no way that any other tool could exist that is using these
oprofile_cpu_type strings we want to change.
Signed-off-by: Mike Wolf m...@linux.vnet.ibm.com
---
--- mainline.orig/arch/powerpc/kernel/cputable.c2009-04-16
09:47:49.0 -0500
+++ mainline/arch/powerpc/kernel/cputable.c 2009-04-27 10:28:03.0
-0500
@@ -382,7 +382,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = ppc64/compat-power5+,
+ .oprofile_cpu_type = ppc64/ibm-compat-v1,
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = power5+,
},
{ /* Power6 */
@@ -416,7 +417,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = ppc64/compat-power6,
+ .oprofile_cpu_type = ppc64/ibm-compat-v1,
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = power6,
},
{ /* 2.06-compliant processor, i.e. Power7 architected mode */
@@ -429,7 +431,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = ppc64/compat-power7,
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_cpu_type = ppc64/ibm-compat-v1,
.platform = power7,
},
{ /* Power7 */
@@ -1833,8 +1836,10 @@
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (old.oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL) {
t-oprofile_cpu_type = s-oprofile_cpu_type;
+ t-oprofile_type = s-oprofile_type;
+ }
}
*PTRRELOC(cur_cpu_spec) = the_cpu_spec;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/86xx: Add device_type entry to soc for ppc9a
The 'device_type = soc;' line *is* needed in the DTS for get_immrbase() to return the correct address. Signed-off-by: Martyn Welch martyn.we...@gefanuc.com --- arch/powerpc/boot/dts/gef_ppc9a.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts b/arch/powerpc/boot/dts/gef_ppc9a.dts index d47ad07..53a7a62 100644 --- a/arch/powerpc/boot/dts/gef_ppc9a.dts +++ b/arch/powerpc/boot/dts/gef_ppc9a.dts @@ -161,6 +161,7 @@ #address-cells = 1; #size-cells = 1; #interrupt-cells = 2; + device_type = soc; compatible = fsl,mpc8641-soc, simple-bus; ranges = 0x0 0xfef0 0x0010; reg = 0xfef0 0x10;// CCSRBAR 1M ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/13] OF device tree handling of PHY drivers
Kumar, David has pulled my phylib changes into his -next tree. However, some of the driver changes have been compile tested only due to lack of hardware. Who can I ask to test the changes to the following files? arch/powerpc/platforms/82xx/ep8248e.c |9 +- drivers/net/fs_enet/fs_enet-main.c| 69 +-- drivers/net/fs_enet/mii-bitbang.c | 29 +- drivers/net/fs_enet/mii-fec.c | 26 +- drivers/net/ucc_geth.c| 47 +- drivers/net/ucc_geth.h|2 +- Thanks, g. On Mon, Apr 27, 2009 at 3:54 AM, David Miller da...@davemloft.net wrote: From: Grant Likely grant.lik...@secretlab.ca Date: Sat, 25 Apr 2009 16:52:34 -0600 This series adds common code for reading PHY connection data out of the OpenFirmware device tree. This simplifies the network drivers which use the device tree and which currently implement their own solutions for reading the PHY data out of the device tree directly. I would like to see this series, or at least the core changes (1-4) plus the tested drivers (5-8 12, but #12 is a new driver and it may need more review), go into -next for 2.6.31. Due to dependencies, I think it is easiest if all of them go in via the same tree. David, are you willing to merge them via yours? Four of the patches are outside of drivers/net (patches 1 and 4 touch drivers/of/, and patches 9 10 touch arch/powerpc), but I personally have no issues if those changes go through you. I just need to double check with BenH. I've applied all of these patches to net-next-2.6, thanks. git://git.secretlab.ca/git/linux-2.6 next-net You know, if you had actually based this tree on net-next-2.6 I could have pulled from it. I actually tried, and I got a lot of upstream stuff I wasn't ready to get in that tree just yet :-/ -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
How to use Localbus on 5200B w/ 2.6.29.1
Hi all,
I have a question about the definition of the localbus on the Freescale
5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which
I could not figure out with the docs and the list archives...
When I use 'compatible = fsl,mpc5200b-lpb;' in the dts file, the
localbus and any nodes below it don't show up in /sys/devices.
When I use the following (top-level, not under the soc node) in the dts
file
snip
localbus {
compatible = fsl,lpb;
#address-cells = 2;
#size-cells = 1;
reg = 0xf300 0x32;
ranges = 0 0 0xfc00 0x0200
3 0 0xf002 0x0001 ;
fl...@0,0 {
compatible = cfi-flash;
reg = 0 0x0 0x200; // 32 MB
bank-width = 1; // width in bytes of
the flash bank
device-width = 1; // one devices on each
bank
#size-cells = 1;
#address-cells = 1;
};
my...@3,0 {
compatible = mydev;
reg = 0 0x0 0x100; // 256 Bytes, 32 used
interrupts = 1 3 2; // todo - level?
interrupt-parent = mpc5200_pic;
};
};
/snip
I see in /sys/devices
snip
# ls -al /sys/devices/
drwxr-xr-x7 00 0 Jan 1 00:00 .
drwxr-xr-x 11 00 0 Jan 1 00:00 ..
drwxr-xr-x 31 00 0 Jan 1 00:00 f000.soc5200
drwxr-xr-x4 00 0 Jan 1 00:00
f300.localbus
drwxr-xr-x2 00 0 Jan 1 00:00 platform
drwxr-xr-x5 00 0 Jan 1 00:00 system
drwxr-xr-x8 00 0 Jan 1 00:00 virtual
/snip
Does this mean that the documentation (and some existing dts files) are
inaccurate? What is the proper way to specify the localbus (or, in
particular, it's child nodes) on the 5200B?
In /sys/devices/f300.localbus, I see
snip
# ls -al /sys/devices/f300.localbus/
drwxr-xr-x4 00 0 Jan 1 00:00 .
drwxr-xr-x7 00 0 Jan 1 00:00 ..
-r--r--r--1 004096 Jan 1 00:00 devspec
drwxr-xr-x2 00 0 Jan 1 00:00 fc00.flash
drwxr-xr-x2 00 0 Jan 1 00:00 fc00.mydev
-r--r--r--1 004096 Jan 1 00:00 modalias
-r--r--r--1 004096 Jan 1 00:00 name
lrwxrwxrwx1 00 0 Jan 1 00:00 subsystem -
../../bus/of_platform
-rw-r--r--1 004096 Jan 1 00:00 uevent
/snip
which is also confusing, as both devices appear to have the same
address? Any idea what goes wrong here?
The flash device itself (mydev isn't present yet...) also doesn't work
although mtd is enabled, but that's probably a different problem.
Any help would be really welcome!
Thanks in advance,
Albrecht.
pgpP00KTgQBWJ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] net: Fix ucc_geth.c handling of phy 'interface' property.
On Mon, Apr 27, 2009 at 09:36:13AM -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
Previous rework to ucc_geth.c to add of_mdio support (net: Rework
ucc_geth driver to use of_mdio infrastructure) added a block of
code which broke older openfirmware device trees which use an
'interface' property in the phy node to describe the connection
between the MAC and the PHY. This patch removes the offending blurb.
[snip]
prop = of_get_property(np, phy-connection-type, NULL);
if (!prop) {
/* handle interface property present in old trees */
- if (!phy)
- return -ENODEV;
-
prop = of_get_property(phy, interface, NULL);
if (prop != NULL) {
phy_interface = enet_to_phy_interface[*prop];
The above test only makes a difference when there is no phy node -- so I
don't see how it was breaking device trees that had a phy node (with or
without an interface property). I can see it breaking fixed link
device trees, though.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to use Localbus on 5200B w/ 2.6.29.1
On Mon, Apr 27, 2009 at 11:18 AM, Albrecht Dreß albrecht.dr...@arcor.de wrote:
Hi all,
I have a question about the definition of the localbus on the Freescale
5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which I
could not figure out with the docs and the list archives...
When I use 'compatible = fsl,mpc5200b-lpb;' in the dts file, the localbus
and any nodes below it don't show up in /sys/devices.
For completeness use: compatible =
fsl,mpc5200b-lpb,fsl,mpc5200-lpb,simple-bus; Then it will work.
The kernel doesn't currently bind on the 'b' string, but we put it in
the list anyway to completely describe the hardware, just in case it
ever becomes important in the future.
[...]
my...@3,0 {
compatible = mydev;
mydev should be in the form: vendor,device.
reg = 0 0x0 0x100; // 256 Bytes, 32 used
If this is on CS3, then reg should be:
reg = 3 0x0 0x100;// 256 Bytes, 32 used
interrupts = 1 3 2; // todo - level?
interrupt-parent = mpc5200_pic;
};
};
# ls -al /sys/devices/f300.localbus/
drwxr-xr-x 4 0 0 0 Jan 1 00:00 .
drwxr-xr-x 7 0 0 0 Jan 1 00:00 ..
-r--r--r-- 1 0 0 4096 Jan 1 00:00 devspec
drwxr-xr-x 2 0 0 0 Jan 1 00:00 fc00.flash
drwxr-xr-x 2 0 0 0 Jan 1 00:00 fc00.mydev
-r--r--r-- 1 0 0 4096 Jan 1 00:00 modalias
-r--r--r-- 1 0 0 4096 Jan 1 00:00 name
lrwxrwxrwx 1 0 0 0 Jan 1 00:00 subsystem -
../../bus/of_platform
-rw-r--r-- 1 0 0 4096 Jan 1 00:00 uevent
/snip
which is also confusing, as both devices appear to have the same address?
Any idea what goes wrong here?
Because the reg property for mydev is wrong (see above).
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] net: Fix ucc_geth.c handling of phy 'interface' property.
On Mon, Apr 27, 2009 at 11:36 AM, Scott Wood scottw...@freescale.com wrote:
On Mon, Apr 27, 2009 at 09:36:13AM -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
Previous rework to ucc_geth.c to add of_mdio support (net: Rework
ucc_geth driver to use of_mdio infrastructure) added a block of
code which broke older openfirmware device trees which use an
'interface' property in the phy node to describe the connection
between the MAC and the PHY. This patch removes the offending blurb.
[snip]
prop = of_get_property(np, phy-connection-type, NULL);
if (!prop) {
/* handle interface property present in old trees */
- if (!phy)
- return -ENODEV;
-
prop = of_get_property(phy, interface, NULL);
if (prop != NULL) {
phy_interface = enet_to_phy_interface[*prop];
The above test only makes a difference when there is no phy node -- so I
don't see how it was breaking device trees that had a phy node (with or
without an interface property). I can see it breaking fixed link
device trees, though.
Sorry, you're right. I got myself confused when I was writing the
description. This patch fixes breakage when using a fixed-link and
there is no phy-connection-type property.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/86xx: Add new LAW MCM device tree nodes for all 86xx systems
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/gef_ppc9a.dts| 13 +
arch/powerpc/boot/dts/gef_sbc310.dts | 13 +
arch/powerpc/boot/dts/gef_sbc610.dts | 13 +
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 13 +
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 13 +
arch/powerpc/boot/dts/sbc8641d.dts | 13 +
7 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts
b/arch/powerpc/boot/dts/gef_ppc9a.dts
index d47ad07..cbf135c 100644
--- a/arch/powerpc/boot/dts/gef_ppc9a.dts
+++ b/arch/powerpc/boot/dts/gef_ppc9a.dts
@@ -166,6 +166,19 @@
reg = 0xfef0 0x10;// CCSRBAR 1M
bus-frequency = ;
+ mcm-...@0 {
+ compatible = fsl,mcm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 10;
+ };
+
+ m...@1000 {
+ compatible = fsl,mpc8641-mcm, fsl,mcm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
i2c1: i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts
b/arch/powerpc/boot/dts/gef_sbc310.dts
index 1569117..155776c 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -166,6 +166,19 @@
reg = 0xfef0 0x10;// CCSRBAR 1M
bus-frequency = ;
+ mcm-...@0 {
+ compatible = fsl,mcm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 10;
+ };
+
+ m...@1000 {
+ compatible = fsl,mpc8641-mcm, fsl,mcm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
i2c1: i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6582dbd..6898d7e 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -131,6 +131,19 @@
reg = 0xfef0 0x10;// CCSRBAR 1M
bus-frequency = ;
+ mcm-...@0 {
+ compatible = fsl,mcm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 10;
+ };
+
+ m...@1000 {
+ compatible = fsl,mpc8641-mcm, fsl,mcm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
i2c1: i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 4f081bb..252db6e 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -115,6 +115,19 @@
reg = 0xe000 0x1000;
bus-frequency = 0;
+ mcm-...@0 {
+ compatible = fsl,mcm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 10;
+ };
+
+ m...@1000 {
+ compatible = fsl,mpc8610-mcm, fsl,mcm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 51852e6..8bcccd7 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -117,6 +117,19 @@
reg = 0xffe0 0x1000; // CCSRBAR
bus-frequency = 0;
+ mcm-...@0 {
+ compatible = fsl,mcm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 10;
+ };
+
+ m...@1000 {
+ compatible = fsl,mpc8641-mcm, fsl,mcm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
[PATCH 1/2] powerpc/86xx: Add binding for LAWs and MCM
The first 4k region of CCSR space is well defined for local access windows, CCSRBAR, etc. The second 4k region is well defined as register for configuring and getting errors for the MPX coherency module. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 1 files changed, 64 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/mcm.txt diff --git a/Documentation/powerpc/dts-bindings/fsl/mcm.txt b/Documentation/powerpc/dts-bindings/fsl/mcm.txt new file mode 100644 index 000..4ceda9b --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mcm.txt @@ -0,0 +1,64 @@ += +MPX LAW Coherency Module Device Tree Binding +Copyright (C) 2009 Freescale Semiconductor Inc. += + +Local Access Window (LAW) Node + +The LAW node represents the region of CCSR space where local access +windows are configured. For MCM based devices this is the first 4k +of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some +number of local access windows as specified by fsl,num-laws. + +PROPERTIES + + - compatible + Usage: required + Value type: string + Definition: Must include fsl,mcm-law + + - reg + Usage: required + Value type: prop-encoded-array + Definition: A standard property. The value specifies the + physical address offset and length of the CCSR space + registers. + + - fsl,num-laws + Usage: required + Value type: u32 + Definition: The value specifies the number of local access + windows for this device. + += + +MPX Coherency Module Node + +The MPX LAW node represents the region of CCSR space where MCM config +and error reporting registers exist, this is the second 4k (0x1000) +of CCSR space. + +PROPERTIES + + - compatible + Usage: required + Value type: string + Definition: Must include fsl,CHIP-mcm, fsl,mcm where + CHIP is the processor (mpc8641, mpc8610, etc.) + + - reg + Usage: required + Value type: prop-encoded-array + Definition: A standard property. The value specifies the + physical address offset and length of the CCSR space + registers. + + - interrupts + Usage: required + Value type: prop-encoded-array + + - interrupt-parent + Usage: required + Value type: phandle + += -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
What about errata discovered after the device tree is deployed?
soc8...@e000 {
[...]
errata {
device_type = errata;
device_type is deprecated except for a couple of legacy uses. Please do
not add new ones.
compatible = fsl,mpc83xx_errata;
To be bound to by an errata driver? :-P
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
But that register is part of the QE parallel I/O port block (even if it
happens to be undocumented within that block), not part of the QE ENET10
erratum block. The device tree describes the hardware, not what you
want to do with it.
The presence of the erratum itself is indicated by the presence of the
buggy device, possibly in conjunction with SVR if the device tree is not
specific enough.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/86xx: Add device_type entry to soc for ppc9a
On Apr 27, 2009, at 11:24 AM, Martyn Welch wrote: The 'device_type = soc;' line *is* needed in the DTS for get_immrbase() to return the correct address. Signed-off-by: Martyn Welch martyn.we...@gefanuc.com --- arch/powerpc/boot/dts/gef_ppc9a.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] alim15x3: Remove historical hacks, re-enable init_hwif for PowerPC
Some time ago we had to disable init_hwif callback for PowerPC builds.
That was because of a historical IRQ overwrite in the driver, which
was causing IDE malfunction on the MPC8610HPCD PowerPC boards.
It's unclear whether this overwrite is still useful, but it is proven
to cause a bit of harm, and today some PowerPC targets (Xilinx ML510,
as reported by Roderick Colenbrander) need the init_hwif, so we have
to re-enable it and remove the overwrite.
Reported-by: Roderick Colenbrander thunderbir...@gmail.com
Suggested-by: Bartlomiej Zolnierkiewicz bzoln...@gmail.com
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
On Mon, Apr 27, 2009 at 10:46:25AM +0200, Roderick Colenbrander wrote:
Seems like this should allow MPC8610HPCD to work with Roderick's patch
if the IDE controller is set to native mode and ALI south-bridge SIRQ
tables are correctly set (or if this is not ALI's south-bridge). Anton?
OK, I'll test this approach.
Did this approach work for you?
I'm sorry for the delay. Yes, it seem to work.
drivers/ide/alim15x3.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
index 537da1c..e59b6de 100644
--- a/drivers/ide/alim15x3.c
+++ b/drivers/ide/alim15x3.c
@@ -402,27 +402,23 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
return cbl;
}
-#if !defined(CONFIG_SPARC64) !defined(CONFIG_PPC)
+#ifndef CONFIG_SPARC64
/**
* init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
* @hwif: interface to configure
*
* Obtain the IRQ tables for an ALi based IDE solution on the PC
* class platforms. This part of the code isn't applicable to the
- * Sparc and PowerPC systems.
+ * Sparc systems.
*/
static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
{
- struct pci_dev *dev = to_pci_dev(hwif-dev);
u8 ideic, inmir;
s8 irq_routing_table[] = { -1, 9, 3, 10, 4, 5, 7, 6,
1, 11, 0, 12, 0, 14, 0, 15 };
int irq = -1;
- if (dev-device == PCI_DEVICE_ID_AL_M5229)
- hwif-irq = hwif-channel ? 15 : 14;
-
if (isa_dev) {
/*
* read IDE interface control
@@ -455,7 +451,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
}
#else
#define init_hwif_ali15x3 NULL
-#endif /* !defined(CONFIG_SPARC64) !defined(CONFIG_PPC) */
+#endif /* CONFIG_SPARC64 */
/**
* init_dma_ali15x3- set up DMA on ALi15x3
--
1.6.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v6] introduce macro spin_event_timeout()
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi ti...@freescale.com
---
I'm making this a PowerPC-specific patch because I want to use
tb_ticks_per_usec, which does not exist on all other platforms. I don't want
to use jiffies because jiffies works only when interrupts are enabled, and
the resolution may not be fine enough.
arch/powerpc/include/asm/delay.h | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..1939e0f 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,6 +2,8 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include asm/time.h
+
/*
* Copyright 1996, Paul Mackerras.
*
@@ -30,5 +32,30 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates if the bit never changes. The delay is for devices that need a
+ * delay in between successive reads.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout;\
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) (tb_ticks_since(__start) = __loops)) \
+ udelay(delay); \
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote: Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c === --- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_native_64.c +++ linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c @@ -38,6 +38,9 @@ static DEFINE_SPINLOCK(native_tlbie_lock); +#define TLBIE(lp,a) \ + stringify_in_c(.long 0x7c000264 | ((a) 11) | ((lp) 21)) + Put this ppc-opcode.h now that we have it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote: Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h === --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h +++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h @@ -195,6 +195,7 @@ extern const char *powerpc_base_platform #define CPU_FTR_SAO LONG_ASM_CONST(0x0020) #define CPU_FTR_CP_USE_DCBTZLONG_ASM_CONST(0x0040) #define CPU_FTR_UNALIGNED_LD_STDLONG_ASM_CONST(0x0080) +#define CPU_FTR_TLBIE_206 LONG_ASM_CONST(0x0100) #ifndef __ASSEMBLY__ @@ -409,7 +410,7 @@ extern const char *powerpc_base_platform CPU_FTR_MMCRA | CPU_FTR_SMT | \ CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \ CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \ - CPU_FTR_DSCR | CPU_FTR_SAO) + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_TLBIE_206) #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 | \ I think our preference is to use MMU features for such things now instead of burning a cpu feature for it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Hi all, You are assuming the PCI memory space is prefetchable( no side effect) for DMA. Is it possible that DMA is from non-prefetchable memory space? This should be a safe assumption for this driver. Remember, this driver just does offload memcpy, from one region to another. So the PCI memory that you are reading from should be just a buffer of data, and there should be side-effect of reading it. However, I would like to see a comment at the top of the file warning people that copying from PCI memory will result in prefetched reads. Here's a few results from DMA tests between two MPC8349EA boards housed in a CPCI chassis. 1. DMA mode register (DMAMRn) PCI read command (PRC, bits 11:10) a) DMAMRn[PRC] = 00 = PCI Read The PCI read command is 6h on the PCI bus. For DMA lengths of less than 1 cache line (32-bytes) the DMA controller will generate a PCI 6h command. However, for lengths of 32-bytes and higher, the DMA controller actually generates a PCI Read Line (Eh) command. Freescale indicated that this 'change of PCI command code' functionality is an undocumented 'feature', there to improve performance for longer read lengths. b) DMAMRn[PRC] = 01 = PCI Read Line Generated the PCI command code for PCI read line (Eh), regardless of DMA length. c) DMAMRn[PRC] = 10 = PCI Read Multiple Generated the PCI command code for PCI Read Multiple (Ch), regardless of DMA length. 2. DMA from areas marked as non-prefetchable. We setup two test cases: a) Two boards in the same PCI segment with no intervening bridges. b) Two boards in separate PCI segments with intervening bridges (in this case, there was two bridges on SBS CPCI-to-CPI backplane bridging cards). The PCI window to the IMMR registers on the boards is marked as non-prefetchable. DMA from that area (reads) appeared on the PCI bus as single 32-bit read transactions, i.e., the target device effectively ignores the PCI read command, and the target returns read data as single reads, i.e., the target acts as as non-prefetchable memory. We tested with the PCI Read Multiple command, and no data was ever prefetched from the target. The bridges did not prefetch and discard data, eg. we tried 36-bytes, and there were 9 separate 4-byte transactions (we were using a 32-bit PCI host for this test). Hence, at least for this example target device, there are no side effects to using PCI read multiple on the bus master, to a target PCI memory region marked as non-prefetchable. So even though the bridges were seeing transactions that indicated read multiple, only single read cycles were seen to be used. Would you like some sort of summary of this info for a commit message? Would you like us to check any other transaction/register combos? Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: minimizing the configuration of linkstation_defconfig
On Apr 24, 2009, at 5:33 PM, Rogério Brito wrote: This patch addresses the following issues: 01. makes CFQ the default scheduler, to be in line with the rest of the kernel. 02. since linkstations are meant to store files, enable large blk devices. 03. disable CONFIG_MIGRATION in in such low memory devices. 04. disable CONFIG_BLK_DEV_RAM. do we not allow booting a ramdisk? 05. disable CONFIG_SCSI_LOWLEVEL, as no device under that tree is used. 06. idem for CONFIG_NETDEV_1. 07. idem for CONFIG_WIRELESS. 08. idem for CONFIG_HWMON. 09. idem for CONFIG_CRYPTO_HW. 10. disable CONFIG_VIDEO_OUTPUT_CONTROL. 11. keep consistency and disable extended attributes in CIFS, ext3, and NFS. 12. enable CONFIG_PRINTK_TIME. Signed-off-by: Rogério Brito rbr...@ime.usp.br --- Dear Kumar, please, apply this one. I have another patch regarding one regression regarding MTD PHYSMAP_COMPAT that I plan to send on top of this one. Thanks. Ok, can we look at just specifying such info in the linkstation device tree. Also, can you break this defconfig update into two patches. 1. that just updates to 2.6.30-rc3 (or latest) and 2. that makes the various changes you've listed above. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
David Hawkins wrote: Would you like some sort of summary of this info for a commit message? That's probably overkill. I just want a sentence or two that tells someone looking at the code casually that the behavior of reading PCI memory might be different than what they expect. Would you like us to check any other transaction/register combos? Yes, could you try this on non-PCI memory? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
On Apr 27, 2009, at 2:31 PM, Kumar Gala wrote: On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote: Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h === --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h +++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h @@ -195,6 +195,7 @@ extern const char *powerpc_base_platform #define CPU_FTR_SAO LONG_ASM_CONST(0x0020) #define CPU_FTR_CP_USE_DCBTZLONG_ASM_CONST(0x0040) #define CPU_FTR_UNALIGNED_LD_STDLONG_ASM_CONST(0x0080) +#define CPU_FTR_TLBIE_206 LONG_ASM_CONST(0x0100) #ifndef __ASSEMBLY__ @@ -409,7 +410,7 @@ extern const char *powerpc_base_platform CPU_FTR_MMCRA | CPU_FTR_SMT | \ CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \ CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \ - CPU_FTR_DSCR | CPU_FTR_SAO) + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_TLBIE_206) #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 | \ I think our preference is to use MMU features for such things now instead of burning a cpu feature for it. I see Ben has already made this comment.. so I just second his notion. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Would you like some sort of summary of this info for a commit message? That's probably overkill. I just want a sentence or two that tells someone looking at the code casually that the behavior of reading PCI memory might be different than what they expect. Ok, will-do. Would you like us to check any other transaction/register combos? Yes, could you try this on non-PCI memory? We've been using it to DMA between the x86 host main memory and the MPC8349EA boards (PCI targets). The reason we changed to Read Multiple was that it had a dramatic improvement in efficiency through bridges. However, the x86 host memory is prefetchable, so is consistent with the use of Read Multiple. Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Apr 27, 2009, at 2:48 PM, David Hawkins wrote: Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) You can mark the pci inbound window on the 83xx as non-prefetchable (assuming 83xx is host). On a x86 host I doubt there is any easy way to get non-prefetchable memory. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) You can mark the pci inbound window on the 83xx as non-prefetchable (assuming 83xx is host). On a x86 host I doubt there is any easy way to get non-prefetchable memory. Yep, we were going to do that, but chose to use the 1MB region already setup for the IMMRs since its already marked as non-prefetchable. We were only doing reads, so it wasn't going to hurt anything. I doubt that marking one of the other BAR regions as non-prefetchable will give a different result. However, we're more than happy to double-check if you'd like. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
You can mark the pci inbound window on the 83xx as non-prefetchable (assuming 83xx is host). On a x86 host I doubt there is any easy way to get non-prefetchable memory. One more note; we don't have access to a host-mode MPC8349EA, our boards are all targets. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Apr 27, 2009, at 3:00 PM, David Hawkins wrote: Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) You can mark the pci inbound window on the 83xx as non-prefetchable (assuming 83xx is host). On a x86 host I doubt there is any easy way to get non-prefetchable memory. Yep, we were going to do that, but chose to use the 1MB region already setup for the IMMRs since its already marked as non-prefetchable. We were only doing reads, so it wasn't going to hurt anything. I doubt that marking one of the other BAR regions as non-prefetchable will give a different result. However, we're more than happy to double-check if you'd like. Its possible you'll get a different result since IMMR is a register space internal and thats normally a completely different bus than memory would be (internal to the 83xx). I'd suggest double-checking w/ a BAR marked non-prefetch pointing to real memory. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
David Hawkins wrote: Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) H I was going to say any SOC device in the IMMR, but I don't see anything there that would constitute a memory buffer. I test this change on an 8610 and DMA to a register I/O, where this bit isn't even defined, and it made no difference. So I guess this change is okay. Acked-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) You can mark the pci inbound window on the 83xx as non-prefetchable (assuming 83xx is host). On a x86 host I doubt there is any easy way to get non-prefetchable memory. Yep, we were going to do that, but chose to use the 1MB region already setup for the IMMRs since its already marked as non-prefetchable. We were only doing reads, so it wasn't going to hurt anything. I doubt that marking one of the other BAR regions as non-prefetchable will give a different result. However, we're more than happy to double-check if you'd like. Its possible you'll get a different result since IMMR is a register space internal and thats normally a completely different bus than memory would be (internal to the 83xx). I'd suggest double-checking w/a BAR marked non-prefetch pointing to real memory. We had a 4k BAR1 setup to point to DDR memory. With prefetchable set, a 36-byte transfer generated a burst-of-8 32-bit words followed by a single transaction. With non-prefetchable set, the transfers were all single. So it works like we'd expect. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'merge' branch for 2.6.30 (updated)
Paul, Can we possibly get this and the other pull requests dealt with and sent to Linus so we might get such fixes in before he tags a -rc4. thanks - k Please pull from 'merge' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge to receive the following updates: arch/powerpc/boot/dts/gef_ppc9a.dts |1 + arch/powerpc/include/asm/mmu.h|6 -- arch/powerpc/include/asm/ppc-opcode.h | 11 +-- arch/powerpc/kernel/cputable.c|2 +- arch/powerpc/mm/tlb_nohash_low.S | 16 ++-- 5 files changed, 5 insertions(+), 31 deletions(-) Kumar Gala (1): Revert powerpc: Add support for early tlbilx opcode Martyn Welch (1): powerpc/86xx: Add device_type entry to soc for ppc9a Stephen Rothwell (1): powerpc: fix for long standing bug noticed by gcc 4.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Hi Timur, Would you like some sort of summary of this info for a commit message? That's probably overkill. I just want a sentence or two that tells someone looking at the code casually that the behavior of reading PCI memory might be different than what they expect. Could you help us with the wording you'd like to see in the code. Did you want to see something in the header comments, or something near the register settings? How about something like this in place of the existing PCI_RM comment: PRC_RM - PCI read multiple The default PCI read command used by the DMA controller is PCI Read (PCI command 6h). When the burst length is 32-bytes or longer, PCI Read Line (PCI command Eh) is used (undocumented feature of the controller). Using PCI read multiple (PCI command Ch) results in high-performance across PCI bridges. DMA transfers to non-prefetchable PCI registers should not result in prefetched reads, even when using the PCI read multiple command. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
David Hawkins wrote: PRC_RM - PCI read multiple The default PCI read command used by the DMA controller is PCI Read (PCI command 6h). When the burst length is 32-bytes or longer, PCI Read Line (PCI command Eh) is used (undocumented feature of the controller). Using PCI read multiple (PCI command Ch) results in high-performance across PCI bridges. DMA transfers to non-prefetchable PCI registers should not result in prefetched reads, even when using the PCI read multiple command. I was thinking more along the lines of: This driver tells the DMA controller to use the PCI Read Multiple command, instead of the PCI Read Line command, for PCI read operations. Please be aware that this setting may result in read pre-fetching on some platforms. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx: Add new LAW MCM device tree nodes for all 85xx systems
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/ksi8560.dts | 13 +
arch/powerpc/boot/dts/mpc8536ds.dts| 13 +
arch/powerpc/boot/dts/mpc8540ads.dts | 13 +
arch/powerpc/boot/dts/mpc8541cds.dts | 13 +
arch/powerpc/boot/dts/mpc8544ds.dts| 13 +
arch/powerpc/boot/dts/mpc8548cds.dts | 13 +
arch/powerpc/boot/dts/mpc8555cds.dts | 13 +
arch/powerpc/boot/dts/mpc8560ads.dts | 13 +
arch/powerpc/boot/dts/mpc8568mds.dts | 13 +
arch/powerpc/boot/dts/mpc8572ds.dts| 13 +
arch/powerpc/boot/dts/mpc8572ds_36b.dts| 13 +
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 13 +
arch/powerpc/boot/dts/sbc8548.dts | 13 +
arch/powerpc/boot/dts/sbc8560.dts | 13 +
arch/powerpc/boot/dts/socrates.dts | 13 +
arch/powerpc/boot/dts/stx_gp3_8560.dts | 13 +
arch/powerpc/boot/dts/tqm8540.dts | 13 +
arch/powerpc/boot/dts/tqm8541.dts | 13 +
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 13 +
arch/powerpc/boot/dts/tqm8548.dts | 13 +
arch/powerpc/boot/dts/tqm8555.dts | 13 +
arch/powerpc/boot/dts/tqm8560.dts | 13 +
22 files changed, 286 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ksi8560.dts
b/arch/powerpc/boot/dts/ksi8560.dts
index c9cfd37..bdb7fc0 100644
--- a/arch/powerpc/boot/dts/ksi8560.dts
+++ b/arch/powerpc/boot/dts/ksi8560.dts
@@ -56,6 +56,19 @@
ranges = 0x 0xfdf0 0x0010;
bus-frequency = 0;/* Fixed by
bootwrapper */
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 8;
+ };
+
+ e...@1000 {
+ compatible = fsl,mpc8560-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
memory-control...@2000 {
compatible = fsl,mpc8540-memory-controller;
reg = 0x2000 0x1000;
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts
b/arch/powerpc/boot/dts/mpc8536ds.dts
index af8c64c..b6fd856 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -54,6 +54,19 @@
reg = 0xffe0 0x1000;
bus-frequency = 0;// Filled out by uboot.
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 12;
+ };
+
+ e...@1000 {
+ compatible = fsl,mpc8536-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
memory-control...@2000 {
compatible = fsl,mpc8536-memory-controller;
reg = 0x2000 0x1000;
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
b/arch/powerpc/boot/dts/mpc8540ads.dts
index de5535c..7c8b109 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -58,6 +58,19 @@
reg = 0xe000 0x10;// CCSRBAR 1M
bus-frequency = 0;
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 8;
+ };
+
+ e...@1000 {
+ compatible = fsl,mpc8540-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
memory-control...@2000 {
compatible = fsl,8540-memory-controller;
reg = 0x2000 0x1000;
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts
b/arch/powerpc/boot/dts/mpc8541cds.dts
index d10f5d6..de9d8b5 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -58,6 +58,19 @@
reg = 0xe000 0x1000; // CCSRBAR 1M
bus-frequency = 0;
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 8;
+ };
+
+ e...@1000 {
+ compatible = fsl,mpc8541-ecm,
Re: [PATCH] fsldma: use PCI Read Multiple command
Hi Timur, PRC_RM - PCI read multiple The default PCI read command used by the DMA controller is PCI Read (PCI command 6h). When the burst length is 32-bytes or longer, PCI Read Line (PCI command Eh) is used (undocumented feature of the controller). Using PCI read multiple (PCI command Ch) results in high-performance across PCI bridges. DMA transfers to non-prefetchable PCI registers should not result in prefetched reads, even when using the PCI read multiple command. I was thinking more along the lines of: This driver tells the DMA controller to use the PCI Read Multiple command, instead of the PCI Read Line command, for PCI read operations. Please be aware that this setting may result in read pre-fetching on some platforms. Ok, thanks. Ira will add your comment to the body of the code near the PRC_RM command and submit a new patch. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Mon, Apr 27, 2009 at 03:26:36PM -0500, Timur Tabi wrote: David Hawkins wrote: PRC_RM - PCI read multiple The default PCI read command used by the DMA controller is PCI Read (PCI command 6h). When the burst length is 32-bytes or longer, PCI Read Line (PCI command Eh) is used (undocumented feature of the controller). Using PCI read multiple (PCI command Ch) results in high-performance across PCI bridges. DMA transfers to non-prefetchable PCI registers should not result in prefetched reads, even when using the PCI read multiple command. I was thinking more along the lines of: This driver tells the DMA controller to use the PCI Read Multiple command, instead of the PCI Read Line command, for PCI read operations. Please be aware that this setting may result in read pre-fetching on some platforms. How about the following revised patch? Is it ok to inline it this way, or should I send another email to the list containing just this patch? From 73e42fa58c93de8d4d429ba8e069b60c42037b58 Mon Sep 17 00:00:00 2001 From: Ira W. Snyder i...@ovro.caltech.edu Date: Thu, 23 Apr 2009 16:17:54 -0700 Subject: [PATCH] fsldma: use PCI Read Multiple command By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI bridge was between the devices trying to communicate. A simple test driver showed an increase from 4MB/sec to 116MB/sec when performing DMA over the PCI bus. Using DMA to transfer between blocks of local SDRAM showed no change in performance with this patch. The dmatest driver was also used to verify the correctness of the transfers, and showed no errors. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- v1 - v2: * Added comment warning about possible prefetching drivers/dma/fsldma.c | 10 -- drivers/dma/fsldma.h |1 + 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index da8a8ed..5943ca8 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -12,6 +12,11 @@ * also fit for MPC8560, MPC8555, MPC8548, MPC8641, and etc. * The support for MPC8349 DMA contorller is also added. * + * This driver instructs the DMA controller to issue the PCI Read Multiple + * command for PCI read operations, instead of using the default PCI Read Line + * command. Please be aware that this setting may result in read pre-fetching + * on some platforms. + * * This is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or @@ -49,9 +54,10 @@ static void dma_init(struct fsl_dma_chan *fsl_chan) case FSL_DMA_IP_83XX: /* Set the channel to below modes: * EOTIE - End-of-transfer interrupt enable +* PRC_RM - PCI read multiple */ - DMA_OUT(fsl_chan, fsl_chan-reg_base-mr, FSL_DMA_MR_EOTIE, - 32); + DMA_OUT(fsl_chan, fsl_chan-reg_base-mr, FSL_DMA_MR_EOTIE + | FSL_DMA_MR_PRC_RM, 32); break; } diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index 4f21a51..dc7f268 100644 --- a/drivers/dma/fsldma.h +++ b/drivers/dma/fsldma.h @@ -38,6 +38,7 @@ /* Special MR definition for MPC8349 */ #define FSL_DMA_MR_EOTIE 0x0080 +#define FSL_DMA_MR_PRC_RM 0x0800 #define FSL_DMA_SR_CH 0x0020 #define FSL_DMA_SR_PE 0x0010 -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
David Hawkins wrote: Ira will add your comment to the body of the code near the PRC_RM command and submit a new patch. I'd rather have it near the top where people can see it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Timur Tabi wrote: David Hawkins wrote: Ira will add your comment to the body of the code near the PRC_RM command and submit a new patch. I'd rather have it near the top where people can see it. Looks like Ira had the same thought :) Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Adding Kumar to the CC: list, since he might pick up the patch. Ira Snyder wrote: From 73e42fa58c93de8d4d429ba8e069b60c42037b58 Mon Sep 17 00:00:00 2001 From: Ira W. Snyder i...@ovro.caltech.edu Date: Thu, 23 Apr 2009 16:17:54 -0700 Subject: [PATCH] fsldma: use PCI Read Multiple command By default, the Freescale 83xx DMA controller uses the PCI Read Line command when reading data over the PCI bus. Setting the controller to use the PCI Read Multiple command instead allows the controller to read much larger bursts of data, which provides a drastic speed increase. The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI bridge was between the devices trying to communicate. A simple test driver showed an increase from 4MB/sec to 116MB/sec when performing DMA over the PCI bus. Using DMA to transfer between blocks of local SDRAM showed no change in performance with this patch. The dmatest driver was also used to verify the correctness of the transfers, and showed no errors. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu Acked-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Mon, Apr 27, 2009 at 03:04:49PM -0500, Timur Tabi wrote: David Hawkins wrote: Can you give me an example of non-PCI memory that would be non-prefetchable that you'd like us to try? We can see if our host CPUs have an area like that ... we just need to know what device to look for first :) H I was going to say any SOC device in the IMMR, but I don't see anything there that would constitute a memory buffer. I test this change on an 8610 and DMA to a register I/O, where this bit isn't even defined, and it made no difference. So I guess this change is okay. I thought the driver only used the bit if the device tree indicated it was an 83xx-era DMA controller? That said, the bits are documented as specifically for PCI, so it would be surprising if it had any effect elsewhere. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Scott Wood wrote: I thought the driver only used the bit if the device tree indicated it was an 83xx-era DMA controller? I just wanted to make sure it didn't do anything weird. It was the only test I could think of that didn't involve PCI. That said, the bits are documented as specifically for PCI, so it would be surprising if it had any effect elsewhere. Surely you wouldn't really be surprised by incorrect documentation of our parts. :-) -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi ti...@freescale.com wrote: Adding Kumar to the CC: list, since he might pick up the patch. Acked-by: Dan Williams dan.j.willi...@intel.com I agree with taking this through Kumar's tree. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: leds: Add openfirmware platform device support breaks sparc
On Tue, 03 Mar 2009 16:37:13 -0800 (PST) David Miller da...@davemloft.net wrote: From: Sean MacLennan smaclen...@pikatech.com Date: Tue, 3 Mar 2009 19:29:32 -0500 It has been. u carry the two... longer than I want to admit since I worked on a sparc. Would GPIO based LEDS make sense on a sparc platform? Is sparc used much in the embedded world? If yes, the of_register_platform_driver is just a nice wrapper. It would be trivial to either change it to work on sparc, or add the wrapper to the sparc includes. We generally create the platform devices by hand for LED devices on sparc64. I'd CONFIG_POWERPC depend this thing for now. Nobody has done this, so current mainline's sparc64 allmodconfig remains busted. This? --- a/drivers/leds/Kconfig~a +++ a/drivers/leds/Kconfig @@ -139,6 +139,7 @@ config LEDS_GPIO_PLATFORM config LEDS_GPIO_OF bool OpenFirmware platform device bindings for GPIO LEDs depends on LEDS_GPIO OF_DEVICE + depends on POWERPC default y help Let the leds-gpio driver drive LEDs which have been defined as _ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/6] powerpc: Move #ifdef'ed body of do_IRQ() into a separate function
On Sat, 2009-04-25 at 20:18 +0200, Christoph Hellwig wrote: On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote: +#ifdef CONFIG_IRQSTACKS Wasn't there a plan to make CONFIG_IRQSTACKS the unconditional default? Not sure. Looks like the 64-bit configs all turn it on, and all but one or two of the 32-bit configs don't. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] fsldma: use PCI Read Multiple command
You are assuming the PCI memory space is prefetchable( no side effect) for DMA. Is it possible that DMA is from non-prefetchable memory space? This should be a safe assumption for this driver. Remember, this driver just does offload memcpy, from one region to another. So the PCI memory that you are reading from should be just a buffer of data, and there should be side-effect of reading it. However, I would like to see a comment at the top of the file warning people that copying from PCI memory will result in prefetched reads. How about FIFO RAM case? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
How about FIFO RAM case? If the FIFO has a fixed address, then according to the user guide, the DMA controller won't generate a burst transaction to it. We can try confirming this if you'd like. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] fsldma: use PCI Read Multiple command
Here's a few results from DMA tests between two MPC8349EA boards housed in a CPCI chassis. 1. DMA mode register (DMAMRn) PCI read command (PRC, bits 11:10) a) DMAMRn[PRC] = 00 = PCI Read The PCI read command is 6h on the PCI bus. For DMA lengths of less than 1 cache line (32-bytes) the DMA controller will generate a PCI 6h command. However, for lengths of 32-bytes and higher, the DMA controller actually generates a PCI Read Line (Eh) command. Freescale indicated that this 'change of PCI command code' functionality is an undocumented 'feature', there to improve performance for longer read lengths. b) DMAMRn[PRC] = 01 = PCI Read Line Generated the PCI command code for PCI read line (Eh), regardless of DMA length. c) DMAMRn[PRC] = 10 = PCI Read Multiple Generated the PCI command code for PCI Read Multiple (Ch), regardless of DMA length. Good summary! For the DMA PCI read/line/multi-line is outbound transaction. So according to your experiment, the 8349 PCI controller(as master) attemp to streaming/combining the outbound transaction(treated as prefetchable space). IIRC, the early 8349EUM has the bit[2]-SE in the POCMRn register, and is removed now. Not sure if it does function. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] fsldma: use PCI Read Multiple command
You can mark the pci inbound window on the 83xx as non-prefetchable(assuming 83xx is host). On a x86 host I doubt there is any easy way to get non-prefetchable memory. One more note; we don't have access to a host-mode MPC8349EA, our boards are all targets. Actually we also can use the inbound window(w/wo prefetchable) in the agent mode. It doesn't care if it is host or agent. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Hi Dave, For the DMA PCI read/line/multi-line is outbound transaction. So according to your experiment, the 8349 PCI controller(as master) attemp to streaming/combining the outbound transaction(treated as prefetchable space). Yep, with the MPC8349EA configured as a PCI Target, and operating as a Bus Master, DMA transfers between two MPC8349EA targets to prefetchable memory on the slave will burst at pretty much full-speed over the PCI bus. The same goes for DMA to the host memory. However, reading from the host is slower, as the bursts get chopped up more than they do between two target boards. At some point I'll get a bunch of screen captures and put them in a document. IIRC, the early 8349EUM has the bit[2]-SE in the POCMRn register, and is removed now. Not sure if it does function. Hey yeah, I looked in the 8349E manual, and it is defined. I'm not sure why it would be defined there though. I can't think of why the master would want to disable streaming based on a bit setting; it should burst until the IOS says its full. Anyway, the bit is gone now, so we'll just ignore the fact it existed :) Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: minimizing the configuration of linkstation_defconfig
Hi, Kumar.
On Apr 27 2009, Kumar Gala wrote:
On Apr 24, 2009, at 5:33 PM, Rogério Brito wrote:
04. disable CONFIG_BLK_DEV_RAM.
do we not allow booting a ramdisk?
Well, do we need a block device in ram to use initramfs?
(...)
Dear Kumar, please, apply this one.
I have another patch regarding one regression regarding MTD
PHYSMAP_COMPAT that I plan to send on top of this one.
Ok, can we look at just specifying such info in the linkstation device
tree.
Thanks. The MTD PHYMAP_COMPAT are the things that have been bugging me
and my main reason to keep with the bleeding edge kernels is to get things
whey they were (regarding mtd) as in kernel 2.6.28.
As I have no experience with MTD devices, I would appreciate a reference to
their workings... All that I know is that all my /dev/mtd* devices are gone
if I boot a 2.6.29* kernel.
Of course, I can do a git bisect process (since the MTD subsystem doesn't
work as it did in the past even if I enable PHYMAP_COMPAT and put the same
settings there, quite unfortunately).
Also, can you break this defconfig update into two patches. 1. that
just updates to 2.6.30-rc3 (or latest) and 2. that makes the various
changes you've listed above.
No problems with that. I will do that ASAP. Thanks for your kind comments.
Regards, Rogério Brito.
P.S.: Guennadi, did you see any regressions with your linkstation/kurobox
HG or whatever device you have?
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: drivers/video/logo/logo_linux_mono.c build error
Hi Andrew, On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton a...@linux-foundation.org wrote: powerpc allmodconfig, current mainline: drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict switching it from __initconst to __initdata fixes it. Interesting. The program that generates the .c file above produces __initdata for me ... -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpTZIQNrjE0k.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please revert edada399 and 9203fc9c
Linus, Please revert commits edada399 (powerpc: Use TEXT_TEXT macro in linker script.) and 9203fc9c (powerpc: Use __REF macro instead of old .text.init.refok.), which depends on edada399. Commit edada399 breaks the build because it moves the __ftr_alt_* sections of a file away from the .text section, causing link failures due to relative conditional branch targets being too far away from the branch instructions. This happens on pretty much all 64-bit powerpc configs. Clearly these patches were never even build-tested. They were never acked by the powerpc maintainer (Ben) - because he was on vacation - and they weren't sent to the deputy maintainer (me) or the relevant mailing list (linuxppc-dev). And they are clearly not fixes for regressions or serious bugs, so why are these patches going in after -rc3 anyway? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removing get_immrbase()??
On Wed, Apr 22, 2009 at 11:41:31PM -0500, Kumar Gala wrote: On Apr 22, 2009, at 11:06 PM, David Gibson wrote: Well, yes, I guess I agree. How immutable you consider the device tree blob to be is a judgement call based on the specific details of platform/board in question. If it is indeed a reference platform, in the early stages of development where it's reasonably easy to change the dtb, then it's probably best to change the dtb in sync with the kernel to reduce long-term cruft build-up. But once the board is sufficiently widely deployed, you want to stop doing that and include backwards compatibility workarounds in the kernel to cope with the widely deployed broken trees. I disagree with the point about providing workarounds to cope w/deployed device trees (at least for the problems I'm thinking off in which nodes didn't exist). This just sounds like double work and is a disincentive to actually making such changes. Lets say I had an error driver for our MCM (core to soc coherency module). It was getting the base address by using get_immrbase(). Today I proposed a proper device node for the MCM block as it doesn't exist in .dts today. We add such a node into .dts and I can clean up my error driver to use proper device node information. However I've just broken any old .dts that didn't have this node. You are saying I need to add code into the kernel to create this new node and we have to keep that code around for ever in the kernel.. why would I ever bother to actually changing anything than. Well, again. It's a judgement call, balancing the pain of having to update the dts files (which depends on how widely deployed the platform is) versus the pain of having to keep the bacwards compatibility shim in the kernel. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: microblaze: Statically linking device tree blobs into the kernel
On Mon, Apr 27, 2009 at 02:24:42PM +1000, John Williams wrote: To MicroBlazers and other interested parties: Currently the MicroBlaze kernel boot-time ABI requires r7 to point to a valid DTB, whereupon in early kernel setup the DTB is copied to a statically allocated 16k memory region inside the kernel. From there it is later queried by the platform startup code. For simple boot scenarios the ability to statically bind a DTB into the kernel image would clearly be useful. In PPC land, this is achieved through the simpleboot bootloader that lives in arch/powerpc/boot. The DTB becomes part of the simpleboot payload, and is passed to the kernel through the normal means. I'm not convinced duplicating this for MicroBlaze is a good idea, I think it would be overkill. However, the make syntax that PPC uses to achieve DTB binding is quite nice: $ make simpleImage.board which binds arch/powerpc/boot/dts/board.dts into the boot payload. My feeling is that we should make use of the fact that the DTB region is statically allocated in the MicroBlaze kernel anyway. From arch/microblaze/kernel/vmlinux.lds.S: . = ALIGN (4) ; _fdt_start = . ; /* place for fdt blob */ . = . + 0x4000; _fdt_end = . ; and in head.S, the DTB at r7 is copied into place at _fdt_start /* save fdt to kernel location */ /* r7 stores pointer to fdt blob */ beqir7, no_fdt_arg or r11, r0, r0 /* incremment */ ori r4, r0, TOPHYS(_fdt_start) /* save bram context */ ori r3, r0, (0x4000 - 4) _copy_fdt: simple copy loop no_fdt_arg: Since this memory is already allocated in the kernel image but is normally just zeros, to bind a DTB to the kernel we could just store it in-situ. This way, if a non-zero r7 is passed in at boot time, head.S will naturally overwrite (and thus override) the default DTB that was inside the kernel image. What I'm not so sure about is how best to achieve this in the kbuild sequence. I see two options: (a) use .incbin in a .S file, similar to how the initramfs gets linked in in /usr/Makefile etc, or Or you could build the .dts directly into a .S file (which dtc supports) and #include or link that in. It's possible the dtc asm output mode would need some work, but that's easily enough done. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removing get_immrbase()??
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote: David Gibson wrote: It's not so much point of view as situation. Putting the device tree in the firmware and putting the device tree in the kernel are both valid choices, with their own distinct advantages and drawbacks. I was under the impression that the reason we put the device trees in the kernel is because we didn't have a better place to put them. Keeping them in the kernel repository was just convenient. So I personally don't consider the *location* of the DTS files to be a basis for deciding what they really mean. I'm not talking abou where the DTS files sit, I'm talking about where the compiled blob sits. There are a number of options here: * built into the firmware * loaded by the firmware, say from a separate flash partition (e.g. modern uboot) * generated at runtime by the firmware * built into the kernel's bootwrapper (e.g. cuboot). * generated by the bootwrapper at runtime from firmware information in another format (e.g. paul's proposed res2dt approach for PReP) Which method is appropriate depends on the needs of the platform, including what legacy stuff we need to deal with for the platform. Then in turn, how hard we should work to make the kernel backwards compatible with old device tree formats depends on what choice we made here (for platform specific devices, obviously). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removing get_immrbase()??
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote: On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote: David Gibson wrote: It's not so much point of view as situation. Putting the device tree in the firmware and putting the device tree in the kernel are both valid choices, with their own distinct advantages and drawbacks. I was under the impression that the reason we put the device trees in the kernel is because we didn't have a better place to put them. Keeping them in the kernel repository was just convenient. So I personally don't consider the *location* of the DTS files to be a basis for deciding what they really mean. I'm not sure why are we trying to make things harder for ourselves? x86 has a long history fighting with bogus bioses/dmi/acpi tables, up to the point where they completely ignore any information that BIOS provides, because that information is unreliable or hard to deal with. With FDT (i.e. not hard-coded OF), we have a great opportunity to keep both device tree and Linux code legacyjunk-free. All we have to do is to declare one simple thing: don't put device-tree into the read-only memory. Upgrading device tree blob in the rewritable NOR/NAND flashes is safe in overwhelming cases, just as safe as upgrading kernel image in the NOR/NAND. And for those who didn't listen our pleases, i.e. for those who put device-tree blob into some kind of ROM or dangerous- to-upgrade memory or region of memory, we can always provide boot wrappers, and thus isolate the legacy stuff. I mean isolate it in their small legacy world, if anyone actually cares about these cases. Indeed, this is a large part of the idea for the flattened device tree. Which is why I don't understand why when the idea of dtbs has been floated, everyone seems to have been in a rush to put the blobs into the firmware. That's certainly one approach, and a good one for certain needs (one kernel binary on many platforms, for example), but putting the blob in the kernel is also an entirely valid approach and avoids some drawbacks of having the blob in the firmware. We're never going to get away from having shitty firmwares, but at least with fdts we can isolate the handling of them from the bulk of the kernel. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removing get_immrbase()??
On Thu, Apr 23, 2009 at 07:53:11AM -0600, Grant Likely wrote: On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote: Scott Wood wrote: Timur Tabi wrote: these two are related and seem like we could look for fsl,cpm2 That's okay, as long as you don't break compatibility with older device trees that don't have that property, unless you can demonstrate that these trees would never work with the current kernel anyway. All CPM2 device trees should have fsl,cpm2 listed in the compatible of the CPM node. Yes, but did they always have that compatible field? I'm concerned about situations where someone updates his kernel but not his device tree. This is a scenerio that we always need to try to support. I disagree. If you update your kernel you should update your device tree (thus we have .dts in the kernel tree and not somewhere else). Not always possible. The device tree may be 'softer' than firmware, and easier to update, but it is still firmer than the kernel. That is Again, this is not inherent, it's a platform design choice. It's this way for modern u-boot, but not for all platforms. why so much effort has been spent to not break compatibility with older device trees. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
From: Milton Miller milt...@bga.com This adds the PowerPC 2.06 tlbie mnemonics and keeps backwards compatibilty for CPUs before 2.06. Only useful for bare metal systems. Signed-off-by: Milton Miller milt...@bga.com Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/include/asm/ppc-opcode.h |3 +++ arch/powerpc/kernel/cputable.c|6 -- arch/powerpc/mm/hash_native_64.c | 11 +-- 3 files changed, 16 insertions(+), 4 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/include/asm/ppc-opcode.h === --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/ppc-opcode.h +++ linux-2.6-ozlabs/arch/powerpc/include/asm/ppc-opcode.h @@ -79,4 +79,7 @@ #define PPC_WAIT(w)stringify_in_c(.long PPC_INST_WAIT | \ __PPC_WC(w)) +#define TLBIE(lp,a) \ + stringify_in_c(.long 0x7c000264 | ((a) 11) | ((lp) 21)) + #endif /* _ASM_POWERPC_PPC_OPCODE_H */ Index: linux-2.6-ozlabs/arch/powerpc/kernel/cputable.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/cputable.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/cputable.c @@ -425,7 +425,8 @@ static struct cpu_spec __initdata cpu_sp .cpu_name = POWER7 (architected), .cpu_features = CPU_FTRS_POWER7, .cpu_user_features = COMMON_USER_POWER7, - .mmu_features = MMU_FTR_HPTE_TABLE, + .mmu_features = MMU_FTR_HPTE_TABLE | + MMU_FTR_TLBIE_206, .icache_bsize = 128, .dcache_bsize = 128, .machine_check = machine_check_generic, @@ -438,7 +439,8 @@ static struct cpu_spec __initdata cpu_sp .cpu_name = POWER7 (raw), .cpu_features = CPU_FTRS_POWER7, .cpu_user_features = COMMON_USER_POWER7, - .mmu_features = MMU_FTR_HPTE_TABLE, + .mmu_features = MMU_FTR_HPTE_TABLE | + MMU_FTR_TLBIE_206, .icache_bsize = 128, .dcache_bsize = 128, .num_pmcs = 6, Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c === --- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_native_64.c +++ linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c @@ -27,6 +27,7 @@ #include asm/cputable.h #include asm/udbg.h #include asm/kexec.h +#include asm/ppc-opcode.h #ifdef DEBUG_LOW #define DBG_LOW(fmt...) udbg_printf(fmt) @@ -49,14 +50,19 @@ static inline void __tlbie(unsigned long case MMU_PAGE_4K: va = ~0xffful; va |= ssize 8; - asm volatile(tlbie %0,0 : : r (va) : memory); + asm volatile(ASM_MMU_FTR_IFCLR(tlbie %0,0, TLBIE(%1,%0), %2) +: : r (va), r(0), i (MMU_FTR_TLBIE_206) +: memory); break; default: penc = mmu_psize_defs[psize].penc; va = ~((1ul mmu_psize_defs[psize].shift) - 1); va |= penc 12; va |= ssize 8; - asm volatile(tlbie %0,1 : : r (va) : memory); + va |= 1; /* L */ + asm volatile(ASM_MMU_FTR_IFCLR(tlbie %0,1, TLBIE(%1,%0), %2) +: : r (va), r(0), i (MMU_FTR_TLBIE_206) +: memory); break; } } @@ -80,6 +86,7 @@ static inline void __tlbiel(unsigned lon va = ~((1ul mmu_psize_defs[psize].shift) - 1); va |= penc 12; va |= ssize 8; + va |= 1; /* L */ asm volatile(.long 0x7c000224 | (%0 11) | (1 21) : : r(va) : memory); break; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Enable MMU feature sections for inline asm
From: Milton Miller milt...@bga.com powerpc: Enable MMU feature sections for inline asm This adds the ability to do MMU feature sections for inline asm. Signed-off-by: Milton Miller milt...@bga.com Signed-off-by: Michael Neuling mi...@neuling.org --- arch/powerpc/include/asm/feature-fixups.h | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/include/asm/feature-fixups.h === --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/feature-fixups.h +++ linux-2.6-ozlabs/arch/powerpc/include/asm/feature-fixups.h @@ -8,8 +8,6 @@ * 2 of the License, or (at your option) any later version. */ -#ifdef __ASSEMBLY__ - /* * Feature section common macros * @@ -23,10 +21,12 @@ /* 64 bits kernel, 32 bits code (ie. vdso32) */ #define FTR_ENTRY_LONG .llong #define FTR_ENTRY_OFFSET .long 0x; .long +#elif defined(CONFIG_PPC64) +#define FTR_ENTRY_LONG .llong +#define FTR_ENTRY_OFFSET .llong #else -/* 64 bit kernel 64 bit code, or 32 bit kernel 32 bit code */ -#define FTR_ENTRY_LONG PPC_LONG -#define FTR_ENTRY_OFFSET PPC_LONG +#define FTR_ENTRY_LONG .long +#define FTR_ENTRY_OFFSET .long #endif #define START_FTR_SECTION(label) label##1: @@ -141,6 +141,21 @@ label##5: \ #define ALT_FW_FTR_SECTION_END_IFCLR(msk) \ ALT_FW_FTR_SECTION_END_NESTED_IFCLR(msk, 97) +#ifndef __ASSEMBLY__ + +#define ASM_MMU_FTR_IF_X(string, estring, msk, val)\ + stringify_in_c(BEGIN_MMU_FTR_SECTION) \ + string ; \ + stringify_in_c(MMU_FTR_SECTION_ELSE)\ + estring ; \ + stringify_in_c(ALT_MMU_FTR_SECTION_END((msk), (val))) + +#define ASM_MMU_FTR_IFSET(string, estring, msk)\ + ASM_MMU_FTR_IF_X(string, estring, (msk), (msk)) + +#define ASM_MMU_FTR_IFCLR(string, estring, msk)\ + ASM_MMU_FTR_IF_X(string, estring, (msk), 0) + #endif /* __ASSEMBLY__ */ /* LWSYNC feature sections */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a collection of bug fixes for powerpc. Thanks, Paul. MAINTAINERS |2 + arch/powerpc/boot/4xx.c | 56 + arch/powerpc/boot/dts/gef_ppc9a.dts |1 + arch/powerpc/include/asm/elf.h|1 + arch/powerpc/include/asm/mmu.h|6 arch/powerpc/include/asm/ppc-opcode.h | 11 +- arch/powerpc/kernel/cputable.c|2 + arch/powerpc/mm/tlb_nohash_low.S | 16 + arch/powerpc/platforms/cell/Kconfig |5 ++- arch/powerpc/platforms/ps3/setup.c|4 -- 10 files changed, 54 insertions(+), 50 deletions(-) Geoff Levand (1): powerpc/ps3: Fix build error on UP Josh Boyer (1): maintainers: Fix PowerPC 4xx git tree Kumar Gala (2): Revert powerpc: Add support for early tlbilx opcode powerpc: ppc32 needs elf_read_implies_exec() Martyn Welch (1): powerpc/86xx: Add device_type entry to soc for ppc9a Michael Ellerman (1): powerpc/cell: Select PCI for IBM_CELL_BLADE AND CELLEB Stephen Rothwell (1): powerpc: fix for long standing bug noticed by gcc 4.4.0 Valentine Barshak (1): powerpc/44x: Correct memory size calculation for denali-based boards ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
