* Re: [PATCH 3/4] Holly DTS
From: David Gibson @ 2007-05-04 23:51 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1178302560.3026.210.camel@zod.rchland.ibm.com>
On Fri, May 04, 2007 at 01:16:00PM -0500, Josh Boyer wrote:
> Add Holly/Hickory DTS file
[...]
> + mdio@6000 {
> + name = "mdio";
> + device_type = "mdio";
> + compatible = "tsi-ethernet";
> + ethernet-phy@6000 {
> + name = "ethernet-phy";
> + device_type = "ethernet-phy";
> + reg = <6000 50>;
> + phy-id = <1>;
> + linux,phandle = <421>;
Kill the explicit phandles, please.
--
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
^ permalink raw reply
* Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Segher Boessenkool @ 2007-05-05 0:41 UTC (permalink / raw)
To: Linas Vepstas; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070504221309.GR6193@austin.ibm.com>
>> Well, Segher doesn't want me to use iobarrier (because it's not I/O).
>> Andy doesn't want me to use wmb() (because it's sync). I don't think
>> something like gfar_wmb() would be appropriate. So the remaining
>> options are either eieio(),
>
> ? Just curious... the original intent of eieio was to order I/O,
> such as MMIO; it has no effect on memory that isn't marked
> cache-inhibited or write-trhough or guarded. Has this changed?
eieio orders all accesses to address space that is WIMG=1xxx
or WIMG=x1x1; separately, it orders stores to address space
that is WIMG=001x.
> I guess I haven't kept up with the times ... is eieio now
> being used to provide some other kind of barrier?
Nothing changed.
> Is eieio providing some sort of SMP synchronization side-effect?
It orders stores to "well-behaved" memory yes.
> Point being: if Segher doesn't let you "use iobarrier (because
> it's not I/O)", then I don't understand why eieio would work (since
> that's for io only).
iobarrier() is a kernel-level primitive, meant for ordering
I/O only, as its name indicates. eieio is a CPU insn that
orders stores to main memory (amongst other things), not that
its name would tell you.
Segher
^ permalink raw reply
* Re: RFC: new device types in the device tree (RE: [PATCH] powerpc: Add EDAC platform devices for 85xx)
From: Segher Boessenkool @ 2007-05-05 0:07 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev, david, bluesmoke-devel
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA302D5E891@az33exm25.fsl.freescale.net>
>>> name is always optional (as defined by b-w-of.txt)
>>
>> Where does it say that? "name" is always required! In
>> the newer flat tree format, it's even impossible to
>> create a node without "name".
>
> I'm specifically referring to the "name" property. Here is
> what booting-without-of.txt says:
Okay, a few separate issues here...
> While earlier users of Open Firmware like OldWorld
> macintoshes tended to use the actual device name for
> the "name" property, it's nowadays considered a good
> practice to use a name that is closer to the device
> class (often equal to device_type)...
Yes, this is known as "generic names" -- it makes device
trees more readable and easier to use (on real OF). See
the "generic names" recommended practice document.
> [snip]... However,
> the kernel doesn't generally put any restriction on the
> "name" property; it is simply considered good practice
> to follow the standard and its evolutions as closely as
> possible.
When the kernel looks for a driver for a device node,
it should first consider "name" and after that the
entries in "compatible", in order.
Yes I know this is not what the kernel does most of
the time.
> Note also that the new format version 16 makes the
> "name" property optional. If it's absent for a node, then
> the node's unit name is then used to reconstruct the name.
> That is, the part of the unit name before the "@" sign
> is used (or the entire unit name if no "@" sign is present).
>
> If the name property is missing the kernel contructs it from
> the unit name.
So there _always_ is a "name" property. Who cares how
it is encoded in the DTB.
> I guess my point is the name property implies
> nothing and the kernel doesn't seem to care what name is used.
It does, in some cases. See the bindings for "isa" and "pci"
busses for example (for the bus nodes, not the device nodes
under those).
> It certainly doesn't imply a required set of properties.
That depends on the specific binding for the type of
device; in most cases, some binding specific properties
_are_ required.
Segher
^ permalink raw reply
* Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Olof Johansson @ 2007-05-04 23:24 UTC (permalink / raw)
To: Linas Vepstas; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070504221309.GR6193@austin.ibm.com>
On Fri, May 04, 2007 at 05:13:09PM -0500, Linas Vepstas wrote:
> On Wed, May 02, 2007 at 03:40:20PM -0500, Scott Wood wrote:
> >
> > Well, Segher doesn't want me to use iobarrier (because it's not I/O).
> > Andy doesn't want me to use wmb() (because it's sync). I don't think
> > something like gfar_wmb() would be appropriate. So the remaining
> > options are either eieio(),
>
> ? Just curious... the original intent of eieio was to order I/O,
> such as MMIO; it has no effect on memory that isn't marked
> cache-inhibited or write-trhough or guarded. Has this changed?
> I guess I haven't kept up with the times ... is eieio now
> being used to provide some other kind of barrier?
> Is eieio providing some sort of SMP synchronization side-effect?
>
> Point being: if Segher doesn't let you "use iobarrier (because
> it's not I/O)", then I don't understand why eieio would work (since
> that's for io only).
Eieio has always worked for regular cachable memory as well, it just never
orders _between_ cache inhibited/guarded and cachable memory.
Book II 2.03 has a pretty good description of it on page 367.
-Olof
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Benjamin Herrenschmidt @ 2007-05-04 22:25 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1HjzWH-0001Wg-Ps@jdl.com>
On Fri, 2007-05-04 at 10:16 -0500, Jon Loeliger wrote:
> So, like, the other day Benjamin Herrenschmidt mumbled:
> >
> > I still maintain it should be a runtime thing tho :-)
> >
> > Ben.
>
> So, could you comment on my proposed solution doing
> things exactly this way? Speifically, would folks
> prefer the dynamic
>
> number_of_cpus() == 1
Sorry I don't remember the actual patch, must have missed it... I
suppose we could have generic code in early_init_devtree set the default
for this based on cpu_possible_map() containing more than one bit and
have platforms using one of those broken bridges force the bit in from
their probe routine.
Ben.
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Robin Getz @ 2007-05-04 22:16 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070504205213.GQ22585@pengutronix.de>
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
> Robin,
>
> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
> > that would be nice to put in the "right" place - I don't think that
> > drivers/char is the right place, nor drivers/misc - I also don't think
> > that /adc is a descriptive place for DAC or mixed signal front ends
> > (MxFE).
>
> What userspace interface do your drivers have?
Right now, it is a little rudimentary char interface, it needs a little care
to be a bit more general purpose, but it suited needs of what the people who
were using it.
http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/?view=markup&path=/trunk/drivers/char/ad9960.c
> I don't think that there
> is anything generic available at the moment, other than COMEDI (which is
> rather outdated as far as I know).
I would be interested in having a detailed discussion/random thoughts on
this - what is the best way to expose these types of devices?
I never actually used COMEDI, to understand the pro/cons of what it did.
> > What about /drivers/char/daq or just drivers/daq - drivers for
> > non-PCI/USB/ISA/PCMCIA Data Acquisition Hardware, D/A and A/D
> > converters, Analog Front ends, etc.
>
> I'd like drivers/daq better, because it doesn't have anything to do with
> the bus it is connected to; a chipselect bus connectable ADC may be
> connected to a SoC CS-bus or to a PCI bridge and you want to use the
> same driver for it.
That makes sense - I have seen more and more parts with selectable interfaces
(I2C or SPI), and you should be able to use the same base driver, independent
of the bus - so drivers/daq would suite me fine.
-Robin
^ permalink raw reply
* Re: [PATCH v2] gianfar: Add I/O barriers when touching buffer descriptor ownership.
From: Linas Vepstas @ 2007-05-04 22:13 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <4638F734.2040809@freescale.com>
On Wed, May 02, 2007 at 03:40:20PM -0500, Scott Wood wrote:
>
> Well, Segher doesn't want me to use iobarrier (because it's not I/O).
> Andy doesn't want me to use wmb() (because it's sync). I don't think
> something like gfar_wmb() would be appropriate. So the remaining
> options are either eieio(),
? Just curious... the original intent of eieio was to order I/O,
such as MMIO; it has no effect on memory that isn't marked
cache-inhibited or write-trhough or guarded. Has this changed?
I guess I haven't kept up with the times ... is eieio now
being used to provide some other kind of barrier?
Is eieio providing some sort of SMP synchronization side-effect?
Point being: if Segher doesn't let you "use iobarrier (because
it's not I/O)", then I don't understand why eieio would work (since
that's for io only).
--linas
^ permalink raw reply
* [PATCH] Add common TSI 108 PCI header file
From: Josh Boyer @ 2007-05-04 21:42 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Add a header file for the common PCI routines used for the TSI bridge
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 5 --
arch/powerpc/sysdev/tsi108_pci.c | 1
include/asm-powerpc/tsi108_pci.h | 45 ++++++++++++++++++++++
3 files changed, 47 insertions(+), 4 deletions(-)
--- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ linux-2.6/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -41,6 +41,7 @@
#include <asm/reg.h>
#include <mm/mmu_decl.h>
#include "mpc7448_hpc2.h"
+#include <asm/tsi108_pci.h>
#include <asm/tsi108_irq.h>
#include <asm/mpic.h>
@@ -57,10 +58,7 @@ isa_mem_base = MPC7448_HPC2_ISA_MEM_BASE
pci_dram_offset = MPC7448_HPC2_PCI_MEM_OFFSET;
#endif
-extern int tsi108_setup_pci(struct device_node *dev);
extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
-extern void tsi108_pci_int_init(struct device_node *node);
-extern void tsi108_irq_cascade(unsigned int irq, struct irq_desc *desc);
int mpc7448_hpc2_exclude_device(u_char bus, u_char devfn)
{
@@ -210,7 +208,6 @@ static int __init mpc7448_hpc2_probe(voi
static int mpc7448_machine_check_exception(struct pt_regs *regs)
{
- extern void tsi108_clear_pci_cfg_error(void);
const struct exception_table_entry *entry;
/* Are we prepared to handle this fault */
--- linux-2.6.orig/arch/powerpc/sysdev/tsi108_pci.c
+++ linux-2.6/arch/powerpc/sysdev/tsi108_pci.c
@@ -35,6 +35,7 @@
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
#include <asm/tsi108.h>
+#include <asm/tsi108_pci.h>
#include <asm/tsi108_irq.h>
#include <asm/prom.h>
--- /dev/null
+++ linux-2.6/include/asm-powerpc/tsi108_pci.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright 2007 IBM Corp
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _ASM_PPC_TSI108_PCI_H
+#define _ASM_PPC_TSI108_PCI_H
+
+#include <asm/tsi108.h>
+
+/* Register definitions */
+#define TSI108_PCI_P2O_BAR0 (TSI108_PCI_OFFSET + 0x10)
+#define TSI108_PCI_P2O_BAR0_UPPER (TSI108_PCI_OFFSET + 0x14)
+#define TSI108_PCI_P2O_BAR2 (TSI108_PCI_OFFSET + 0x18)
+#define TSI108_PCI_P2O_BAR2_UPPER (TSI108_PCI_OFFSET + 0x1c)
+#define TSI108_PCI_P2O_PAGE_SIZES (TSI108_PCI_OFFSET + 0x4c)
+#define TSI108_PCI_PFAB_BAR0 (TSI108_PCI_OFFSET + 0x204)
+#define TSI108_PCI_PFAB_BAR0_UPPER (TSI108_PCI_OFFSET + 0x208)
+#define TSI108_PCI_PFAB_IO (TSI108_PCI_OFFSET + 0x20c)
+#define TSI108_PCI_PFAB_IO_UPPER (TSI108_PCI_OFFSET + 0x210)
+#define TSI108_PCI_PFAB_MEM32 (TSI108_PCI_OFFSET + 0x214)
+#define TSI108_PCI_PFAB_PFM3 (TSI108_PCI_OFFSET + 0x220)
+#define TSI108_PCI_PFAB_PFM4 (TSI108_PCI_OFFSET + 0x230)
+
+extern int tsi108_setup_pci(struct device_node *dev);
+extern void tsi108_pci_int_init(struct device_node *node);
+extern void tsi108_irq_cascade(unsigned int irq, struct irq_desc *desc);
+extern void tsi108_clear_pci_cfg_error(void);
+
+#endif /* _ASM_PPC_TSI108_PCI_H */
^ permalink raw reply
* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
From: Christoph Lameter @ 2007-05-04 21:21 UTC (permalink / raw)
To: Andrew Morton
Cc: gregkh, linux-kernel, linuxppc-dev, paulus, Christoph Lameter
In-Reply-To: <20070504130952.b43fc676.akpm@linux-foundation.org>
On Fri, 4 May 2007, Andrew Morton wrote:
> Better, we should be emitting loud warnigns which then disable themselves
> and then succeeding the allocation so that people can proceed with their
> kernel testing.
>
> When all the loud-warning sites have been fixed, we can take that code out
> again.
>
> The present situation is maximally tester-hostile.
i
SLUB: Allocate smallest object size if the user asks for 0 bytes.
Makes SLUB behave like SLAB in this area to avoid issues....
Throw a stack dump to alert people.
At some point the behavior should be switched back. NULL is no
memory as far as I can tell and if the use asked for 0 bytes then
he need to get no memory.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
include/linux/slub_def.h | 8 ++++++--
mm/slub.c | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-04 14:17:22.000000000 -0700
+++ slub/mm/slub.c 2007-05-04 14:19:36.000000000 -0700
@@ -2009,7 +2009,7 @@ static struct kmem_cache *get_slab(size_
{
int index = kmalloc_index(size);
- if (!size)
+ if (!index)
return NULL;
/* Allocation too large? */
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h 2007-05-04 14:13:40.000000000 -0700
+++ slub/include/linux/slub_def.h 2007-05-04 14:18:25.000000000 -0700
@@ -81,8 +81,12 @@ extern struct kmem_cache kmalloc_caches[
*/
static inline int kmalloc_index(int size)
{
- if (size == 0)
- return 0;
+ /*
+ * We should return 0 if size == 0 but we use the smallest object
+ * here for SLAB legacy reasons.
+ */
+ WARN_ON(size == 0);
+
if (size > 64 && size <= 96)
return 1;
if (size > 128 && size <= 192)
^ permalink raw reply
* [PATCH] powerpc: check cache coherency of kernel vs firmware
From: Dale Farnsworth @ 2007-05-04 21:16 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Stephen Rothwell, Paul Mackerras
In-Reply-To: <20070502215938.GF27253@xyzzy.farnsworth.org>
check_cache_coherency() verifies that the cache coherency setting of
the kernel (CONFIG_NOT_COHERENT_CACHE) matches that left by the firmware,
as indicated by coherency-off device tree property.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
New, improved! Now with matching config var names. Thanks Stephen.
arch/powerpc/Kconfig | 3 +
arch/powerpc/kernel/setup-common.c | 41 +++++++++++++++++++
arch/powerpc/platforms/embedded6xx/Kconfig | 1
3 files changed, 45 insertions(+)
Index: linux-2.6-powerpc-df/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6-powerpc-df/arch/powerpc/kernel/setup-common.c
@@ -530,3 +530,44 @@ void __init setup_panic(void)
{
atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
}
+
+#ifdef CONFIG_CHECK_CACHE_COHERENCY
+/*
+ * For platforms that have configurable cache-coherency. This function
+ * checks that the cache coherency setting of the kernel matches the setting
+ * left by the firmware, as indicated in the device tree. Since a mismatch
+ * will eventually result in DMA failures, we print * and error and call
+ * BUG() in that case.
+ */
+
+#ifdef CONFIG_NOT_COHERENT_CACHE
+#define KERNEL_COHERENCY 0
+#else
+#define KERNEL_COHERENCY 1
+#endif
+
+static int __init check_cache_coherency(void)
+{
+ struct device_node *np;
+ const void *prop;
+ int devtree_coherency;
+
+ np = of_find_node_by_path("/");
+ prop = of_get_property(np, "coherency-off", NULL);
+ of_node_put(np);
+
+ devtree_coherency = prop ? 0 : 1;
+
+ if (devtree_coherency != KERNEL_COHERENCY) {
+ printk(KERN_ERR
+ "kernel coherency:%s != device tree_coherency:%s\n",
+ KERNEL_COHERENCY ? "on" : "off",
+ devtree_coherency ? "on" : "off");
+ BUG();
+ }
+
+ return 0;
+}
+
+late_initcall(check_cache_coherency);
+#endif /* CONFIG_CHECK_CACHE_COHERENCY */
Index: linux-2.6-powerpc-df/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/Kconfig
@@ -373,6 +373,9 @@ config NOT_COHERENT_CACHE
bool
depends on 4xx || 8xx || E200
default y
+
+config CONFIG_CHECK_CACHE_COHERENCY
+ bool
endmenu
source "init/Kconfig"
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/embedded6xx/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -41,6 +41,7 @@ config MPC10X_BRIDGE
config MV64X60
bool
select PPC_INDIRECT_PCI
+ select CONFIG_CHECK_CACHE_COHERENCY
config MPC10X_OPENPIC
bool
^ permalink raw reply
* [PATCH 10/13] powerpc: Add Marvell mv64x60 PCI bridge support
From: Dale Farnsworth @ 2007-05-04 21:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070502214609.GE27253@xyzzy.farnsworth.org>
This patch adds PCI bridge support for the Marvell mv64x60 chip.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
I think I have addressed all of the issues raised by Arnd and Stephen.
arch/powerpc/platforms/embedded6xx/Kconfig | 1
arch/powerpc/sysdev/Makefile | 3
arch/powerpc/sysdev/mv64x60.h | 2
arch/powerpc/sysdev/mv64x60_pci.c | 172 +++++++++++++++++++
4 files changed, 177 insertions(+), 1 deletion(-)
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/Makefile
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
@@ -14,7 +14,8 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
-obj-$(CONFIG_MV64X60) += mv64x60_pic.o mv64x60_dev.o
+mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
+obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
# contains only the suspend handler for time
obj-$(CONFIG_PM) += timer.o
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60.h
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/mv64x60.h
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60.h
@@ -6,4 +6,6 @@
extern void __init mv64x60_init_irq(void);
extern unsigned int mv64x60_get_irq(void);
+extern void __init mv64x60_pci_init(void);
+
#endif /* __MV64X60_H__ */
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_pci.c
===================================================================
--- /dev/null
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_pci.c
@@ -0,0 +1,172 @@
+/*
+ * PCI bus setup for Marvell mv64360/mv64460 host bridges (Discovery)
+ *
+ * Author: Dale Farnsworth <dale@farnsworth.org>
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+
+#include <asm/prom.h>
+#include <asm/pci-bridge.h>
+
+#define PCI_HEADER_TYPE_INVALID 0x7f /* Invalid PCI header type */
+
+#ifdef CONFIG_SYSFS
+/* 32-bit hex or dec stringified number + '\n' */
+#define MV64X60_VAL_LEN_MAX 11
+#define MV64X60_PCICFG_CPCI_HOTSWAP 0x68
+
+static ssize_t mv64x60_hs_reg_read(struct kobject *kobj, char *buf, loff_t off,
+ size_t count)
+{
+ struct pci_dev *phb;
+ u32 v;
+
+ if (off > 0)
+ return 0;
+ if (count < MV64X60_VAL_LEN_MAX)
+ return -EINVAL;
+
+ phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ if (!phb)
+ return -ENODEV;
+ pci_read_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, &v);
+ pci_dev_put(phb);
+
+ return sprintf(buf, "0x%08x\n", v);
+}
+
+static ssize_t mv64x60_hs_reg_write(struct kobject *kobj, char *buf, loff_t off,
+ size_t count)
+{
+ struct pci_dev *phb;
+ u32 v;
+
+ if (off > 0)
+ return 0;
+ if (count <= 0)
+ return -EINVAL;
+
+ if (sscanf(buf, "%i", &v) != 1)
+ return -EINVAL;
+
+ phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ if (!phb)
+ return -ENODEV;
+ pci_write_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, v);
+ pci_dev_put(phb);
+
+ return count;
+}
+
+static struct bin_attribute mv64x60_hs_reg_attr = { /* Hotswap register */
+ .attr = {
+ .name = "hs_reg",
+ .mode = S_IRUGO | S_IWUSR,
+ .owner = THIS_MODULE,
+ },
+ .size = MV64X60_VAL_LEN_MAX,
+ .read = mv64x60_hs_reg_read,
+ .write = mv64x60_hs_reg_write,
+};
+
+static int __init mv64x60_sysfs_init(void)
+{
+ struct device_node *np;
+ struct platform_device *pdev;
+ const unsigned int *prop;
+
+ np = of_find_compatible_node(NULL, NULL, "mv64x60");
+ if (!np)
+ return 0;
+
+ prop = of_get_property(np, "hs_reg_valid", NULL);
+ of_node_put(np);
+
+ pdev = platform_device_register_simple("mv64x60", 0, NULL, 0);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return sysfs_create_bin_file(&pdev->dev.kobj, &mv64x60_hs_reg_attr);
+}
+
+subsys_initcall(mv64x60_sysfs_init);
+
+#endif /* CONFIG_SYSFS */
+
+static void __init mv64x60_pci_fixup_early(struct pci_dev *dev)
+{
+ /*
+ * Set the host bridge hdr_type to an invalid value so that
+ * pci_setup_device() will ignore the host bridge.
+ */
+ dev->hdr_type = PCI_HEADER_TYPE_INVALID;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360,
+ mv64x60_pci_fixup_early);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64460,
+ mv64x60_pci_fixup_early);
+
+static int __init mv64x60_add_bridge(struct device_node *dev)
+{
+ int len;
+ struct pci_controller *hose;
+ struct resource rsrc;
+ const int *bus_range;
+ int primary;
+
+ memset(&rsrc, 0, sizeof(rsrc));
+
+ /* Fetch host bridge registers address */
+ if (of_address_to_resource(dev, 0, &rsrc)) {
+ printk(KERN_ERR "No PCI reg property in device tree\n");
+ return -ENODEV;
+ }
+
+ /* Get bus range if any */
+ bus_range = of_get_property(dev, "bus-range", &len);
+ if (bus_range == NULL || len < 2 * sizeof(int))
+ printk(KERN_WARNING "Can't get bus-range for %s, assume"
+ " bus 0\n", dev->full_name);
+
+ hose = pcibios_alloc_controller();
+ if (!hose)
+ return -ENOMEM;
+
+ hose->arch_data = dev;
+ hose->set_cfg_type = 1;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ setup_indirect_pci(hose, rsrc.start, rsrc.start + 4);
+ hose->bus_offset = hose->first_busno;
+
+ printk(KERN_INFO "Found MV64x60 PCI host bridge at 0x%016llx. "
+ "Firmware bus number: %d->%d\n",
+ (unsigned long long)rsrc.start, hose->first_busno,
+ hose->last_busno);
+
+ /* Interpret the "ranges" property */
+ /* This also maps the I/O region and sets isa_io/mem_base */
+ primary = (hose->first_busno == 0);
+ pci_process_bridge_OF_ranges(hose, dev, primary);
+
+ return 0;
+}
+
+void __init mv64x60_pci_init(void)
+{
+ struct device_node *np = NULL;
+
+ while ((np = of_find_compatible_node(np, "pci", "mv64x60-pci")))
+ mv64x60_add_bridge(np);
+}
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/embedded6xx/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -40,6 +40,7 @@ config MPC10X_BRIDGE
config MV64X60
bool
+ select PPC_INDIRECT_PCI
config MPC10X_OPENPIC
bool
^ permalink raw reply
* [PATCH 9/13] powerpc: Create Marvell mv64x60 I2C platform_data
From: Dale Farnsworth @ 2007-05-04 21:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070502214416.GD27253@xyzzy.farnsworth.org>
This patch creates platform_device entries for the Marvell mv64x60
I2C ports, based on information contained in device tree.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
Latest rev. I think I've addressed all of Stephen's and Arnd's issues.
arch/powerpc/sysdev/mv64x60_dev.c | 74 +++++++++++++++++++++++++++-
1 file changed, 72 insertions(+), 2 deletions(-)
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_dev.c
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/mv64x60_dev.c
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_dev.c
@@ -323,14 +323,79 @@ error:
return err;
}
+/*
+ * Create mv64x60_i2c platform devices
+ */
+static int __init mv64x60_i2c_device_setup(struct device_node *np, int id)
+{
+ struct resource r[2];
+ struct platform_device *pdev;
+ struct mv64xxx_i2c_pdata pdata;
+ const unsigned int *prop;
+ int err;
+
+ memset(&r, 0, sizeof(r));
+
+ err = of_address_to_resource(np, 0, &r[0]);
+ if (err)
+ return err;
+
+ of_irq_to_resource(np, 0, &r[1]);
+
+ memset(&pdata, 0, sizeof(pdata));
+
+ prop = of_get_property(np, "freq_m", NULL);
+ if (!prop)
+ return -ENODEV;
+ pdata.freq_m = *prop;
+
+ prop = of_get_property(np, "freq_n", NULL);
+ if (!prop)
+ return -ENODEV;
+ pdata.freq_n = *prop;
+
+ prop = of_get_property(np, "timeout", NULL);
+ if (prop)
+ pdata.timeout = *prop;
+ else
+ pdata.timeout = 1000; /* 1 second */
+
+ prop = of_get_property(np, "retries", NULL);
+ if (prop)
+ pdata.retries = *prop;
+ else
+ pdata.retries = 1;
+
+ pdev = platform_device_alloc(MV64XXX_I2C_CTLR_NAME, id);
+ if (!pdev)
+ return -ENOMEM;
+
+ err = platform_device_add_resources(pdev, r, 2);
+ if (err)
+ goto error;
+
+ err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto error;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto error;
+
+ return 0;
+
+error:
+ platform_device_put(pdev);
+ return err;
+}
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
int id;
int err;
- for (id = 0;
- (np = of_find_compatible_node(np, "serial", "mpsc")); id++)
+ for (id = 0; (np = of_find_compatible_node(np, "serial", "mpsc")); id++)
if ((err = mv64x60_mpsc_device_setup(np, id)))
goto error;
@@ -339,6 +404,11 @@ static int __init mv64x60_device_setup(v
if ((err = mv64x60_eth_device_setup(np, id)))
goto error;
+ for (id = 0;
+ (np = of_find_compatible_node(np, "i2c", "mv64x60-i2c")); id++)
+ if ((err = mv64x60_i2c_device_setup(np, id)))
+ goto error;
+
return 0;
error:
^ permalink raw reply
* [PATCH 8/13] powerpc: Create Marvell mv64x60 ethernet platform_data
From: Dale Farnsworth @ 2007-05-04 21:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070502214312.GC27253@xyzzy.farnsworth.org>
This patch creates platform_device entries for the Marvell mv64x60
ethernet controller ports, based on information contained in the
device tree.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
Latest rev. I think I've addressed all of Stephen Rothwell's and
Arnd Bergmann's comments. Thanks.
arch/powerpc/sysdev/mv64x60_dev.c | 129 +++++++++++++++++++++++++++-
drivers/net/Kconfig | 2
2 files changed, 129 insertions(+), 2 deletions(-)
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_dev.c
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/mv64x60_dev.c
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_dev.c
@@ -201,6 +201,128 @@ error:
return err;
}
+/*
+ * Create mv64x60_eth platform devices
+ */
+static int __init eth_register_shared_pdev(struct device_node *np)
+{
+ struct platform_device *pdev;
+ struct resource r[1];
+ int err;
+
+ np = of_get_parent(np);
+ if (!np)
+ return -ENODEV;
+
+ err = of_address_to_resource(np, 0, &r[0]);
+ of_node_put(np);
+ if (err)
+ return err;
+
+ pdev = platform_device_register_simple(MV643XX_ETH_SHARED_NAME, 0,
+ r, 1);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+static int __init mv64x60_eth_device_setup(struct device_node *np, int id)
+{
+ struct resource r[1];
+ struct mv643xx_eth_platform_data pdata;
+ struct platform_device *pdev;
+ struct device_node *phy;
+ const u8 *mac_addr;
+ const int *prop;
+ const phandle *ph;
+ int err;
+
+ /* only register the shared platform device the first time through */
+ if (id == 0 && (err = eth_register_shared_pdev(np)))
+ return err;;
+
+ memset(r, 0, sizeof(r));
+ of_irq_to_resource(np, 0, &r[0]);
+
+ memset(&pdata, 0, sizeof(pdata));
+
+ prop = of_get_property(np, "block-index", NULL);
+ if (!prop)
+ return -ENODEV;
+ pdata.port_number = *prop;
+
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata.mac_addr, mac_addr, 6);
+
+ prop = of_get_property(np, "speed", NULL);
+ if (prop)
+ pdata.speed = *prop;
+
+ prop = of_get_property(np, "tx_queue_size", NULL);
+ if (prop)
+ pdata.tx_queue_size = *prop;
+
+ prop = of_get_property(np, "rx_queue_size", NULL);
+ if (prop)
+ pdata.rx_queue_size = *prop;
+
+ prop = of_get_property(np, "tx_sram_addr", NULL);
+ if (prop)
+ pdata.tx_sram_addr = *prop;
+
+ prop = of_get_property(np, "tx_sram_size", NULL);
+ if (prop)
+ pdata.tx_sram_size = *prop;
+
+ prop = of_get_property(np, "rx_sram_addr", NULL);
+ if (prop)
+ pdata.rx_sram_addr = *prop;
+
+ prop = of_get_property(np, "rx_sram_size", NULL);
+ if (prop)
+ pdata.rx_sram_size = *prop;
+
+ ph = of_get_property(np, "phy", NULL);
+ if (!ph)
+ return -ENODEV;
+
+ phy = of_find_node_by_phandle(*ph);
+ if (phy == NULL)
+ return -ENODEV;
+
+ prop = of_get_property(phy, "reg", NULL);
+ if (prop) {
+ pdata.force_phy_addr = 1;
+ pdata.phy_addr = *prop;
+ }
+
+ of_node_put(phy);
+
+ pdev = platform_device_alloc(MV643XX_ETH_NAME, pdata.port_number);
+ if (!pdev)
+ return -ENOMEM;
+
+ err = platform_device_add_resources(pdev, r, 1);
+ if (err)
+ goto error;
+
+ err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto error;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto error;
+
+ return 0;
+
+error:
+ platform_device_put(pdev);
+ return err;
+}
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
@@ -212,6 +334,11 @@ static int __init mv64x60_device_setup(v
if ((err = mv64x60_mpsc_device_setup(np, id)))
goto error;
+ for (id = 0;
+ (np = of_find_compatible_node(np, "network", "mv64x60-eth")); id++)
+ if ((err = mv64x60_eth_device_setup(np, id)))
+ goto error;
+
return 0;
error:
Index: linux-2.6-powerpc-df/drivers/net/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/drivers/net/Kconfig
+++ linux-2.6-powerpc-df/drivers/net/Kconfig
@@ -2299,7 +2299,7 @@ config UGETH_TX_ON_DEMAND
config MV643XX_ETH
tristate "MV-643XX Ethernet support"
- depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MOMENCO_OCELOT_3 || (PPC_MULTIPLATFORM && PPC32)
+ depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MV64X60 || MOMENCO_OCELOT_3 || (PPC_MULTIPLATFORM && PPC32)
select MII
help
This driver supports the gigabit Ethernet on the Marvell MV643XX
^ permalink raw reply
* [PATCH 7/13] powerpc: Create Marvell mv64x60 MPSC (serial) platform_data
From: Dale Farnsworth @ 2007-05-04 21:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070502214104.GB27253@xyzzy.farnsworth.org>
This patch creates platform_device entries for the Marvell mv64x60
MPSC (multi-protocol serial controller) ports, based on information
contained in the device tree.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
Latest rev. I believe I have address all the issues raised by
Stephen Rothwell and Arnd Bergmann.
arch/powerpc/platforms/embedded6xx/Kconfig | 3
arch/powerpc/sysdev/Makefile | 2
arch/powerpc/sysdev/mv64x60_dev.c | 221 +++++++++++++++++++
3 files changed, 225 insertions(+), 1 deletion(-)
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_dev.c
===================================================================
--- /dev/null
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_dev.c
@@ -0,0 +1,221 @@
+/*
+ * Platform device setup for Marvell mv64360/mv64460 host bridges (Discovery)
+ *
+ * Author: Dale Farnsworth <dale@farnsworth.org>
+ *
+ * 2007 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/mv643xx.h>
+#include <linux/platform_device.h>
+
+#include <asm/prom.h>
+
+/*
+ * These functions provide the necessary setup for the mv64x60 drivers.
+ * These drivers are unusual in that they work on both the MIPS and PowerPC
+ * architectures. Because of that, the drivers do not support the normal
+ * PowerPC of_platform_bus_type. They support platform_bus_type instead.
+ */
+
+/*
+ * Create MPSC platform device
+ */
+static int __init mv64x60_mpsc_register_shared_pdev(struct device_node *np)
+{
+ struct platform_device *pdev;
+ struct resource r[2];
+ struct mpsc_shared_pdata pdata;
+ const phandle *ph;
+ struct device_node *mpscrouting, *mpscintr;
+ int err;
+
+ ph = of_get_property(np, "mpscrouting", NULL);
+ mpscrouting = of_find_node_by_phandle(*ph);
+ if (!mpscrouting)
+ return -ENODEV;
+
+ err = of_address_to_resource(mpscrouting, 0, &r[0]);
+ of_node_put(mpscrouting);
+ if (err)
+ return err;
+
+ ph = of_get_property(np, "mpscintr", NULL);
+ mpscintr = of_find_node_by_phandle(*ph);
+ if (!mpscintr)
+ return -ENODEV;
+
+ err = of_address_to_resource(mpscintr, 0, &r[1]);
+ of_node_put(mpscintr);
+ if (err)
+ return err;
+
+ memset(&pdata, 0, sizeof(pdata));
+
+ pdev = platform_device_alloc(MPSC_SHARED_NAME, 0);
+ if (!pdev)
+ return -ENOMEM;
+
+ err = platform_device_add_resources(pdev, r, 2);
+ if (err)
+ goto error;
+
+ err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto error;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto error;
+
+ return 0;
+
+error:
+ platform_device_put(pdev);
+ return err;
+}
+
+
+static int __init mv64x60_mpsc_device_setup(struct device_node *np, int id)
+{
+ struct resource r[5];
+ struct mpsc_pdata pdata;
+ struct platform_device *pdev;
+ const unsigned int *prop;
+ const phandle *ph;
+ struct device_node *sdma, *brg;
+ int err;
+ int port_number;
+
+ /* only register the shared platform device the first time through */
+ if (id == 0 && (err = mv64x60_mpsc_register_shared_pdev(np)))
+ return err;
+
+ memset(&r, 0, sizeof(r));
+
+ err = of_address_to_resource(np, 0, &r[0]);
+ if (err)
+ return err;
+
+ of_irq_to_resource(np, 0, &r[4]);
+
+ ph = of_get_property(np, "sdma", NULL);
+ sdma = of_find_node_by_phandle(*ph);
+ if (!sdma)
+ return -ENODEV;
+
+ of_irq_to_resource(sdma, 0, &r[3]);
+ err = of_address_to_resource(sdma, 0, &r[1]);
+ of_node_put(sdma);
+ if (err)
+ return err;
+
+ ph = of_get_property(np, "brg", NULL);
+ brg = of_find_node_by_phandle(*ph);
+ if (!brg)
+ return -ENODEV;
+
+ err = of_address_to_resource(brg, 0, &r[2]);
+ of_node_put(brg);
+ if (err)
+ return err;
+
+ prop = of_get_property(np, "block-index", NULL);
+ if (!prop)
+ return -ENODEV;
+ port_number = *(int *)prop;
+
+ memset(&pdata, 0, sizeof(pdata));
+
+ pdata.cache_mgmt = 1; /* All current revs need this set */
+
+ prop = of_get_property(np, "max_idle", NULL);
+ if (prop)
+ pdata.max_idle = *prop;
+
+ prop = of_get_property(brg, "current-speed", NULL);
+ if (prop)
+ pdata.default_baud = *prop;
+
+ /* Default is 8 bits, no parity, no flow control */
+ pdata.default_bits = 8;
+ pdata.default_parity = 'n';
+ pdata.default_flow = 'n';
+
+ prop = of_get_property(np, "chr_1", NULL);
+ if (prop)
+ pdata.chr_1_val = *prop;
+
+ prop = of_get_property(np, "chr_2", NULL);
+ if (prop)
+ pdata.chr_2_val = *prop;
+
+ prop = of_get_property(np, "chr_10", NULL);
+ if (prop)
+ pdata.chr_10_val = *prop;
+
+ prop = of_get_property(np, "mpcr", NULL);
+ if (prop)
+ pdata.mpcr_val = *prop;
+
+ prop = of_get_property(brg, "bcr", NULL);
+ if (prop)
+ pdata.bcr_val = *prop;
+
+ pdata.brg_can_tune = 1; /* All current revs need this set */
+
+ prop = of_get_property(brg, "clock-src", NULL);
+ if (prop)
+ pdata.brg_clk_src = *prop;
+
+ prop = of_get_property(brg, "clock-frequency", NULL);
+ if (prop)
+ pdata.brg_clk_freq = *prop;
+
+ pdev = platform_device_alloc(MPSC_CTLR_NAME, port_number);
+ if (!pdev)
+ return -ENOMEM;
+
+ err = platform_device_add_resources(pdev, r, 5);
+ if (err)
+ goto error;
+
+ err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto error;
+
+ err = platform_device_add(pdev);
+ if (err)
+ goto error;
+
+ return 0;
+
+error:
+ platform_device_put(pdev);
+ return err;
+}
+
+static int __init mv64x60_device_setup(void)
+{
+ struct device_node *np = NULL;
+ int id;
+ int err;
+
+ for (id = 0;
+ (np = of_find_compatible_node(np, "serial", "mpsc")); id++)
+ if ((err = mv64x60_mpsc_device_setup(np, id)))
+ goto error;
+
+ return 0;
+
+error:
+ of_node_put(np);
+ return err;
+}
+arch_initcall(mv64x60_device_setup);
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/Makefile
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
-obj-$(CONFIG_MV64X60) += mv64x60_pic.o
+obj-$(CONFIG_MV64X60) += mv64x60_pic.o mv64x60_dev.o
# contains only the suspend handler for time
obj-$(CONFIG_PM) += timer.o
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/embedded6xx/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -38,6 +38,9 @@ config MPC10X_BRIDGE
select PPC_INDIRECT_PCI
default y
+config MV64X60
+ bool
+
config MPC10X_OPENPIC
bool
depends on LINKSTATION
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Robert Schwebel @ 2007-05-04 20:52 UTC (permalink / raw)
To: Robin Getz; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200705041421.50830.rgetz@blackfin.uclinux.org>
Robin,
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
> We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
> that would be nice to put in the "right" place - I don't think that
> drivers/char is the right place, nor drivers/misc - I also don't think
> that /adc is a descriptive place for DAC or mixed signal front ends
> (MxFE).
What userspace interface do your drivers have? I don't think that there
is anything generic available at the moment, other than COMEDI (which is
rather outdated as far as I know).
> What about /drivers/char/daq or just drivers/daq - drivers for
> non-PCI/USB/ISA/PCMCIA Data Acquisition Hardware, D/A and A/D
> converters, Analog Front ends, etc.
I'd like drivers/daq better, because it doesn't have anything to do with
the bus it is connected to; a chipselect bus connectable ADC may be
connected to a SoC CS-bus or to a PCI bridge and you want to use the
same driver for it.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Kumar Gala @ 2007-05-04 20:19 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178187440.20944.12.camel@localhost.localdomain>
On May 3, 2007, at 5:17 AM, Adrian Cox wrote:
> On Wed, 2007-05-02 at 16:34 -0500, Jon Loeliger wrote:
>> From: James.Yang <James.Yang@freescale.com>
>>
>> Remove CPU_FTR_NEED_COHERENT for MPC7448 (and single-core MPC86xx).
>> This prevents needlessly setting M=1 when not SMP.
>
> There may be side effects to removing this. Most of the 74xx
> processors
> had this flag added because of the L2 prefetch bug (erratum #16 on the
> 7447A). I see that bug is missing from the 7448 errata.
>
> The problem is that many 32-bit PowerPC machines needed
> CPU_FTR_NEED_COHERENT set for a second reason: compatibility with the
> cache in the MPC107. This was handled by CPU_FTR_COMMON in cputable.h
> before the L2 prefetch bug was known. There may be other host bridges
> that cache, but nobody will have noticed because all the CPUs had
> CPU_FTR_NEED_COHERENT set already.
While this may be the case for non-10X bridges I don't think we
should impose the restriction if we don't know its actually needed.
- k
^ permalink raw reply
* Re: [PATCH] Xilinx framebuffer device driver - 4th version
From: Antonino A. Daplas @ 2007-05-04 20:19 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linux-fbdev-devel, linuxppc-embedded
In-Reply-To: <463B504C.5050500@ru.mvista.com>
On Fri, 2007-05-04 at 19:25 +0400, Andrei Konovalov wrote:
> Add support for the video controller IP block included into Xilinx ML300
> and ML403 reference designs.
>
My tree does not have arch/ppc/syslib/virtex_devices.h. Either I wait
for that to be merged to the -mm or mainline tree, or you can submit
this driver yourself with the platform-specific changes. Either way:
> Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
Acked-by: Antonino Daplas <adaplas@gmail.com>
Tony
^ permalink raw reply
* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
From: Andrew Morton @ 2007-05-04 20:09 UTC (permalink / raw)
To: Andy Whitcroft
Cc: linuxppc-dev, gregkh, paulus, linux-kernel, Christoph Lameter
In-Reply-To: <4fe4528cb20beb569a8f2ac817c776e5@pinky>
On Fri, 04 May 2007 12:38:58 +0100
Andy Whitcroft <apw@shadowen.org> wrote:
>
> Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
> bit of a challenge. We have been seeing panics on boot from the
> hvsi driver:
>
> Couldn't register hvsi console driver
>
> Tracking this back, this seems to come from hvsi driver trying to
> register itself via tty_register_driver() with a zero units.
>
> The failure is triggered by a change in semantics for kmalloc()
> between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
> allocation at the smallest size. Looking at the code in question
> even when the allocation succeeds we will not actually use the
> memory when device->num is zero.
OK, thanks for working that out.
Christoph, we should be emitting loud warnings so that this problem is easy
to debug.
Better, we should be emitting loud warnigns which then disable themselves
and then succeeding the allocation so that people can proceed with their
kernel testing.
When all the loud-warning sites have been fixed, we can take that code out
again.
The present situation is maximally tester-hostile.
> It is not clear to me if this is a bug in the hvsi driver in that
> it should specify some units. It seems we will try and reserve zero
> devices in this case, which seems pointless.
>
> I have tested with the patch below which seems safe to me and stops
> the errors and even seems to make the console work. But perhaps
> someone with more driver fu, could verify if driver->num of zero
> has any meaning and kick this to the hvsi people if not.
>
> -apw
>
> === 8< ===
> tty_register_driver: only allocate tty instances when defined
>
> If device->num is zero we attempt to kmalloc() zero bytes.
> When SLUB is enabled this returns a null pointer and take that as
> an allocation failure and fail the device register. Check for no
> devices and avoid the allocation.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
> ---
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index 959a616..71c4579 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -3724,7 +3724,7 @@ int tty_register_driver(struct tty_driver *driver)
> if (driver->flags & TTY_DRIVER_INSTALLED)
> return 0;
>
> - if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
> + if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM) && driver->num) {
> p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
> if (!p)
> return -ENOMEM;
^ permalink raw reply
* Re: [PATCH 1/4] Add support for 750CL Holly board
From: Josh Boyer @ 2007-05-04 20:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705042144.31194.arnd@arndb.de>
On Fri, 2007-05-04 at 21:44 +0200, Arnd Bergmann wrote:
> On Friday 04 May 2007, Josh Boyer wrote:
> > +
> > +#undef DEBUG
> > +#ifdef DEBUG
> > +#define DBG(fmt...) do { printk(fmt); } while(0)
> > +#else
> > +#define DBG(fmt...) do { } while(0)
> > +#endif
>
> Please replace this with the generic pr_debug()
Already noted, but yes.
> > +extern int tsi108_setup_pci(struct device_node *dev);
> > +extern void tsi108_pci_int_init(struct device_node *node);
> > +extern void tsi108_irq_cascade(unsigned int irq, struct irq_desc *desc);
>
> please move any extern declarations into a header file that
> is included by both the file that defines and uses them
Ok.
>
> > +static void holly_remap_bridge(void)
> > +{
> > + u32 lut_val, lut_addr = 0x900, misc_cfg;
> > + int i;
> > +
> > + printk(KERN_ERR "Remapping PCI bridge\n");
>
> Is it an error to remap the bridge? If not, KERN_INFO would be more
> appropriate ;-)
This whole function is under work at the moment, so it'll get cleaned
up.
>
> > +void holly_show_cpuinfo(struct seq_file *m)
> > +{
> > + seq_printf(m, "vendor\t\t: IBM\n");
> > + seq_printf(m, "machine\t\t: PPC750 GX/CL\n");
> > +}
>
> If it's an IBM product, it should come with a product code like 123-4567,
> which fits in here, instead of just listing the CPU.
Erm... why? There are other boards that don't do this as well...
>
> > +static int ppc750_machine_check_exception(struct pt_regs *regs)
> > +{
> > + extern void tsi108_clear_pci_cfg_error(void);
>
> move declaration to header file.
Ok.
>
> > + const struct exception_table_entry *entry;
> > +
> > + /* Are we prepared to handle this fault */
> > + if ((entry = search_exception_tables(regs->nip)) != NULL) {
> > + tsi108_clear_pci_cfg_error();
> > + regs->msr |= MSR_RI;
> > + regs->nip = entry->fixup;
> > + return 1;
> > + }
> > + return 0;
> > +}
>
> Are you sure that you can use the generic exception table mechanism
> like this? I can't see why it doesn't work, but it's something I haven't
> seen anyone do like this.
Yes, this works and is actually required. See tsi108_pci.c for where
the fixup/exception table information is generated.
> > --- linux-2.6.orig/drivers/net/tsi108_eth.h
> > +++ linux-2.6/drivers/net/tsi108_eth.h
> > @@ -49,7 +49,11 @@
> > */
> > #define PHY_MV88E 1 /* Marvel 88Exxxx PHY */
> > #define PHY_BCM54XX 2 /* Broardcom BCM54xx PHY */
> > +#if defined(CONFIG_HOLLY)
> > +#define TSI108_PHY_TYPE PHY_BCM54XX
> > +#else
> > #define TSI108_PHY_TYPE PHY_MV88E
> > +#endif
> >
>
> this breaks multiplatform setups.
I know. Looking for a better suggestions. Kumar suggested a Kconfig
option at least, which is what I'm going to go with unless someone has a
better idea...
josh
^ permalink raw reply
* Re: [PATCH 1/4] Add support for 750CL Holly board
From: Arnd Bergmann @ 2007-05-04 19:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1178302469.3026.204.camel@zod.rchland.ibm.com>
On Friday 04 May 2007, Josh Boyer wrote:
> +
> +#undef DEBUG
> +#ifdef DEBUG
> +#define DBG(fmt...) do { printk(fmt); } while(0)
> +#else
> +#define DBG(fmt...) do { } while(0)
> +#endif
Please replace this with the generic pr_debug()
> +#ifndef CONFIG_PCI
> +pci_dram_offset = PPC750GXCL_TSI_PCI_MEM_OFFSET;
> +#endif
This looks like the compile would expect a type.
> +extern int tsi108_setup_pci(struct device_node *dev);
> +extern void tsi108_pci_int_init(struct device_node *node);
> +extern void tsi108_irq_cascade(unsigned int irq, struct irq_desc *desc);
please move any extern declarations into a header file that
is included by both the file that defines and uses them
> +static void holly_remap_bridge(void)
> +{
> + u32 lut_val, lut_addr = 0x900, misc_cfg;
> + int i;
> +
> + printk(KERN_ERR "Remapping PCI bridge\n");
Is it an error to remap the bridge? If not, KERN_INFO would be more
appropriate ;-)
> +void holly_show_cpuinfo(struct seq_file *m)
> +{
> + seq_printf(m, "vendor\t\t: IBM\n");
> + seq_printf(m, "machine\t\t: PPC750 GX/CL\n");
> +}
If it's an IBM product, it should come with a product code like 123-4567,
which fits in here, instead of just listing the CPU.
> +static int ppc750_machine_check_exception(struct pt_regs *regs)
> +{
> + extern void tsi108_clear_pci_cfg_error(void);
move declaration to header file.
> + const struct exception_table_entry *entry;
> +
> + /* Are we prepared to handle this fault */
> + if ((entry = search_exception_tables(regs->nip)) != NULL) {
> + tsi108_clear_pci_cfg_error();
> + regs->msr |= MSR_RI;
> + regs->nip = entry->fixup;
> + return 1;
> + }
> + return 0;
> +}
Are you sure that you can use the generic exception table mechanism
like this? I can't see why it doesn't work, but it's something I haven't
seen anyone do like this.
> --- linux-2.6.orig/drivers/net/tsi108_eth.h
> +++ linux-2.6/drivers/net/tsi108_eth.h
> @@ -49,7 +49,11 @@
> */
> #define PHY_MV88E 1 /* Marvel 88Exxxx PHY */
> #define PHY_BCM54XX 2 /* Broardcom BCM54xx PHY */
> +#if defined(CONFIG_HOLLY)
> +#define TSI108_PHY_TYPE PHY_BCM54XX
> +#else
> #define TSI108_PHY_TYPE PHY_MV88E
> +#endif
>
this breaks multiplatform setups.
> --- linux-2.6.orig/include/asm-powerpc/tsi108.h
> +++ linux-2.6/include/asm-powerpc/tsi108.h
> @@ -68,7 +68,11 @@
> #define TSI108_PB_ERRCS_ES (1 << 1)
> #define TSI108_PB_ISR_PBS_RD_ERR (1 << 8)
>
> +#ifdef CONFIG_HOLLY
> +#define TSI108_PCI_CFG_BASE_PHYS (0x7c000000)
> +#else
> #define TSI108_PCI_CFG_BASE_PHYS (0xfb000000)
> +#endif
> #define TSI108_PCI_CFG_SIZE (0x01000000)
> /* Global variables */
>
Same here.
Arnd <><
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Andrew Morton @ 2007-05-04 19:35 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <20070503235747.29275.37271.stgit@localhost.localdomain>
On Fri, 04 May 2007 03:57:51 +0400
Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> Adds support for PowerQuicc on-chip PCMCIA. The driver is implemented as
> of_device, so only arch/powerpc stuff is capable to use it, which now
> implies only mpc885ads reference board.
>
> To cope with the code that should be hooked inside driver, but is really
> board specific (like set_voltage), global structure mpc8xx_pcmcia_ops
> holds necessary function pointers that are filled in the BSP code.
>
argh.
akpm:/home/akpm> grep '^.* ' x | wc -l
72
please, Linux uses hard-tabs, not spacespacespacespacespacespacespacespace
everywhere.
> +
> cpm@ff000000 {
> linux,phandle = <ff000000>;
> #address-cells = <1>;
> diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
> index 0901dba..f169355 100644
> --- a/arch/powerpc/platforms/8xx/m8xx_setup.c
> +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> @@ -32,6 +32,7 @@
> #include <linux/root_dev.h>
> #include <linux/time.h>
> #include <linux/rtc.h>
> +#include <linux/fsl_devices.h>
>
> #include <asm/mmu.h>
> #include <asm/reg.h>
> @@ -49,6 +50,10 @@
>
> #include "sysdev/mpc8xx_pic.h"
>
> +#ifdef CONFIG_PCMCIA_M8XX
> +struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
> +#endif
Please declare this in a header file.
> +/* Some internal interrupt registers use an 8-bit mask for the interrupt
> + * level instead of a number.
> + */
Standard Linux commenting style is:
/*
* Some internal interrupt registers use an 8-bit mask for the interrupt
* level instead of a number.
*/
> +#define mk_int_int_mask(IL) (1 << (7 - (IL/2)))
Insufficiently parenthesised?
static inline functions are preferred.
> +#ifdef CONFIG_PCMCIA_M8XX
> +extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
Please don't ever put extern declarations in C files. Declare it in a
header, include that header in the C file which contains the definition as
well as within all C files which use the symbol.
> +static void pcmcia_hw_setup(int slot, int enable);
> +static int pcmcia_set_voltage(int slot, int vcc, int vpp);
> +#endif
> +
> void __init mpc885ads_board_setup(void)
> {
> cpm8xx_t *cp;
> @@ -115,6 +122,12 @@ void __init mpc885ads_board_setup(void)
> immr_unmap(io_port);
>
> #endif
> +
> +#ifdef CONFIG_PCMCIA_M8XX
> + /*Set up board specific hook-ups*/
> + m8xx_pcmcia_ops.hw_ctrl = pcmcia_hw_setup;
> + m8xx_pcmcia_ops.voltage_set = pcmcia_set_voltage;
> +#endif
> }
>
>
> @@ -322,6 +335,70 @@ void init_smc_ioports(struct fs_uart_platform_info *data)
> }
> }
>
> +#ifdef CONFIG_PCMCIA_M8XX
> +static void pcmcia_hw_setup(int slot, int enable)
> +{
> + unsigned *bcsr_io;
> +
> + bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
> + if (enable)
> + clrbits32(bcsr_io, BCSR1_PCCEN);
> + else
> + setbits32(bcsr_io, BCSR1_PCCEN);
Missing a tab.
> + iounmap(bcsr_io);
> +}
> +
> +static int pcmcia_set_voltage(int slot, int vcc, int vpp)
> +{
> + u32 reg = 0;
> + unsigned *bcsr_io;
> +
> + bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
> +
> + switch(vcc) {
> + case 0:
> + break;
> + case 33:
> + reg |= BCSR1_PCCVCC0;
> + break;
> + case 50:
> + reg |= BCSR1_PCCVCC1;
> + break;
> + default:
> + return 1;
> + }
Standard Linux layout for switch statements is:
switch(vcc) {
case 0:
break;
case 33:
reg |= BCSR1_PCCVCC0;
break;
case 50:
reg |= BCSR1_PCCVCC1;
break;
default:
return 1;
}
> + switch(vpp) {
> + case 0:
> + break;
> + case 33:
> + case 50:
> + if(vcc == vpp)
> + reg |= BCSR1_PCCVPP1;
> + else
> + return 1;
> + break;
> + case 120:
> + if ((vcc == 33) || (vcc == 50))
> + reg |= BCSR1_PCCVPP0;
> + else
> + return 1;
> + default:
> + return 1;
> + }
Ditto.
> + /* first, turn off all power */
> + clrbits32(bcsr_io, 0x00610000);
> +
> + /* enable new powersettings */
> + setbits32(bcsr_io, reg);
> +
> + iounmap(bcsr_io);
> + return 0;
> +}
> +#endif
> +
> int platform_device_skip(const char *model, int id)
> {
> #ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
> index 8a123c7..01e4a40 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -1028,6 +1028,18 @@ err:
>
> arch_initcall(fs_enet_of_init);
>
> +static int __init fsl_pcmcia_of_init(void)
> +{
> + struct device_node *np = NULL;
> + /*
> + * Register all the devices which type is "pcmcia"
> + */
> + while ((np = of_find_compatible_node(np, "pcmcia", "fsl,pq-pcmcia")) != NULL)
> + of_platform_device_create(np, "m8xx-pcmcia", NULL);
please try to fit code into 80 columns.
>
> -static DEFINE_SPINLOCK(events_lock);
> +static spinlock_t events_lock = SPIN_LOCK_UNLOCKED;
This is wrong. DEFINE_SPINLOCK is required for correct lockdep operation.
> +#define hardware_enable(_slot_) m8xx_pcmcia_ops.hw_ctrl(_slot_, 1)
> +#define hardware_disable(_slot_) m8xx_pcmcia_ops.hw_ctrl(_slot_, 0)
> +#define voltage_set(slot, vcc, vpp) m8xx_pcmcia_ops.voltage_set(slot, vcc, vpp)
static inline functions are preferred. One reason is that people are more
inclined to add comments to them than to macros.
> -static DEFINE_SPINLOCK(pending_event_lock);
> +static spinlock_t pending_event_lock = SPIN_LOCK_UNLOCKED;
again, you added a bug.
> + for(i = 0; i < PCMCIA_SOCKETS_NO; i++){
No, we format `for' statements as:
for (i = 0; i < PCMCIA_SOCKETS_NO; i++) {
> + w = (void *) &pcmcia->pcmc_pbr0;
>
> + out_be32(&pcmcia->pcmc_pscr, M8XX_PCMCIA_MASK(i));
> + out_be32(&pcmcia->pcmc_per, in_be32(&pcmcia->pcmc_per) & ~M8XX_PCMCIA_MASK(i));
80-cols
> +
> + /* turn off interrupt and disable CxOE */
> + out_be32(M8XX_PGCRX(i), M8XX_PGCRX_CXOE);
> +
> + /* turn off memory windows */
> + for(m = 0; m < PCMCIA_MEM_WIN_NO; m++) {
formatting
> + out_be32(&w->or, 0); /* set to not valid */
> + w++;
> + }
> +
> + /* turn off voltage */
> + voltage_set(i, 0, 0);
> +
> + /* disable external hardware */
> + hardware_disable(i);
> + }
> for (i = 0; i < PCMCIA_SOCKETS_NO; i++)
> pcmcia_unregister_socket(&socket[i].socket);
>
> - m8xx_shutdown();
> + free_irq(pcmcia_schlvl, NULL);
> +
> + return 0;
> +}
> - platform_device_unregister(&m8xx_device);
> - driver_unregister(&m8xx_driver);
> +#ifdef CONFIG_PM
> +static int m8xx_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> + return pcmcia_socket_dev_suspend(&pdev->dev, state);
> +}
> +
> +static int m8xx_resume(struct platform_device *pdev)
> +{
> + return pcmcia_socket_dev_resume(&pdev->dev);
> +}
> +#endif
Here, use
#else
#define m8xx_suspend NULL
#define m8xx_resume NULL
#endif
> +static struct of_device_id m8xx_pcmcia_match[] = {
> + {
> + .type = "pcmcia",
> + .compatible = "fsl,pq-pcmcia",
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, m8xx_pcmcia_match);
> +
> +static struct of_platform_driver m8xx_pcmcia_driver = {
> + .name = (char *) driver_name,
> + .match_table = m8xx_pcmcia_match,
> + .probe = m8xx_probe,
> + .remove = m8xx_remove,
> +#ifdef CONFIG_PM
> + .suspend = m8xx_suspend,
> + .resume = m8xx_resume,
> +#endif
then remove this ifdef.
^ permalink raw reply
* Re: [PATCH 1/4] Add support for 750CL Holly board
From: Josh Boyer @ 2007-05-04 19:18 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070504190140.GA13067@lixom.net>
On Fri, 2007-05-04 at 14:01 -0500, Olof Johansson wrote:
> > +#undef DEBUG
> > +#ifdef DEBUG
> > +#define DBG(fmt...) do { printk(fmt); } while(0)
> > +#else
> > +#define DBG(fmt...) do { } while(0)
> > +#endif
>
> Please use pr_debug() instead.
/me hides head in shame. I'm guilt of the copy/paste crime. Will fix.
> > +#ifndef CONFIG_PCI
> > +pci_dram_offset = PPC750GXCL_TSI_PCI_MEM_OFFSET;
> > +#endif
>
> What's this about?
To be honest, I'm not sure. I haven't tried compiling without PCI.
Just following the Taiga board's example again.
> > +static void holly_remap_bridge(void)
> > +{
> > + u32 lut_val, lut_addr = 0x900, misc_cfg;
>
> Please initialize lut_addr right before using it instead of here, especially
> since you re-assign it later on.
Ok.
>
> > + int i;
> > +
> > + printk(KERN_ERR "Remapping PCI bridge\n");
> > +
> > + /* Re-init the PCI bridge and LUT registers to have mappings that don't
> > + * rely on PIBS */
>
> Comment style
Yep.
> > +
> > + /* We don't need MEM32 and PRM remapping so disable them */
> > + tsi108_write_reg(TSI108_PCI_OFFSET + 0x214, 0x0);
> > + tsi108_write_reg(TSI108_PCI_OFFSET + 0x220, 0x0);
> > + tsi108_write_reg(TSI108_PCI_OFFSET + 0x230, 0x0);
>
> It would be nice to get these constants defined up, but I know it's not always
> practical. I'll bring it up anyway. :-)
This is part of the on-going PCI fixup stuff. It'll get cleaned up in
the final version.
> > + /* setup PCI host bridge */
> > + holly_remap_bridge();
> > +#ifdef CONFIG_PCI
> > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > + tsi108_setup_pci(np);
>
> On an environment without PCI, wouldn't it make more sense to leave it
> out of the device tree, and thus not have a match in the above, instead
> of taking out CONFIG_PCI?
Yes, actually. Good catch.
> > +static int __init holly_probe(void)
> > +{
> > + unsigned long root = of_get_flat_dt_root();
> > +
> > + if (!of_flat_dt_is_compatible(root, "ppc750"))
> > + return 0;
>
> That's a pretty broad compatible check?
Yeah, will fix.
> > +define_machine(holly){
> > + .name = "PPC750 GX/CL TSI",
> > + .probe = holly_probe,
> > + .setup_arch = holly_setup_arch,
> > + .init_IRQ = holly_init_IRQ,
> > + .show_cpuinfo = holly_show_cpuinfo,
> > + .get_irq = mpic_get_irq,
> > + .restart = holly_restart,
> > + .calibrate_decr = generic_calibrate_decr,
> > + .machine_check_exception = ppc750_machine_check_exception,
> > + .progress = udbg_progress,
>
> These look all unaligned for me.
Erg.
> > --- linux-2.6.orig/drivers/net/tsi108_eth.h
> > +++ linux-2.6/drivers/net/tsi108_eth.h
> > @@ -49,7 +49,11 @@
> > */
> > #define PHY_MV88E 1 /* Marvel 88Exxxx PHY */
> > #define PHY_BCM54XX 2 /* Broardcom BCM54xx PHY */
> > +#if defined(CONFIG_HOLLY)
> > +#define TSI108_PHY_TYPE PHY_BCM54XX
> > +#else
> > #define TSI108_PHY_TYPE PHY_MV88E
> > +#endif
>
> This won't work well if you ever want to build a multiplatform kernel.
I know. What do you suggest? TSI doesn't use phylib, and adding a
property to specify PHY type in the DT seems like a hack too...
> > * TSI108 GIGE port registers
> > --- linux-2.6.orig/include/asm-powerpc/tsi108.h
> > +++ linux-2.6/include/asm-powerpc/tsi108.h
> > @@ -68,7 +68,11 @@
> > #define TSI108_PB_ERRCS_ES (1 << 1)
> > #define TSI108_PB_ISR_PBS_RD_ERR (1 << 8)
> >
> > +#ifdef CONFIG_HOLLY
> > +#define TSI108_PCI_CFG_BASE_PHYS (0x7c000000)
> > +#else
> > #define TSI108_PCI_CFG_BASE_PHYS (0xfb000000)
> > +#endif
> > #define TSI108_PCI_CFG_SIZE (0x01000000)
>
> Same here. Shouldn't this come out of the devicetree?
As a "reg" property perhaps? I'm not a DT guru, so I was a bit lost as
to how to fix that up.
josh
^ permalink raw reply
* Re: [PATCH 1/4] Add support for 750CL Holly board
From: Josh Boyer @ 2007-05-04 19:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7BB5A3C3-DBE6-475A-A826-1A95E7B69A4F@kernel.crashing.org>
On Fri, 2007-05-04 at 13:35 -0500, Kumar Gala wrote:
> On May 4, 2007, at 1:14 PM, Josh Boyer wrote:
> > +
> > +config HOLLY
> > + bool "PPC750GX/CL with TSI10x bridge (Hickory/Holly)"
> > + select TSI108_BRIDGE
> > + select PPC_UDBG_16550
> > + select MPIC
> > + select MPIC_WEIRD
> > + help
> > + Select HOLLY if configuring for an IBM 750GX/CL Eval
> > + Board with TSI108/9 bridge (Hickory/Holly)
> > endchoice
> >
> > config TSI108_BRIDGE
> > bool
>
> I wondering if we should have select MPIC and MPIC_WEIRD here instead
> of on the board config.
Could be done, yes. I don't have an mpc7448hpc2 to test with, but I can
make that change.
> > + printk(KERN_INFO "PPC750GX/CL Platform\n");
>
> Should this be something like "Holly PPC750GX/CL Platform"
Well... no. It should really be "Hickory/Holly PPC750GX/CL Platform" to
be correct. But that sucks. Suppose I could match off of the cpu node
in the DT and just print one or the other... except they share a DT too
at the moment.
I'll think about what to do.
> > +void holly_show_cpuinfo(struct seq_file *m)
> > +{
> > + seq_printf(m, "vendor\t\t: IBM\n");
> > + seq_printf(m, "machine\t\t: PPC750 GX/CL\n");
>
> Should 'Holly' be in the machine name?
Again, the whole "Hickory/Holly" thing.
>
> > +}
> > +
> > +void holly_restart(char *cmd)
> > +{
> > + unsigned long *ocn_bar1 = NULL;
>
> This should probably be __be32 __iomem
Good catch. I need to run this through sparse.
> > +/*
> > + * Called very early, device-tree isn't unflattened
> > + */
> > +static int __init holly_probe(void)
> > +{
> > + unsigned long root = of_get_flat_dt_root();
> > +
> > + if (!of_flat_dt_is_compatible(root, "ppc750"))
> > + return 0;
>
> This seems like to generic of a match.
Likely is, yes.
> > --- linux-2.6.orig/drivers/net/tsi108_eth.h
> > +++ linux-2.6/drivers/net/tsi108_eth.h
> > @@ -49,7 +49,11 @@
> > */
> > #define PHY_MV88E 1 /* Marvel 88Exxxx PHY */
> > #define PHY_BCM54XX 2 /* Broardcom BCM54xx PHY */
> > +#if defined(CONFIG_HOLLY)
> > +#define TSI108_PHY_TYPE PHY_BCM54XX
> > +#else
> > #define TSI108_PHY_TYPE PHY_MV88E
> > +#endif
>
> This seems pretty bad. Can we at least make this some type of kernel
> config since I'm guessing the tsi108 isn't using the phylib.
Yep.
Thanks for the comments. I'll fix it up in the next round.
josh
^ permalink raw reply
* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
From: Linas Vepstas @ 2007-05-04 19:04 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linuxppc-dev, gregkh, paulus, linux-kernel
In-Reply-To: <4fe4528cb20beb569a8f2ac817c776e5@pinky>
On Fri, May 04, 2007 at 12:38:58PM +0100, Andy Whitcroft wrote:
>
> Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
> bit of a challenge. We have been seeing panics on boot from the
> hvsi driver:
>
> Couldn't register hvsi console driver
>
> Tracking this back, this seems to come from hvsi driver trying to
> register itself via tty_register_driver() with a zero units.
>
> The failure is triggered by a change in semantics for kmalloc()
> between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
> allocation at the smallest size. Looking at the code in question
> even when the allocation succeeds we will not actually use the
> memory when device->num is zero.
>
> It is not clear to me if this is a bug in the hvsi driver in that
> it should specify some units. It seems we will try and reserve zero
> devices in this case, which seems pointless.
Yes, it seems pointless to me ...
> I have tested with the patch below which seems safe to me and stops
> the errors and even seems to make the console work. But perhaps
> someone with more driver fu, could verify if driver->num of zero
> has any meaning and kick this to the hvsi people if not.
Hollis nominated me to be "hvsi people", although I'm near-totally
ignorant of the thing.
If hvsi_count is zero, then the device tree did not have any
"serial" nodes that speak "hvterm-protocol". The hvsi should not
have even tried to register anything. The attached patch seems more
to the point.
--linas
The hvsi driver is used whenever the device-tree contains
nodes for serial ports, and those serial ports speak the hvterm
protocol. However, if no such nodes are found, then the hvsi
driver should not even register.
This patch avoids a kernel panic with "Couldn't register hvsi
console driver".
In addition, this patch makes tty_register_driver refuse
to do anything, if there are no actual tty ports to be
registered.
Utterly & completely untested.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/char/hvsi.c | 4 ++++
drivers/char/tty_io.c | 3 +++
2 files changed, 7 insertions(+)
Index: linux-2.6.21-rc7-mm2/drivers/char/hvsi.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/drivers/char/hvsi.c 2007-04-26 15:37:33.000000000 -0500
+++ linux-2.6.21-rc7-mm2/drivers/char/hvsi.c 2007-05-04 13:55:56.000000000 -0500
@@ -1148,6 +1148,10 @@ static int __init hvsi_init(void)
{
int i;
+ /* No serial hvterm-protocol device-tree nodes found. */
+ if (hvsi_count == 0)
+ return 0;
+
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
return -ENOMEM;
Index: linux-2.6.21-rc7-mm2/drivers/char/tty_io.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/drivers/char/tty_io.c 2007-04-26 15:37:33.000000000 -0500
+++ linux-2.6.21-rc7-mm2/drivers/char/tty_io.c 2007-05-04 13:54:14.000000000 -0500
@@ -3724,6 +3724,9 @@ int tty_register_driver(struct tty_drive
if (driver->flags & TTY_DRIVER_INSTALLED)
return 0;
+ if (driver->num == 0)
+ return -ENODEV;
+
if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
if (!p)
^ permalink raw reply
* Re: initramfs on PowerPC
From: David H. Lynch Jr. @ 2007-05-04 19:02 UTC (permalink / raw)
To: Richard Danter; +Cc: linuxppc-embedded
In-Reply-To: <200705041332.27296.richard.danter@ntlworld.com>
I tried numerous approaches, I never got anything to work except pointing
CONFIG_INITRAMFS_SOURCE at a directory with my intramfs tree in it.
I am sure other ways work, but I never managed to figure out what I was
doing
wrong. Regardless that has worked well for me.
When I build I end up with a single file - zImage,.elf that has both my
kernel
and the initramfs tree in it. While there are a number of distro's that
seem to
use initramfs as a separate file - much like initrd, my loader has no
provisions for a 2nd file, and the kernel build process wraps everything
together
which works fine for me.
I have never seen your "junk in compressed archive" error, and I have
been doing this
for almost 2 years. But I have frequently had decompression errors.
These typically
have been the result of errors in the PPC zlib libraries. I beleive
somewhere between
2.6.16 and 2.6.18 these libraries got updated, and the PPC version of
the new ones
had problems. Anyway, after 2.6.18 the new ones are good - though somehow
once in a while the broken ones seem to creep into my development tree,
but updating it usually fixes things.
There also may be a total size issue. I am hazy on the details, but I
beleive if the
size of size of the kernel goes over 3mb that there are CONFIG values that
may need to be changed. I am not sure whether that is compressed size
decompressed size, kernel size, or combined kernel + initramfs size.
Regardless, one suguestion would be to try with a very minimal initramfs
tree
and add things until it blows up.
Richard Danter wrote:
> Hi all,
>
> I am having a problem booting a kernel with an initramfs. The kernel version
> is 2.6.14. The target is a ppc 82xx board.
>
> I have tried both generating the cpio.gz file myself (find . | copi -o -H
> newc | gzip > ../initramfs_data.cpio.gz) and pointing initramfs source to a
> root FS directory (using xconfig) and then re-building my kernel.
>
> Usually the error is "junk in compressed archive" though I also see an
> occasional error about padding.
>
> I am using U-Boot to load the kernel image (uImage).
>
> My host is SuSE 10.0 (x86), though I guess that shouldn't make any difference
> (endianism?).
>
> Any thoughts on what I may be doing wrong?
>
> Thanks
> Rich
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox