[RFC/PATCH 0/9] powerpc: 4xx PCI work in progress
Because a mailing list is the best of backups and I've get something working allright on ebony right now, I figured I would post my WIP pile of patch bringing PCI to the 44x arch/powerpc world. At this stage, only ebony is hooked up, there's a known problem with the SCSI layer and non-coherent architecture that causes random corruption for which I'm trying to find a solution, and e1000 has a problem with resources 32 bits for which I have a separate patch. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 1/9] powerpc: Make isa_mem_base common to 32 and 64 bits
This defines isa_mem_base on both 32 and 64 bits (it used to be 32 bits only). This avoids a few ifdef's in later patches and potentially can allow support for VGA text mode on 64 bits powerpc. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Small cleanup pre-requisite for my next patch arch/powerpc/kernel/pci-common.c |4 arch/powerpc/kernel/pci_32.c |1 - include/asm-powerpc/io.h |5 +++-- 3 files changed, 7 insertions(+), 3 deletions(-) Index: linux-work/arch/powerpc/kernel/pci-common.c === --- linux-work.orig/arch/powerpc/kernel/pci-common.c2007-11-13 14:11:11.0 +1100 +++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 14:15:43.0 +1100 @@ -52,6 +52,10 @@ int global_phb_number; /* Global phb co extern struct list_head hose_list; +/* ISA Memory physical address (or 0 if none) */ +resource_size_t isa_mem_base= 0; + + /* * pci_controller(phb) initialized common variables. */ Index: linux-work/include/asm-powerpc/io.h === --- linux-work.orig/include/asm-powerpc/io.h2007-11-13 14:12:01.0 +1100 +++ linux-work/include/asm-powerpc/io.h 2007-11-13 14:12:48.0 +1100 @@ -50,15 +50,16 @@ extern int check_legacy_ioport(unsigned #define PCI_DRAM_OFFSETpci_dram_offset #else #define _IO_BASE pci_io_base -#define _ISA_MEM_BASE 0 +#define _ISA_MEM_BASE isa_mem_base #define PCI_DRAM_OFFSET0 #endif extern unsigned long isa_io_base; -extern unsigned long isa_mem_base; extern unsigned long pci_io_base; extern unsigned long pci_dram_offset; +extern resource_size_t isa_mem_base; + #if defined(CONFIG_PPC32) defined(CONFIG_PPC_INDIRECT_IO) #error CONFIG_PPC_INDIRECT_IO is not yet supported on 32 bits #endif Index: linux-work/arch/powerpc/kernel/pci_32.c === --- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-11-13 14:16:15.0 +1100 +++ linux-work/arch/powerpc/kernel/pci_32.c 2007-11-13 14:16:17.0 +1100 @@ -32,7 +32,6 @@ #endif unsigned long isa_io_base = 0; -unsigned long isa_mem_base= 0; unsigned long pci_dram_offset = 0; int pcibios_assign_bus_offset = 1; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 2/9] powerpc: Merge pci_process_bridge_OF_ranges()
This patch merges the 32 and 64 bits implementations of
pci_process_bridge_OF_ranges(). The new function is cleaner than both
the old ones supports 64 bits ranges on ppc32 which is necessary for
the 4xx port.
It also adds some better (hopefully) output to the kernel log which
should help disagnose problems and makes better use of existing OF
parsing helpers (avoiding a few bugs of both implementations along
the way).
There are still a few unfortunate ifdef's but there is no way around
these for now at least not until some other bits of the PCI code are
made common.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and
a BriQ. Please let me know if it misbehaves anywhere else.
arch/powerpc/kernel/pci-common.c | 176 +++
arch/powerpc/kernel/pci_32.c | 114 -
arch/powerpc/kernel/pci_64.c | 93
include/asm-powerpc/pci-bridge.h |1
4 files changed, 177 insertions(+), 207 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2007-11-13
14:15:43.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 16:04:06.0
+1100
@@ -479,3 +479,179 @@ void pci_resource_to_user(const struct p
*start = rsrc-start - offset;
*end = rsrc-end - offset;
}
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the ranges property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ * - We can only cope with one IO space range and up to 3 Memory space
+ * ranges. However, some machines (thanks Apple !) tend to split their
+ * space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ * - We can only cope with all memory ranges having the same offset
+ * between CPU addresses and PCI addresses. Unfortunately, some bridges
+ * are setup for a large 1:1 mapping along with a small window which
+ * maps PCI address 0 to some arbitrary high address of the CPU space in
+ * order to give access to the ISA memory hole.
+ * The way out of here that I've chosen for now is to always set the
+ * offset based on the first resource found, then override it if we
+ * have a different offset and the previous was set by an ISA hole.
+ *
+ * - Some busses have IO space not starting at 0, which causes trouble with
+ * the way we do our IO resource renumbering. The code somewhat deals with
+ * it for 64 bits but I would expect problems on 32 bits.
+ *
+ * - Some 32 bits platforms such as 4xx can have physical space larger than
+ * 32 bits so we need to use 64 bits values for the parsing
+ */
+void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
+ struct device_node *dev,
+ int primary)
+{
+ const u32 *ranges;
+ int rlen;
+ int pna = of_n_addr_cells(dev);
+ int np = pna + 5;
+ int memno = 0, isa_hole = -1;
+ u32 pci_space;
+ unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+ unsigned long long isa_mb = 0;
+ struct resource *res;
+
+ printk(KERN_INFO PCI host bridge %s %s ranges:\n,
+ dev-full_name, primary ? (primary) : );
+
+ /* Get ranges property */
+ ranges = of_get_property(dev, ranges, rlen);
+ if (ranges == NULL)
+ return;
+
+ /* Parse it */
+ while ((rlen -= np * 4) = 0) {
+ /* Read next ranges element */
+ pci_space = ranges[0];
+ pci_addr = of_read_number(ranges + 1, 2);
+ cpu_addr = of_translate_address(dev, ranges + 3);
+ size = of_read_number(ranges + pna + 3, 2);
+ ranges += np;
+ if (cpu_addr == OF_BAD_ADDR || size == 0)
+ continue;
+
+ /* Now consume following elements while they are contiguous */
+ for (;rlen = np * sizeof(u32); ranges += np, rlen -= np * 4) {
+ if (ranges[0] != pci_space)
+ break;
+ pci_next = of_read_number(ranges + 1, 2);
+ cpu_next = of_translate_address(dev, ranges + 3);
+ if (pci_next != pci_addr + size ||
+ cpu_next != cpu_addr + size)
+ break;
+
[RFC/PATCH 8/9] powerpc 4xx PCI support
This is the common 4xx PCI support code for PCI, PCI-X and PCI-E bridges
The bridges are configured based on device-tree properties.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Only PCI-X in this version, I'll do 405-type PCI soon and will wait for
others to do PCI-E unless somebody sends me hardware :-)
arch/powerpc/sysdev/Makefile |4
arch/powerpc/sysdev/ppc4xx_pci.c | 315 +++
arch/powerpc/sysdev/ppc4xx_pci.h | 106 +
include/asm-powerpc/pci-bridge.h |3
4 files changed, 428 insertions(+)
Index: linux-work/arch/powerpc/sysdev/Makefile
===
--- linux-work.orig/arch/powerpc/sysdev/Makefile2007-11-19
15:01:08.0 +1100
+++ linux-work/arch/powerpc/sysdev/Makefile 2007-11-19 15:01:17.0
+1100
@@ -29,6 +29,10 @@ obj-$(CONFIG_4xx)+= uic.o
obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
endif
+ifeq ($(CONFIG_PCI),y)
+obj-$(CONFIG_4xx) += ppc4xx_pci.o
+endif
+
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
obj-$(CONFIG_CPM) += cpm_common.o
Index: linux-work/arch/powerpc/sysdev/ppc4xx_pci.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/sysdev/ppc4xx_pci.c 2007-11-19 15:01:17.0
+1100
@@ -0,0 +1,315 @@
+/*
+ * PCI / PCI-X / PCI-Express support for 4xx parts
+ *
+ * Copyright 2007 Ben. Herrenschmidt [EMAIL PROTECTED], IBM Corp.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/bootmem.h
+#include linux/of.h
+
+#include asm/io.h
+#include asm/pci-bridge.h
+#include asm/machdep.h
+
+#include ppc4xx_pci.h
+
+static int dma_offset_set;
+
+/* Move that to a useable header */
+extern unsigned long total_memory;
+
+/* Defined in drivers/pci/pci.c but not exposed by a header */
+extern u8 pci_cache_line_size;
+
+static int __init ppc4xx_parse_dma_window(struct pci_controller *hose,
+ void __iomem *reg,
+ struct resource *res)
+{
+ struct device_node *np = hose-arch_data;
+ u64 size;
+ const u32 *dmaw;
+
+ /* Default */
+ res-start = 0;
+ res-end = 0x8000;
+ res-flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
+
+ /* Get dma-window property */
+ dmaw = of_get_property(np, dma-window, NULL);
+ if (dmaw == NULL)
+ goto out;
+
+ /* Check if it makes sense (ie. it encodes memory */
+ if ((dmaw[0] 0x0300) != 0x0200) {
+ printk(KERN_ERR %s: non-memory dma-window\n,
+ np-full_name);
+ return -ENXIO;
+ }
+
+ /* Check if not prefetchable */
+ if (!(dmaw[0] 0x4000))
+ res-flags = ~IORESOURCE_PREFETCH;
+
+ /* Read the DMA window. We should sanity check that it's
+* not overlapping with the outbound ranges.
+*/
+ res-start = of_read_number(dmaw + 1, 2);
+ size = of_read_number(dmaw + 3, 2);
+ res-end = res-start + size - 1;
+
+ /* We only support one global DMA offset */
+ if (dma_offset_set pci_dram_offset != res-start) {
+ printk(KERN_ERR %s: dma-window(s) mismatch\n,
+ np-full_name);
+ return -ENXIO;
+ }
+
+ /* Check that we can fit all of memory as we don't support
+* DMA bounce buffers
+*/
+ if (size total_memory) {
+ printk(KERN_ERR %s: dma-window too small\n,
+ np-full_name);
+ return -ENXIO;
+ }
+
+ /* Check we are a power of 2 size and that base is a multiple of size*/
+ if (!is_power_of_2(size) ||
+ (res-start (size - 1)) != 0) {
+ printk(KERN_ERR %s: dma-window unaligned\n,
+ np-full_name);
+ return -ENXIO;
+ }
+
+ /* Check that we are fully contained within 32 bits space */
+ if (res-end 0x) {
+ printk(KERN_ERR %s: dma-window outside of 32 bits space\n,
+ np-full_name);
+ return -ENXIO;
+ }
+ out:
+ dma_offset_set = 1;
+ pci_dram_offset = res-start;
+
+ printk(KERN_INFO 4xx PCI DMA offset set to 0x%08lx\n,
+ pci_dram_offset);
+ return 0;
+}
+
+/*
+ * 4xx PCI 2.x part
+ */
+static void __init ppc4xx_probe_pci_bridge(struct device_node *np)
+{
+ /* NYI */
+}
+
+/*
+ * 4xx PCI-X part
+ */
+
+static void __init ppc4xx_configure_pcix_POMs(struct pci_controller *hose,
+ void __iomem *reg)
+{
+ struct device_node *np = hose-arch_data;
+ u32 lah, lal, pciah, pcial, sa;
+ int i, j;
+
+ /* Setup outbound memory windows */
+
[RFC/PATCH 9/9] powerpc: PCI support for 4xx Ebony board
Based on the previous patch, this hooks up PCI for Ebony.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/ebony.dts| 39 -
arch/powerpc/platforms/44x/ebony.c |7 ++
2 files changed, 41 insertions(+), 5 deletions(-)
Index: linux-work/arch/powerpc/boot/dts/ebony.dts
===
--- linux-work.orig/arch/powerpc/boot/dts/ebony.dts 2007-11-19
15:01:08.0 +1100
+++ linux-work/arch/powerpc/boot/dts/ebony.dts 2007-11-19 15:01:17.0
+1100
@@ -284,12 +284,41 @@
};
- PCIX0: [EMAIL PROTECTED] {
+ PCIX0: [EMAIL PROTECTED] {
device_type = pci;
- /* FIXME */
- reg = 2 0ec0 8
- 2 0ec8 f0
- 2 0ec80100 fc;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = ibm,plb440gp-pcix, ibm,plb-pcix;
+ primary;
+ reg = 2 0ec0 8 /* Config space access */
+ 2 0ec8 f0/* Internal registers */
+ 2 0ec80100 fc; /* Internal messaging registers
*/
+
+ /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+ ranges = 0200 0 8000 0003 8000 0
8000
+ 0100 0 0002 0800 0
0001;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-window = 4200 0 0 0 8000;
+
+ /* Ebony has all 4 IRQ pins tied together per slot */
+ interrupt-map-mask = f800 0 0 0;
+ interrupt-map =
+ /* IDSEL 1 */
+ 0800 0 0 0 UIC0 17 8
+
+ /* IDSEL 2 */
+ 1000 0 0 0 UIC0 18 8
+
+ /* IDSEL 3 */
+ 1800 0 0 0 UIC0 19 8
+
+ /* IDSEL 4 */
+ 2000 0 0 0 UIC0 1a 8
+ ;
};
};
Index: linux-work/arch/powerpc/platforms/44x/ebony.c
===
--- linux-work.orig/arch/powerpc/platforms/44x/ebony.c 2007-11-19
15:01:08.0 +1100
+++ linux-work/arch/powerpc/platforms/44x/ebony.c 2007-11-19
15:01:17.0 +1100
@@ -23,6 +23,7 @@
#include asm/time.h
#include asm/uic.h
#include asm/of_platform.h
+#include asm/pci-bridge.h
#include 44x.h
@@ -44,6 +45,11 @@ static int __init ebony_device_probe(voi
}
device_initcall(ebony_device_probe);
+static void __init ebony_setup_arch(void)
+{
+ ppc4xx_pci_find_bridges();
+}
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
@@ -60,6 +66,7 @@ static int __init ebony_probe(void)
define_machine(ebony) {
.name = Ebony,
.probe = ebony_probe,
+ .setup_arch = ebony_setup_arch,
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq= uic_get_irq,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
On Mon, 19 Nov 2007 08:15:48 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote: On Nov 18, 2007 8:18 PM, Trond Myklebust [EMAIL PROTECTED] wrote: On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote: NFSv2/3 and NFSv4 share the same dentry_iput and so share the same unlink and sillyrename logic. But they do not share nfs_init_server()! I wonder why this doesn't blow up more violently, but only hangs... But as I don't know if it is correct to add the workqueue initialization to nfs4_init_server() or remove the nfs_sb_active / nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this. Torsten I had already fixed that one in my own stack. Attached are the 3 patches that I've got. 1 from SteveD, 2 fixes. Moving the init_waitqueue_head() like patch linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif and applying linux-2.6.24-007-fix_nfs_free_unlinkdata.dif lets my testcase work. Also lockdep no longer complains about the non-static key. Thanks. To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see David's mail for a start.
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = flinger,2
flinger is some company that sells something they call the 2?
Interesting.
model should be the real-world exact model name/number of the device.
Isn't the primary concern of an audio codec, to play audio?
And the primary purpose of the device tree is to describe the hardware,
and (indirectly) how to program it. For an audio codec that has I2C
and I2S connections, the interface over which you program it is I2C.
There are other technicalities, too; for example, if the codec node
would be a child node of the I2S bus, you cannot have two codecs with
the same name on one such bus (since that bus isn't a bus really,
it's more like a broadcast interface; it cannot address separate devices
on that bus, so in the device tree the codecs wouldn't get a reg,
etc.)
Therefore, shouldn't the audio codec point back to it's control
interface?
No. The codec node _is_ the control interface.
Also, why give the name as 'i2s-handle'?
Why not?
Surely it could be any interface.
No it cannot; this property is only present for audio codecs that have
an I2S bus (and not even all those, it is dependent on the device
binding
in use).
In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
That's another great argument against doing as you suggest, yes.
What they should really do, is be told where their control
interface handle is, then you can look at that handle and
the device it contains
What you *should* do is just look at the parent node if you want to
know how to talk to the device. This is the same for *all* nodes in
*all* device trees.
Remember, it doesn't matter what NAME you give it, the name
is for people to read,
Not only. When the generic naming recommended practice is in use,
name
can be used to find all nodes of a certain type. Neither name nor
device_type should be used for device driver matching though;
compatible
is for that.
[As a historic note, before the generic naming thing, name was used
for exactly what the first entry in compatible is used for now. But
let's try to forget that, okay?]
device_type is what you search for,
Unless you are programming in real Open Firmware itself, you do _not_
search for device_type. Ever.
and phandles let you attach specific devices to each other.
compatible is for when you want to tell people it acts the
same as this
_Including_ acts the same as itself.
and model is to give you the enviable ability
to define PRECISELY what you are looking at beyond a chip
name.
When a device driver uses model for anything, it is typically because
compatible says the device is a member of some family of devices that
all behave identically, but uh-oh, this isn't actually true.
It's also not all that great for human readers, since the format is
vendor-specific.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Matt, the various properties you list do not mean what you think they mean. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). It is not arbitrary, there is a single well-defined name for every common class of device. It _is_ machine-readable (but shouldn't be used for driver matching, indeed -- it says nothing about the programming model). device_type - indicates the open firmware method interface for the device. Not method interface, just interface. Therefore, meaningless in flattened trees. Even in flat trees, a device_type of for example block indicates the node will have the required properties for that device type, for example block-size. Such properties are perfectly useful. OTOH, it isn't very useful to search for device with a specific device type from within the kernel, since it currently has no firmware interaction to speak of (flat trees don't interact, and the kernel kills real OF dead as soon as possible). No new driver should use this. Not without very good rationalisation, anyway. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. Yeah. Any non-workaround value a driver would derive from model is usually better described using a separate property. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Matt Sealey wrote: Jon Smirl wrote: The codec-fabric node was just being used to trigger the loading of the platform specific driver. Just remember one thing. 1) the term fabric when coined for audio drivers is a new, ALSA SoC specific term. It isn't relevant for anything but ALSA SoC drivers. Earlier this year, when I started working on an ASoC driver, the fabric driver was called a machine driver. 2) this device tree stuff will end up in more than Linux device trees Sorry, I don't understand. The device trees are technically OS-independent, so technically there's no such thing as a Linux device tree. In addition, the current master repository for device trees happens to be the Linux kernel, so I'm not sure where else device trees are going to be. 3) you're going to piss off Open Firmware developers by specifying very Linux-specific features in a device tree the same way Apple pissed off Linux developers by encoding MacOS X-specific features in the device tree. The current device trees have left their OF roots behind. Sure, we try to conform as much as possible, but they're not OF trees any more. Audio driver control like this has to be very specific for a good reason; you can do it a billion ways to Sunday. I'd suggest basically that if you must control a device in a way that needs to be defined by a device which can change address (either dynamically on boot or by board design change - per revision, for example, or with a change of controller) then simply use the device tree to report this address so that you can have the same basic fabric driver (all in Linux) which can handle minor modifications of your board design. My position is that the fabric driver should be loaded as a normal device tree and it should use the device tree to pick up some data to help it instantiate the other drivers. I'll be posting the code to my PowerPC ASoC driver in a couple weeks. If you require the codec to be subservient to some fabric then I The codec is subservient to a bus (sometimes multiple buses), which is why it is a child to bus nodes. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! The layout of the hardware and the relationship between the I2S, I2C, codec, and whatever device is determined by *both* the fabric driver and the device tree. The information about the devices itself, and *some* information about their relationship is stored in the device tree. Everything else is in the fabric driver. The design of the device tree is already locked in stone, so to speak. The DT can only store what it is allowed to store. If there's something more that you need, you'll have to put it in the fabric driver. If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
So, like, the other day Timur Tabi mumbled: If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. Are the margins of this paper too small for your proof? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] hugetlb: follow_hugetlb_page for write access
On Wednesday 07 November 2007 20:51, Adam Litke wrote: When calling get_user_pages(), a write flag is passed in by the caller to indicate if write access is required on the faulted-in pages. Currently, follow_hugetlb_page() ignores this flag and always faults pages for read-only access. This can cause data corruption because a device driver that calls get_user_pages() with write set will not expect COW faults to occur on the returned pages. This patch passes the write flag down to follow_hugetlb_page() and makes sure hugetlb_fault() is called with the right write_access parameter. Signed-off-by: Adam Litke [EMAIL PROTECTED] Apologize for this late response. Tested on 2.6.23 with ehca and mthca. It works like a charm for me. Thanks! Nam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. Another option is to explicitly call of_platform_device_create in the platform code on the fabric node (which should be a child of the root node) so that you can have an of_platform_bus fabric driver. Cheers, g. The layout of the hardware and the relationship between the I2S, I2C, codec, and whatever device is determined by *both* the fabric driver and the device tree. The information about the devices itself, and *some* information about their relationship is stored in the device tree. Everything else is in the fabric driver. The design of the device tree is already locked in stone, so to speak. The DT can only store what it is allowed to store. If there's something more that you need, you'll have to put it in the fabric driver. If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. -- Timur Tabi Linux Kernel Developer @ Freescale ___ 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. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! If I have a multiplatform kernel with 10 fabric drivers built in, how do you decide which one to activate without looking at the device tree? Multiplatform kernels are what is causing this problem. If the kernel is just for a single platform I can hardwire the fabric driver in without looking at the tree. The layout of the hardware and the relationship between the I2S, I2C, codec, and whatever device is determined by *both* the fabric driver and the device tree. The information about the devices itself, and *some* information about their relationship is stored in the device tree. Everything else is in the fabric driver. The design of the device tree is already locked in stone, so to speak. The DT can only store what it is allowed to store. If there's something more that you need, you'll have to put it in the fabric driver. If I weren't on vacation this week, I'd email you my code. It's almost done and it demonstrates what I'm thinking. -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
David Gibson wrote: On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote: Gah! For the benefit of others on this list who may be misled. *Neither* of you correctly understands the device tree, what I've seen of *both* your suggested approaches is crap. The device tree describes the _hardware_. If you start reasoning about how to lay out the device tree based on your driver model, you're already wrong. Matt, the various properties you list do not mean what you think they mean. No, David, I understand exactly what they mean, in the context of a guy who works on Open Firmware, real Open Firmware, as was standardised 12 years ago. Not your whacky newspeak device trees, which to be fair, are a good idea, but it seems you all have tried to change something for the sake of changing something. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). I never said drivers should depend on it but why do you want to name an i2s bus as i2s or the i2c bus as i2c? There are far, far more descriptive names that can be used. i2s is basically audio, so why not audio or sound or headphone? Why is gpt a gpt and not a timer, it defeats the whole object of having a name for it. Since drivers never switch on it, why not give them real names? device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. .. you seem to think you must only design for the guys making Linux flattened device trees. I'm sorry, but I am not one of those guys and I am much more concerned with how this will affect the OF device tree and the usage for anyone else. Meaningless in flattened device trees, but useful information in real OF device trees, do you implement it or not? I'd say, yes. Even if you don't agree with real firmware, you can't just ignore it, shrug it away and say it doesn't matter. Jon's fabric driver should be looking for digispeaker,flinger and nothing else. The name doesn't matter but I called it sound because it's far, FAR more descriptive than i2s, and of course both the device_type and compatible properties report exactly what Jon will need to write a driver which handles, however that might be, his audio codec subsystem - pcm, control, magic gpios, or whatever. If there is an Open Firmware standard for it, I would use that name, then it gives everyone a rough idea of what to expect. Open Firmware developers can then CHOOSE TO IMPLEMENT THE STANDARD METHODS, and Linux device tree authors can just ignore it. You are cutting out a working specification for the sake of some arbitrary simplification. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. Compatible is meant to list alternative, compatible devices as a *supplement* to device_type. device_type is your primary and compatible is your secondary. In this case, device_type is exactly what Jon wants, something to mark out that the audio device is his board design and requires special work (it is not merely an i2s bus that you can just use - although throwing PCM data at it would work, who knows what mixer it goes to, and what controls are needed to define the bitrate or other features) model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. I don't see why model can't encode the particular revision of the hardware in this way when it comes to the audio group of features on his board. After all, if you are looking at a digispeaker,flinger (I made that name up) then you need to know depending on the board or even based on weird configurability options of the board, what certain things may be - Apple used layout-id and a number. Why NOT encode the model in the model? Why choose some magical, new property, which then has to be further standardised for no reason? I also think that specifying an audio codec - after all the Open Firmware standard defines an audio interface and device tree requirements for it, even if they are methods that we don't implement and you don't care about - as a function of it's control interface is so backwards it doesn't bare thinking about. If you want to output audio you do it through most audio controllers as a simple transfer of PCM data. Be it Creative or Freescale I2S or AC97, you push data at some port/fifo and it plays a sound. It is NOT defined by i2c control ports, you don't ever use those to *play* audio. It may also be very, very true that a codec DOES NOT REQUIRE
Re: Revisited, audio codec device tree entries.
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. First, I have platform bus turned off in my builds. Platform bus is a place where cruft accumulates that really belongs somewhere else. For example when I turned it off I discovered that there was a PC speaker driver in my kernel and well as several drivers from 82xx chips. ALSA creates it own bus like i2c. My fabric driver sits on this bus., Kconfig attributes control if it is built-in. I've altered the i2c code to look for child device tree nodes and then load the appropriate drivers. Can't you then instantiate the ALSA bus device in your board platform code? Then when the driver is registered, the bus should call it's probe routine. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: You probably mean don't use the of_platform bus to load the fabric driver. Yes, that is what I meant. He still needs to use the data in the device tree to decide what fabric drivers to use. I'm not sure about that. The fabric driver is tied to the platform itself, mostly because the fabric driver isn't really a device driver. It's a platform driver, in that its job is to initialize the other device drivers, or make sure the kernel initializes them. It's also responsible for telling ALSA which driver does what and how they're connected. With the current version of ASoC (V1), I don't think it's possible to have an independent platform driver. V2 is in development, but it's not ready yet and I haven't had a chance to study it. V2 is intended to address the problems that a device tree model raises. I'm using the v2 code. The v2 code is modeled after the i2c bus code which is the correct way to do drivers for open firmware. v1 creates asoc core as a platform device which was completely wrong since it is a driver core, not a device. That is fixed in v2 where it initializes with a subsysinit() call and then creates a bus. The whole driver organization of v2 is superior to v1. Open firmware support was the main motivation behind v2. In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. Another option is to explicitly call of_platform_device_create in the platform code on the fabric node (which should be a child of the root node) so that you can have an of_platform_bus fabric driver. I don't fully understand platform drivers. Do we really need a full-blown OF platform driver for this? -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Segher Boessenkool wrote:
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see David's mail for a start.
Why? I'm sorry but I am living in the real world where we have real
firmwares and real dynamic device trees here. You can't just say
this is wrong because it has a device_type.
\\ and this defines the layout Jon picked for the DACs
\\ just like Apple's layout-id value
model = flinger,2
flinger is some company that sells something they call the 2?
Interesting.
No, but who cares of the format of the model? It's for information -
in this case it's just there so that Jon can find out what layout
his codec, control interface, GPIOs, ports on the board, mixer
names, what colour the sky was on that day in June when he met his
wife-to-be, the name of his first dog, whatever information he needs
to implement on ANY driver model on ANY operating system is on that
particular version.
Maybe it should be digispeaker,2 or digispeaker,666 - who cares?
It's for the driver to know what it means.
I suggest it because I think Apple's layout-id is cryptic and
ridiculous duplication. Jon suggested to me a couple days back
that the layout-id is so model-specific (it increments each time
they brought out a new board, so it is synchronised with the
root model property!) that it's redundant. He suggested using
the root model property to switch his driver on the layout.
In this scenario, why not use the model property to keep the
audio driver more self-contained here? That was the theory
behind it.
model should be the real-world exact model name/number of the device.
Well, on this example, it's quite obvious it's an MPC5200B I2S bus,
but you're not describing solely the i2s bus (although in the
example it will operate with a standard mpc5200b-psc-i2s driver)
but the entire audio solution and indirectly how to program that
audio solution (ta-da!) - i2s bus, pcm codec, it's control interface,
and anything else besides, which is...
Isn't the primary concern of an audio codec, to play audio?
And the primary purpose of the device tree is to describe the hardware,
and (indirectly) how to program it.
.. exactly what it does.
For an audio codec that has I2C and I2S connections, the interface
over which you program it is I2C.
What if you don't connect I2C to something Linux can access directly?
There are other technicalities, too; for example, if the codec node
would be a child node of the I2S bus, you cannot have two codecs with
the same name on one such bus (since that bus isn't a bus really,
it's more like a broadcast interface; it cannot address separate devices
on that bus, so in the device tree the codecs wouldn't get a reg,
etc.)
*shrug* as an example..
Therefore, shouldn't the audio codec point back to it's control
interface?
No. The codec node _is_ the control interface.
I think that flies in the face of the implementation of a bunch of
codecs.
Also, why give the name as 'i2s-handle'?
Why not?
Surely it could be any interface.
No it cannot; this property is only present for audio codecs that have
an I2S bus (and not even all those, it is dependent on the device binding
in use).
See below.
In reverse, it would be, perhaps, as
above, i2c-handle, but then what if you change the interface
type (for instance a bunch of Wolfson codecs can do i2c and
spi for control). Your property name is obselete, then and
drivers will need to switch on property names to find out
which control interface is present.
That's another great argument against doing as you suggest, yes.
Why? The i2s codec sits on the i2s bus. You're right there is no
addressing on i2s it just has a stream of auduo going through it.
The i2s bus is one thing. This defines a PCM transport. This is
standardised.
The codec node defines which PCM/DAC you have on the end. This
DAC may have certain features - it may only have certain sample
rates supported, or may only support certain clock speeds. This
is what the codec node under the bus is for.
The codec node references the package handle of it's control
interface. If you want to play audio - well, go ahead, stream
some audio to the i2s bus, based on the abilities of the codec
(which are well defined in the datasheet you'd hope). You may
even use the OF standard properties for a sound node to define
these too - after all, it has a binding already and it would
improve driver support.
If you want to fiddle with it you need control interface, but
the primary purpose of an *audio device* is to play audio.
It is not to switch mixers on and off and change bass boost, that
is a totally secondary feature of an audio output or input
device, which may not even be present.
What they should really do, is be told
Re: Revisited, audio codec device tree entries.
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. First, I have platform bus turned off in my builds. Platform bus is a place where cruft accumulates that really belongs somewhere else. For example when I turned it off I discovered that there was a PC speaker driver in my kernel and well as several drivers from 82xx chips. ALSA creates it own bus like i2c. My fabric driver sits on this bus., Kconfig attributes control if it is built-in. I've altered the i2c code to look for child device tree nodes and then load the appropriate drivers. Can't you then instantiate the ALSA bus device in your board platform code? Then when the driver is registered, the bus should call it's probe routine. Yes, I can do that. I have just been resisting creating a code linkage from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need to create the fabric driver after alsa has made the bus, subsys_initcall(asoc_bus_init); Hmmm, you could add a drivers_initcall to the platform code, but that only works if the ALSA code is compiled statically. It doesn't work for modules. :-( You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hangs after Freeing unused kernel memory
On Thu, Nov 15, 2007 at 04:00:09PM -0800, Siva Prasad wrote: Hi, This sounds like a familiar problem, but could not get answers in posts that came up in google search. My system hangs after printing the message Freeing unused kernel memory. It should execute init after that, but not sure what exactly is happening. Appreciate if some one can throw few ideas to try out. It might not be a hang, it might be simply that you loose the console. If this is a redhat system, and you didn't tweak initrd and udev just right, this can happen. Try doing this: mount --bind / /mnt cp -a /dev/null /mnt/dev cp -a /dev/console /mnt/dev cp -a /dev/hv* /mnt/dev umount /mnt Seems it is actually hanging when it makes the call run_init_process(ramdisk_execute_command) in init/main.c Then again, your initrd might be corrupted. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
On Nov 19, 2007 10:00 AM, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 19 Nov 2007 08:15:48 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote:
On Nov 18, 2007 8:18 PM, Trond Myklebust [EMAIL PROTECTED] wrote:
I had already fixed that one in my own stack. Attached are the 3 patches
that I've got. 1 from SteveD, 2 fixes.
Moving the init_waitqueue_head() like patch
linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif and applying
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif lets my testcase work.
Also lockdep no longer complains about the non-static key.
Thanks.
To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1?
Umm... As I applied this changes manually there is a not insignificant
change of goofups on my part...
For the hang problem I think Tronds suggestion with replacing the
patches from -mm with fresh versions would be the best.
Anyway, currently I have the patch from
http://lkml.org/lkml/2007/11/16/74 to fix the can't-create-files-bug.
To fix the hang bug I used Tronds
linux-2.6.24-007-fix_nfs_free_unlinkdata.dif and the first two hunks
from linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif.
Torsten
The needed 2 hunks for reference:
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -594,9 +594,6 @@ static int nfs_init_server(struct nfs_server *server,
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
- init_waitqueue_head(server-active_wq);
- atomic_set(server-active, 0);
-
dprintk(-- nfs_init_server() = 0 [new %p]\n, clp);
return 0;
@@ -736,6 +733,9 @@ static struct nfs_server *nfs_alloc_server(void)
INIT_LIST_HEAD(server-client_link);
INIT_LIST_HEAD(server-master_link);
+ init_waitqueue_head(server-active_wq);
+ atomic_set(server-active, 0);
+
server-io_stats = nfs_alloc_iostats();
if (!server-io_stats) {
kfree(server);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote: I never said drivers should depend on it but why do you want to name an i2s bus as i2s or the i2c bus as i2c? Because that's what they are? There are far, far more descriptive names that can be used. i2s is basically audio, so why not audio or sound or headphone? For i2s, that may be reasonable, but i2c can have several devices under it. Why is gpt a gpt and not a timer, it defeats the whole object of having a name for it. Since drivers never switch on it, why not give them real names? That one *should* be timer. Ask whoever did the device tree for it. :-P device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. .. you seem to think you must only design for the guys making Linux flattened device trees. I'm sorry, but I am not one of those guys and I am much more concerned with how this will affect the OF device tree and the usage for anyone else. Meaningless in flattened device trees, but useful information in real OF device trees, do you implement it or not? I'd say, yes. Yes, if you have real OF and provide the corresponding method interface. That doesn't mean the driver should match on it if it doesn't depend on the method interface. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. Compatible is meant to list alternative, compatible devices as a *supplement* to device_type. device_type is your primary and compatible is your secondary. No, please read the spec: “compatible” Standard property name to define alternate “name” property values. No mention of device_type anywhere in the definition. The generic names recommendation further suggests that compatible always be used for matching. I don't see why model can't encode the particular revision of the hardware in this way when it comes to the audio group of features on his board. After all, if you are looking at a digispeaker,flinger (I made that name up) then you need to know depending on the board or even based on weird configurability options of the board, what certain things may be - Apple used layout-id and a number. Why NOT encode the model in the model? Why choose some magical, new property, which then has to be further standardised for no reason? compatible is not a magical, new property. I'm not going to defend what Apple did... I also think that specifying an audio codec - after all the Open Firmware standard defines an audio interface and device tree requirements for it, even if they are methods that we don't implement and you don't care about - as a function of it's control interface is so backwards it doesn't bare thinking about. It's how the device tree works. Devices go underneath the bus (or other attachment interface) that they're on. If you have an audio codec that has an i2c interface and an soc interface, then you have two nodes, because you're on two buses. If you want to output audio you do it through most audio controllers as a simple transfer of PCM data. Be it Creative or Freescale I2S or AC97, you push data at some port/fifo and it plays a sound. It is NOT defined by i2c control ports, you don't ever use those to *play* audio. You certainly do use the i2c ports in order to do anything with the device underneath the i2c bus. It may also be very, very true that a codec DOES NOT REQUIRE implementation of it's control interface, or that control interface could be connected to some other chip which handles initial configuration (like a boot sequencer eeprom) and not to a system bus. Sure... in that case, then that's *not the bus it's on*. There's still some register set somewhere that software uses to shove data at the codec; that's where the node should go. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/21] ide/Kconfig: fix mpc8xx host driver dependencies
Bartlomiej Zolnierkiewicz wrote: Only LWMON, IVMS8, IVML24 and TQM8xxL platforms have the needed defines (IDE0_BASE_OFFSET and friends) in the platform header file. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: In the ALSA SOC model the i2s, codec and ac97 drivers are all generic. A fabric driver tells specifically how a generic codec is wired into the board. What I haven't been able figure out is how to load the right fabric driver. Do not use the device tree to load the fabric driver! Heh, technically you can't use the device tree to load any device drivers, it's just a data structure. :-) You probably mean don't use the of_platform bus to load the fabric driver. He still needs to use the data in the device tree to decide what fabric drivers to use. of_platform_bus would be awkward to use for this because the node describing the fabric doesn't cleanly sit on any particular bus (ie. it describes the board; it does not describe the device). In this case; it probably is appropriate to have the platform code instantiate a platform_device for the fabric (instead of an of_platform device) which the fabric driver can bind against. First, I have platform bus turned off in my builds. Platform bus is a place where cruft accumulates that really belongs somewhere else. For example when I turned it off I discovered that there was a PC speaker driver in my kernel and well as several drivers from 82xx chips. ALSA creates it own bus like i2c. My fabric driver sits on this bus., Kconfig attributes control if it is built-in. I've altered the i2c code to look for child device tree nodes and then load the appropriate drivers. Can't you then instantiate the ALSA bus device in your board platform code? Then when the driver is registered, the bus should call it's probe routine. Yes, I can do that. I have just been resisting creating a code linkage from arch/powerpc/platform/xx to sound/alsa/soc/powerpc. I also need to create the fabric driver after alsa has made the bus, subsys_initcall(asoc_bus_init); Hmmm, you could add a drivers_initcall to the platform code, but that only works if the ALSA code is compiled statically. It doesn't work for modules. :-( You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. I also concluded that I need a of_platform stepping stone. There are several ways this could be done, which one is the right one? a) fabric is global, create a global device node for it and implement it as a of_platform device b) fabric is per audio bus, make it an attribute or child node under i2s, ac97, spi. This is messy since it can appear in many places. This is the apple layout-id scheme. c) fabric is per codec entry. make it an attribute or child node under the codec node. d) after I load the codec node, walk up the device tree to the root node and then use the compatible string in the root node to trigger the specific fabric driver. This one avoids making obviously redundant attributes down lower in the tree. I need things to initialize in this order. All of these can be modules. 1) alsa subsystem 2) i2c ac97 bus 3) codec driver 4) fabric - it then glues everything together in alsa. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. I also concluded that I need a of_platform stepping stone. There are several ways this could be done, which one is the right one? a) fabric is global, create a global device node for it and implement it as a of_platform device This is really board level description stuff. I'd make the node global off the root myself and use whatever linkage you think appropriate to get you to the codec nodes (phandle's most likely) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
Index: linux-work/arch/powerpc/mm/mmu_decl.h === --- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:09:16.0 +1100 +++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-11-15 14:14:29.0 +1100 @@ -56,7 +56,7 @@ extern unsigned long total_lowmem; * architectures. -- Dan */ #if defined(CONFIG_8xx) -#define flush_HPTE(X, va, pg) _tlbie(va) +#define flush_HPTE(X, va, pg) _tlbie(va, 0, /* 8xx doesn't care about PID */) Spurious ','? Weird, it did build ... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.24' branch of 4xx tree
Hi Paul, Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24 to pick up a few bug fixes for 2.6.24. The AC97 change is fairly harmless and is required to get AC97 working on Virtex boards. josh Joachim Foerster (1): [POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus Jon Loeliger (1): [POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platfo Josh Boyer (1): [POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP Roel Kluin (1): [POWERPC] 4xx: balance ioremap/ioumap calls for Yucca Valentine Barshak (1): [POWERPC] 4xx: UIC add mask_ack callback arch/powerpc/platforms/40x/walnut.c |3 ++- arch/powerpc/platforms/44x/bamboo.c |3 ++- arch/powerpc/platforms/44x/ebony.c |3 ++- arch/powerpc/platforms/44x/sequoia.c |3 ++- arch/powerpc/sysdev/uic.c| 18 +- arch/ppc/kernel/setup.c |7 +++ arch/ppc/platforms/4xx/yucca.c |1 + arch/ppc/syslib/virtex_devices.c | 31 +++ 8 files changed, 64 insertions(+), 5 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
Jon Smirl wrote: Now how do I pick which fabric driver to initialize? I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way that works. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On 11/19/07, Timur Tabi [EMAIL PROTECTED] wrote: Jon Smirl wrote: Now how do I pick which fabric driver to initialize? I'm doing it via a Kconfig option. For ASoC V1, I think that's the only way that works. I believe that is your only choice on v1. V1 is not set up to correctly handle for device trees. It is fixed in v2 except for the problem with how to load the fabric; no one has address that problem yet. The sound portion of the code is pretty much the same between v1 and v2, it is all the driver setup code that has been reworked. -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
On Sun, 18 Nov 2007, root wrote:
@@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
{
struct page *page;
struct kmem_cache_node *n;
+ unsigned long flags;
BUG_ON(kmalloc_caches-size sizeof(struct kmem_cache_node));
Well local_irq_save is a bit of an overkill. We know that interrupts are
enabled during this phase of the boot sequence.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Mon, 5 Nov 2007 12:15:30 -0600 Kim Phillips [EMAIL PROTECTED] wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Kumar, Leo, re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since issued his Tested-by. Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5 to go through netdev? Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: mpc832x mds: Fix board PHY reset code
currently the board-level PHY reset code for the mpc832x MDS messes with
reset configuration words source settings which is plain wrong (it
looks like this board code was cut-n-pasted from the mpc8360 mds code,
which has the PHY reset bits in a different BCSR); this patch points
the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR.
Signed-off-by: Peter Van Ackeren [EMAIL PROTECTED]
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/mpc832x_mds.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..9e3bfcc 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -90,10 +90,11 @@ static void __init mpc832x_sys_setup_arch(void)
if ((np = of_find_compatible_node(NULL, network, ucc_geth))
!= NULL){
- /* Reset the Ethernet PHY */
- bcsr_regs[9] = ~0x20;
+ /* Reset the Ethernet PHYs */
+#define BCSR8_FETH_RST 0x50
+ bcsr_regs[8] = ~BCSR8_FETH_RST;
udelay(1000);
- bcsr_regs[9] |= 0x20;
+ bcsr_regs[8] |= BCSR8_FETH_RST;
iounmap(bcsr_regs);
of_node_put(np);
}
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] [POWERPC] vdso: Fixes for cache block sizes
[POWERPC] vdso: Fixes for cache line sizes Current VDSO implementation is hardcoded to 128 byte cache blocks, which are only used on IBM's 64-bit processors. Convert it to get the blocks sizes out of vdso_data instead, similar to how the ppc64 in-kernel cache flush does it. Signed-off-by: Olof Johansson [EMAIL PROTECTED] --- Added back the crclr instructions that got removed by mistake when moving over the in-kernel functions. -Olof diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index 2c8e756..d67bcd8 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -284,6 +284,10 @@ int main(void) DEFINE(CFG_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32)); DEFINE(WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec)); DEFINE(WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec)); + DEFINE(CFG_ICACHE_BLOCKSZ, offsetof(struct vdso_data, icache_block_size)); + DEFINE(CFG_DCACHE_BLOCKSZ, offsetof(struct vdso_data, dcache_block_size)); + DEFINE(CFG_ICACHE_LOGBLOCKSZ, offsetof(struct vdso_data, icache_log_block_size)); + DEFINE(CFG_DCACHE_LOGBLOCKSZ, offsetof(struct vdso_data, dcache_log_block_size)); #ifdef CONFIG_PPC64 DEFINE(CFG_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64)); DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec)); diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c index 2322ba5..3702df7 100644 --- a/arch/powerpc/kernel/vdso.c +++ b/arch/powerpc/kernel/vdso.c @@ -699,11 +699,22 @@ static int __init vdso_init(void) vdso_data-icache_size = ppc64_caches.isize; vdso_data-icache_line_size = ppc64_caches.iline_size; + /* XXXOJN: Blocks should be added to ppc64_caches and used instead */ + vdso_data-dcache_block_size = ppc64_caches.dline_size; + vdso_data-icache_block_size = ppc64_caches.iline_size; + vdso_data-dcache_log_block_size = ppc64_caches.log_dline_size; + vdso_data-icache_log_block_size = ppc64_caches.log_iline_size; + /* * Calculate the size of the 64 bits vDSO */ vdso64_pages = (vdso64_end - vdso64_start) PAGE_SHIFT; DBG(vdso64_kbase: %p, 0x%x pages\n, vdso64_kbase, vdso64_pages); +#else + vdso_data-dcache_block_size = L1_CACHE_BYTES; + vdso_data-dcache_log_block_size = L1_CACHE_SHIFT; + vdso_data-icache_block_size = L1_CACHE_BYTES; + vdso_data-icache_log_block_size = L1_CACHE_SHIFT; #endif /* CONFIG_PPC64 */ diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S index 9cb3199..1ba6feb 100644 --- a/arch/powerpc/kernel/vdso32/cacheflush.S +++ b/arch/powerpc/kernel/vdso32/cacheflush.S @@ -23,29 +23,46 @@ * * Flushes the data cache invalidate the instruction cache for the * provided range [start, end[ - * - * Note: all CPUs supported by this kernel have a 128 bytes cache - * line size so we don't have to peek that info from the datapage */ V_FUNCTION_BEGIN(__kernel_sync_dicache) .cfi_startproc - li r5,127 - andcr6,r3,r5/* round low to line bdy */ + mflrr12 + .cfi_register lr,r12 + mr r11,r3 + bl [EMAIL PROTECTED] + mtlrr12 + mr r10,r3 + + lwz r7,CFG_DCACHE_BLOCKSZ(r10) + addir5,r7,-1 + andcr6,r11,r5 /* round low to line bdy */ subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ - srwi. r8,r8,7 /* compute line count */ + lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10) + srw.r8,r8,r9/* compute line count */ crclr cr0*4+so beqlr /* nothing to do? */ mtctr r8 - mr r3,r6 -1: dcbst 0,r3 - addir3,r3,128 +1: dcbst 0,r6 + add r6,r6,r7 bdnz1b sync + +/* Now invalidate the instruction cache */ + + lwz r7,CFG_ICACHE_BLOCKSZ(r10) + addir5,r7,-1 + andcr6,r11,r5 /* round low to line bdy */ + subfr8,r6,r4/* compute length */ + add r8,r8,r5 + lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10) + srw.r8,r8,r9/* compute line count */ + crclr cr0*4+so + beqlr /* nothing to do? */ mtctr r8 -1: icbi0,r6 - addir6,r6,128 - bdnz1b +2: icbi0,r6 + add r6,r6,r7 + bdnz2b isync li r3,0 blr diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S index 66a36d3..69c5af2 100644 --- a/arch/powerpc/kernel/vdso64/cacheflush.S +++ b/arch/powerpc/kernel/vdso64/cacheflush.S @@ -23,29 +23,46 @@ * * Flushes the data cache
[PATCH] powerpc: fix os-term usage on kernel panic
The rtas_os_term() routine was being called at the wrong time.
The actual rtas call os-term will not ever return, and so
calling it from the panic notifier is too early. Instead,
call it from the machine_reset() call.
The patch splits the rtas_os_term() routine into two: one
part to capture the kernel panic message, invoked during
the panic notifier, and another part that is invoked during
machine_reset().
Prior to this patch, the os-term call was never being made,
because panic_timeout was always non-zero. Calling os-term
helps keep the hypervisor happy! We have to keep the hypervisor
happy to avoid service, dump and error reporting problems.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
One could make a strong argument to move all of this code
from kernel/rtas.c to platforms/pseries/setup.c I did not
do this, just so as to make the changes minimal.
arch/powerpc/kernel/rtas.c | 12 ++--
arch/powerpc/platforms/pseries/setup.c |3 ++-
include/asm-powerpc/rtas.h |3 ++-
3 files changed, 10 insertions(+), 8 deletions(-)
Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
===
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19
18:58:53.0 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c2007-11-19
19:01:10.0 -0600
@@ -631,18 +631,18 @@ void rtas_halt(void)
/* Must be in the RMO region, so we place it here */
static char rtas_os_term_buf[2048];
-void rtas_os_term(char *str)
+void rtas_panic_msg(char *str)
{
- int status;
+ snprintf(rtas_os_term_buf, 2048, OS panic: %s, str);
+}
- if (panic_timeout)
- return;
+void rtas_os_term(void)
+{
+ int status;
if (RTAS_UNKNOWN_SERVICE == rtas_token(ibm,os-term))
return;
- snprintf(rtas_os_term_buf, 2048, OS panic: %s, str);
-
do {
status = rtas_call(rtas_token(ibm,os-term), 1, 1, NULL,
__pa(rtas_os_term_buf));
Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
===
--- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c
2007-11-19 18:58:53.0 -0600
+++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
2007-11-19 19:01:10.0 -0600
@@ -507,7 +507,8 @@ define_machine(pseries) {
.restart= rtas_restart,
.power_off = pSeries_power_off,
.halt = rtas_halt,
- .panic = rtas_os_term,
+ .panic = rtas_panic_msg,
+ .machine_shutdown = rtas_os_term,
.get_boot_time = rtas_get_boot_time,
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
===
--- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19
18:58:53.0 -0600
+++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h2007-11-19
19:01:10.0 -0600
@@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
extern void rtas_restart(char *cmd);
extern void rtas_power_off(void);
extern void rtas_halt(void);
-extern void rtas_os_term(char *str);
+extern void rtas_panic_msg(char *str);
+extern void rtas_os_term(void);
extern int rtas_get_sensor(int sensor, int index, int *state);
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
Kim Phillips wrote: On Mon, 5 Nov 2007 12:15:30 -0600 Kim Phillips [EMAIL PROTECTED] wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Kumar, Leo, re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since issued his Tested-by. Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5 to go through netdev? FWIW I just got back from vacation... I'm grabbing what DaveM has collected into davem/netdev-2.6.git, and then going from there... Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.24' branch of pasemi tree
Hi Paul, Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.24 For the following bugfix for 2.6.24: Olof Johansson (1): [POWERPC] pasemi: Don't reset mpic at boot setup.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 04:31:57PM +, Matt Sealey wrote: David Gibson wrote: On Sun, Nov 18, 2007 at 11:31:13PM +, Matt Sealey wrote: Gah! For the benefit of others on this list who may be misled. *Neither* of you correctly understands the device tree, what I've seen of *both* your suggested approaches is crap. The device tree describes the _hardware_. If you start reasoning about how to lay out the device tree based on your driver model, you're already wrong. Matt, the various properties you list do not mean what you think they mean. No, David, I understand exactly what they mean, in the context of a guy who works on Open Firmware, real Open Firmware, as was standardised 12 years ago. No, you really don't. Either your knowledge of OF is out of date, or you've forgotten what you thought you knew. Not your whacky newspeak device trees, which to be fair, are a good idea, but it seems you all have tried to change something for the sake of changing something. With a couple of tiny exceptions, everything I've said applies equally to real OF trees. [snip] device_type - indicates the open firmware method interface for the device. Therefore, meaningless in flattened trees. No new driver should use this. .. you seem to think you must only design for the guys making Linux flattened device trees. I'm sorry, but I am not one of those guys and I am much more concerned with how this will affect the OF device tree and the usage for anyone else. No, which is exactly why it's wrong to organize the device tree so that it's convenient for loading this fabric driver thing (which AFAICT is a Linux-specific driver model limitation). Meaningless in flattened device trees, but useful information in real OF device trees, do you implement it or not? I'd say, yes. Even if you don't agree with real firmware, you can't just ignore it, shrug it away and say it doesn't matter. Useful information in a real OF tree *if* an OF runtime interface for the device is defined and implemented. [snip] compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. Compatible is meant to list alternative, compatible devices as a *supplement* to device_type. device_type is your primary and compatible is your secondary. In this case, device_type is exactly what Jon wants, something to mark out that the audio device is his board design and requires special work (it is not merely an i2s bus that you can just use - although throwing PCM data at it would work, who knows what mixer it goes to, and what controls are needed to define the bitrate or other features) No, as Segher explains, that's Just Plain Wrong. Originally name did perform the function you think device_type had. But the generic names convention, which has been very well established for a long time now means that the register-level (or equivalent) programming interface is described by compatible. Period. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. I don't see why model can't encode the particular revision of the hardware in this way when it comes to the audio group of features on his board. After all, if you are looking at a digispeaker,flinger (I made that name up) then you need to know depending on the board or even based on weird configurability options of the board, what certain things may be - Apple used layout-id and a number. Why NOT encode the model in the model? Why choose some magical, new property, which then has to be further standardised for no reason? I also think that specifying an audio codec - after all the Open Firmware standard defines an audio interface and device tree requirements for it, even if they are methods that we don't implement and you don't care about - as a function of it's control interface is so backwards it doesn't bare thinking about. Sure, it's fine for a firmware to implement the OF method interface and put in the relevant device_type for audio in the appropriate place (although with complex sound systems with many components, the right place may be non-obvious or even not well defined). It's *not* fine to make up random new device_type values because you think it's convenient. -- 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: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 04:58:44PM +, Matt Sealey wrote:
Segher Boessenkool wrote:
And I forgot the rant you guys usually get - for god's sake, why isn't
anyone using the model property?
Probably because it isn't useful all that often.
[EMAIL PROTECTED] {
\\ this is our magic audio fabric
device_type = digispeaker,flinger;
This is wrong in so many ways; see David's mail for a start.
Why? I'm sorry but I am living in the real world where we have real
firmwares and real dynamic device trees here. You can't just say
this is wrong because it has a device_type.
It's not wrong because it has a device_type, it's wrong because the
device_type value is some random made-up thing that doesn't have an OF
binding behind it. Nor do you suggest an OF binding. Nor should
driver selection be based off device_type.
--
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: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote: Matt, the various properties you list do not mean what you think they mean. name - should be named according to the generic names convention. It's pretty much arbitrary, meant for human readability of the device tree. Drivers should not depend on it (some do, historically, but new drivers and trees should not). It is not arbitrary, there is a single well-defined name for every common class of device. It _is_ machine-readable (but shouldn't be used for driver matching, indeed -- it says nothing about the programming model). Sorry, that was an (over?) simplification on my part. Yes, there are conventions as to what devices should be called by class (usually, but not universally observed), yes they can be used machine-readable under some circumstances. My point is that since driver matching is *not* done off name, and machine-readable uses are not common, the name tends not to matter very much. Plus if an incorrect name is used, it's usually not too bad to fix. device_type - indicates the open firmware method interface for the device. Not method interface, just interface. Right, I say method interface just to emphasise the fact that we're talking about the runtime OF-call interface, rather than register-level or other programming interface. Therefore, meaningless in flattened trees. Even in flat trees, a device_type of for example block indicates the node will have the required properties for that device type, for example block-size. Such properties are perfectly useful. OTOH, it isn't very useful to search for device with a specific device type from within the kernel, since it currently has no firmware interaction to speak of (flat trees don't interact, and the kernel kills real OF dead as soon as possible). Uh... it was you who convinced me that device_type was not appropriate for new flat-tree devices. No new driver should use this. Not without very good rationalisation, anyway. compatible - *this* is the one for driver selection. It describes the hardware level interface(s) of the device. model - usually just for debugging / diagnosis / human-readable purposes, describes exact model / revision of the hardware. It can be used to enable driver quirks / workarounds for when various devices are supposed to be compatible (as encoded in 'compatible') but aren't, due to hardware bugs. However, you should never aim to use it this way in design. Yeah. Any non-workaround value a driver would derive from model is usually better described using a separate property. Well, yes, if the need for the workaround is known when the device tree is created. But by their nature workarounds tend not to be planned, so from the driver's perspective it's legitimate to use *any* reliable-in-practice information to activate a workaround (even if it's not reliable in theory, if there's no other option). That includes both everything in the device tree, and any information the driver can probe from the hardware. My point above is that iIt's reasonably common in such cases for model to be a decent choice. -- 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 03/59] arch/powerpc: Add missing space
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
arch/powerpc/kernel/isa-bridge.c |4 ++--
arch/powerpc/mm/fault.c|2 +-
arch/powerpc/platforms/8xx/m8xx_setup.c|2 +-
arch/powerpc/platforms/celleb/io-workarounds.c |2 +-
arch/powerpc/platforms/celleb/scc_epci.c |2 +-
arch/powerpc/sysdev/fsl_pci.c |2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index f0f49d1..965bfcc 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -108,7 +108,7 @@ static void __devinit pci_process_ISA_OF_ranges(struct
device_node *isa_node,
if (size 0x1)
size = 0x1;
- printk(KERN_ERR no ISA IO ranges or unexpected isa range,
+ printk(KERN_ERR no ISA IO ranges or unexpected isa range,
mapping 64k\n);
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
@@ -116,7 +116,7 @@ static void __devinit pci_process_ISA_OF_ranges(struct
device_node *isa_node,
return;
inval_range:
- printk(KERN_ERR no ISA IO ranges or unexpected isa range,
+ printk(KERN_ERR no ISA IO ranges or unexpected isa range,
mapping 64k\n);
__ioremap_at(phb_io_base_phys, (void *)ISA_IO_BASE,
0x1, _PAGE_NO_CACHE|_PAGE_GUARDED);
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 8135da0..10dda22 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -189,7 +189,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned
long address,
return SIGSEGV;
/* in_atomic() in user mode is really bad,
as is current-mm == NULL. */
- printk(KERN_EMERG Page fault in user mode with
+ printk(KERN_EMERG Page fault in user mode with
in_atomic() = %d mm = %p\n, in_atomic(), mm);
printk(KERN_EMERG NIP = %lx MSR = %lx\n,
regs-nip, regs-msr);
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
b/arch/powerpc/platforms/8xx/m8xx_setup.c
index d35eda8..ba645c2 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -120,7 +120,7 @@ void __init mpc8xx_calibrate_decr(void)
ppc_tb_freq /= 16;
ppc_proc_freq = 5000;
if (!get_freq(clock-frequency, ppc_proc_freq))
- printk(KERN_ERR WARNING: Estimating processor frequency
+ printk(KERN_ERR WARNING: Estimating processor frequency
(not found)\n);
printk(Decrementer Frequency = 0x%lx\n, ppc_tb_freq);
diff --git a/arch/powerpc/platforms/celleb/io-workarounds.c
b/arch/powerpc/platforms/celleb/io-workarounds.c
index 2b91214..32b9cec 100644
--- a/arch/powerpc/platforms/celleb/io-workarounds.c
+++ b/arch/powerpc/platforms/celleb/io-workarounds.c
@@ -256,7 +256,7 @@ int __init celleb_pci_workaround_init(void)
celleb_dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!celleb_dummy_page_va) {
- printk(KERN_ERR Celleb: dummy read disabled.
+ printk(KERN_ERR Celleb: dummy read disabled.
Alloc celleb_dummy_page_va failed\n);
return 1;
}
diff --git a/arch/powerpc/platforms/celleb/scc_epci.c
b/arch/powerpc/platforms/celleb/scc_epci.c
index 9d07642..a3c7cfb 100644
--- a/arch/powerpc/platforms/celleb/scc_epci.c
+++ b/arch/powerpc/platforms/celleb/scc_epci.c
@@ -95,7 +95,7 @@ void __init epci_workaround_init(struct pci_controller *hose)
private-dummy_page_da = dma_map_single(hose-parent,
celleb_dummy_page_va, PAGE_SIZE, DMA_FROM_DEVICE);
if (private-dummy_page_da == DMA_ERROR_CODE) {
- printk(KERN_ERR EPCI: dummy read disabled.
+ printk(KERN_ERR EPCI: dummy read disabled.
Map dummy page failed.\n);
return;
}
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 33df4c3..87e58e0 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -222,7 +222,7 @@ int __init fsl_add_bridge(struct device_node *dev, int
is_primary)
hose-indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
}
- printk(KERN_INFO Found FSL PCI host bridge at 0x%016llx.
+ printk(KERN_INFO Found FSL PCI host bridge at 0x%016llx.
Firmware bus number: %d-%d\n,
(unsigned long long)rsrc.start, hose-first_busno,
hose-last_busno);
--
1.5.3.5.652.gf192c
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Revisited, audio codec device tree entries.
On Mon, Nov 19, 2007 at 12:28:02PM -0700, Grant Likely wrote: On 11/19/07, Jon Smirl [EMAIL PROTECTED] wrote: On 11/19/07, Grant Likely [EMAIL PROTECTED] wrote: You might be stuck with using either a platform_device or an of_platform_device as a stepping stone to creating the device on the ALSA fabric driver. I also concluded that I need a of_platform stepping stone. There are several ways this could be done, which one is the right one? a) fabric is global, create a global device node for it and implement it as a of_platform device This is really board level description stuff. I'd make the node global off the root myself and use whatever linkage you think appropriate to get you to the codec nodes (phandle's most likely) No. I think this is the whole damn point we've been spiralling around. An of_platform device is appropriate *only* if there is an OF node for the device. There should be an OF node for the device only if it it really is a well-defined hardware component which implements it. As far as I can understand, the fabric driver is really just a catchall to cover whatever various interconnections there are between audio components on the board. Those interconnections could (and probably should) be described in the OF tree. But that description would be to describe each of those interconnections individually e.g. codecs have links to sound PHY devices (speakers) or whatever, codecs, i2s AC97 and so forth devices have links between them appropriate to the type of device. Not as some imaginary fabric device. Therefore the fabric driver cannot be instantiated as an of_platfornm device. Therfore arch code will have to instantiate the fabric driver some other way. There are a couple of options here: 1) We have a universal device-tree-based fabric driver which parses all the above-described interconnection information in the device tree and handles any situation. Cool, but probably a lot of work and fiddly to get right. 2) Or, the platform code instantiates an appopriate fabric driver for the board (which will probably make assumptions about how things are interconnected). Platform code can optionally examine board level model properties or other device information to select the correct fabric driver and/or options. The fabric driver can optionally look at some parts of the device tree information to configure details of its operation. Option (2) is a hack, but it's a reasonably well-contained hack. It works for now, and doesn't preclude switching to option (1) later - without changes to the device tree, and on a board-by-board basis. It can also handle the (almost inevitable) case of device trees with missing or incorrect detailed audio interconnection information. The basic thing is that we have a mismatch between the Linux driver model and the device tree model. Rather than hacking the device tree to match the Linux model, we should provide whatever glue code is necessary to instantiate the necessary Linux drivers from the device tree information we have. This is, essentially, the exact purpose for which platform code exists. -- 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
libfdt: Abolish _typed() variants, add _cell() variants
In a number of places through libfdt and its tests, we have *_typed()
macro variants on functions which use gcc's typeof and statement
expression extensions to allow passing literals where the underlying
function takes a buffer and size.
These seemed like a good idea at the time, but in fact they have some
problems. They use typeof and statement expressions, extensions I'd
prefer to avoid for portability. Plus, they have potential gotchas -
although they'll deal with the size of the thing passed, they won't
deal with other representation issues (like endianness) and results
could be very strange if the type of the expression passed isn't what
you think it is.
In fact, the only users of these _typed() macros were when the value
passed is a single cell (32-bit integer). Therefore, this patch
removes all these _typed() macros and replaces them with explicit
_cell() variants which handle a single 32-bit integer, and which also
perform endian convesions as appropriate.
With this in place, it now becomes easy to use standardized big-endian
representation for integer valued properties in the testcases,
regardless of the platform we're running on. We therefore do that,
which has the additional advantage that all the example trees created
during a test run are now byte-for-byte identical regardless of
platform.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2007-11-20 13:04:09.0 +1100
+++ dtc/libfdt/libfdt.h 2007-11-20 13:05:24.0 +1100
@@ -657,12 +657,12 @@ int fdt_node_offset_by_compatible(const
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
-
-#define fdt_setprop_inplace_typed(fdt, nodeoffset, name, val) \
- ({ \
- typeof(val) x = val; \
- fdt_setprop_inplace(fdt, nodeoffset, name, x, sizeof(x)); \
- })
+static inline int fdt_setprop_inplace_cell(void *fdt, int nodeoffset,
+ const char *name, uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_setprop_inplace(fdt, nodeoffset, name, val, sizeof(val));
+}
int fdt_nop_property(void *fdt, int nodeoffset, const char *name);
int fdt_nop_node(void *fdt, int nodeoffset);
@@ -676,11 +676,11 @@ int fdt_add_reservemap_entry(void *fdt,
int fdt_finish_reservemap(void *fdt);
int fdt_begin_node(void *fdt, const char *name);
int fdt_property(void *fdt, const char *name, const void *val, int len);
-#define fdt_property_typed(fdt, name, val) \
- ({ \
- typeof(val) x = (val); \
- fdt_property((fdt), (name), x, sizeof(x)); \
- })
+static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_property(fdt, name, val, sizeof(val));
+}
#define fdt_property_string(fdt, name, str) \
fdt_property(fdt, name, str, strlen(str)+1)
int fdt_end_node(void *fdt);
@@ -698,11 +698,12 @@ int fdt_del_mem_rsv(void *fdt, int n);
int fdt_setprop(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
-#define fdt_setprop_typed(fdt, nodeoffset, name, val) \
- ({ \
- typeof(val) x = (val); \
- fdt_setprop((fdt), (nodeoffset), (name), x, sizeof(x)); \
- })
+static inline int fdt_setprop_cell(void *fdt, int nodeoffset, const char *name,
+ uint32_t val)
+{
+ val = cpu_to_fdt32(val);
+ return fdt_setprop(fdt, nodeoffset, name, val, sizeof(val));
+}
#define fdt_setprop_string(fdt, nodeoffset, name, str) \
fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
int fdt_delprop(void *fdt, int nodeoffset, const char *name);
Index: dtc/tests/setprop_inplace.c
===
--- dtc.orig/tests/setprop_inplace.c2007-11-20 10:15:51.0 +1100
+++ dtc/tests/setprop_inplace.c 2007-11-20 13:05:55.0 +1100
@@ -42,14 +42,14 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- intp = check_getprop_typed(fdt, 0, prop-int, TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, prop-int, TEST_VALUE_1);
verbose_printf(Old int value was 0x%08x\n, *intp);
- err = fdt_setprop_inplace_typed(fdt, 0, prop-int, ~TEST_VALUE_1);
+ err = fdt_setprop_inplace_cell(fdt, 0, prop-int, ~TEST_VALUE_1);
if (err)
FAIL(Failed to set \prop-int\ to 0x08%x: %s,
~TEST_VALUE_1, fdt_strerror(err));
- intp = check_getprop_typed(fdt, 0, prop-int, ~TEST_VALUE_1);
+ intp = check_getprop_cell(fdt, 0, prop-int, ~TEST_VALUE_1);
verbose_printf(New int value is 0x%08x\n, *intp);
strp = check_getprop(fdt, 0, prop-str, strlen(TEST_STRING_1)+1,
Index:
Re: [PATCH v2] PMU: replace information ioctls and schedule for removal
Johannes Berg writes: This patch adds sysfs attributes to the PMU to allow getting the information on the PMU type and whether adb is present from there instead of via the ioctl. The ioctl is made optional and scheduled for removal. I don't see any reason to ever remove the ioctls. We're talking about just 4 lines of code here. Sure we can add the sysfs attributes - even though that adds an order of magnitude more lines of code (thanks sysfs :) but I don't see any good reason to remove the existing interface. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fix scaled time accounting possible divide by zero
This fixes a problem noticed by Balbir Singh Signed-off-by: Michael Neuling [EMAIL PROTECTED] --- Paulus: can we send this up for 2.6.24? arch/powerpc/kernel/time.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c @@ -244,8 +244,9 @@ void account_system_vtime(struct task_st /* deltascaled includes both user and system time. * Hence scale it based on the purr ratio to estimate * the system time */ - deltascaled = deltascaled * get_paca()-system_time / - (get_paca()-system_time + get_paca()-user_time); + if (get_paca()-user_time) + deltascaled = deltascaled * get_paca()-system_time / + (get_paca()-system_time + get_paca()-user_time); delta += get_paca()-system_time; get_paca()-system_time = 0; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ibm_newemac: Fix possible lockup on close
It's a bad idea to call flush_scheduled_work from within a
netdev-stop because the linkwatch will occasionally take the
rtnl lock from a workqueue context, and thus that can deadlock.
This reworks things a bit in that area to avoid the problem.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c | 31 ---
drivers/net/ibm_newemac/core.h |1 +
2 files changed, 21 insertions(+), 11 deletions(-)
Index: linux-work/drivers/net/ibm_newemac/core.c
===
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-20
14:42:50.0 +1100
+++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-20 14:46:51.0
+1100
@@ -642,9 +642,11 @@ static void emac_reset_work(struct work_
DBG(dev, reset_work NL);
mutex_lock(dev-link_lock);
- emac_netif_stop(dev);
- emac_full_tx_reset(dev);
- emac_netif_start(dev);
+ if (dev-opened) {
+ emac_netif_stop(dev);
+ emac_full_tx_reset(dev);
+ emac_netif_start(dev);
+ }
mutex_unlock(dev-link_lock);
}
@@ -1063,10 +1065,9 @@ static int emac_open(struct net_device *
dev-rx_sg_skb = NULL;
mutex_lock(dev-link_lock);
+ dev-opened = 1;
- /* XXX Start PHY polling now. Shouldn't wr do like sungem instead and
-* always poll the PHY even when the iface is down ? That would allow
-* things like laptop-net to work. --BenH
+ /* Start PHY polling now.
*/
if (dev-phy.address = 0) {
int link_poll_interval;
@@ -1145,9 +1146,11 @@ static void emac_link_timer(struct work_
int link_poll_interval;
mutex_lock(dev-link_lock);
-
DBG2(dev, link timer NL);
+ if (!dev-opened)
+ goto bail;
+
if (dev-phy.def-ops-poll_link(dev-phy)) {
if (!netif_carrier_ok(dev-ndev)) {
/* Get new link parameters */
@@ -1170,13 +1173,14 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_OFF;
}
schedule_delayed_work(dev-link_work, link_poll_interval);
-
+ bail:
mutex_unlock(dev-link_lock);
}
static void emac_force_link_update(struct emac_instance *dev)
{
netif_carrier_off(dev-ndev);
+ smp_rmb();
if (dev-link_polling) {
cancel_rearming_delayed_work(dev-link_work);
if (dev-link_polling)
@@ -1191,11 +1195,14 @@ static int emac_close(struct net_device
DBG(dev, close NL);
- if (dev-phy.address = 0)
+ if (dev-phy.address = 0) {
+ dev-link_polling = 0;
cancel_rearming_delayed_work(dev-link_work);
-
+ }
+ mutex_lock(dev-link_lock);
emac_netif_stop(dev);
- flush_scheduled_work();
+ dev-opened = 0;
+ mutex_unlock(dev-link_lock);
emac_rx_disable(dev);
emac_tx_disable(dev);
@@ -2756,6 +2763,8 @@ static int __devexit emac_remove(struct
unregister_netdev(dev-ndev);
+ flush_scheduled_work();
+
if (emac_has_feature(dev, EMAC_FTR_HAS_TAH))
tah_detach(dev-tah_dev, dev-tah_port);
if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII))
Index: linux-work/drivers/net/ibm_newemac/core.h
===
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2007-11-20
14:42:50.0 +1100
+++ linux-work/drivers/net/ibm_newemac/core.h 2007-11-20 14:46:51.0
+1100
@@ -258,6 +258,7 @@ struct emac_instance {
int stop_timeout; /* in us */
int no_mcast;
int mcast_pending;
+ int opened;
struct work_struct reset_work;
spinlock_t lock;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix scaled time accounting possible divide by zero
In message [EMAIL PROTECTED] you wrote: Michael Neuling wrote: This fixes a problem noticed by Balbir Singh Signed-off-by: Michael Neuling [EMAIL PROTECTED] --- Paulus: can we send this up for 2.6.24? arch/powerpc/kernel/time.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c @@ -244,8 +244,9 @@ void account_system_vtime(struct task_st /* deltascaled includes both user and system time. * Hence scale it based on the purr ratio to estimate * the system time */ - deltascaled = deltascaled * get_paca()-system_time / - (get_paca()-system_time + get_paca()-user_time); + if (get_paca()-user_time) + deltascaled = deltascaled * get_paca()-system_time / + (get_paca()-system_time + get_paca()-user_time); Hi, Michael, I'd be doubly careful with scaled multiplication approach, we tried this for CFS (please see task_utime() and task_stime() and the fixes that went around it). We ran into problems were due to multiplication rounding errors, we would see stime and utime go back after a period of time. Please see http://kerneltrap.org/mailarchive/linux-kernel/2007/10/16/344377 Our problems were made severe by the fact that sum_exec_runtime and stime/utime accounting occured differently. stime/utime were sampled at jiffy boundaries and hence could we incorrect. I think we need to use rounding to ensure that ac_scaled*time never goes back due to rounding errors. I've not changed the math here much, just the case of user_time being zero. Is this related to this patch specifically, or something that's been wrong with these patches for a while? Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix scaled time accounting possible divide by zero
Michael Neuling wrote: This fixes a problem noticed by Balbir Singh Signed-off-by: Michael Neuling [EMAIL PROTECTED] --- Paulus: can we send this up for 2.6.24? arch/powerpc/kernel/time.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c @@ -244,8 +244,9 @@ void account_system_vtime(struct task_st /* deltascaled includes both user and system time. * Hence scale it based on the purr ratio to estimate * the system time */ - deltascaled = deltascaled * get_paca()-system_time / - (get_paca()-system_time + get_paca()-user_time); + if (get_paca()-user_time) + deltascaled = deltascaled * get_paca()-system_time / + (get_paca()-system_time + get_paca()-user_time); Hi, Michael, I'd be doubly careful with scaled multiplication approach, we tried this for CFS (please see task_utime() and task_stime() and the fixes that went around it). We ran into problems were due to multiplication rounding errors, we would see stime and utime go back after a period of time. Please see http://kerneltrap.org/mailarchive/linux-kernel/2007/10/16/344377 Our problems were made severe by the fact that sum_exec_runtime and stime/utime accounting occured differently. stime/utime were sampled at jiffy boundaries and hence could we incorrect. I think we need to use rounding to ensure that ac_scaled*time never goes back due to rounding errors. delta += get_paca()-system_time; get_paca()-system_time = 0; } -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] xmon bitlock fix
(sorry, untested for lack of hardware)
--
xmon uses a bit lock spinlock but doesn't close the critical section
when releasing it. It doesn't seem like a big deal because it will
eventually break out of the lock anyway, but presumably that's only
in exceptional cases where some error is tolerated, while the lack of a memory
barrier could allow incorrect results during normal functioning operation
as well.
Convert it to use a regular spinlock instead.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Index: linux-2.6/arch/ppc/xmon/start.c
===
--- linux-2.6.orig/arch/ppc/xmon/start.c
+++ linux-2.6/arch/ppc/xmon/start.c
@@ -92,16 +92,14 @@ xmon_write(void *handle, void *ptr, int
{
char *p = ptr;
int i, c, ct;
-
-#ifdef CONFIG_SMP
- static unsigned long xmon_write_lock;
+ static DEFINE_SPINLOCK(xmon_write_lock);
int lock_wait = 100;
int locked;
- while ((locked = test_and_set_bit(0, xmon_write_lock)) != 0)
+ while (!(locked = spin_trylock(xmon_write_lock))) {
if (--lock_wait == 0)
break;
-#endif
+ }
if (!scc_initialized)
xmon_init_scc();
@@ -122,10 +120,9 @@ xmon_write(void *handle, void *ptr, int
eieio();
}
-#ifdef CONFIG_SMP
- if (!locked)
- clear_bit(0, xmon_write_lock);
-#endif
+ if (locked)
+ spin_unlock(xmon_write_lock);
+
return nb;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] powerpc: hash lock use lock bitops
This isn't a bugfix, but may help performance slightly...
--
powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
of lock bitops for slightly more optimal memory barriers (can avoid an lwsync
in the trylock).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Index: linux-2.6/arch/powerpc/mm/hash_native_64.c
===
--- linux-2.6.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6/arch/powerpc/mm/hash_native_64.c
@@ -113,7 +113,7 @@ static inline void native_lock_hpte(stru
unsigned long *word = hptep-v;
while (1) {
- if (!test_and_set_bit(HPTE_LOCK_BIT, word))
+ if (!test_and_set_bit_lock(HPTE_LOCK_BIT, word))
break;
while(test_bit(HPTE_LOCK_BIT, word))
cpu_relax();
@@ -124,8 +124,7 @@ static inline void native_unlock_hpte(st
{
unsigned long *word = hptep-v;
- asm volatile(lwsync:::memory);
- clear_bit(HPTE_LOCK_BIT, word);
+ clear_bit_unlock(HPTE_LOCK_BIT, word);
}
static long native_hpte_insert(unsigned long hpte_group, unsigned long va,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PPC: Fix potential NULL dereference
On Thu, 15 Nov 2007, Cyrill Gorcunov wrote: This patch does fix potential NULL pointer dereference that could take place inside of strcmp() if of_get_property() call failed. Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED] --- arch/powerpc/platforms/83xx/usb.c |8 1 files changed, 4 insertions(+), 4 deletions(-) CC the linuxppc-dev@ozlabs.org list in the future. applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
On Mon, 19 Nov 2007, Kim Phillips wrote: currently the board-level PHY reset code for the mpc832x MDS messes with reset configuration words source settings which is plain wrong (it looks like this board code was cut-n-pasted from the mpc8360 mds code, which has the PHY reset bits in a different BCSR); this patch points the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR. Signed-off-by: Peter Van Ackeren [EMAIL PROTECTED] Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- arch/powerpc/platforms/83xx/mpc832x_mds.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix 2nd UCC entry in mpc832x_mds.dts
On Tue, 13 Nov 2007, Kim Phillips wrote: correct the reg property, remove duplicate io port entry, whitespace fixes. Thanks to Peter Van Ackeren for pointing this out. Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc832x_mds.dts |9 - 1 files changed, 4 insertions(+), 5 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] powerpc: handle mpc8360 rev. 2.1 RGMII timing erratum
On Mon, 5 Nov 2007, Kim Phillips wrote: if on a rev. 2.1, adjust UCC clock and data timing characteristics as specified in the rev.2.1 erratum #2. Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 ++-- 1 files changed, 28 insertions(+), 3 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.24' branch
Please pull from 'for-2.6.24' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24 to receive the following updates: Documentation/powerpc/booting-without-of.txt |5 - arch/powerpc/boot/dts/mpc832x_mds.dts|9 - arch/powerpc/boot/dts/mpc8544ds.dts | 20 ++-- arch/powerpc/boot/dts/mpc8572ds.dts | 108 --- arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 ++- arch/powerpc/platforms/83xx/mpc832x_mds.c|7 - arch/powerpc/platforms/83xx/mpc836x_mds.c| 31 ++ arch/powerpc/platforms/83xx/usb.c|8 - 8 files changed, 254 insertions(+), 60 deletions(-) Cyrill Gorcunov (1): [POWERPC] Fix potential NULL dereference Kim Phillips (4): [POWERPC] 83xx: mpc832x mds: Fix board PHY reset code [POWERPC] 83xx: Fix 2nd UCC entry in mpc832x_mds.dts [POWERPC] Document rgmii-rxid and rgmii-txid phy-connection-types [POWERPC] 83xx: Handle mpc8360 rev. 2.1 RGMII timing erratum Kumar Gala (1): [POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] xmon bitlock fix
On Tue, Nov 20, 2007 at 04:28:02PM +1100, Paul Mackerras wrote: Nick Piggin writes: xmon uses a bit lock spinlock but doesn't close the critical section when releasing it. It doesn't seem like a big deal because it will eventually break out of the lock anyway, but presumably that's only in exceptional cases where some error is tolerated, while the lack of a memory barrier could allow incorrect results during normal functioning operation as well. Convert it to use a regular spinlock instead. I'd rather not. The idea is that xmon is as independent as possible of the rest of the kernel, so that it will work even when lots of kernel data structures are corrupted. If spinlocks were simple spin loops then maybe, but they're not these days. Fair enough, I guess you still want lockdep kernels to work. As for the memory barrier comment, I don't think it is a reason, since test_and_set_bit acts as a barrier, and in any case the worst thing test_and_set_bit is a barrier (although heavier than required to acquire a lock). But clear_bit isn't strong enough... you do have eieio() in there, making it probably less problem, but that won't get executed if nb is 0, and it is still doing the xmon_init_scc() outside the loop. I just prefer to make it a simple lock that doesn't rely on barriers or the specific structure of the critical section. that could happen is that the characters from different cpu's outputs get interleaved (that's one reason why the loop has a timeout, the other is for robustness). In any case this is in arch/ppc which is dying code. I don't think there are any SMP platforms supported in arch/ppc any more except for some (fairly rare) PReP platforms, and I hope to get PReP moved over soon. I was just grepping the tree, and trying to reduce code which might be fragile, broken, or a poor example. Finally, why do you say that it doesn't close the critical section? Possibly the locked variable is badly named (it's zero when we get the lock) but AFAICS the code is actually correct. Well the unlock itself doesn't close it properly because clear_bit doesn't order previous loads or stores. How about this? --- xmon uses a bit lock spinlock but doesn't close the critical section when releasing it. It doesn't seem like a big deal because it will eventually break out of the lock anyway, but presumably that's only in exceptional cases where some error is tolerated, while the lack of a memory barrier could allow incorrect results during normal functioning operation as well. Signed-off-by: Nick Piggin [EMAIL PROTECTED] --- Index: linux-2.6/arch/ppc/xmon/start.c === --- linux-2.6.orig/arch/ppc/xmon/start.c +++ linux-2.6/arch/ppc/xmon/start.c @@ -98,7 +98,7 @@ xmon_write(void *handle, void *ptr, int int lock_wait = 100; int locked; - while ((locked = test_and_set_bit(0, xmon_write_lock)) != 0) + while ((locked = test_and_set_bit_lock(0, xmon_write_lock)) != 0) if (--lock_wait == 0) break; #endif @@ -124,7 +124,7 @@ xmon_write(void *handle, void *ptr, int #ifdef CONFIG_SMP if (!locked) - clear_bit(0, xmon_write_lock); + clear_bit_unlock(0, xmon_write_lock); #endif return nb; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
On Sun, 18 Nov 2007 14:18:06 -0500 Trond Myklebust [EMAIL PROTECTED] wrote: Torsten I had already fixed that one in my own stack. Attached are the 3 patches that I've got. 1 from SteveD, 2 fixes. Andrew, could you please unapply the sillyrename patches you've got, and apply these 3 instead? I'd expect to see things like this appear in git-nfs.patch. Did something change? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards
The interrupt map for the PCI PHB that had the ULI1575 was not correct
on the boards that have it.
* 8544 DS:
- Fix interrupt mask
- Be explicit about use of INTA for on chip peripherals
* 8572 DS/8641 HPCN:
- Fix interrupt mask
- Expand interrupt map for PCI slots to cover all functions
- Be explicit about use of INTA for on chip peripherals
---
intended for 2.6.24 as a bug fix. Its ugly but I don't think we have a
choice, silly HW.
arch/powerpc/boot/dts/mpc8544ds.dts| 20 +++---
arch/powerpc/boot/dts/mpc8572ds.dts| 108 ---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 ++-
3 files changed, 211 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 3f9d15c..6c608de 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -272,24 +272,24 @@
clock-frequency = 1fca055;
interrupt-parent = mpic;
interrupts = 1b 2;
- interrupt-map-mask = fb00 0 0 0;
+ interrupt-map-mask = ff00 0 0 1;
interrupt-map =
// IDSEL 0x1c USB
- e000 0 0 0 i8259 c 2
- e100 0 0 0 i8259 9 2
- e200 0 0 0 i8259 a 2
- e300 0 0 0 i8259 b 2
+ e000 0 0 1 i8259 c 2
+ e100 0 0 1 i8259 9 2
+ e200 0 0 1 i8259 a 2
+ e300 0 0 1 i8259 b 2
// IDSEL 0x1d Audio
- e800 0 0 0 i8259 6 2
+ e800 0 0 1 i8259 6 2
// IDSEL 0x1e Legacy
- f000 0 0 0 i8259 7 2
- f100 0 0 0 i8259 7 2
+ f000 0 0 1 i8259 7 2
+ f100 0 0 1 i8259 7 2
// IDSEL 0x1f IDE/SATA
- f800 0 0 0 i8259 e 2
- f900 0 0 0 i8259 5 2
+ f800 0 0 1 i8259 e 2
+ f900 0 0 1 i8259 5 2
;
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts
b/arch/powerpc/boot/dts/mpc8572ds.dts
index d638dee..0eb44fb 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -219,36 +219,120 @@
clock-frequency = 1fca055;
interrupt-parent = mpic;
interrupts = 18 2;
- interrupt-map-mask = fb00 0 0 0;
+ interrupt-map-mask = ff00 0 0 7;
interrupt-map =
- /* IDSEL 0x11 - PCI slot 1 */
+ /* IDSEL 0x11 func 0 - PCI slot 1 */
8800 0 0 1 mpic 2 1
8800 0 0 2 mpic 3 1
8800 0 0 3 mpic 4 1
8800 0 0 4 mpic 1 1
- /* IDSEL 0x12 - PCI slot 2 */
+ /* IDSEL 0x11 func 1 - PCI slot 1 */
+ 8900 0 0 1 mpic 2 1
+ 8900 0 0 2 mpic 3 1
+ 8900 0 0 3 mpic 4 1
+ 8900 0 0 4 mpic 1 1
+
+ /* IDSEL 0x11 func 2 - PCI slot 1 */
+ 8a00 0 0 1 mpic 2 1
+ 8a00 0 0 2 mpic 3 1
+ 8a00 0 0 3 mpic 4 1
+ 8a00 0 0 4 mpic 1 1
+
+ /* IDSEL 0x11 func 3 - PCI slot 1 */
+ 8b00 0 0 1 mpic 2 1
+ 8b00 0 0 2 mpic 3 1
+ 8b00 0 0 3 mpic 4 1
+ 8b00 0 0 4 mpic 1 1
+
+ /* IDSEL 0x11 func 4 - PCI slot 1 */
+ 8c00 0 0 1 mpic 2 1
+ 8c00 0 0 2 mpic 3 1
+ 8c00 0 0 3 mpic 4 1
+ 8c00 0 0 4 mpic 1 1
+
+ /* IDSEL 0x11 func 5 - PCI slot 1 */
+ 8d00 0 0 1 mpic 2 1
+ 8d00 0 0 2 mpic 3 1
+ 8d00 0 0 3 mpic 4 1
+ 8d00 0 0 4 mpic 1 1
+
+ /* IDSEL 0x11 func 6 - PCI slot 1 */
+ 8e00 0 0 1 mpic 2 1
+ 8e00 0 0 2 mpic 3 1
+ 8e00 0 0 3 mpic 4 1
+ 8e00 0 0 4 mpic 1 1
+
+ /* IDSEL 0x11 func 7 - PCI slot 1 */
+ 8f00 0 0 1 mpic 2 1
+ 8f00 0 0 2 mpic 3 1
+ 8f00 0 0 3 mpic 4 1
+ 8f00 0 0 4 mpic 1 1
+
+ /* IDSEL 0x12 func 0 - PCI slot 2 */
9000 0 0 1 mpic 3 1
9000 0 0 2 mpic 4 1
9000 0 0 3 mpic 1 1
9000 0 0 4 mpic 2 1
+
Re: [PATCH 1/5] powerpc: document rgmii-rxid and rgmii-txid phy-connection-types
On Mon, 5 Nov 2007, Kim Phillips wrote: A h/w bug requires we program the PHY in RGMII mode for internal delay on the receive or transmit side only; document the new property values. Signed-off-by: Kim Phillips [EMAIL PROTECTED] --- Documentation/powerpc/booting-without-of.txt |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc: hash lock use lock bitops
On Tue, Nov 20, 2007 at 05:08:24PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2007-11-20 at 06:09 +0100, Nick Piggin wrote:
This isn't a bugfix, but may help performance slightly...
--
powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
of lock bitops for slightly more optimal memory barriers (can avoid an
lwsync
in the trylock).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Looks nice, I'll try it out on a G5 and let you know.
Cool, thanks (I don't have mine handy ATM...).
BTW, here is another thing which you might want to think about. Again
untested for temporary lack of hardware.
--
The radix-tree is now RCU safe, so powerpc can avoid the games it was playing
in order to have a lockless readside. Saves an irq disable/enable, a couple of
__get_cpu_var()s, a cacheline, and a memory barrier, in the fastpath. Should
save a cycle or two...
---
Index: linux-2.6/arch/powerpc/kernel/irq.c
===
--- linux-2.6.orig/arch/powerpc/kernel/irq.c
+++ linux-2.6/arch/powerpc/kernel/irq.c
@@ -406,8 +406,6 @@ void do_softirq(void)
static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
-static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
-static unsigned int irq_radix_writer;
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
@@ -550,57 +548,6 @@ void irq_set_virq_count(unsigned int cou
irq_virq_count = count;
}
-/* radix tree not lockless safe ! we use a brlock-type mecanism
- * for now, until we can use a lockless radix tree
- */
-static void irq_radix_wrlock(unsigned long *flags)
-{
- unsigned int cpu, ok;
-
- spin_lock_irqsave(irq_big_lock, *flags);
- irq_radix_writer = 1;
- smp_mb();
- do {
- barrier();
- ok = 1;
- for_each_possible_cpu(cpu) {
- if (per_cpu(irq_radix_reader, cpu)) {
- ok = 0;
- break;
- }
- }
- if (!ok)
- cpu_relax();
- } while(!ok);
-}
-
-static void irq_radix_wrunlock(unsigned long flags)
-{
- smp_wmb();
- irq_radix_writer = 0;
- spin_unlock_irqrestore(irq_big_lock, flags);
-}
-
-static void irq_radix_rdlock(unsigned long *flags)
-{
- local_irq_save(*flags);
- __get_cpu_var(irq_radix_reader) = 1;
- smp_mb();
- if (likely(irq_radix_writer == 0))
- return;
- __get_cpu_var(irq_radix_reader) = 0;
- smp_wmb();
- spin_lock(irq_big_lock);
- __get_cpu_var(irq_radix_reader) = 1;
- spin_unlock(irq_big_lock);
-}
-
-static void irq_radix_rdunlock(unsigned long flags)
-{
- __get_cpu_var(irq_radix_reader) = 0;
- local_irq_restore(flags);
-}
-
static int irq_setup_virq(struct irq_host *host, unsigned int virq,
irq_hw_number_t hwirq)
{
@@ -791,9 +738,9 @@ void irq_dispose_mapping(unsigned int vi
/* Check if radix tree allocated yet */
if (host-revmap_data.tree.gfp_mask == 0)
break;
- irq_radix_wrlock(flags);
+ spin_lock_irqsave(irq_big_lock, flags);
radix_tree_delete(host-revmap_data.tree, hwirq);
- irq_radix_wrunlock(flags);
+ spin_unlock_irqrestore(irq_big_lock, flags);
break;
}
@@ -861,9 +808,9 @@ unsigned int irq_radix_revmap(struct irq
return irq_find_mapping(host, hwirq);
/* Now try to resolve */
- irq_radix_rdlock(flags);
+ rcu_read_lock();
ptr = radix_tree_lookup(tree, hwirq);
- irq_radix_rdunlock(flags);
+ rcu_read_unlock();
/* Found it, return */
if (ptr) {
@@ -874,9 +821,9 @@ unsigned int irq_radix_revmap(struct irq
/* If not there, try to insert it */
virq = irq_find_mapping(host, hwirq);
if (virq != NO_IRQ) {
- irq_radix_wrlock(flags);
+ spin_lock_irqsave(irq_big_lock, flags);
radix_tree_insert(tree, hwirq, irq_map[virq]);
- irq_radix_wrunlock(flags);
+ spin_unlock_irqrestore(irq_big_lock, flags);
}
return virq;
}
@@ -989,12 +936,12 @@ static int irq_late_init(void)
struct irq_host *h;
unsigned long flags;
- irq_radix_wrlock(flags);
+ spin_lock_irqsave(irq_big_lock, flags);
list_for_each_entry(h, irq_hosts, link) {
if (h-revmap_type == IRQ_HOST_MAP_TREE)
INIT_RADIX_TREE(h-revmap_data.tree, GFP_ATOMIC);
}
- irq_radix_wrunlock(flags);
+ spin_unlock_irqrestore(irq_big_lock, flags);
return 0;
}
Re: [patch] powerpc: hash lock use lock bitops
On Tue, 2007-11-20 at 06:09 +0100, Nick Piggin wrote: This isn't a bugfix, but may help performance slightly... -- powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage of lock bitops for slightly more optimal memory barriers (can avoid an lwsync in the trylock). Signed-off-by: Nick Piggin [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Looks nice, I'll try it out on a G5 and let you know. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [PPC] Remove xmon from ml300 and ml403 defconfig
From: Grant Likely [EMAIL PROTECTED] xmon is broken under arch/ppc so remove it from the defconfig. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- Josh; I'm not going to even bother doing a full defconfig update for these boards right now; it's probably not worth it. This change just eliminates the xmon build issue. Plus doing it this way is trivial to review. :-) In fact; looking at the code, I don't think xmon builds for *any* arch/ppc platforms at the moment. :-/ Probably not even worth worrying about. As we discussed, this should go in for .24 Cheers, g. arch/ppc/configs/ml300_defconfig |2 +- arch/ppc/configs/ml403_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/ppc/configs/ml300_defconfig b/arch/ppc/configs/ml300_defconfig index 69bad91..d66cacd 100644 --- a/arch/ppc/configs/ml300_defconfig +++ b/arch/ppc/configs/ml300_defconfig @@ -719,7 +719,7 @@ CONFIG_DEBUG_INFO=y CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_KGDB is not set -CONFIG_XMON=y +# CONFIG_XMON is not set # CONFIG_BDI_SWITCH is not set # CONFIG_SERIAL_TEXT_DEBUG is not set diff --git a/arch/ppc/configs/ml403_defconfig b/arch/ppc/configs/ml403_defconfig index a78896e..71bcfa7 100644 --- a/arch/ppc/configs/ml403_defconfig +++ b/arch/ppc/configs/ml403_defconfig @@ -720,7 +720,7 @@ CONFIG_DEBUG_INFO=y CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_KGDB is not set -CONFIG_XMON=y +# CONFIG_XMON is not set # CONFIG_BDI_SWITCH is not set # CONFIG_SERIAL_TEXT_DEBUG is not set ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
My changes to _tlbie to fix 4xx unfortunately broke 8xx build in a
couple of places. This fixes it.
Spotted by Olof Johansson
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
arch/powerpc/mm/mem.c |2 +-
arch/powerpc/mm/mmu_decl.h |2 +-
arch/ppc/mm/init.c |2 +-
arch/ppc/mm/mmu_decl.h |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 81eb96e..5402fb6 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -464,7 +464,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned
long address,
* we invalidate the TLB here, thus avoiding dcbst
* misbehaviour.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
!test_bit(PG_arch_1, page-flags)) {
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index eb3a732..ebfd13d 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -56,7 +56,7 @@ extern unsigned long total_lowmem;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0 /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram()(0UL)
diff --git a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
index 390dd19..dd898d3 100644
--- a/arch/ppc/mm/init.c
+++ b/arch/ppc/mm/init.c
@@ -561,7 +561,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned
long address,
* That means the zeroed TLB has to be invalidated
* whenever a page miss occurs.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
!test_bit(PG_arch_1, page-flags)) {
diff --git a/arch/ppc/mm/mmu_decl.h b/arch/ppc/mm/mmu_decl.h
index f1d4f21..b298b60 100644
--- a/arch/ppc/mm/mmu_decl.h
+++ b/arch/ppc/mm/mmu_decl.h
@@ -49,7 +49,7 @@ extern unsigned int num_tlbcam_entries;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0 /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram()(0UL)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc: hash lock use lock bitops
On Tue, 2007-11-20 at 07:26 +0100, Nick Piggin wrote: BTW, here is another thing which you might want to think about. Again untested for temporary lack of hardware. -- The radix-tree is now RCU safe, so powerpc can avoid the games it was playing in order to have a lockless readside. Saves an irq disable/enable, a couple of __get_cpu_var()s, a cacheline, and a memory barrier, in the fastpath. Should save a cycle or two... Yup, I know. I need to work on that for -rt anyway due to other issues... Thanks ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
