Regarding MPC8641D
Hai, We have designed a MPC8641D based AMC card. We are using the kernel (2.6.23-rc4) and uboot (1.2.0). When we disable the core1 Low Memory offset mode the kernel was up and when we enable this core1 Low Memory offset mode kernel was not up, It was hang after MPIC initialization. Kerenl dump : # Booting image at 0020 ... Image Name: Linux-2.6.23-rc4-g5326152f-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:4544816 Bytes = 4.3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x70 data:0 Probing machine type ... MPC86xx HPCN ...start c05d1e10 end c05d1ee0 <6>Using MPC86xx HPCN machine description Total memory = 600MB; using 2048kB for hash table (at cfe0) Linux version 2.6.23-rc4-g5326152f-dirty ([EMAIL PROTECTED]) (gcc version 4.0.2 20060628 (Wasabi)) #45 SMP Wed Dec 5 12:01:58 IST 2007 console [udbg0] enabled setup_arch: bootmem mpc86xx_hpcn_setup_arch() Found FSL PCI host bridge at 0xf8008000.Firmware bus number: 0->254 MPC86xx HPCN board from Freescale Semiconductor arch: exit Zone PFN ranges: DMA 0 -> 153600 Normal 153600 -> 153600 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 153600 Built 1 zonelists in Zone order. Total pages: 152400 Kernel command line: root=/dev/ram console=ttyS0,115200 mem=600M mpic: Setting up MPIC " MPIC " version 1.2 at f804, max 2 CPUs mpic: ISU size: 88, shift: 7, mask: 7f mpic: Initializing for 88 sources PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 600064k/614400k available (5832k kernel code, 14096k reserved, 116k data, 233k bss, 3244k init) SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=2, Nodes=1 Security Framework v1.0.0 initialized SELinux: Initializing. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 mpic: requesting IPIs ... After this the kernel was hang, i want to know why kernel was hang when we enalbe Low memory Offset mode. Please help me to fix this issue. Thanks and Regards Sivaji -- View this message in context: http://www.nabble.com/Regarding-MPC8641D-tf4948004.html#a14166848 Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] Remove bogus comment in dma_direct_alloc_coherent()
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use node local allocations) went in this comment makes no sense. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/kernel/dma_64.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c index 26c0d8c..1ef919d 100644 --- a/arch/powerpc/kernel/dma_64.c +++ b/arch/powerpc/kernel/dma_64.c @@ -137,7 +137,6 @@ static void *dma_direct_alloc_coherent(struct device *dev, size_t size, void *ret; int node = dev->archdata.numa_node; - /* TODO: Maybe use the numa node here too ? */ page = alloc_pages_node(node, flag, get_order(size)); if (page == NULL) return NULL; -- 1.5.3.7.1.g4e596e ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/7] Remove the global dma_direct_offset
We no longer need the global dma_direct_offset, update the comment to
reflect the new reality.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c |7 ---
include/asm-powerpc/dma-mapping.h |2 --
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 19d5fb0..26c0d8c 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -112,10 +112,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
/*
* Generic direct DMA implementation
*
- * This implementation supports a global offset that can be applied if
- * the address at which memory is visible to devices is not 0.
+ * This implementation supports a per-device offset that can be applied if
+ * the address at which memory is visible to devices is not 0. Platform code
+ * can point archdata.dma_data at an unsigned long holding the offset. By
+ * default no offset is used.
*/
-unsigned long dma_direct_offset;
static unsigned long get_dma_direct_offset(struct device *dev)
{
diff --git a/include/asm-powerpc/dma-mapping.h
b/include/asm-powerpc/dma-mapping.h
index ff52013..d9b429a 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -186,8 +186,6 @@ static inline void dma_unmap_sg(struct device *dev, struct
scatterlist *sg,
extern struct dma_mapping_ops dma_iommu_ops;
extern struct dma_mapping_ops dma_direct_ops;
-extern unsigned long dma_direct_offset;
-
#else /* CONFIG_PPC64 */
#define dma_supported(dev, mask) (1)
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/7] Have celleb use its own dma_direct_offset variable
Rather than using the global variable, have celleb use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/celleb/iommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c
b/arch/powerpc/platforms/celleb/iommu.c
index 04d5678..85af76f 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -51,6 +51,8 @@ static int __init find_dma_window(u64 *io_space_id, u64 *ioid,
return 0;
}
+static unsigned long celleb_dma_direct_offset;
+
static void __init celleb_init_direct_mapping(void)
{
u64 lpar_addr, io_addr;
@@ -68,13 +70,13 @@ static void __init celleb_init_direct_mapping(void)
ioid, DMA_FLAGS);
}
- dma_direct_offset = dma_base;
+ celleb_dma_direct_offset = dma_base;
}
static void celleb_dma_dev_setup(struct device *dev)
{
dev->archdata.dma_ops = get_pci_dma_ops();
- dev->archdata.dma_data = &dma_direct_offset;
+ dev->archdata.dma_data = &celleb_dma_direct_offset;
}
static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/7] Have cell use its own dma_direct_offset variable
Rather than using the global variable, have cell use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 2edb1ad..d2f9242 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -489,6 +489,8 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
return NULL;
}
+static unsigned long cell_dma_direct_offset;
+
static void cell_dma_dev_setup(struct device *dev)
{
struct iommu_window *window;
@@ -496,7 +498,7 @@ static void cell_dma_dev_setup(struct device *dev)
struct dev_archdata *archdata = &dev->archdata;
if (get_pci_dma_ops() == &dma_direct_ops) {
- archdata->dma_data = &dma_direct_offset;
+ archdata->dma_data = &cell_dma_direct_offset;
return;
}
@@ -654,7 +656,7 @@ static int __init cell_iommu_init_disabled(void)
/* If we have no Axon, we set up the spider DMA magic offset */
if (of_find_node_by_name(NULL, "axon") == NULL)
- dma_direct_offset = SPIDER_DMA_OFFSET;
+ cell_dma_direct_offset = SPIDER_DMA_OFFSET;
/* Now we need to check to see where the memory is mapped
* in PCI space. We assume that all busses use the same dma
@@ -688,10 +690,10 @@ static int __init cell_iommu_init_disabled(void)
return -ENODEV;
}
- dma_direct_offset += base;
+ cell_dma_direct_offset += base;
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
- dma_direct_offset);
+ cell_dma_direct_offset);
return 0;
}
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] Use archdata.dma_data in dma_direct_ops
Now that all platforms using dma_direct_offset setup the archdata.dma_data
correctly, we can change the dma_direct_ops to retrieve the offset from
the dma_data, rather than directly from the global.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 14206e3..19d5fb0 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -117,6 +117,18 @@ EXPORT_SYMBOL(dma_iommu_ops);
*/
unsigned long dma_direct_offset;
+static unsigned long get_dma_direct_offset(struct device *dev)
+{
+ unsigned long *offset;
+
+ offset = dev->archdata.dma_data;
+
+ if (offset)
+ return *offset;
+
+ return 0;
+}
+
static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
@@ -130,7 +142,7 @@ static void *dma_direct_alloc_coherent(struct device *dev,
size_t size,
return NULL;
ret = page_address(page);
memset(ret, 0, size);
- *dma_handle = virt_to_abs(ret) | dma_direct_offset;
+ *dma_handle = virt_to_abs(ret) | get_dma_direct_offset(dev);
return ret;
}
@@ -145,7 +157,7 @@ static dma_addr_t dma_direct_map_single(struct device *dev,
void *ptr,
size_t size,
enum dma_data_direction direction)
{
- return virt_to_abs(ptr) | dma_direct_offset;
+ return virt_to_abs(ptr) | get_dma_direct_offset(dev);
}
static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
@@ -161,7 +173,7 @@ static int dma_direct_map_sg(struct device *dev, struct
scatterlist *sgl,
int i;
for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = sg_phys(sg) | dma_direct_offset;
+ sg->dma_address = sg_phys(sg) | get_dma_direct_offset(dev);
sg->dma_length = sg->length;
}
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] Add celleb_dma_dev_setup()
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
should set dma_data to dma_direct_offset.
Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/celleb/iommu.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/iommu.c
b/arch/powerpc/platforms/celleb/iommu.c
index 755d869..04d5678 100644
--- a/arch/powerpc/platforms/celleb/iommu.c
+++ b/arch/powerpc/platforms/celleb/iommu.c
@@ -71,6 +71,17 @@ static void __init celleb_init_direct_mapping(void)
dma_direct_offset = dma_base;
}
+static void celleb_dma_dev_setup(struct device *dev)
+{
+ dev->archdata.dma_ops = get_pci_dma_ops();
+ dev->archdata.dma_data = &dma_direct_offset;
+}
+
+static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
+{
+ celleb_dma_dev_setup(&pdev->dev);
+}
+
static int celleb_of_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -80,7 +91,7 @@ static int celleb_of_bus_notify(struct notifier_block *nb,
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;
- dev->archdata.dma_ops = get_pci_dma_ops();
+ celleb_dma_dev_setup(dev);
return 0;
}
@@ -96,6 +107,7 @@ static int __init celleb_init_iommu(void)
celleb_init_direct_mapping();
set_pci_dma_ops(&dma_direct_ops);
+ ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
bus_register_notifier(&of_platform_bus_type, &celleb_of_bus_notifier);
return 0;
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
Store a pointer to the direct_dma_offset in each device's dma_data
in the case where we're using the direct DMA ops.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index faabc3f..2edb1ad 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -495,9 +495,10 @@ static void cell_dma_dev_setup(struct device *dev)
struct cbe_iommu *iommu;
struct dev_archdata *archdata = &dev->archdata;
- /* If we run without iommu, no need to do anything */
- if (get_pci_dma_ops() == &dma_direct_ops)
+ if (get_pci_dma_ops() == &dma_direct_ops) {
+ archdata->dma_data = &dma_direct_offset;
return;
+ }
/* Current implementation uses the first window available in that
* node's iommu. We -might- do something smarter later though it may
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
PS3: Update ps3_defconfig
Update ps3_defconfig. Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- arch/powerpc/configs/ps3_defconfig | 177 ++--- 1 file changed, 89 insertions(+), 88 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc2 -# Tue Aug 7 19:17:26 2007 +# Linux kernel version: 2.6.24-rc4 +# Tue Dec 4 22:49:57 2007 # CONFIG_PPC64=y @@ -11,6 +11,7 @@ CONFIG_PPC64=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y +CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y @@ -19,8 +20,13 @@ CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_64BIT=y +CONFIG_WORD_SIZE=64 CONFIG_PPC_MERGE=y CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y @@ -59,14 +65,18 @@ CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y -# CONFIG_POSIX_MQUEUE is not set +CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 -# CONFIG_CPUSETS is not set +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y @@ -87,13 +97,11 @@ CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLUB_DEBUG=y -# CONFIG_SLAB is not set -CONFIG_SLUB=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set @@ -108,6 +116,7 @@ CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y +CONFIG_BLOCK_COMPAT=y # # IO Schedulers @@ -126,7 +135,6 @@ CONFIG_DEFAULT_IOSCHED="anticipatory" # Platform support # CONFIG_PPC_MULTIPLATFORM=y -# CONFIG_EMBEDDED6xx is not set # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_86xx is not set @@ -176,10 +184,15 @@ CONFIG_SPU_BASE=y # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_CPM2 is not set +# CONFIG_FSL_ULI1575 is not set # # Kernel options # +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set @@ -211,6 +224,8 @@ CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y +CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y +CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y CONFIG_SPLIT_PTLOCK_CPUS=4 @@ -237,10 +252,6 @@ CONFIG_GENERIC_ISA_DMA=y # CONFIG_PCI_DOMAINS is not set # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set - -# -# PCCARD (PCMCIA/CardBus) support -# # CONFIG_PCCARD is not set CONFIG_KERNEL_START=0xc000 @@ -280,6 +291,7 @@ CONFIG_INET_TUNNEL=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_LRO is not set # CONFIG_INET_DIAG is not set # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y @@ -318,10 +330,6 @@ CONFIG_IPV6_SIT=y # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set - -# -# QoS and/or fair queueing -# # CONFIG_NET_SCHED is not set # @@ -330,26 +338,7 @@ CONFIG_IPV6_SIT=y # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set -CONFIG_BT=m -CONFIG_BT_L2CAP=m -CONFIG_BT_SCO=m -CONFIG_BT_RFCOMM=m -CONFIG_BT_RFCOMM_TTY=y -# CONFIG_BT_BNEP is not set -CONFIG_BT_HIDP=m - -# -# Bluetooth device drivers -# -CONFIG_BT_HCIUSB=m -CONFIG_BT_HCIUSB_SCO=y -CONFIG_BT_HCIUART=m -CONFIG_BT_HCIUART_H4=y -CONFIG_BT_HCIUART_BCSP=y -# CONFIG_BT_HCIBCM203X is not set -# CONFIG_BT_HCIBPA10X is not set -# CONFIG_BT_HCIBFUSB is not set -# CONFIG_BT_HCIVHCI is not set +# CONFIG_BT is not set # CONFIG_AF_RXRPC is not set # @@ -358,7 +347,13 @@ CONFIG_BT_HCIUART_BCSP=y # CONFIG_CFG80211 is not set CONFIG_WIRELESS_EXT=y # CONFIG_MAC80211 is not set -# CONFIG_IEEE80211 is not set +CONFIG_IEEE80211=m +# CONFIG_IEEE80211_DEBUG is not set +CONFIG_IEEE80211_CRYPT_WEP=m +CONFIG_IEEE80211_CRYPT_CCMP=m +CONFIG_IEEE80211_CRYPT_TKIP=m +CONFIG_IEEE80211_SOFTMAC=m +# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set @@ -369,9 +364,10 @@ CONFIG_WIRELESS_EXT=y # # Generic Driver Options # +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_S
[PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't need it in every printk around.
This is a pre-requisite for making powerpc use the generic code instead of
its own half-useful implementation.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
This version fixes some stupid warnings when using 32 bits resources
drivers/pci/pci.h | 11 +++
drivers/pci/setup-bus.c | 32 +---
drivers/pci/setup-res.c |5 ++---
include/linux/pci.h |4 ++--
4 files changed, 32 insertions(+), 20 deletions(-)
Index: linux-work/drivers/pci/pci.h
===
--- linux-work.orig/drivers/pci/pci.h 2007-12-05 11:55:49.0 +1100
+++ linux-work/drivers/pci/pci.h2007-12-05 13:37:45.0 +1100
@@ -91,3 +91,14 @@ pci_match_one_device(const struct pci_de
}
struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
+
+#ifdef CONFIG_RESOURCES_64BIT
+#define RESOURCE_ORDER(order) (1ULL << (order))
+#define RES_PR "%016llx"
+#else
+#define RESOURCE_ORDER(order) (1UL << (order))
+#define RES_PR "%08x"
+#endif
+
+#define RANGE_PR RES_PR "-" RES_PR
+
Index: linux-work/drivers/pci/setup-bus.c
===
--- linux-work.orig/drivers/pci/setup-bus.c 2007-12-05 11:55:49.0
+1100
+++ linux-work/drivers/pci/setup-bus.c 2007-12-05 12:04:35.0 +1100
@@ -26,6 +26,7 @@
#include
#include
+#include "pci.h"
#define DEBUG_CONFIG 1
#if DEBUG_CONFIG
@@ -89,8 +90,9 @@ void pci_setup_cardbus(struct pci_bus *b
* The IO resource is allocated a range twice as large as it
* would normally need. This allows us to set both IO regs.
*/
- printk(" IO window: %08lx-%08lx\n",
- region.start, region.end);
+ printk(KERN_INFO " IO window: 0x%08lx-0x%08lx\n",
+ (unsigned long)region.start,
+ (unsigned long)region.end);
pci_write_config_dword(bridge, PCI_CB_IO_BASE_0,
region.start);
pci_write_config_dword(bridge, PCI_CB_IO_LIMIT_0,
@@ -99,7 +101,7 @@ void pci_setup_cardbus(struct pci_bus *b
pcibios_resource_to_bus(bridge, ®ion, bus->resource[1]);
if (bus->resource[1]->flags & IORESOURCE_IO) {
- printk(" IO window: %08lx-%08lx\n",
+ printk(KERN_INFO " IO window: "RANGE_PR"\n",
region.start, region.end);
pci_write_config_dword(bridge, PCI_CB_IO_BASE_1,
region.start);
@@ -109,7 +111,7 @@ void pci_setup_cardbus(struct pci_bus *b
pcibios_resource_to_bus(bridge, ®ion, bus->resource[2]);
if (bus->resource[2]->flags & IORESOURCE_MEM) {
- printk(" PREFETCH window: %08lx-%08lx\n",
+ printk(KERN_INFO " PREFETCH window: "RANGE_PR"\n",
region.start, region.end);
pci_write_config_dword(bridge, PCI_CB_MEMORY_BASE_0,
region.start);
@@ -119,7 +121,7 @@ void pci_setup_cardbus(struct pci_bus *b
pcibios_resource_to_bus(bridge, ®ion, bus->resource[3]);
if (bus->resource[3]->flags & IORESOURCE_MEM) {
- printk(" MEM window: %08lx-%08lx\n",
+ printk(KERN_INFO " MEM window: "RANGE_PR"\n",
region.start, region.end);
pci_write_config_dword(bridge, PCI_CB_MEMORY_BASE_1,
region.start);
@@ -159,7 +161,8 @@ pci_setup_bridge(struct pci_bus *bus)
/* Set up upper 16 bits of I/O base/limit. */
io_upper16 = (region.end & 0x) | (region.start >> 16);
DBG(KERN_INFO " IO window: %04lx-%04lx\n",
- region.start, region.end);
+ (unsigned long)region.start,
+ (unsigned long)region.end);
}
else {
/* Clear upper 16 bits of I/O base/limit. */
@@ -180,7 +183,7 @@ pci_setup_bridge(struct pci_bus *bus)
if (bus->resource[1]->flags & IORESOURCE_MEM) {
l = (region.start >> 16) & 0xfff0;
l |= region.end & 0xfff0;
- DBG(KERN_INFO " MEM window: %08lx-%08lx\n",
+ DBG(KERN_INFO " MEM window: "RANGE_PR"\n",
region.start, region.end);
}
else {
@@ -199,7 +202,7 @@ pci_setup_bridge(struct pci_bus *bus)
if (bus->resource[2]->flags & I
Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
On Wed, 2007-12-05 at 15:21 +1100, David Gibson wrote: > On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote: > > > > On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote: > > > It occurred to me the other day. Instead of using a new "unused" > > > property for this, should we be using the OF standard "status" > > > property. > > > > Dunno... it's really not wired. Probably not even clocked. > > status = "fail-notconnected"; ? Bah, that's fugly.. jeff, don't hold the patches, we may sort that out later. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Tue, Dec 04, 2007 at 10:00:12PM -0600, Josh Boyer wrote: > So if mkimage is going to be put in-kernel, I'd rather it be in a more > generic place. Arguably, dtc should go there as well seeing as how > microblaze could probably use it too. Well, kconfig is in scripts/ in spite of not being a script. Maybe dtc and mkimage should go there too? -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote: > > It occurred to me the other day. Instead of using a new "unused" > > property for this, should we be using the OF standard "status" > > property. > > Dunno... it's really not wired. Probably not even clocked. status = "fail-notconnected"; ? -- 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: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote: > It occurred to me the other day. Instead of using a new "unused" > property for this, should we be using the OF standard "status" > property. Dunno... it's really not wired. Probably not even clocked. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
On Wed, Dec 05, 2007 at 11:14:30AM +1100, Benjamin Herrenschmidt wrote: > From: Hugh Blemings <[EMAIL PROTECTED]> > > Depending on how the 44x processors are wired, some EMAC cells > might not be useable (and not connected to a PHY). However, some > device-trees may choose to still expose them (since their registers > are present in the MMIO space) but with an "unused" property in > them. It occurred to me the other day. Instead of using a new "unused" property for this, should we be using the OF standard "status" property. -- 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: Merge dtc
On Tue, 4 Dec 2007 20:26:25 -0600 Josh Boyer <[EMAIL PROTECTED]> wrote: > On Wed, 5 Dec 2007 13:22:46 +1100 > Paul Mackerras <[EMAIL PROTECTED]> wrote: > > > Josh Boyer writes: > > > > > Using that same reasoning, should we merge a mkimage patch for the > > > boards that use U-Boot? > > > > I think so. It's fairly small and it would mean that people could > > cross-compile all the defconfigs easily. > > I'll try to work up a patch tonight. OK so it won't be tonight. The problem we have with mkimage, unlike DTC at the moment, is that it _is_ used on other architectures. There's already a mkuboot.sh script, which calls mkimage, in scripts/ right now. Adding mkimage to arch/powerpc only seems pretty wrong. So if mkimage is going to be put in-kernel, I'd rather it be in a more generic place. Arguably, dtc should go there as well seeing as how microblaze could probably use it too. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote: > On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote: > > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote: > > > tristate "Generic platform device PATA support" > > > - depends on EMBEDDED || ARCH_RPC > > > + depends on EMBEDDED || ARCH_PPC > > > > It needs to be || PPC, not || ARCH_PPC. > > > Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC. > > ARCH_RPC is not a typo, it's an ARM platform. Please grep first :-) I'm sorry, but seeing ARCH_RPC and not having an arch/rpc made me suspect it being a typo. It surprises me that the ARM guys chose such a generic prefix as ARCH_ for their specific platforms. (powerpc uses PPC_). Anyway, thanks for catching it. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
On Tue, 2007-12-04 at 17:08 +1100, Benjamin Herrenschmidt wrote: > The current pci_assign_unassigned_resources() code doesn't work properly > on 32 bits platforms with 64 bits resources. The main reason is the use > of unsigned long in various places instead of resource_size_t. > > This fixes it, along with some tricks to avoid casting to 64 bits on > platforms that don't need it in every printk around. > > This is a pre-requisite for making powerpc use the generic code instead of > its own half-useful implementation. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Drop it for now, stupid warnings without 64 bits resources... I'll fix that. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Wed, 5 Dec 2007 13:22:46 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Josh Boyer writes: > > > Using that same reasoning, should we merge a mkimage patch for the > > boards that use U-Boot? > > I think so. It's fairly small and it would mean that people could > cross-compile all the defconfigs easily. I'll try to work up a patch tonight. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
Josh Boyer writes: > Using that same reasoning, should we merge a mkimage patch for the > boards that use U-Boot? I think so. It's fairly small and it would mean that people could cross-compile all the defconfigs easily. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] pasemi: Register i2c_board_info
On Wed, Dec 05, 2007 at 11:41:50AM +1100, Paul Mackerras wrote: > Olof Johansson writes: > > > Yep, I realized that after (re)asking Paul to pull though, and didn't > > want to do a third request before he's done it. :) > > > > If he doesn't pull in the next few days I might just keep adding new > > patches as they come in though, and add it back. > > I haven't pulled yet; sounds like I need to wait a few more days > first. :) Heh, nah, just pull now, I'll have more going in before 2.6.25 as but it's good to get current contents into -mm sooner rather than later. :) Thanks, -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Wed, 05 Dec 2007 00:54:38 + David Woodhouse <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-12-04 at 22:33 +, David Woodhouse wrote: > > Make vmlinux the default target instead of zImage would seem like a > > better answer. I'm surprised that it isn't like that already, in fact -- > > and I'm only inferring that it isn't from your message. I always thought > > that if I typed 'make' I got the vmlinux and not a zImage. > > Ooh, no -- I don't. I get an error, and I never even noticed... > > WRAParch/powerpc/boot/zImage.chrp > WRAParch/powerpc/boot/zImage.pmac > WRAParch/powerpc/boot/cuImage.52xx > /pmac/git/libertas-2.6/arch/powerpc/boot/wrapper: line 257: mkimage: command > not found > make[1]: *** [arch/powerpc/boot/cuImage.52xx] Error 127 > > > I'd be perfectly happy with 'make vmlinux then' as a response to anyone > who complains. And in fact since it'll correctly make the vmlinux and > _then_ fail to create the zImage, I would have thought that anyone with > even a modicum of common sense will _notice_ that, and start using > 'make vmlinux' all by themselves without prompting. People build what the default is. You don't boot a vmlinux, you boot a zImage (in most cases). (Nevermind the fact that for the 'build patch on all arches' part Paul mentioned earlier it doesn't really matter since they probably aren't going to actually boot it anyway.) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix Firmware class name collision
Scott Wood wrote: > The physical address certainly is useful when you have more than one > device of the same name. What I meant was that the physical address isn't helpful by itself. > So then you'd get "firmware-ucc.e01024". What if there's another ucc at > e0102480? For devices with longer names, you'd have even less > precision in the address. Maybe we need to consider a more sophisticated algorithm, one that guarantees that the device name in its entirety is preserved? Either that, or replace the physical address with something shorter, like the offset to the root node only? That way, ucc.e0102400 because just ucc.2400. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
On Tue, 04 Dec 2007 15:07:49 -0500 Jeff Garzik wrote: > Vitaly Bordug wrote: > > With that patch fixed.c now fully emulates MDIO bus, thus no need > > to duplicate PHY layer functionality. That, in turn, drastically > > simplifies the code, and drops down line count. > > > > As an additional bonus, now there is no need to register MDIO bus > > for each PHY, all emulated PHYs placed on the platform fixed MDIO > > bus. There is also no more need to pre-allocate PHYs via .config > > option, this is all now handled dynamically. > > > > p.s. Don't even try to understand patch content! Better: apply patch > > and look into resulting drivers/net/phy/fixed.c. > > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > ACK, I presume this will go via the ppc tree? > Yes, I'll add your ack in next respin and will ask Paul to consider it, if you don't mind. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make QSpan PCI work
On Mon, 3 Dec 2007 13:05:00 -0800 John Tyner wrote: > The following patch makes the QSpan PCI code compile and work on my > hardware. The patch is against 2.4, but I'm hoping it will still be > viewed as useful since the code currently does not even compile (2.6 > is the same). I had to make a change to move the PCI setup later in > the m8xx_setup code as well because the kernel would crash during the > pcibios_alloc_controller because the bootmem stuff had not come up > yet. > This looks interesting, but again would make a lot of sense for powerpc and 2.6. Is that possible to have your patches rebased against 2.6, arch/ppc at least? -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] pasemi: Register i2c_board_info
Olof Johansson writes: > Yep, I realized that after (re)asking Paul to pull though, and didn't > want to do a third request before he's done it. :) > > If he doesn't pull in the next few days I might just keep adding new > patches as they come in though, and add it back. I haven't pulled yet; sounds like I need to wait a few more days first. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
David Woodhouse writes: > Make vmlinux the default target instead of zImage would seem like a > better answer. I'm surprised that it isn't like that already, in fact -- > and I'm only inferring that it isn't from your message. I always thought > that if I typed 'make' I got the vmlinux and not a zImage. You're obviously an old-timer. :) Plain "make" has made the zImage since at least 2002 in 32-bit and since January 2004 in 64-bit. The alternative to including dtc is to include compiled versions of all the .dts files. The difficulty with that is that .dtb files are binary blobs which can't be updated with a patch. The shipped versions could possibly be shipped as .S versions, or I (and everyone else who has a tree that I pull from) could have something in my/their patch-applying scripts that updates the .dtbs if necessary, but in both cases things could get out of sync for one reason or another without it being obvious. In contrast, if the version of dtc in the kernel tree gets out of date, it will become obvious pretty quickly because compiles will start failing. And anyway, the kernel dtc only needs to be recent enough to compile the .dts files in the kernel tree. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix 8xx compile errors
On Mon, 3 Dec 2007 12:58:38 -0800 John Tyner wrote: > Building for 8xx fails to compile due to errors in a couple of > places. The first is due to the casting of an lvalue (if I remember > correctly), and the second was due to the cpmp variable being > declared static even though the headers previously defined it as > extern. The following patch corrects these errors. The patch is > against 2.4 since that's what I'm working with. (I've been unable to > get 2.6 to run properly on my hardware so far.) > > Please CC me on any responses since I'm not subscribed. > You don't need these quirks with 2.6 and arch/powerpc... It does not use 8xx_io and arch/powerpc/boot/* having a bit different meaning. What is your platform btw? Adding something to 8xx camp should not be huge effort with powerpc... -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ucc_uart: add support for Freescale QUICCEngine UART
On Wed, 5 Dec 2007 00:56:39 +0100 Arnd Bergmann wrote: > On Wednesday 05 December 2007, Timur Tabi wrote: > > Arnd Bergmann wrote: > > > > > You can argue that the QS is really a DMA device, but in that > > > case you should convert the driver to use the DMA mapping > > > interfaces correctly, which I would consider overkill. > > > > I'm confused. I'm already calling dma_alloc_coherent() and getting > > a dma_addr_t back. Why do I need to use mapping functions to > > convert between virtual and physical/bus addresses? > > No, I'm sorry but I'm the one who was confused. The problem I saw was > that you return something offset from "bd_phys" as a dma_addr_t. This > would be a lot easier if you had called it bd_bus or bd_dma instead > of bd_phys, but your code looks absolutely correct upon closer > inspection. > Adding my 2 cents, we already have very similar thing in cpm_uart driver... > Arnd <>< > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] [libata] pata_platform: s/ioport_shift/reg_shift/g
On Tue, Dec 04, 2007 at 08:07:45PM +0300, Anton Vorontsov wrote: > This patch renames ioport_shift member of pata_platform_info > structure to reg_shift. Users of pata_platform are followed > appropriately. > > Rationale of that change is: shifting applies to the whole memory > mapped region, not only to the command block of the ATA registers, > despite the fact that shifting is meaningless for ctl register. > It's called ioport_shift because of the fact it shifts an ioport, namely a struct ata_ioport *. We could rename it, but I really don't see the point. If you don't like the choice of name on your platform, add a comment to your platform-specific code noting this particular outrage so it can be grepped for by future generations ;-) Nacked-by: Paul Mundt <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Tue, 2007-12-04 at 22:33 +, David Woodhouse wrote: > Make vmlinux the default target instead of zImage would seem like a > better answer. I'm surprised that it isn't like that already, in fact -- > and I'm only inferring that it isn't from your message. I always thought > that if I typed 'make' I got the vmlinux and not a zImage. Ooh, no -- I don't. I get an error, and I never even noticed... WRAParch/powerpc/boot/zImage.chrp WRAParch/powerpc/boot/zImage.pmac WRAParch/powerpc/boot/cuImage.52xx /pmac/git/libertas-2.6/arch/powerpc/boot/wrapper: line 257: mkimage: command not found make[1]: *** [arch/powerpc/boot/cuImage.52xx] Error 127 I'd be perfectly happy with 'make vmlinux then' as a response to anyone who complains. And in fact since it'll correctly make the vmlinux and _then_ fail to create the zImage, I would have thought that anyone with even a modicum of common sense will _notice_ that, and start using 'make vmlinux' all by themselves without prompting. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 6/6] powerpc: pci32: 4xx embedded platforms want to reassign all PCI resources
This makes 4xx embedded platforms re-assign all PCI resources as we
pretty much never care about what the various firmwares have done on
these, it's generally not compatible with the way the kernel will map
the bridges.
We still need to also enable bus renumbering on some of them, but I
will do that from a separate patch after I've fixed 4xx PCIe to handle
all bus numbers.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/ep405.c |2 ++
arch/powerpc/platforms/40x/kilauea.c |3 +++
arch/powerpc/platforms/40x/walnut.c |3 +++
arch/powerpc/platforms/44x/bamboo.c |4
arch/powerpc/platforms/44x/ebony.c |3 +++
arch/powerpc/platforms/44x/katmai.c |3 +++
arch/powerpc/platforms/44x/sequoia.c |5 -
arch/powerpc/platforms/44x/taishan.c |2 ++
8 files changed, 24 insertions(+), 1 deletion(-)
Index: linux-work/arch/powerpc/platforms/44x/bamboo.c
===
--- linux-work.orig/arch/powerpc/platforms/44x/bamboo.c 2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/44x/bamboo.c 2007-12-05
11:23:35.0 +1100
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+
#include "44x.h"
static struct of_device_id bamboo_of_bus[] = {
@@ -48,6 +50,8 @@ static int __init bamboo_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,bamboo"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/40x/ep405.c
===
--- linux-work.orig/arch/powerpc/platforms/40x/ep405.c 2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/40x/ep405.c 2007-12-05
11:23:35.0 +1100
@@ -102,6 +102,8 @@ static void __init ep405_setup_arch(void
{
/* Find & init the BCSR CPLD */
ep405_init_bcsr();
+
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
}
static int __init ep405_probe(void)
Index: linux-work/arch/powerpc/platforms/40x/kilauea.c
===
--- linux-work.orig/arch/powerpc/platforms/40x/kilauea.c2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/40x/kilauea.c 2007-12-05
11:24:41.0 +1100
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
static struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -45,6 +46,8 @@ static int __init kilauea_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,kilauea"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/40x/walnut.c
===
--- linux-work.orig/arch/powerpc/platforms/40x/walnut.c 2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/40x/walnut.c 2007-12-05
11:24:47.0 +1100
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
static struct of_device_id walnut_of_bus[] = {
{ .compatible = "ibm,plb3", },
@@ -51,6 +52,8 @@ static int __init walnut_probe(void)
if (!of_flat_dt_is_compatible(root, "ibm,walnut"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/ebony.c
===
--- linux-work.orig/arch/powerpc/platforms/44x/ebony.c 2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/44x/ebony.c 2007-12-05
11:24:13.0 +1100
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "44x.h"
@@ -55,6 +56,8 @@ static int __init ebony_probe(void)
if (!of_flat_dt_is_compatible(root, "ibm,ebony"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/katmai.c
===
--- linux-work.orig/arch/powerpc/platforms/44x/katmai.c 2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/44x/katmai.c 2007-12-05
11:24:00.0 +1100
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "44x.h"
@@ -49,6 +50,8 @@ static int __init katmai_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,katmai"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/sequoia.c
===
--- linux-work.orig/arch/powerpc/platforms/44x/sequoia.c2007-12-05
11:22:15.0 +1100
+++ linux-work/arch/powerpc/platforms/44x/sequoia.c 2007-12-05
11:24:53.0 +1100
@@ -21,7 +21,8 @@
#
[RFC/PATCH 5/6] powerpc: pci32: Remove obsolete PowerMac bus number hack
The 32 bits PCI code carries an old hack that was only useful for G5
machines. Nowdays, the 32 bits kernel doesn't support any of those
machines anymore so the hack is basically never used, remove it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c | 11 ---
1 file changed, 11 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-12-05
11:36:30.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-12-05 11:36:36.0
+1100
@@ -922,17 +922,6 @@ long sys_pciconfig_iobase(long which, un
struct pci_controller* hose;
long result = -EOPNOTSUPP;
- /* Argh ! Please forgive me for that hack, but that's the
-* simplest way to get existing XFree to not lockup on some
-* G5 machines... So when something asks for bus 0 io base
-* (bus 0 is HT root), we return the AGP one instead.
-*/
-#ifdef CONFIG_PPC_PMAC
- if (machine_is(powermac) && machine_is_compatible("MacRISC4"))
- if (bus == 0)
- bus = 0xf0;
-#endif /* CONFIG_PPC_PMAC */
-
hose = pci_bus_to_hose(bus);
if (!hose)
return -ENODEV;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 4/6] powerpc: pci32: Add flags modifying the PCI code behaviour
This adds to the 32 bits PCI code some flags, replacing the old
pci_assign_all_busses global, that allow to control various
aspects of the PCI probing, such as whether to re-assign all
resources or not, or to not try to assign anything at all.
This also adds the flag x86 already has to avoid ISA alignment
on bridges that don't have ISA forwarding enabled (no legacy
devices on the top level bus) and sets it for PowerMacs.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c | 42 --
arch/powerpc/kernel/pci_64.c |1
arch/powerpc/kernel/rtas_pci.c|6 ++--
arch/powerpc/platforms/52xx/mpc52xx_pci.c |2 -
arch/powerpc/platforms/82xx/pq2.c |2 -
arch/powerpc/platforms/83xx/pci.c |2 -
arch/powerpc/platforms/chrp/pci.c |2 -
arch/powerpc/platforms/powermac/pci.c |6 ++--
arch/powerpc/sysdev/fsl_pci.c |2 -
arch/powerpc/sysdev/grackle.c |2 -
include/asm-powerpc/pci-bridge.h | 20 ++
include/asm-powerpc/pci.h |9 --
12 files changed, 74 insertions(+), 22 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-12-05
11:10:45.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-12-05 11:16:34.0
+1100
@@ -35,6 +35,9 @@ unsigned long isa_io_base = 0;
unsigned long pci_dram_offset = 0;
int pcibios_assign_bus_offset = 1;
+/* Default PCI flags is 0 */
+unsigned int ppc_pci_flags;
+
void pcibios_make_OF_bus_map(void);
static void pcibios_fixup_resources(struct pci_dev* dev);
@@ -48,7 +51,7 @@ static u8* pci_to_OF_bus_map;
/* By default, we don't re-assign bus numbers. We do this only on
* some pmacs
*/
-int pci_assign_all_buses;
+static int pci_assign_all_buses;
LIST_HEAD(hose_list);
@@ -174,6 +177,14 @@ void pcibios_bus_to_resource(struct pci_
}
EXPORT_SYMBOL(pcibios_bus_to_resource);
+static int skip_isa_ioresource_align(struct pci_dev *dev)
+{
+ if ((ppc_pci_flags & PPC_PCI_CAN_SKIP_ISA_ALIGN) &&
+ !(dev->bus->bridge_ctl & PCI_BRIDGE_CTL_ISA))
+ return 1;
+ return 0;
+}
+
/*
* We need to avoid collisions with `mirrored' VGA ports
* and other strange ISA hardware, so we always want the
@@ -195,6 +206,8 @@ void pcibios_align_resource(void *data,
if (res->flags & IORESOURCE_IO) {
resource_size_t start = res->start;
+ if (skip_isa_ioresource_align(dev))
+ return;
if (start & 0x300) {
start = (start + 0x3ff) & ~0x3ff;
res->start = start;
@@ -251,8 +264,13 @@ pcibios_allocate_bus_resources(struct li
continue;
if (bus->parent == NULL)
pr = (res->flags & IORESOURCE_IO)?
- &ioport_resource: &iomem_resource;
+ &ioport_resource : &iomem_resource;
else {
+ /* Don't bother with non-root busses when
+* re-assigning all resources.
+*/
+ if (ppc_pci_flags & PPC_PCI_REASSIGN_ALL_RSRC)
+ continue;
pr = pci_find_parent_resource(bus->self, res);
if (pr == res) {
/* this happens when the generic PCI
@@ -720,6 +738,9 @@ pcibios_init(void)
printk(KERN_INFO "PCI: Probing PCI hardware\n");
+ if (ppc_pci_flags & PPC_PCI_REASSIGN_ALL_BUS)
+ pci_assign_all_buses = 1;
+
/* Scan all of the recorded PCI controllers. */
list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
if (pci_assign_all_buses)
@@ -746,13 +767,18 @@ pcibios_init(void)
if (ppc_md.pcibios_fixup)
ppc_md.pcibios_fixup();
- /* Allocate and assign resources */
+ /* Allocate and assign resources. If we re-assign everything, then
+* we skip the allocate phase
+*/
pcibios_allocate_bus_resources(&pci_root_buses);
- pcibios_allocate_resources(0);
- pcibios_allocate_resources(1);
-
- DBG("PCI: Assigning unassigned resouces...\n");
- pci_assign_unassigned_resources();
+ if (!(ppc_pci_flags & PPC_PCI_REASSIGN_ALL_RSRC)) {
+ pcibios_allocate_resources(0);
+ pcibios_allocate_resources(1);
+ }
+ if (!(ppc_pci_flags & PPC_PCI_PROBE_ONLY)) {
+ DBG("PCI: Assigning unassigned resouces...\n");
+ pci_assign_unassigned_resources();
+ }
[RFC/PATCH 3/6] powerpc: pci32: Remove PowerMac P2P bridge IO hack
The 32 bits PowerPC PCI code has a hack for use by some PowerMacs
to try to re-open PCI<->PCI bridge IO resources that were closed
by the firmware. This is no longer necessary as the generic code
will now do that for us.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c | 215 ---
1 file changed, 1 insertion(+), 214 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-12-04
17:02:13.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-12-04 17:02:31.0
+1100
@@ -711,217 +711,6 @@ void pcibios_make_OF_bus_map(void)
}
#endif /* CONFIG_PPC_OF */
-#ifdef CONFIG_PPC_PMAC
-/*
- * This set of routines checks for PCI<->PCI bridges that have closed
- * IO resources and have child devices. It tries to re-open an IO
- * window on them.
- *
- * This is a _temporary_ fix to workaround a problem with Apple's OF
- * closing IO windows on P2P bridges when the OF drivers of cards
- * below this bridge don't claim any IO range (typically ATI or
- * Adaptec).
- *
- * A more complete fix would be to use drivers/pci/setup-bus.c, which
- * involves a working pcibios_fixup_pbus_ranges(), some more care about
- * ordering when creating the host bus resources, and maybe a few more
- * minor tweaks
- */
-
-/* Initialize bridges with base/limit values we have collected */
-static void __init
-do_update_p2p_io_resource(struct pci_bus *bus, int enable_vga)
-{
- struct pci_dev *bridge = bus->self;
- struct pci_controller* hose = (struct pci_controller *)bridge->sysdata;
- u32 l;
- u16 w;
- struct resource res;
-
- if (bus->resource[0] == NULL)
- return;
- res = *(bus->resource[0]);
-
- DBG("Remapping Bus %d, bridge: %s\n", bus->number, pci_name(bridge));
- res.start -= ((unsigned long) hose->io_base_virt - isa_io_base);
- res.end -= ((unsigned long) hose->io_base_virt - isa_io_base);
- DBG(" IO window: %016llx-%016llx\n", res.start, res.end);
-
- /* Set up the top and bottom of the PCI I/O segment for this bus. */
- pci_read_config_dword(bridge, PCI_IO_BASE, &l);
- l &= 0x000f;
- l |= (res.start >> 8) & 0x00f0;
- l |= res.end & 0xf000;
- pci_write_config_dword(bridge, PCI_IO_BASE, l);
-
- if ((l & PCI_IO_RANGE_TYPE_MASK) == PCI_IO_RANGE_TYPE_32) {
- l = (res.start >> 16) | (res.end & 0x);
- pci_write_config_dword(bridge, PCI_IO_BASE_UPPER16, l);
- }
-
- pci_read_config_word(bridge, PCI_COMMAND, &w);
- w |= PCI_COMMAND_IO;
- pci_write_config_word(bridge, PCI_COMMAND, w);
-
-#if 0 /* Enabling this causes XFree 4.2.0 to hang during PCI probe */
- if (enable_vga) {
- pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &w);
- w |= PCI_BRIDGE_CTL_VGA;
- pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, w);
- }
-#endif
-}
-
-/* This function is pretty basic and actually quite broken for the
- * general case, it's enough for us right now though. It's supposed
- * to tell us if we need to open an IO range at all or not and what
- * size.
- */
-static int __init
-check_for_io_childs(struct pci_bus *bus, struct resource* res, int *found_vga)
-{
- struct pci_dev *dev;
- int i;
- int rc = 0;
-
-#define push_end(res, mask) do { \
- BUG_ON((mask+1) & mask);\
- res->end = (res->end + mask) | mask;\
-} while (0)
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- u16 class = dev->class >> 8;
-
- if (class == PCI_CLASS_DISPLAY_VGA ||
- class == PCI_CLASS_NOT_DEFINED_VGA)
- *found_vga = 1;
- if (class >> 8 == PCI_BASE_CLASS_BRIDGE && dev->subordinate)
- rc |= check_for_io_childs(dev->subordinate, res,
found_vga);
- if (class == PCI_CLASS_BRIDGE_CARDBUS)
- push_end(res, 0xfff);
-
- for (i=0; iclass >> 8 == PCI_CLASS_BRIDGE_PCI
- && i >= PCI_BRIDGE_RESOURCES)
- continue;
- r = &dev->resource[i];
- r_size = r->end - r->start;
- if (r_size < 0xfff)
- r_size = 0xfff;
- if (r->flags & IORESOURCE_IO && (r_size) != 0) {
- rc = 1;
- push_end(res, r_size);
- }
- }
- }
-
- return rc;
-}
-
-/* Here we scan all P2P bridges of a given level that have a closed
- * IO window. Note that the test for the presence of a VGA card should
- * be improved to take into account already con
[RFC/PATCH 2/6] powerpc: pci32: use generic pci_assign_unassign_resources
This makes the 32 bits PowerPC PCI code use the generic code to assign
resources to devices that had unassigned or conflicting resources.
This allow to remove the local implementation that was incomplete and
could not assign for example a PCI<->PCI bridge from scratch, which is
needed on various embedded platforms.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c | 191 +++
1 file changed, 17 insertions(+), 174 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-12-04
17:02:12.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-12-04 17:02:13.0
+1100
@@ -37,10 +37,6 @@ int pcibios_assign_bus_offset = 1;
void pcibios_make_OF_bus_map(void);
-static int pci_relocate_bridge_resource(struct pci_bus *bus, int i);
-static int probe_resource(struct pci_bus *parent, struct resource *pr,
- struct resource *res, struct resource **conflict);
-static void update_bridge_base(struct pci_bus *bus, int i);
static void pcibios_fixup_resources(struct pci_dev* dev);
static void fixup_broken_pcnet32(struct pci_dev* dev);
static int reparent_resources(struct resource *parent, struct resource *res);
@@ -134,7 +130,7 @@ pcibios_fixup_resources(struct pci_dev *
if (offset != 0) {
res->start = (res->start + offset) & mask;
res->end = (res->end + offset) & mask;
- DBG("Fixup res %d (%lx) of dev %s: %llx -> %llx\n",
+ DBG("PCI: Fixup res %d (0x%lx) of dev %s: %llx ->
%llx\n",
i, res->flags, pci_name(dev),
(u64)res->start - offset, (u64)res->start);
}
@@ -267,9 +263,12 @@ pcibios_allocate_bus_resources(struct li
}
}
- DBG("PCI: bridge rsrc %llx..%llx (%lx), parent %p\n",
+ DBG("PCI: dev %s (bus 0x%02x) bridge rsrc %d:
%016llx..%016llx "
+ "(f:0x%08lx), parent %p\n",
+ bus->self ? pci_name(bus->self) : "PHB",
bus->number, i,
(u64)res->start, (u64)res->end, res->flags, pr);
- if (pr) {
+
+ if (pr && !(pr->flags & IORESOURCE_UNSET)) {
if (request_resource(pr, res) == 0)
continue;
/*
@@ -280,10 +279,11 @@ pcibios_allocate_bus_resources(struct li
if (reparent_resources(pr, res) == 0)
continue;
}
- printk(KERN_ERR "PCI: Cannot allocate resource region "
- "%d of PCI bridge %d\n", i, bus->number);
- if (pci_relocate_bridge_resource(bus, i))
- bus->resource[i] = NULL;
+ printk(KERN_WARNING
+ "PCI: Cannot allocate resource region "
+ "%d of PCI bridge %d, will remap\n",
+ i, bus->number);
+ res->flags |= IORESOURCE_UNSET;
}
pcibios_allocate_bus_resources(&bus->children);
}
@@ -324,112 +324,6 @@ reparent_resources(struct resource *pare
return 0;
}
-/*
- * A bridge has been allocated a range which is outside the range
- * of its parent bridge, so it needs to be moved.
- */
-static int __init
-pci_relocate_bridge_resource(struct pci_bus *bus, int i)
-{
- struct resource *res, *pr, *conflict;
- resource_size_t try, size;
- struct pci_bus *parent = bus->parent;
- int j;
-
- if (parent == NULL) {
- /* shouldn't ever happen */
- printk(KERN_ERR "PCI: can't move host bridge resource\n");
- return -1;
- }
- res = bus->resource[i];
- if (res == NULL)
- return -1;
- pr = NULL;
- for (j = 0; j < 4; j++) {
- struct resource *r = parent->resource[j];
- if (!r)
- continue;
- if ((res->flags ^ r->flags) & (IORESOURCE_IO | IORESOURCE_MEM))
- continue;
- if (!((res->flags ^ r->flags) & IORESOURCE_PREFETCH)) {
- pr = r;
- break;
- }
- if (res->flags & IORESOURCE_PREFETCH)
- pr = r;
- }
- if (pr == NULL)
- return -1;
- size = res->end - res->start;
- if (pr->start > pr->end || size > pr->end - pr->start)
- return -1;
- try = pr->end;
- for (
[RFC/PATCH 1/6] powerpc: pci32: remove bogus alignment message
There's a stale & bogus piece of code in 32 bits PCI code that
complains about ISA related alignment issues. Just remove it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c |6 --
1 file changed, 6 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci_32.c
===
--- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-12-04
16:59:57.0 +1100
+++ linux-work/arch/powerpc/kernel/pci_32.c 2007-12-04 16:59:57.0
+1100
@@ -199,12 +199,6 @@ void pcibios_align_resource(void *data,
if (res->flags & IORESOURCE_IO) {
resource_size_t start = res->start;
- if (size > 0x100) {
- printk(KERN_ERR "PCI: I/O Region %s/%d too large"
- " (%lld bytes)\n", pci_name(dev),
- dev->resource - res, (unsigned long long)size);
- }
-
if (start & 0x300) {
start = (start + 0x3ff) & ~0x3ff;
res->start = start;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 0/6] powerpc: 32 bits PCI updates
This serie of patches converts the 32 bits PCI code to use the generic pci_assign_unassigned_resources() instead of its own assignment code which was unable to deal with unassigned PCI<->PCI bridges among other issues. We also add flags to control the behaviour of the PCI code, such as letting some platforms force a full re-assignment (similar to what pci-auto used to provide in arch/ppc) and remove a whole bunch of hackish code that is made obsolete by that change. This also brings us one step closer to a merge of the PCI code with ppc64 as we are now in a shape where most of that resource management code will be able to move to pci-common.c and be used by 64 bits. 32 bits platforms with 64 bits resources support will also need my separate patch to fix the generic setup-bus.c for that situation. Note that the patch that updates 4xx platforms to enable full resource assignments applied on top of my 4xx series for which I'll post a new version soon. You can apply the other ones and ignore this one if you want to test on some other platform without the other patch serie. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote: > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote: > > tristate "Generic platform device PATA support" > > - depends on EMBEDDED || ARCH_RPC > > + depends on EMBEDDED || ARCH_PPC > > It needs to be || PPC, not || ARCH_PPC. > Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC. ARCH_RPC is not a typo, it's an ARM platform. Please grep first :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 11/11] ibm_newemac: Update file headers copyright notices
This updates the copyright notices of the new EMAC driver to avoid confusion as who is to be blamed for new bugs. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |5 + drivers/net/ibm_newemac/core.h |5 + drivers/net/ibm_newemac/debug.c |5 + drivers/net/ibm_newemac/debug.h |5 + drivers/net/ibm_newemac/emac.h |5 + drivers/net/ibm_newemac/mal.c |5 + drivers/net/ibm_newemac/mal.h |5 + drivers/net/ibm_newemac/phy.c |5 + drivers/net/ibm_newemac/phy.h |5 + drivers/net/ibm_newemac/rgmii.c |5 + drivers/net/ibm_newemac/rgmii.h |5 + drivers/net/ibm_newemac/tah.c |5 + drivers/net/ibm_newemac/tah.h |5 + drivers/net/ibm_newemac/zmii.c |5 + drivers/net/ibm_newemac/zmii.h |5 + 15 files changed, 75 insertions(+) Index: linux-work/drivers/net/ibm_newemac/core.c === --- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-30 15:35:50.0 +1100 +++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-30 16:03:30.0 +1100 @@ -3,6 +3,11 @@ * * Driver for PowerPC 4xx on-chip ethernet controller. * + * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. + *<[EMAIL PROTECTED]> + * + * Based on the arch/ppc version of the driver: + * * Copyright (c) 2004, 2005 Zultys Technologies. * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> * Index: linux-work/drivers/net/ibm_newemac/core.h === --- linux-work.orig/drivers/net/ibm_newemac/core.h 2007-11-30 15:35:50.0 +1100 +++ linux-work/drivers/net/ibm_newemac/core.h 2007-11-30 16:03:23.0 +1100 @@ -3,6 +3,11 @@ * * Driver for PowerPC 4xx on-chip ethernet controller. * + * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. + *<[EMAIL PROTECTED]> + * + * Based on the arch/ppc version of the driver: + * * Copyright (c) 2004, 2005 Zultys Technologies. * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> * Index: linux-work/drivers/net/ibm_newemac/debug.c === --- linux-work.orig/drivers/net/ibm_newemac/debug.c 2007-11-30 15:35:50.0 +1100 +++ linux-work/drivers/net/ibm_newemac/debug.c 2007-11-30 16:03:18.0 +1100 @@ -3,6 +3,11 @@ * * Driver for PowerPC 4xx on-chip ethernet controller, debug print routines. * + * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. + *<[EMAIL PROTECTED]> + * + * Based on the arch/ppc version of the driver: + * * Copyright (c) 2004, 2005 Zultys Technologies * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> * Index: linux-work/drivers/net/ibm_newemac/debug.h === --- linux-work.orig/drivers/net/ibm_newemac/debug.h 2007-11-30 15:35:50.0 +1100 +++ linux-work/drivers/net/ibm_newemac/debug.h 2007-11-30 16:03:15.0 +1100 @@ -3,6 +3,11 @@ * * Driver for PowerPC 4xx on-chip ethernet controller, debug print routines. * + * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. + *<[EMAIL PROTECTED]> + * + * Based on the arch/ppc version of the driver: + * * Copyright (c) 2004, 2005 Zultys Technologies * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> * Index: linux-work/drivers/net/ibm_newemac/emac.h === --- linux-work.orig/drivers/net/ibm_newemac/emac.h 2007-11-30 15:35:50.0 +1100 +++ linux-work/drivers/net/ibm_newemac/emac.h 2007-11-30 16:03:09.0 +1100 @@ -3,6 +3,11 @@ * * Register definitions for PowerPC 4xx on-chip ethernet contoller * + * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. + *<[EMAIL PROTECTED]> + * + * Based on the arch/ppc version of the driver: + * * Copyright (c) 2004, 2005 Zultys Technologies. * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> * Index: linux-work/drivers/net/ibm_newemac/mal.c === --- linux-work.orig/drivers/net/ibm_newemac/mal.c 2007-11-30 15:35:51.0 +1100 +++ linux-work/drivers/net/ibm_newemac/mal.c2007-11-30 16:03:02.0 +1100 @@ -3,6 +3,11 @@ * * Memory Access Layer (MAL) support * + * Copyright 2007 Benjamin Herrenschmidt, IBM Corp. + *<[EMAIL PROTECTED]> + * + * Based on the arch/ppc version of the driver: + * * Copyright (c) 2004, 2005 Zultys Technologies. * Eugene Surovegin <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> * Index: linux-work/drivers/net/ibm_newemac/mal.h === --- linux-work.orig/drivers/net/ibm_newemac/mal.h 2007-11-30 15:35:51.0
[PATCH 10/11] ibm_newemac: Call dev_set_drvdata() before tah_reset()
From: Valentine Barshak <[EMAIL PROTECTED]> The patch moves dev_set_drvdata(&ofdev->dev, dev) up before tah_reset(ofdev) is called to avoid a NULL pointer dereference, since tah_reset uses drvdata. Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/tah.c linux-2.6/drivers/net/ibm_newemac/tah.c --- linux-2.6.orig/drivers/net/ibm_newemac/tah.c2007-11-23 21:27:57.0 +0300 +++ linux-2.6/drivers/net/ibm_newemac/tah.c 2007-11-23 21:35:12.0 +0300 @@ -116,13 +116,14 @@ static int __devinit tah_probe(struct of goto err_free; } + dev_set_drvdata(&ofdev->dev, dev); + /* Initialize TAH and enable IPv4 checksum verification, no TSO yet */ tah_reset(ofdev); printk(KERN_INFO "TAH %s initialized\n", ofdev->node->full_name); wmb(); - dev_set_drvdata(&ofdev->dev, dev); return 0; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 9/11] ibm_newemac: Fix typo reading TAH channel info
From: Valentine Barshak <[EMAIL PROTECTED]> This patch fixes a typo in ibm_newemac/core.c (tah_port should be used instead of tah_ph) Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-work/drivers/net/ibm_newemac/core.c === --- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-26 09:43:04.0 +1100 +++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-26 09:43:05.0 +1100 @@ -2442,7 +2442,7 @@ static int __devinit emac_init_config(st if (emac_read_uint_prop(np, "tah-device", &dev->tah_ph, 0)) dev->tah_ph = 0; if (emac_read_uint_prop(np, "tah-channel", &dev->tah_port, 0)) - dev->tah_ph = 0; + dev->tah_port = 0; if (emac_read_uint_prop(np, "mdio-device", &dev->mdio_ph, 0)) dev->mdio_ph = 0; if (emac_read_uint_prop(np, "zmii-device", &dev->zmii_ph, 0)) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/11] ibm_newemac: Correct opb_bus_freq value
From: Valentine Barshak <[EMAIL PROTECTED]>
The EMAC4_MR1_OBCI(freq) macro expects freg in MHz,
while opb_bus_freq is kept in Hz. Correct this.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c
linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-11-23
21:27:57.0 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c2007-11-23 21:47:53.0
+0300
@@ -402,7 +402,7 @@ static u32 __emac_calc_base_mr1(struct e
static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int
rx_size)
{
u32 ret = EMAC_MR1_VLE | EMAC_MR1_IST | EMAC4_MR1_TR |
- EMAC4_MR1_OBCI(dev->opb_bus_freq);
+ EMAC4_MR1_OBCI(dev->opb_bus_freq / 100);
DBG2(dev, "__emac4_calc_base_mr1" NL);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
From: Hugh Blemings <[EMAIL PROTECTED]> Depending on how the 44x processors are wired, some EMAC cells might not be useable (and not connected to a PHY). However, some device-trees may choose to still expose them (since their registers are present in the MMIO space) but with an "unused" property in them. Signed-off-by: Hugh Blemings <[EMAIL PROTECTED]> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |4 1 file changed, 4 insertions(+) Index: linux-work/drivers/net/ibm_newemac/core.c === --- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-20 14:47:02.0 +1100 +++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-20 14:47:05.0 +1100 @@ -2550,6 +2550,10 @@ static int __devinit emac_probe(struct o struct device_node **blist = NULL; int err, i; + /* Skip unused/unwired EMACS */ + if (of_get_property(np, "unused", NULL)) + return -ENODEV; + /* Find ourselves in the bootlist if we are there */ for (i = 0; i < EMAC_BOOT_LIST_SIZE; i++) if (emac_boot_list[i] == np) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/11] ibm_newemac: Cleanup/fix support for STACR register variants
There are a few variants of the STACR register that affect more than
just the "AXON" version of EMAC. Replace the current test of various
chip models with tests for generic properties in the device-tree.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts |4
drivers/net/ibm_newemac/core.c| 23 +--
drivers/net/ibm_newemac/core.h|6 +++---
3 files changed, 20 insertions(+), 13 deletions(-)
Index: linux-work/arch/powerpc/boot/dts/sequoia.dts
===
--- linux-work.orig/arch/powerpc/boot/dts/sequoia.dts 2007-11-20
14:47:01.0 +1100
+++ linux-work/arch/powerpc/boot/dts/sequoia.dts2007-11-20
14:47:02.0 +1100
@@ -274,6 +274,8 @@
zmii-channel = <0>;
rgmii-device = <&RGMII0>;
rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
};
EMAC1: [EMAIL PROTECTED] {
@@ -302,6 +304,8 @@
zmii-channel = <1>;
rgmii-device = <&RGMII0>;
rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
};
};
};
Index: linux-work/drivers/net/ibm_newemac/core.c
===
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-20
14:46:58.0 +1100
+++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-20 14:47:02.0
+1100
@@ -711,7 +711,7 @@ static int __emac_mdio_read(struct emac_
r = EMAC_STACR_BASE(dev->opb_bus_freq);
if (emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
r |= EMAC_STACR_OC;
- if (emac_has_feature(dev, EMAC_FTR_HAS_AXON_STACR))
+ if (emac_has_feature(dev, EMAC_FTR_HAS_NEW_STACR))
r |= EMACX_STACR_STAC_READ;
else
r |= EMAC_STACR_STAC_READ;
@@ -783,7 +783,7 @@ static void __emac_mdio_write(struct ema
r = EMAC_STACR_BASE(dev->opb_bus_freq);
if (emac_has_feature(dev, EMAC_FTR_STACR_OC_INVERT))
r |= EMAC_STACR_OC;
- if (emac_has_feature(dev, EMAC_FTR_HAS_AXON_STACR))
+ if (emac_has_feature(dev, EMAC_FTR_HAS_NEW_STACR))
r |= EMACX_STACR_STAC_WRITE;
else
r |= EMAC_STACR_STAC_WRITE;
@@ -2480,16 +2480,19 @@ static int __devinit emac_init_config(st
/* Check EMAC version */
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
- if (of_device_is_compatible(np, "ibm,emac-axon")
- || of_device_is_compatible(np, "ibm,emac-440epx"))
- dev->features |= EMAC_FTR_HAS_AXON_STACR
- | EMAC_FTR_STACR_OC_INVERT;
- if (of_device_is_compatible(np, "ibm,emac-440spe"))
+
+ /* Fixup some feature bits based on the device tree */
+ if (of_get_property(np, "has-inverted-stacr-oc", NULL))
dev->features |= EMAC_FTR_STACR_OC_INVERT;
+ if (of_get_property(np, "has-new-stacr-staopc", NULL))
+ dev->features |= EMAC_FTR_HAS_NEW_STACR;
- /* Fixup some feature bits based on the device tree and verify
-* we have support for them compiled in
-*/
+ /* CAB lacks the appropriate properties */
+ if (of_device_is_compatible(np, "ibm,emac-axon"))
+ dev->features |= EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_STACR_OC_INVERT;
+
+ /* Enable TAH/ZMII/RGMII features as found */
if (dev->tah_ph != 0) {
#ifdef CONFIG_IBM_NEW_EMAC_TAH
dev->features |= EMAC_FTR_HAS_TAH;
Index: linux-work/drivers/net/ibm_newemac/core.h
===
--- linux-work.orig/drivers/net/ibm_newemac/core.h 2007-11-20
14:46:51.0 +1100
+++ linux-work/drivers/net/ibm_newemac/core.h 2007-11-20 14:47:02.0
+1100
@@ -293,9 +293,9 @@ struct emac_instance {
*/
#define EMAC_FTR_HAS_RGMII 0x0020
/*
- * Set if we have axon-type STACR
+ * Set if we have new type STACR with STAOPC
*/
-#define EMAC_FTR_HAS_AXON_STACR0x0040
+#define EMAC_FTR_HAS_NEW_STACR 0x0040
/* Right now, we don't quite handle the always/possible masks on the
@@ -307,7 +307,7 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_AXON_STACR |
+ EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR|
EMAC_FTR_STACR_OC_INVERT|
#endif
#ifdef CONFIG_IB
[PATCH 5/11] ibm_newemac: Cleanup/Fix RGMII MDIO support detection
More than just "AXON" version of EMAC RGMII supports MDIO, so replace
the current test with a generic property in the device-tree that
indicates such support.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts |1 +
drivers/net/ibm_newemac/rgmii.c | 20 +++-
drivers/net/ibm_newemac/rgmii.h |5 +++--
3 files changed, 15 insertions(+), 11 deletions(-)
Index: linux-work/drivers/net/ibm_newemac/rgmii.c
===
--- linux-work.orig/drivers/net/ibm_newemac/rgmii.c 2007-11-12
10:55:54.0 +1100
+++ linux-work/drivers/net/ibm_newemac/rgmii.c 2007-11-12 10:56:56.0
+1100
@@ -140,7 +140,7 @@ void rgmii_get_mdio(struct of_device *of
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ if (!(dev->flags & EMAC_RGMII_FLAG_HAS_MDIO))
return;
mutex_lock(&dev->lock);
@@ -161,7 +161,7 @@ void rgmii_put_mdio(struct of_device *of
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ if (!(dev->flags & EMAC_RGMII_FLAG_HAS_MDIO))
return;
fer = in_be32(&p->fer);
@@ -250,11 +250,13 @@ static int __devinit rgmii_probe(struct
goto err_free;
}
- /* Check for RGMII type */
+ /* Check for RGMII flags */
+ if (of_get_property(ofdev->node, "has-mdio", NULL))
+ dev->flags |= EMAC_RGMII_FLAG_HAS_MDIO;
+
+ /* CAB lacks the right properties, fix this up */
if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
- dev->type = RGMII_AXON;
- else
- dev->type = RGMII_STANDARD;
+ dev->flags |= EMAC_RGMII_FLAG_HAS_MDIO;
DBG2(dev, " Boot FER = 0x%08x, SSR = 0x%08x\n",
in_be32(&dev->base->fer), in_be32(&dev->base->ssr));
@@ -263,9 +265,9 @@ static int __devinit rgmii_probe(struct
out_be32(&dev->base->fer, 0);
printk(KERN_INFO
- "RGMII %s %s initialized\n",
- dev->type == RGMII_STANDARD ? "standard" : "axon",
- ofdev->node->full_name);
+ "RGMII %s initialized with%s MDIO support\n",
+ ofdev->node->full_name,
+ (dev->flags & EMAC_RGMII_FLAG_HAS_MDIO) ? "" : "out");
wmb();
dev_set_drvdata(&ofdev->dev, dev);
Index: linux-work/drivers/net/ibm_newemac/rgmii.h
===
--- linux-work.orig/drivers/net/ibm_newemac/rgmii.h 2007-11-12
10:55:54.0 +1100
+++ linux-work/drivers/net/ibm_newemac/rgmii.h 2007-11-12 10:56:56.0
+1100
@@ -35,8 +35,9 @@ struct rgmii_regs {
struct rgmii_instance {
struct rgmii_regs __iomem *base;
- /* Type of RGMII bridge */
- int type;
+ /* RGMII bridge flags */
+ int flags;
+#define EMAC_RGMII_FLAG_HAS_MDIO 0x0001
/* Only one EMAC whacks us at a time */
struct mutexlock;
Index: linux-work/arch/powerpc/boot/dts/sequoia.dts
===
--- linux-work.orig/arch/powerpc/boot/dts/sequoia.dts 2007-11-12
10:58:38.0 +1100
+++ linux-work/arch/powerpc/boot/dts/sequoia.dts2007-11-12
10:58:47.0 +1100
@@ -245,6 +245,7 @@
device_type = "rgmii-interface";
compatible = "ibm,rgmii-440epx", "ibm,rgmii";
reg = ;
+ has-mdio;
};
EMAC0: [EMAIL PROTECTED] {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/11] ibm_newemac: Workaround reset timeout when no link
With some PHYs, when the link goes away, the EMAC reset fails due
to the loss of the RX clock I believe.
The old EMAC driver worked around that using some internal chip-specific
clock force bits that are different on various 44x implementations.
This is an attempt at doing it differently, by avoiding the reset when
there is no link, but forcing loopback mode instead. It seems to work
on my Taishan 440GX based board so far.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
Index: linux-work/drivers/net/ibm_newemac/core.c
===
--- linux-work.orig/drivers/net/ibm_newemac/core.c 2007-11-20
14:46:51.0 +1100
+++ linux-work/drivers/net/ibm_newemac/core.c 2007-11-20 14:46:58.0
+1100
@@ -464,26 +464,34 @@ static int emac_configure(struct emac_in
{
struct emac_regs __iomem *p = dev->emacp;
struct net_device *ndev = dev->ndev;
- int tx_size, rx_size;
+ int tx_size, rx_size, link = netif_carrier_ok(dev->ndev);
u32 r, mr1 = 0;
DBG(dev, "configure" NL);
- if (emac_reset(dev) < 0)
+ if (!link) {
+ out_be32(&p->mr1, in_be32(&p->mr1)
+| EMAC_MR1_FDE | EMAC_MR1_ILE);
+ udelay(100);
+ } else if (emac_reset(dev) < 0)
return -ETIMEDOUT;
if (emac_has_feature(dev, EMAC_FTR_HAS_TAH))
tah_reset(dev->tah_dev);
- DBG(dev, " duplex = %d, pause = %d, asym_pause = %d\n",
- dev->phy.duplex, dev->phy.pause, dev->phy.asym_pause);
+ DBG(dev, " link = %d duplex = %d, pause = %d, asym_pause = %d\n",
+ link, dev->phy.duplex, dev->phy.pause, dev->phy.asym_pause);
/* Default fifo sizes */
tx_size = dev->tx_fifo_size;
rx_size = dev->rx_fifo_size;
+ /* No link, force loopback */
+ if (!link)
+ mr1 = EMAC_MR1_FDE | EMAC_MR1_ILE;
+
/* Check for full duplex */
- if (dev->phy.duplex == DUPLEX_FULL)
+ else if (dev->phy.duplex == DUPLEX_FULL)
mr1 |= EMAC_MR1_FDE | EMAC_MR1_MWSW_001;
/* Adjust fifo sizes, mr1 and timeouts based on link speed */
@@ -1165,9 +1173,9 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_ON;
} else {
if (netif_carrier_ok(dev->ndev)) {
- emac_reinitialize(dev);
netif_carrier_off(dev->ndev);
netif_tx_disable(dev->ndev);
+ emac_reinitialize(dev);
emac_print_link_status(dev);
}
link_poll_interval = PHY_POLL_LINK_OFF;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/11] ibm_newemac: Fix ZMII refcounting bug
When using ZMII for MDIO only (such as 440GX with RGMII for data and ZMII for
MDIO), the ZMII code would fail to properly refcount, thus triggering a
BUG_ON().
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/zmii.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-work/drivers/net/ibm_newemac/zmii.c
===
--- linux-work.orig/drivers/net/ibm_newemac/zmii.c 2007-11-08
15:45:32.0 +1100
+++ linux-work/drivers/net/ibm_newemac/zmii.c 2007-11-08 15:46:21.0
+1100
@@ -83,12 +83,14 @@ int __devinit zmii_attach(struct of_devi
ZMII_DBG(dev, "init(%d, %d)" NL, input, *mode);
- if (!zmii_valid_mode(*mode))
+ if (!zmii_valid_mode(*mode)) {
/* Probably an EMAC connected to RGMII,
* but it still may need ZMII for MDIO so
* we don't fail here.
*/
+ dev->users++;
return 0;
+ }
mutex_lock(&dev->lock);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese <[EMAIL PROTECTED]>
This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
board.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 37 +
1 file changed, 37 insertions(+)
Index: linux-work/drivers/net/ibm_newemac/phy.c
===
--- linux-work.orig/drivers/net/ibm_newemac/phy.c 2007-12-03
11:58:16.0 +1100
+++ linux-work/drivers/net/ibm_newemac/phy.c2007-12-03 11:59:53.0
+1100
@@ -327,6 +327,42 @@ static int m88e_init(struct mii_phy
return 0;
}
+static int et1011c_init(struct mii_phy *phy)
+{
+ u16 reg_short;
+
+ reg_short = (u16)(phy_read(phy, 0x16));
+ reg_short &= ~(0x7);
+ reg_short |= 0x6; /* RGMII Trace Delay*/
+ phy_write(phy, 0x16, reg_short);
+
+ reg_short = (u16)(phy_read(phy, 0x17));
+ reg_short &= ~(0x40);
+ phy_write(phy, 0x17, reg_short);
+
+ phy_write(phy, 0x1c, 0x74f0);
+ return 0;
+}
+
+static struct mii_phy_ops et1011c_phy_ops = {
+ .init = et1011c_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def et1011c_phy_def = {
+ .phy_id = 0x0282f000,
+ .phy_id_mask= 0x0f00,
+ .name = "ET1011C Gigabit Ethernet",
+ .ops= &et1011c_phy_ops
+};
+
+
+
+
+
static struct mii_phy_ops m88e_phy_ops = {
.init = m88e_init,
.setup_aneg = genmii_setup_aneg,
@@ -344,6 +380,7 @@ static struct mii_phy_def m88e_phy_d
};
static struct mii_phy_def *mii_phy_table[] = {
+ &et1011c_phy_def,
&cis8201_phy_def,
&bcm5248_phy_def,
&m88e_phy_def,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Stefan Roese <[EMAIL PROTECTED]>
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 39 +++
1 file changed, 39 insertions(+)
Index: linux-work/drivers/net/ibm_newemac/phy.c
===
--- linux-work.orig/drivers/net/ibm_newemac/phy.c 2007-12-03
11:50:26.0 +1100
+++ linux-work/drivers/net/ibm_newemac/phy.c2007-12-03 11:58:16.0
+1100
@@ -306,8 +306,47 @@ static struct mii_phy_def cis8201_phy_de
.ops= &cis8201_phy_ops
};
+static struct mii_phy_def bcm5248_phy_def = {
+
+ .phy_id = 0x0143bc00,
+ .phy_id_mask= 0x0ff0,
+ .name = "BCM5248 10/100 SMII Ethernet",
+ .ops= &generic_phy_ops
+};
+
+static int m88e_init(struct mii_phy *phy)
+{
+ pr_debug("%s: Marvell 88E Ethernet\n", __FUNCTION__);
+ phy_write(phy, 0x14, 0x0ce3);
+ phy_write(phy, 0x18, 0x4101);
+ phy_write(phy, 0x09, 0x0e00);
+ phy_write(phy, 0x04, 0x01e1);
+ phy_write(phy, 0x00, 0x9140);
+ phy_write(phy, 0x00, 0x1140);
+
+ return 0;
+}
+
+static struct mii_phy_ops m88e_phy_ops = {
+ .init = m88e_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def m88e_phy_def = {
+
+ .phy_id = 0x01410CC0,
+ .phy_id_mask= 0x0ff0,
+ .name = "Marvell 88E Ethernet",
+ .ops= &m88e_phy_ops,
+};
+
static struct mii_phy_def *mii_phy_table[] = {
&cis8201_phy_def,
+ &bcm5248_phy_def,
+ &m88e_phy_def,
&genmii_phy_def,
NULL
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On Tue, Dec 04, 2007 at 01:05:46PM -0700, Grant Likely wrote: > On 12/4/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2007-12-04 at 11:01 -0700, Mark A. Greer wrote: > > > On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote: > > > > > > > > On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote: > > > > > From: Mark A. Greer <[EMAIL PROTECTED]> > > > > > > > > > > The ppc_md.power_off hook performs the same function that the > > > > > pm_power_off hook is supposed to. However, it is powerpc-specific > > > > > and prevents kernel drivers (e.g., IPMI) from changing how a platform > > > > > is powered off. So, get rid of ppc_md.power_off and replace it with > > > > > pm_power_off. > > > > > > > > I'm less happy with that one... probably aesthetics :-) > > > > > > > > Can't we just have the generic code call pm_power_off and ppc_md and > > > > which ever powers the machine off wins ? > > > > > > Yes, that would be easy to do. Seems like duplication though. > > > If you are sure you're okay with the duplication, I'll do that. > > > > Let's ask Paulus what he thinks. > > We could simply have the setup code copy the ppc_md.power_off pointer > into pm_power_off; that we retain the nice assignment in > define_machine(), but eliminate the duplicated calls. Hmm, yeah, that would look nice--nicer than what I have. The only issue I have with it is that we still have duplication and potential for reassigning the wrong one (e.g., reassigning ppc_md.power_off instead of pm_power_off in maple/setup.c:maple_use_rtas_reboot_and_halt_if_present()). We could call both in machine_power_off but that's messy too (IMHO). Paul, do you have an opinion? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [XILINX][HWICAP] Xilinx Internal Configuration Access Port device driver.
On 12/4/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote: > Supports static platform_device and static device tree configuration. > This is a standalone driver that does not depend on EDK generated > files. However, it is also somewhat different in functionality from > the standard EDK driver. > > 1) The EDK driver doesn't support readback, which this driver does. > 2) The EDK driver supports fine granularity reading and writing, which > this driver does not. The fine granularity support is heavily > architecture independent, which makes it difficult to make the driver > forward compatible. The fine granularity support is also complex and > probably better handled in user space anyway. > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > --- > > Grant, > > No comments last time... It would be nice if this merged with 2.6.25, I think. Sorry Steve, I must have missed it. I'll review and comment. 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
[PATCH] [XILINX][HWICAP] Xilinx Internal Configuration Access Port device driver.
Supports static platform_device and static device tree configuration. This is a standalone driver that does not depend on EDK generated files. However, it is also somewhat different in functionality from the standard EDK driver. 1) The EDK driver doesn't support readback, which this driver does. 2) The EDK driver supports fine granularity reading and writing, which this driver does not. The fine granularity support is heavily architecture independent, which makes it difficult to make the driver forward compatible. The fine granularity support is also complex and probably better handled in user space anyway. Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> --- Grant, No comments last time... It would be nice if this merged with 2.6.25, I think. Steve drivers/char/Kconfig |5 + drivers/char/Makefile |1 + drivers/char/xilinx_hwicap/Makefile|7 + drivers/char/xilinx_hwicap/xhwicap_srp.c | 414 drivers/char/xilinx_hwicap/xilinx_hwicap.c | 565 drivers/char/xilinx_hwicap/xilinx_hwicap.h | 539 ++ 6 files changed, 1531 insertions(+), 0 deletions(-) create mode 100644 drivers/char/xilinx_hwicap/Makefile create mode 100644 drivers/char/xilinx_hwicap/xhwicap_srp.c create mode 100644 drivers/char/xilinx_hwicap/xilinx_hwicap.c create mode 100644 drivers/char/xilinx_hwicap/xilinx_hwicap.h diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index bf18d75..72295cc 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -573,6 +573,11 @@ config HVC_DRIVER It will automatically be selected if one of the back-end console drivers is selected. +config XILINX_HWICAP + tristate "Xilinx OPB HWICAP Support" + depends on XILINX_VIRTEX + help + This option enables support for Xilinx Internal Configuration Access Port (ICAP) driver. config HVC_CONSOLE bool "pSeries Hypervisor Virtual Console support" diff --git a/drivers/char/Makefile b/drivers/char/Makefile index 07304d5..8cfcbb0 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_EFI_RTC) += efirtc.o obj-$(CONFIG_SGI_DS1286) += ds1286.o obj-$(CONFIG_SGI_IP27_RTC) += ip27-rtc.o obj-$(CONFIG_DS1302) += ds1302.o +obj-$(CONFIG_XILINX_HWICAP)+= xilinx_hwicap/ ifeq ($(CONFIG_GENERIC_NVRAM),y) obj-$(CONFIG_NVRAM) += generic_nvram.o else diff --git a/drivers/char/xilinx_hwicap/Makefile b/drivers/char/xilinx_hwicap/Makefile new file mode 100644 index 000..818f4e1 --- /dev/null +++ b/drivers/char/xilinx_hwicap/Makefile @@ -0,0 +1,7 @@ +# +# Makefile for the Xilinx OPB hwicap driver +# + +obj-$(CONFIG_XILINX_HWICAP) += xilinx_hwicap_m.o + +xilinx_hwicap_m-y := xilinx_hwicap.o xhwicap_srp.o diff --git a/drivers/char/xilinx_hwicap/xhwicap_srp.c b/drivers/char/xilinx_hwicap/xhwicap_srp.c new file mode 100644 index 000..388eefe --- /dev/null +++ b/drivers/char/xilinx_hwicap/xhwicap_srp.c @@ -0,0 +1,414 @@ +/* + * + * Author: Xilinx, Inc. + * + * 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. + * + * XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION "AS IS" + * AS A COURTESY TO YOU, SOLELY FOR USE IN DEVELOPING PROGRAMS AND + * SOLUTIONS FOR XILINX DEVICES. BY PROVIDING THIS DESIGN, CODE, + * OR INFORMATION AS ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE, + * APPLICATION OR STANDARD, XILINX IS MAKING NO REPRESENTATION + * THAT THIS IMPLEMENTATION IS FREE FROM ANY CLAIMS OF INFRINGEMENT, + * AND YOU ARE RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE + * FOR YOUR IMPLEMENTATION. XILINX EXPRESSLY DISCLAIMS ANY + * WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE + * IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR + * REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF + * INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE. + * + * Xilinx products are not intended for use in life support appliances, + * devices, or systems. Use in such applications is expressly prohibited. + * + * (c) Copyright 2003-2007 Xilinx Inc. + * All rights reserved. + * + * 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., + * 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#include "xilinx_hwicap.h" + +#define XHI_BUFFER_START 0 + +/*
Re: ucc_uart: add support for Freescale QUICCEngine UART
On Wednesday 05 December 2007, Timur Tabi wrote: > Arnd Bergmann wrote: > > > You can argue that the QS is really a DMA device, but in that case you > > should convert the driver to use the DMA mapping interfaces correctly, > > which I would consider overkill. > > I'm confused. I'm already calling dma_alloc_coherent() and getting a > dma_addr_t > back. Why do I need to use mapping functions to convert between virtual and > physical/bus addresses? No, I'm sorry but I'm the one who was confused. The problem I saw was that you return something offset from "bd_phys" as a dma_addr_t. This would be a lot easier if you had called it bd_bus or bd_dma instead of bd_phys, but your code looks absolutely correct upon closer inspection. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix Firmware class name collision
Timur Tabi wrote: > > In other words, the only thing you get is the first letter of the device > name. > You used to get the whole name. The physical address obviously isn't very > helpful. The physical address certainly is useful when you have more than one device of the same name. > Now, there are two solutions: > > 1) Change the PowerPC device names from physical_address.device_name to > device_name.physical_address (so that e0102400.ucc becomes ucc.e0102400) So then you'd get "firmware-ucc.e01024". What if there's another ucc at e0102480? For devices with longer names, you'd have even less precision in the address. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ucc_uart: add support for Freescale QUICCEngine UART
Arnd Bergmann wrote: > You can argue that the QS is really a DMA device, but in that case you > should convert the driver to use the DMA mapping interfaces correctly, > which I would consider overkill. I'm confused. I'm already calling dma_alloc_coherent() and getting a dma_addr_t back. Why do I need to use mapping functions to convert between virtual and physical/bus addresses? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fix Firmware class name collision
Markus and Greg,
I've found a problem with this patch that probably affects a number of embedded
PowerPC systems:
http://marc.info/?l=linux-kernel&m=119222892713518&w=2
The problem is that the device name for many PowerPC SoC devices is based on
the
physical address. So we have stuff like this:
# ls -l /sys/devices/
drwxr-xr-x9 root root0 Nov 9 17:29 e000.soc8323
drwxr-xr-x 11 root root0 Nov 9 17:22 e010.qe
[snip]
# ls -l /sys/devices/e000.soc8323/
drwxr-xr-x2 root root0 Nov 9 17:34 e200.wdt
drwxr-xr-x2 root root0 Nov 9 17:34 e700.pic
drwxr-xr-x2 root root0 Nov 9 17:34 e0001400.par_io
drwxr-xr-x2 root root0 Nov 9 17:34 e0003000.i2c
drwxr-xr-x2 root root0 Nov 9 17:34 e0004500.serial
drwxr-xr-x2 root root0 Nov 9 17:34 e0004600.serial
drwxr-xr-x2 root root0 Nov 9 17:34 e003.crypto
[snip]
With this patch, the device names in /sys/class/firmware look like this:
# ls -l /sys/class/firmware/
drwxr-xr-x2 root root0 Nov 9 17:37 firmware-e0102400.u
-rw-r--r--1 root root 4096 Nov 9 17:22 timeout
In other words, the only thing you get is the first letter of the device name.
You used to get the whole name. The physical address obviously isn't very
helpful.
The problem is the size of the string is only 20 characters:
static inline void fw_setup_device_id(struct device *f_dev, struct device *dev)
{
snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s", dev->bus_id);
}
Now, there are two solutions:
1) Change the PowerPC device names from physical_address.device_name to
device_name.physical_address (so that e0102400.ucc becomes ucc.e0102400)
2) Change fw_setup_device_id() to something like this:
snprintf(f_dev->bus_id, BUS_ID_SIZE, "fw-%s", dev->bus_id);
which do you think is a better idea?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ucc_uart: add support for Freescale QUICCEngine UART
Arnd Bergmann wrote: > On Wednesday 05 December 2007, Scott Wood wrote: >>> You can argue that the QS is really a DMA device, but in that >>> case you should convert the driver to use the DMA mapping >>> interfaces correctly, which I would consider overkill. >> Why is it overkill? >> > > Well, if the QE can never be used with an IOMMU anyway, I'm unconvinced that that will always be the case. > The DMA mapping API is meant for the cases where physical and dma > addresses can be different in the first place. It's also used for noncoherent DMA; while it's unlikely Freescale will come out with a QE 8xx chip any time soon, there could be hardware bugs or performance considerations that make it desireable to treat it as non-coherent. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Implement path references
This patch extends dtc syntax to allow references (&label, or
&{/full/path}) directly within property definitions, rather than
inside a cell list. Such references are expanded to the full path of
the referenced node, as a string, instead of to a phandle as
references within cell lists are evaluated.
A testcase is also included.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/tests/run_tests.sh
===
--- dtc.orig/tests/run_tests.sh 2007-12-05 09:48:12.0 +1100
+++ dtc/tests/run_tests.sh 2007-12-05 10:31:51.0 +1100
@@ -148,6 +148,9 @@
run_test dtc.sh -I dts -O dtb -o dtc_references_dts0.test.dtb
references_dts0.dts
run_test references dtc_references_dts0.test.dtb
+run_test dtc.sh -I dts -O dtb -o dtc_path-references.test.dtb
path-references.dts
+run_test path-references dtc_path-references.test.dtb
+
# Check -Odts mode preserve all dtb information
for tree in test_tree1.dtb dtc_tree1.test.dtb dtc_escapes.test.dtb ; do
run_test dtc.sh -I dtb -O dts -o odts_$tree.test.dts $tree
Index: dtc/dtc-parser.y
===
--- dtc.orig/dtc-parser.y 2007-12-05 10:18:26.0 +1100
+++ dtc/dtc-parser.y2007-12-05 10:31:51.0 +1100
@@ -192,6 +192,10 @@
{
$$ = data_merge($1, $3);
}
+ | propdataprefix DT_REF
+ {
+ $$ = data_add_marker($1, REF_PATH, $2);
+ }
| propdata DT_LABEL
{
$$ = data_add_marker($1, LABEL, $2);
Index: dtc/dtc.h
===
--- dtc.orig/dtc.h 2007-12-05 09:02:20.0 +1100
+++ dtc/dtc.h 2007-12-05 10:32:26.0 +1100
@@ -104,6 +104,7 @@
/* Data blobs */
enum markertype {
REF_PHANDLE,
+ REF_PATH,
LABEL,
};
@@ -139,6 +140,8 @@
struct data data_copy_file(FILE *f, size_t len);
struct data data_append_data(struct data d, const void *p, int len);
+struct data data_insert_at_marker(struct data d, struct marker *m,
+ const void *p, int len);
struct data data_merge(struct data d1, struct data d2);
struct data data_append_cell(struct data d, cell_t word);
struct data data_append_re(struct data d, const struct fdt_reserve_entry *re);
Index: dtc/tests/Makefile.tests
===
--- dtc.orig/tests/Makefile.tests 2007-12-03 15:33:10.0 +1100
+++ dtc/tests/Makefile.tests2007-12-05 10:31:51.0 +1100
@@ -9,7 +9,7 @@
sw_tree1 \
move_and_save mangle-layout \
open_pack rw_tree1 setprop del_property del_node \
- string_escapes references \
+ string_escapes references path-references \
dtbs_equal_ordered
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
Index: dtc/tests/path-references.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/path-references.c 2007-12-05 10:31:51.0 +1100
@@ -0,0 +1,83 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for string references in dtc
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_ref(const void *fdt, int node, const char *checkpath)
+{
+ const char *p;
+ int len;
+
+ p = fdt_getprop(fdt, node, "ref", &len);
+ if (!p)
+ FAIL("fdt_getprop(%d, \"ref\"): %s", node, fdt_strerror(len));
+ if (!streq(p, checkpath))
+ FAIL("'ref' in node at %d has value \"%s\" instead of \"%s\"",
+node, p, checkpath);
+
+ p = fdt_getprop(fdt, node, "lref", &len);
+ if (!p)
+ FAIL("fdt_getprop(%d, \"lref\"): %s", node, fdt_strerror(len));
+ if (!streq(p, checkpath))
+ FAIL("'lref' in node at %d has value \"%s\" instead of \"%s\"",
+node, p, checkpath);
+}
+
+int main(i
Re: ucc_uart: add support for Freescale QUICCEngine UART
On Wednesday 05 December 2007, Scott Wood wrote: > > > You can argue that the QS is really a DMA device, but in that case you > > should convert the driver to use the DMA mapping interfaces correctly, > > which I would consider overkill. > > Why is it overkill? > Well, if the QE can never be used with an IOMMU anyway, you don't lose any functionality by considering it a physical address instead of a DMA address. The DMA mapping API is meant for the cases where physical and dma addresses can be different in the first place. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [FDT][PATCH] Print out the total size as part of ftdump
On Dec 4, 2007, at 4:20 PM, David Gibson wrote: > On Tue, Dec 04, 2007 at 10:33:20AM -0600, Kumar Gala wrote: >> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > > You know, the whole batch of fprintf()s of header information in > dt_from_blob() are really just a debugging hack that uglifies dtc's > output. The whole lot could be moved over to ftdump instead, which > is, after all, *supposed* to be a debugging hack. Yeah, I realized having a way to dump just the header info was nice. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[FDT][PATCH] Fix padding options
"Add an option to pad the blob that is generated" broke the padding
support. We were updating the fdt header after writing it.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Better commit message for this, since my commit ID is different.
flattree.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/flattree.c b/flattree.c
index c860b63..eb9c82c 100644
--- a/flattree.c
+++ b/flattree.c
@@ -399,6 +399,12 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
if (padsize > 0)
padlen = padsize;
+ if (padlen > 0) {
+ int tsize = be32_to_cpu(fdt.totalsize);
+ tsize += padlen;
+ fdt.totalsize = cpu_to_be32(tsize);
+ }
+
/*
* Assemble the blob: start with the header, add with alignment
* the reserve buffer, add the reserve map terminating zeroes,
@@ -414,12 +420,8 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
/*
* If the user asked for more space than is used, pad out the blob.
*/
- if (padlen > 0) {
- int tsize = be32_to_cpu(fdt.totalsize);
- tsize += padlen;
+ if (padlen > 0)
blob = data_append_zeroes(blob, padlen);
- fdt.totalsize = cpu_to_be32(tsize);
- }
fwrite(blob.val, blob.len, 1, f);
--
1.5.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ucc_uart: add support for Freescale QUICCEngine UART
Arnd Bergmann wrote: > From a code clarity perspective, the interesting point is that dma_addr_t is > what comes back from the functions in dma-mapping.h. If you don't use them, > a physical address is phys_addr_t. > > You can argue that the QS is really a DMA device, but in that case you > should convert the driver to use the DMA mapping interfaces correctly, > which I would consider overkill. Why is it overkill? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Generate useful error message for properties after subnodes
On several occasions, I've accidentally put properties after subnodes
in a dts file. I've then spent ages thinking that the resulting
syntax error was because of something else.
This patch arranges for this specific syntax error to generate a more
specific and useful error message.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/tests/prop-after-subnode.dts
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/prop-after-subnode.dts2007-12-05 10:24:52.0 +1100
@@ -0,0 +1,9 @@
+/dts-v1/;
+
+/ {
+ node1 {
+ };
+ prop;
+ node2 {
+ };
+};
Index: dtc/dtc-parser.y
===
--- dtc.orig/dtc-parser.y 2007-12-05 10:12:10.0 +1100
+++ dtc/dtc-parser.y2007-12-05 10:18:26.0 +1100
@@ -276,6 +276,11 @@
{
$$ = chain_node($1, $2);
}
+ | subnode propdef
+ {
+ yyerror("syntax error: properties must precede
subnodes\n");
+ YYERROR;
+ }
;
subnode:
--
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: ucc_uart: add support for Freescale QUICCEngine UART
On Tuesday 04 December 2007, Timur Tabi wrote: > When I program the DMA controller, I give it a dma_addr_t. And yet, the DMA > controller and the QE are both devices on the SoC. So if the DMA controller > takes a dma_addr_t, then shouldn't the QE also take one? > >From a code clarity perspective, the interesting point is that dma_addr_t is what comes back from the functions in dma-mapping.h. If you don't use them, a physical address is phys_addr_t. You can argue that the QS is really a DMA device, but in that case you should convert the driver to use the DMA mapping interfaces correctly, which I would consider overkill. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Fix hardware IRQ time accounting problem.
Hallo Tony, Tony Breeds <[EMAIL PROTECTED]> wrote: > The commit fa13a5a1f25f671d084d8884be96fc48d9b68275 (sched: restore > deterministic CPU accounting on powerpc), unconditionally calls > update_process_tick() in system context. In the deterministic accounting case > this is the correct thing to do. However, in the non-deterministic accounting > case we need to not do this, and results in the time accounted as hardware irq > time being artificially elevated. > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> > --- > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c > index 41e13f4..b9d8837 100644 > --- a/arch/powerpc/kernel/process.c > +++ b/arch/powerpc/kernel/process.c > @@ -350,7 +350,7 @@ struct task_struct *__switch_to(struct task_struct *prev, > local_irq_save(flags); > > account_system_vtime(current); > - account_process_tick(current, 0); > + account_process_vtime(current); > calculate_steal_time(); This patch works for me. The high hardware interrupt load is gone. Thanks. Bye, Jörg. -- Der Klügere gibt so lange nach bis er der Dumme ist. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Trivial lexer cleanups
This patch applies a couple of tiny cleanups to the lexer. The
not-very-useful 'WS' named pattern is removed, and the debugging
printf() for single character tokens is moved to the top of the
action, which results in less confusing output when LEXDEBUG is
switched on (because it goes before the printf()s for possible
resulting lexer state changes).
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/dtc-lexer.l
===
--- dtc.orig/dtc-lexer.l2007-11-22 17:29:51.0 +1100
+++ dtc/dtc-lexer.l 2007-11-22 17:30:55.0 +1100
@@ -29,7 +29,6 @@ PROPNODECHAR [a-zA-Z0-9,[EMAIL PROTECTED]
PATHCHAR ({PROPNODECHAR}|[/])
LEGACYPATHCHAR [a-zA-Z0-9_@/]
LABEL [a-zA-Z_][a-zA-Z0-9_]*
-WS [[:space:]]
%{
#include "dtc.h"
@@ -193,7 +192,7 @@ static int dts_version; /* = 0 */
}
-<*>{WS}+ /* eat whitespace */
+<*>[[:space:]]+/* eat whitespace */
<*>"/*"([^*]|\*+[^*/])*\*+"/" {
yylloc.filenum = srcpos_filenum;
@@ -207,6 +206,8 @@ static int dts_version; /* = 0 */
<*>. {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
+ DPRINT("Char: %c (\\x%02x)\n", yytext[0],
+ (unsigned)yytext[0]);
if (yytext[0] == '[') {
DPRINT("\n");
BEGIN(BYTESTRING);
@@ -216,9 +217,6 @@ static int dts_version; /* = 0 */
DPRINT("\n");
BEGIN(PROPNODENAME);
}
- DPRINT("Char: %c (\\x%02x)\n", yytext[0],
- (unsigned)yytext[0]);
-
return yytext[0];
}
--
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
dtc: Convert "name" property checking to new infrastructure
This patch removes the old-style checking code for the "name" property
- i.e. verifying that the "name" property, if present, matches the
node name. It replaces it with a pair of more-or-less equivalent
checks in the new checking framework.
This also promotes this check to a "structural" check, or at least an
error-rather-than-warning test, since the structural/semantic
distinction doesn't really apply in the new framework.
A testcase for the check is also added.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/checks.c
===
--- dtc.orig/checks.c 2007-12-04 14:14:41.0 +1100
+++ dtc/checks.c2007-12-04 14:41:46.0 +1100
@@ -170,6 +170,27 @@ out:
}
/*
+ * Utility check functions
+ */
+
+static void check_is_string(struct check *c, struct node *root,
+ struct node *node)
+{
+ struct property *prop;
+ char *propname = c->data;
+
+ prop = get_property(node, propname);
+ if (!prop)
+ return; /* Not present, assumed ok */
+
+ if (!data_is_one_string(prop->val))
+ FAIL(c, "\"%s\" property in %s is not a string",
+propname, node->fullpath);
+}
+#define CHECK_IS_STRING(nm, propname, lvl) \
+ CHECK(nm, NULL, check_is_string, NULL, (propname), (lvl))
+
+/*
* Structural check functions
*/
@@ -236,6 +257,23 @@ static void check_explicit_phandles(stru
}
NODE_CHECK(explicit_phandles, NULL, ERROR);
+static void check_name_properties(struct check *c, struct node *root,
+ struct node *node)
+{
+ struct property *prop;
+
+ prop = get_property(node, "name");
+ if (!prop)
+ return; /* No name property, that's fine */
+
+ if ((prop->val.len != node->basenamelen+1)
+ || (memcmp(prop->val.val, node->name, node->basenamelen) != 0))
+ FAIL(c, "\"name\" property in %s is incorrect (\"%s\" instead"
+" of base node name)", node->fullpath, prop->val.val);
+}
+CHECK_IS_STRING(name_is_string, "name", ERROR);
+NODE_CHECK(name_properties, NULL, ERROR, &name_is_string);
+
/*
* Reference fixup functions
*/
@@ -266,6 +304,7 @@ CHECK(phandle_references, NULL, NULL, fi
static struct check *check_table[] = {
&duplicate_node_names, &duplicate_property_names,
+ &name_is_string, &name_properties,
&explicit_phandles,
&phandle_references,
};
@@ -350,25 +389,10 @@ static int must_be_string(struct propert
return 1;
}
-static int name_prop_check(struct property *prop, struct node *node)
-{
- if ((prop->val.len != node->basenamelen+1)
- || !strneq(prop->val.val, node->name, node->basenamelen)) {
- ERRMSG("name property \"%s\" does not match node basename in
%s\n",
- prop->val.val,
- node->fullpath);
- return 0;
- }
-
- return 1;
-}
-
static struct {
char *propname;
int (*check_fn)(struct property *prop, struct node *node);
} prop_checker_table[] = {
- {"name", must_be_string},
- {"name", name_prop_check},
{"linux,phandle", must_be_one_cell},
{"#address-cells", must_be_one_cell},
{"#size-cells", must_be_one_cell},
Index: dtc/tests/bad-name-property.dts
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/bad-name-property.dts 2007-12-04 14:28:54.0 +1100
@@ -0,0 +1,7 @@
+/dts-v1/;
+
+/ {
+ [EMAIL PROTECTED] {
+ name = "badthing";
+ };
+};
Index: dtc/tests/run_tests.sh
===
--- dtc.orig/tests/run_tests.sh 2007-12-04 14:29:14.0 +1100
+++ dtc/tests/run_tests.sh 2007-12-04 14:29:27.0 +1100
@@ -163,6 +163,7 @@ dtc_tests () {
run_test dtc-checkfails.sh -I dts -O dtb minusone-phandle.dts
run_test dtc-checkfails.sh -I dts -O dtb nonexist-node-ref.dts
run_test dtc-checkfails.sh -I dts -O dtb nonexist-label-ref.dts
+run_test dtc-checkfails.sh -I dts -O dtb bad-name-property.dts
}
while getopts "vt:m" ARG ; do
--
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
dtc: Fix FAIL() macro varargs
The way the checking subsystem FAIL() macro is currently implemented
it must take at least one paramater after the format string. This
patch corrects the problem.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/checks.c
===
--- dtc.orig/checks.c 2007-12-04 16:42:48.0 +1100
+++ dtc/checks.c2007-12-04 17:17:42.0 +1100
@@ -101,11 +101,11 @@ static inline void check_msg(struct chec
fprintf(stderr, "\n");
}
-#define FAIL(c, fmt, ...) \
+#define FAIL(c, ...) \
do { \
TRACE((c), "\t\tFAILED at %s:%d", __FILE__, __LINE__); \
(c)->status = FAILED; \
- check_msg((c), fmt, __VA_ARGS__); \
+ check_msg((c), __VA_ARGS__); \
} while (0)
static void check_nodes_props(struct check *c, struct node *dt, struct node
*node)
--
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: ucc_uart: add support for Freescale QUICCEngine UART
Arnd Bergmann wrote: > I'm guessing that you don't really mean dma_addr_t here, but rather > phys_addr_t, which is something different. Now that I think about it, I don't know which is correct. The value is plugged into the pointer register of a buffer descriptor, and the QE performs a DMA-like memory transfer from that address into its local memory. I don't know if the QE is considered "external" enough that the address is a DMA address or a physical address. When I program the DMA controller, I give it a dma_addr_t. And yet, the DMA controller and the QE are both devices on the SoC. So if the DMA controller takes a dma_addr_t, then shouldn't the QE also take one? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Wed, 5 Dec 2007 09:21:21 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > David Woodhouse writes: > > > I think this is a bad idea -- it's hardly a difficult for those people > > who _do_ need dts to obtain it separately. > > The trouble is that it's not just people who are making a kernel for a > specific embedded board that need dtc. These days anyone who wants to > try cross-compiling a powerpc kernel and does a make allyesconfig, or > who picks cell_defconfig or ps3_defconfig to try, needs dtc if their > kernel build is to go all the way through and give them an exit status > of 0. I can see that for people who are trying to do the right thing > and compile-test their patch across architectures, it's annoying that > powerpc has an extra external requirement when no other architecture > does, and it usually just means they don't compile-test on powerpc. > > Of the various options for solving this, including dtc in the kernel > sources seems best to me. Using that same reasoning, should we merge a mkimage patch for the boards that use U-Boot? (That's a serious question, not a smart-ass response) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge dtc
On Wed, 2007-12-05 at 09:21 +1100, Paul Mackerras wrote: > David Woodhouse writes: > > > I think this is a bad idea -- it's hardly a difficult for those people > > who _do_ need dts to obtain it separately. > > The trouble is that it's not just people who are making a kernel for a > specific embedded board that need dtc. These days anyone who wants to > try cross-compiling a powerpc kernel and does a make allyesconfig, or > who picks cell_defconfig or ps3_defconfig to try, needs dtc if their > kernel build is to go all the way through and give them an exit status > of 0. I can see that for people who are trying to do the right thing > and compile-test their patch across architectures, it's annoying that > powerpc has an extra external requirement when no other architecture > does, and it usually just means they don't compile-test on powerpc. > > Of the various options for solving this, including dtc in the kernel > sources seems best to me. Make vmlinux the default target instead of zImage would seem like a better answer. I'm surprised that it isn't like that already, in fact -- and I'm only inferring that it isn't from your message. I always thought that if I typed 'make' I got the vmlinux and not a zImage. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ucc_uart: add support for Freescale QUICCEngine UART
Arnd Bergmann wrote:
> Can you use the driver on CPUs without this particular bug when it's built
> in Soft-UART mode?
No, you have to build with Soft-UART mode turned off. Soft-UART mode actually
uses the HMC mode of the QE and hacks it up to act like a UART.
The only way to know at runtime whether Soft-UART is required is to check the
SOC model/revision and compare it to a list.
I could add code to check this list and enable Soft-UART if when there's a
known
CPU with the problem. However, I can't know whether I need to upload the
microcode. I also have a U-Boot version of qe_upload_firmware(), so it's
conceivable that U-Boot could have uploaded the microcode but I still need the
Linux driver to use Soft-UART.
I also have no control over which Soft-UART microcodes are available. It's
possible that some SOCs could have this bug but Freescale won't produce a
microcode to fix it.
> Try to reduce the number of #ifdefs in your code. In particular, you should
> not do conditional #includes and #defines, as they often lead to subtle bugs.
Ok, I can remove those #defines, but my main concern was to clearly isolate the
Soft-UART code, since it is an ugly hack. I didn't want to mesh the Soft-UART
code with the normal UART code. I don't know what more I could do to limit the
number of #ifdefs.
>> +struct ucc_uart_pram {
>> +struct ucc_slow_pram common;
>> +u8 res1[8]; /* reserved */
>> +__be16 maxidl; /* Maximum idle chars */
>> +__be16 idlc;/* temp idle counter */
>> +__be16 brkcr; /* Break count register */
>> +__be16 parec; /* receive parity error counter */
>> +__be16 frmec; /* receive framing error counter */
>> +__be16 nosec; /* receive noise counter */
>> +__be16 brkec; /* receive break condition counter */
>> +__be16 brkln; /* last received break length */
>> +__be16 uaddr[2];/* UART address character 1 & 2 */
>> +__be16 rtemp; /* Temp storage */
>> +__be16 toseq; /* Transmit out of sequence char */
>> +__be16 cchars[8]; /* control characters 1-8 */
>> +__be16 rccm;/* receive control character mask */
>> +__be16 rccr;/* receive control character register */
>> +__be16 rlbc;/* receive last break character */
>> +__be16 res2;/* reserved */
>> +__be32 res3;/* reserved, should be cleared */
>> +u8 res4;/* reserved, should be cleared */
>> +u8 res5[3]; /* reserved, should be cleared */
>> +__be32 res6;/* reserved, should be cleared */
>> +__be32 res7;/* reserved, should be cleared */
>> +__be32 res8;/* reserved, should be cleared */
>> +__be32 res9;/* reserved, should be cleared */
>> +__be32 res10; /* reserved, should be cleared */
>> +__be32 res11; /* reserved, should be cleared */
>> +__be32 res12; /* reserved, should be cleared */
>> +__be32 res13; /* reserved, should be cleared */
>> +#ifdef CONFIG_SERIAL_QE_SOFT_UART
>> +__be16 supsmr; /* 0x90, Shadow UPSMR */
>> +__be16 res92; /* 0x92, reserved, initialize to 0 */
>> +__be32 rx_state;/* 0x94, RX state, initialize to 0 */
>> +__be32 rx_cnt; /* 0x98, RX count, initialize to 0 */
>> +u8 rx_length; /* 0x9C, Char length, set to 1+CL+PEN+1+SL */
>> +u8 rx_bitmark; /* 0x9D, reserved, initialize to 0 */
>> +u8 rx_temp_dlst_qe; /* 0x9E, reserved, initialize to 0 */
>> +u8 res14[0xBC - 0x9F]; /* reserved */
>> +__be32 dump_ptr;/* 0xBC, Dump pointer */
>> +__be32 rx_frame_rem;/* 0xC0, reserved, initialize to 0 */
>> +u8 rx_frame_rem_size; /* 0xC4, reserved, initialize to 0 */
>> +u8 tx_mode; /* 0xC5, mode, 0=AHDLC, 1=UART */
>> +u16 tx_state; /* 0xC6, TX state */
>> +u8 res15[0xD0 - 0xC8]; /* reserved */
>> +__be32 resD0; /* 0xD0, reserved, initialize to 0 */
>> +u8 resD4; /* 0xD4, reserved, initialize to 0 */
>> +__be16 resD5; /* 0xD5, reserved, initialize to 0 */
>> +#endif
>> +} __attribute__ ((packed));
>
> The structure is perfectly packed even without your __attribute__ ((packed)),
> so you should leave out the attribute in order to get more efficient code
> accessing it.
If the structure is packed either way, why would the code differ? I don't see
how the code would be more efficient if I removed "__attribute__ ((packed))".
If gcc does something differently, that's news to me.
> Do you really need the debugging function like this in the code?
> Usually they are rather pointless once the code works, and will
> suffer from bitrot because nobody enables the code.
Well, I'm hesitant to remove it because I have a feeling that
Re: Merge dtc
David Woodhouse writes: > I think this is a bad idea -- it's hardly a difficult for those people > who _do_ need dts to obtain it separately. The trouble is that it's not just people who are making a kernel for a specific embedded board that need dtc. These days anyone who wants to try cross-compiling a powerpc kernel and does a make allyesconfig, or who picks cell_defconfig or ps3_defconfig to try, needs dtc if their kernel build is to go all the way through and give them an exit status of 0. I can see that for people who are trying to do the right thing and compile-test their patch across architectures, it's annoying that powerpc has an extra external requirement when no other architecture does, and it usually just means they don't compile-test on powerpc. Of the various options for solving this, including dtc in the kernel sources seems best to me. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [FDT][PATCH] Print out the total size as part of ftdump
On Tue, Dec 04, 2007 at 10:33:20AM -0600, Kumar Gala wrote: > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> You know, the whole batch of fprintf()s of header information in dt_from_blob() are really just a debugging hack that uglifies dtc's output. The whole lot could be moved over to ftdump instead, which is, after all, *supposed* to be a debugging hack. -- 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: [FDT][PATCH] Fix padding options
I guess it was really git commit 2b7dc8dce549ad72ad437b254bf756d7ba4c2a5a Add an option to pad the blob that is generated - k On Dec 4, 2007, at 4:04 PM, David Gibson wrote: > On Tue, Dec 04, 2007 at 10:27:52AM -0600, Kumar Gala wrote: >> commit 22e787ca2b1e49a9a0f3c43262564ab1038c5c3c broke the padding >> support. We were updating the fdt header after writing it. > > Uh.. I can't find a commit with that SHA1. Which one are you > referring to? > > -- > 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: Merge dtc
On Tue, Dec 04, 2007 at 10:04:53AM -0600, Kumar Gala wrote: > > On Dec 4, 2007, at 9:26 AM, Josh Boyer wrote: > > > On Tue, 04 Dec 2007 07:25:57 -0600 > > Jon Loeliger <[EMAIL PROTECTED]> wrote: > > > >> So, like, the other day David Woodhouse mumbled: > >>> > >>> I think this is a bad idea -- it's hardly a difficult for those > >>> people > >>> who _do_ need dts to obtain it separately. > >>> > >>> We shouldn't be merging _more_ stuff in. > >> > >> Thanks for chiming in here, David W. As far as I can tell > >> so far, the only two people who have voiced an opinion on > >> this issue are Dave G, submitting patches, and me disagreeing > >> with the approach. :-) > >> > >> Anyone else? > > > > I don't see an overwhelmingly great reason to merge it. It might help > > test people who do automated rebuilds, etc and aren't used to dealing > > with powerpc and it's requirements. Outside of that, I see it as > > dual-maintenance. > > > > But I'm not doing the maintenance, and it doesn't effect me too much. > > I only ask that a decision is made and executed on soon so we can move > > on. > > I'm also in disagreement of duplicating dtc in the kernel. > > However, if we are going to do this we should make the path expansion > for labels work before we do it. Since we're going to have to update the in-kernel copy reasonably frequently anyway, I don't see that there's much point in waiting for particular features to be implemented. -- 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: ucc_uart: add support for Freescale QUICCEngine UART
On Tuesday 04 December 2007, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
> microcode is required. This microcode implements UART via a work-around,
> hence it's called "Soft-UART". This driver can use QE firmware upload feature
> to upload the correct microcode to the QE.
Can you use the driver on CPUs without this particular bug when it's built
in Soft-UART mode?
> +
> +#ifdef CONFIG_SERIAL_QE_SOFT_UART_UPLOAD
> +#include
> +#include
> +#endif
> +
> +#ifdef CONFIG_SERIAL_QE_SOFT_UART
> +/*
> + * The GUMR flag for Soft UART. This would normally be defined in qe.h,
> + * but Soft-UART is a hack and we want to keep everything related to it in
> + * this file.
> + */
> +#define UCC_SLOW_GUMR_H_SUART0x4000 /* Soft UART */
> +
> +/*
> + * firmware_loaded is 1 if the firmware has been loaded, 0 otherwise.
> + */
> +#ifdef CONFIG_SERIAL_QE_SOFT_UART_UPLOAD
> +static int firmware_loaded;
> +#endif
Try to reduce the number of #ifdefs in your code. In particular, you should
not do conditional #includes and #defines, as they often lead to subtle bugs.
> +struct ucc_uart_pram {
> + struct ucc_slow_pram common;
> + u8 res1[8]; /* reserved */
> + __be16 maxidl; /* Maximum idle chars */
> + __be16 idlc;/* temp idle counter */
> + __be16 brkcr; /* Break count register */
> + __be16 parec; /* receive parity error counter */
> + __be16 frmec; /* receive framing error counter */
> + __be16 nosec; /* receive noise counter */
> + __be16 brkec; /* receive break condition counter */
> + __be16 brkln; /* last received break length */
> + __be16 uaddr[2];/* UART address character 1 & 2 */
> + __be16 rtemp; /* Temp storage */
> + __be16 toseq; /* Transmit out of sequence char */
> + __be16 cchars[8]; /* control characters 1-8 */
> + __be16 rccm;/* receive control character mask */
> + __be16 rccr;/* receive control character register */
> + __be16 rlbc;/* receive last break character */
> + __be16 res2;/* reserved */
> + __be32 res3;/* reserved, should be cleared */
> + u8 res4;/* reserved, should be cleared */
> + u8 res5[3]; /* reserved, should be cleared */
> + __be32 res6;/* reserved, should be cleared */
> + __be32 res7;/* reserved, should be cleared */
> + __be32 res8;/* reserved, should be cleared */
> + __be32 res9;/* reserved, should be cleared */
> + __be32 res10; /* reserved, should be cleared */
> + __be32 res11; /* reserved, should be cleared */
> + __be32 res12; /* reserved, should be cleared */
> + __be32 res13; /* reserved, should be cleared */
> +#ifdef CONFIG_SERIAL_QE_SOFT_UART
> + __be16 supsmr; /* 0x90, Shadow UPSMR */
> + __be16 res92; /* 0x92, reserved, initialize to 0 */
> + __be32 rx_state;/* 0x94, RX state, initialize to 0 */
> + __be32 rx_cnt; /* 0x98, RX count, initialize to 0 */
> + u8 rx_length; /* 0x9C, Char length, set to 1+CL+PEN+1+SL */
> + u8 rx_bitmark; /* 0x9D, reserved, initialize to 0 */
> + u8 rx_temp_dlst_qe; /* 0x9E, reserved, initialize to 0 */
> + u8 res14[0xBC - 0x9F]; /* reserved */
> + __be32 dump_ptr;/* 0xBC, Dump pointer */
> + __be32 rx_frame_rem;/* 0xC0, reserved, initialize to 0 */
> + u8 rx_frame_rem_size; /* 0xC4, reserved, initialize to 0 */
> + u8 tx_mode; /* 0xC5, mode, 0=AHDLC, 1=UART */
> + u16 tx_state; /* 0xC6, TX state */
> + u8 res15[0xD0 - 0xC8]; /* reserved */
> + __be32 resD0; /* 0xD0, reserved, initialize to 0 */
> + u8 resD4; /* 0xD4, reserved, initialize to 0 */
> + __be16 resD5; /* 0xD5, reserved, initialize to 0 */
> +#endif
> +} __attribute__ ((packed));
The structure is perfectly packed even without your __attribute__ ((packed)),
so you should leave out the attribute in order to get more efficient code
accessing it.
> +
> +#ifdef DEBUG
> +static void dump_ucc_uart_pram(struct ucc_uart_pram __iomem *uccup)
> +{
> + unsigned int i;
Do you really need the debugging function like this in the code?
Usually they are rather pointless once the code works, and will
suffer from bitrot because nobody enables the code.
> +
> +#ifdef CONFIG_SERIAL_QE_SOFT_UART
> +#define UCC_UART_SUPSMR_SL 0x8000
> +#define UCC_UART_SUPSMR_RPM_MASK 0x6000
> +#define UCC_UART_SUPSMR_RPM_ODD 0x
> +#define UCC_UART_SUPSMR_RPM_LOW 0x2000
again, the #ifdef should
Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
On Tuesday 04 December 2007, Benjamin Herrenschmidt wrote:
> > 2. The call to firmware_has_feature() turns into a compile-time check
> > in
> > many cases, so if the kernel does not contain support for any firmware
> > with the given feature, all the code referenced it can get optimized
> > away by the compiler.
>
> The machine init stuff will soon get rid of whatever test is in it too,
> as soon as I get to do the ELF magic.
Section magic is often painful and causes a number of problems. Moreover, it
won't do the same thing as what the compiler can do. Consider
static int x __attribute__((section("some_platform.data"))) = 1;
static int f(void) __attribute__((section("some_platform.text")));
{
if (firmware_has_feature(FOO))
return x;
return 0;
}
When firmware_has_feature(FOO) statically evaluates to false, f becomes an
empty function and x is left out from the object file.
If you turn it into a platform_is() check and discard all "some_platform"
sections, you need to have both in the vmlinux file and can discard them
at run time, which is something completely different. You can also
discard them in the linker script, but that's a lot more work than having
the compiler do the right thing.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [FDT][PATCH] Fix padding options
On Tue, Dec 04, 2007 at 10:27:52AM -0600, Kumar Gala wrote: > commit 22e787ca2b1e49a9a0f3c43262564ab1038c5c3c broke the padding > support. We were updating the fdt header after writing it. Uh.. I can't find a commit with that SHA1. Which one are you referring to? -- 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: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
On Tuesday 04 December 2007, Benjamin Herrenschmidt wrote: > On Tue, 2007-12-04 at 20:35 +0100, Arnd Bergmann wrote: > > > > 1. If another platform gets added that uses the same firmware feature, > > it > > will automatically do the right thing. > > Yes but is it something that we want to happen ? That is, do we want > code somewhere in a platform/foo dir to run when using platform/bar > because they happen to share a feature ? It should be decided case-by-case of course. My assumption was that in those places where we currently check the firmware feature, that is actually the right thing to do. For the lv1 specific device drivers (vuart, sound, graphics, ...), my feeling is that they should really check for lv1, not for ps3, because the check for lv1 is only needed in order to make sure that you can run the hcall that probes for the actual device. For some of the iseries checks, it would be more logical to test the platform instead of the firmware feature IMHO, but I don't see a significant reason to change that. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
Geert Uytterhoeven wrote: > On Tue, 4 Dec 2007, Grant Likely wrote: >> On 12/4/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: >> > On Sat, 1 Dec 2007, Grant Likely wrote: >> > > From: Grant Likely <[EMAIL PROTECTED]> >> > > >> > > This patch makes the platform code use the new machine-specific initcall >> > > hooks. This has the advantage of not needing to explicitly test >> > > machine_is() at the top of every initcall function. >> > >> > You seem to have missed the PS3 *_initcall()s. >> > Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) >> > instead >> > of machine_is(ps3). >> >> That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable >> substitute so I left it alone. > > I think it's OK. But... > > Geoff: is there any specific reason why you used > firmware_has_feature(FW_FEATURE_PS3_LV1)? As Arnd pointed out, the code in the firmware_has_feature() conditional will be removed by the optimizer when the kernel is built without support for that feature. This then gives a multi-platform binary that has only the code for the sub-set of features the user selected. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: Move electra-ide support over to new framework
On Tue, Dec 04, 2007 at 03:50:03PM -0500, Jeff Garzik wrote: > Olof Johansson wrote: >> [POWERPC] Move electra-ide support over to new pata_of_platform framework >> Move electra-ide glue over to the new pata_of_platform framework, and >> add the quirks needed to that driver. >> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> >> --- >> I'll remove the electra-ide stuff from arch/powerpc/platforms/pasemi >> once this hits a common tree, since otherwise I'd be without IDE until >> they converge (i.e. 2.6.25 merge window). > > FWIW I'm presuming this work will go via a powerpc tree not libata... > Generally that's not the case, but here it's largely an arch-specific work. Ok, that works. I was thinking of letting this patch go through libata, and do the removal through the powerpc merge path. But I can do both through powerpc. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Xilinx: clear data caches.
On 12/4/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
> This code is needed to boot without a boot loader.
>
> Grant: I'm not sure where the right place to put this is. I'm assuming
> we'll actually need some boot code that is not generic? Also, note that
> there is a V4FX errata workaround in arch/ppc/boot/head.S, which probably
> also needs to get pulled to powerpc.
Thanks Steve, I'll pull this into my tree. I hope to find some time
to get the raw platform cleaned up to get into mainline.
And, yes, the V4FX errata needs to be merged into arch/powerpc.
Thanks again!
g.
>
> Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/raw-platform.c | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/raw-platform.c
> b/arch/powerpc/boot/raw-platform.c
> index b9caeee..2a5e493 100644
> --- a/arch/powerpc/boot/raw-platform.c
> +++ b/arch/powerpc/boot/raw-platform.c
> @@ -24,6 +24,28 @@ void platform_init(unsigned long r3, unsigned long r4,
> unsigned long r5,
> unsigned long r6, unsigned long r7)
> {
> u64 memsize64 = memsize[0];
> + static const unsigned long line_size = 32;
> + static const unsigned long congruence_classes = 256;
> + unsigned long addr;
> + unsigned long dccr;
> +
> + /*
> +* Invalidate the data cache if the data cache is turned off.
> +* - The 405 core does not invalidate the data cache on power-up
> +* or reset but does turn off the data cache. We cannot assume
> +* that the cache contents are valid.
> +* - If the data cache is turned on this must have been done by
> +* a bootloader and we assume that the cache contents are
> +* valid.
> +*/
> + __asm__("mfdccr %0": "=r" (dccr));
> + if (dccr == 0) {
> + for (addr = 0;
> +addr < (congruence_classes * line_size);
> +addr += line_size) {
> + __asm__("dccci 0,%0": :"b"(addr));
> + }
> + }
>
> if (mem_size_cells == 2) {
> memsize64 <<= 32;
> --
> 1.5.3.4-dirty
>
>
>
>
--
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: [BUG] 2.6.24-rc3-git2 softlockup detected
* Kamalesh Babulal <[EMAIL PROTECTED]> wrote: > Hi Ingo, > > This softlockup is seen in the 2.6.24-rc4 either and looks like a > message because this is seen while running tbench and machine > continues running other test's after the softlockup messages and some > times seen with the bootup, but the machines reaches the login prompt > and able to continue running tests. do you know whether there's any true delay when this happens, or is it a pure softlockup-detector false positive? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: Move electra-ide support over to new framework
Olof Johansson wrote: > [POWERPC] Move electra-ide support over to new pata_of_platform framework > > Move electra-ide glue over to the new pata_of_platform framework, and > add the quirks needed to that driver. > > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > --- > > I'll remove the electra-ide stuff from arch/powerpc/platforms/pasemi > once this hits a common tree, since otherwise I'd be without IDE until > they converge (i.e. 2.6.25 merge window). FWIW I'm presuming this work will go via a powerpc tree not libata... Generally that's not the case, but here it's largely an arch-specific work. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Xilinx: clear data caches.
This code is needed to boot without a boot loader.
Grant: I'm not sure where the right place to put this is. I'm assuming we'll
actually need some boot code that is not generic? Also, note that there is a
V4FX errata workaround in arch/ppc/boot/head.S, which probably also needs to
get pulled to powerpc.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/raw-platform.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/raw-platform.c b/arch/powerpc/boot/raw-platform.c
index b9caeee..2a5e493 100644
--- a/arch/powerpc/boot/raw-platform.c
+++ b/arch/powerpc/boot/raw-platform.c
@@ -24,6 +24,28 @@ void platform_init(unsigned long r3, unsigned long r4,
unsigned long r5,
unsigned long r6, unsigned long r7)
{
u64 memsize64 = memsize[0];
+ static const unsigned long line_size = 32;
+ static const unsigned long congruence_classes = 256;
+ unsigned long addr;
+ unsigned long dccr;
+
+ /*
+* Invalidate the data cache if the data cache is turned off.
+* - The 405 core does not invalidate the data cache on power-up
+* or reset but does turn off the data cache. We cannot assume
+* that the cache contents are valid.
+* - If the data cache is turned on this must have been done by
+* a bootloader and we assume that the cache contents are
+* valid.
+*/
+ __asm__("mfdccr %0": "=r" (dccr));
+ if (dccr == 0) {
+ for (addr = 0;
+addr < (congruence_classes * line_size);
+addr += line_size) {
+ __asm__("dccci 0,%0": :"b"(addr));
+ }
+ }
if (mem_size_cells == 2) {
memsize64 <<= 32;
--
1.5.3.4-dirty
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pata_of_platform: Move electra-ide support over to new framework
[POWERPC] Move electra-ide support over to new pata_of_platform framework
Move electra-ide glue over to the new pata_of_platform framework, and
add the quirks needed to that driver.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
I'll remove the electra-ide stuff from arch/powerpc/platforms/pasemi
once this hits a common tree, since otherwise I'd be without IDE until
they converge (i.e. 2.6.25 merge window).
-Olof
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 4daf118..3e9675a 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -34,11 +34,20 @@ static int __devinit pata_of_platform_probe(struct
of_device *ofdev,
return -EINVAL;
}
- ret = of_address_to_resource(dn, 1, &ctl_res);
- if (ret) {
- dev_err(&ofdev->dev, "can't get CTL address from "
- "device tree\n");
- return -EINVAL;
+ if (of_device_is_compatible(dn, "electra-ide")) {
+ /* Altstatus is really at offset 0x3f6 from the primary window
+* on electra-ide. Adjust ctl_res and io_res accordingly.
+*/
+ ctl_res = io_res;
+ ctl_res.start = ctl_res.start+0x3f6;
+ io_res.end = ctl_res.start-1;
+ } else {
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
}
ret = of_irq_to_resource(dn, 0, &irq_res);
@@ -76,6 +85,7 @@ static int __devexit pata_of_platform_remove(struct of_device
*ofdev)
static struct of_device_id pata_of_platform_match[] = {
{ .compatible = "ata-generic", },
+ { .compatible = "electra-ide", },
{},
};
MODULE_DEVICE_TABLE(of, pata_of_platform_match);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] [libata] pata_platform: make probe and remove functions device type neutral
On Tue, Dec 04, 2007 at 08:06:25PM +0300, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Olof Johansson <[EMAIL PROTECTED]>
Tested with both the old pata_platform and new pata_of_platform drivers on
PA Semi Electra (see separate post with pata_of_platform cutover patch).
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
On Tue, Dec 04, 2007 at 10:45:31PM +0300, Anton Vorontsov wrote: > This patch adds localbus and pata nodes to use CF IDE interface > on MPC8349E-mITX boards. > > Patch also adds code to probe localbus. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Acked-by: Olof Johansson <[EMAIL PROTECTED]> -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, Dec 04, 2007 at 11:37:51PM +0300, Anton Vorontsov wrote: > On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote: > > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote: > > > tristate "Generic platform device PATA support" > > > - depends on EMBEDDED || ARCH_RPC > > > + depends on EMBEDDED || ARCH_PPC > > > > It needs to be || PPC, not || ARCH_PPC. > > D'oh. > > - - - - > From: Anton Vorontsov <[EMAIL PROTECTED]> > Subject: [PATCH v2.2] [libata] pata_of_platform: OF-Platform PATA device > driver > > This driver nicely wraps around pata_platform library functions, > and provides OF platform bus bindings to the PATA devices. > > In addition fix ARCH_RPC typo in the PATA_PLATFORM Kconfig entry, > spotted by Olof Johansson. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Reviewed-by: Olof Johansson <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > tristate "Generic platform device PATA support"
> > - depends on EMBEDDED || ARCH_RPC
> > + depends on EMBEDDED || ARCH_PPC
>
> It needs to be || PPC, not || ARCH_PPC.
D'oh.
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Subject: [PATCH v2.2] [libata] pata_of_platform: OF-Platform PATA device driver
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
In addition fix ARCH_RPC typo in the PATA_PLATFORM Kconfig entry,
spotted by Olof Johansson.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig| 12 -
drivers/ata/Makefile |1 +
drivers/ata/pata_of_platform.c | 104
3 files changed, 116 insertions(+), 1 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..299ff1f 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -607,13 +607,23 @@ config PATA_WINBOND_VLB
config PATA_PLATFORM
tristate "Generic platform device PATA support"
- depends on EMBEDDED || ARCH_RPC
+ depends on EMBEDDED || PPC
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI)+= pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 000..4daf118
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,104 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int reg_shift = 0;
+ int pio_mode = 0;
+ int pio_mask;
+ const u32 *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = (u32 *)of_get_property(dn, "reg-shift", NULL);
+ if (prop)
+ reg_shift = *prop;
+
+ prop = (u32 *)of_get_property(dn, "pio-mode", NULL);
+ if (prop) {
+ pio_mode = *prop;
+ if (pio_mode > 6) {
+ dev_err(&ofdev->dev, "invalid pio-mode\n");
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&ofdev->dev, "pio-mode unspecified, assuming PIO0\n");
+ }
+
+ pio_mask = 1 << pio_mode;
+ pio_mask |= (1 << pio_mode) - 1;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+reg_shift, pio_mask);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struc
Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
On Tue, 2007-12-04 at 20:35 +0100, Arnd Bergmann wrote: > > 1. If another platform gets added that uses the same firmware feature, > it > will automatically do the right thing. Yes but is it something that we want to happen ? That is, do we want code somewhere in a platform/foo dir to run when using platform/bar because they happen to share a feature ? I don't think so ... such code should be located elsewhere, maybe in sysdev, where it's clear that it's shared. Thus, thing that is -really- platform specific and wants to stay in the platform code should move to the new mechanism I believe. As for PS3, will there ever be another platform using LV1 ? If that is the case, we may want to create a shared directory with all the LV1 bits... > 2. The call to firmware_has_feature() turns into a compile-time check > in > many cases, so if the kernel does not contain support for any firmware > with the given feature, all the code referenced it can get optimized > away by the compiler. The machine init stuff will soon get rid of whatever test is in it too, as soon as I get to do the ELF magic. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On Tue, 2007-12-04 at 13:05 -0700, Grant Likely wrote: > We could simply have the setup code copy the ppc_md.power_off pointer > into pm_power_off; that we retain the nice assignment in > define_machine(), but eliminate the duplicated calls. Good idea. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar driver: eliminate compiler warnings and unnecessary macros
Grant Likely wrote: > From: Grant Likely <[EMAIL PROTECTED]> > > This patch eliminates the warning of unused return values when the driver > registers it sysfs files. Now the driver will print an error if it is > unable to register the sysfs files. > > It also eliminates the macros used to wrap the DEVICE_ATTR macro and the > device_create_file function call. The macros don't reduce the number of > lines of source code in the file and the name munging makes is so that > cscope and friends don't see the references to the functions. It's better > to just call the kernel API directly. > > While we're at it, the DEVICE_ATTR instances have been moved down to > be grouped with the functions they depend on. > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > --- > > drivers/net/gianfar_sysfs.c | 50 > ++- > 1 files changed, 25 insertions(+), 25 deletions(-) applied #upstream ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
Vitaly Bordug wrote: > With that patch fixed.c now fully emulates MDIO bus, thus no need > to duplicate PHY layer functionality. That, in turn, drastically > simplifies the code, and drops down line count. > > As an additional bonus, now there is no need to register MDIO bus > for each PHY, all emulated PHYs placed on the platform fixed MDIO bus. > There is also no more need to pre-allocate PHYs via .config option, > this is all now handled dynamically. > > p.s. Don't even try to understand patch content! Better: apply patch > and look into resulting drivers/net/phy/fixed.c. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> ACK, I presume this will go via the ppc tree? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar: fix compile warning
Grant Likely wrote: > From: Grant Likely <[EMAIL PROTECTED]> > > Eliminate an uninitialized variable warning. The code is correct, but > a pointer to the automatic variable 'addr' is passed to dma_alloc_coherent. > Since addr has never been initialized, and the compiler doesn't know > what dma_alloc_coherent will do with it, it complains. > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > --- > > Jeff, this one should go in for 2.6.24 applied #upstream-fixes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On 12/4/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-12-04 at 11:01 -0700, Mark A. Greer wrote: > > On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote: > > > > > > On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote: > > > > From: Mark A. Greer <[EMAIL PROTECTED]> > > > > > > > > The ppc_md.power_off hook performs the same function that the > > > > pm_power_off hook is supposed to. However, it is powerpc-specific > > > > and prevents kernel drivers (e.g., IPMI) from changing how a platform > > > > is powered off. So, get rid of ppc_md.power_off and replace it with > > > > pm_power_off. > > > > > > I'm less happy with that one... probably aesthetics :-) > > > > > > Can't we just have the generic code call pm_power_off and ppc_md and > > > which ever powers the machine off wins ? > > > > Yes, that would be easy to do. Seems like duplication though. > > If you are sure you're okay with the duplication, I'll do that. > > Let's ask Paulus what he thinks. We could simply have the setup code copy the ppc_md.power_off pointer into pm_power_off; that we retain the nice assignment in define_machine(), but eliminate the duplicated calls. 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: [PATCH] Stop phy code from returning success to unknown ioctls.
On Nov 28, 2007, at 13:56, David Woodhouse wrote: > This kind of sucks, and prevents the Fedora installer from using the > device for network installs... > > [EMAIL PROTECTED] phy]# iwconfig eth0 > Warning: Driver for device eth0 has been compiled with an ancient > version > of Wireless Extension, while this program support version 11 and > later. > Some things may be broken... > > eth0ESSID:off/any Nickname:"" > NWID:0 Channel:0 Access Point: 00:00:BF:81:14:E0 > Bit Rate:-1.08206e+06 kb/s Sensitivity=0/0 > RTS thr:off Fragment thr:off > Encryption key: > Power Management:off > > Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> d'oh! Acked-by: Andy Fleming <[EMAIL PROTECTED]> > > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > index 9bc1177..7c9e6e3 100644 > --- a/drivers/net/phy/phy.c > +++ b/drivers/net/phy/phy.c > @@ -406,6 +406,9 @@ int phy_mii_ioctl(struct phy_device *phydev, > && phydev->drv->config_init) > phydev->drv->config_init(phydev); > break; > + > + default: > + return -ENOTTY; > } > > return 0; > > -- > dwmw2 > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
On Tue, 2007-12-04 at 13:39 +0100, Geert Uytterhoeven wrote: > > Can we please have them in ? They look very useful to > me > elsewhere (other bus drivers, device drivers), too. > > What about naming the printf format specifier macros more like in C99, > e.g. > PRI*? That's a can of worms I just didn't want to open... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
