Re: [PATCH] net: Add 405EX support to new EMAC driver
On Sunday 04 November 2007, Benjamin Herrenschmidt wrote:
Isn't this the case where there should really be device tree properties
instead? If you had an ibm,emac-has-axon-stacr property in the device
node, then you don't have to modify the driver for every new board out
there. Same for the other device properties, of course.
I thought this was what having the device tree was all about. :(
Somewhat yeah. There are subtle variations here or there we haven't
totally indenfified... It might be a better option in our case here to
add has-mdio to the rgmii nodes indeed.
So how exactly do you want me to handle this (I'm still new to this device
tree stuff, so please bear with me)? Like this?
RGMII0: [EMAIL PROTECTED] {
device_type = rgmii-interface;
compatible = ibm,rgmii-405ex, ibm,rgmii;
reg = ef601000 8;
has-mdio;
};
Or add this to the compatible property?
RGMII0: [EMAIL PROTECTED] {
device_type = rgmii-interface;
compatible = ibm,rgmii-405ex, ibm,rgmii,
ibm,has-mdio;
reg = ef601000 8;
};
Part of the problem with those cells is that the chip folks keep
changing things subtly from one rev to another though, it's not even
totally clear to me yet whether the RGMII registers are totally
compatible betwee axon and 405ex, which is why I've pretty much stuck to
compatible properties to identify the variants.
The device-tree can do both. It's still better than no device-tree since
at least you know what cell variant is in there.
As for the STACR, Axon isn't the first one to have that bit flipped, I
think we should name the property differently, something like
stacr-oc-inverted.
It's not only the OC bit-flip on AXON, but also the different STACR register
layout for read/write op-codes (STAOPC). This seems to be the same on all new
EMAC core's like on AXON, 440EPx/GRx and 405EX. So stacr-oc-inverted is not
enough here. This is what is needed for 440SPe, which only has the bit-flip
and the old STAOPC layout.
So perhaps most flexible would be to add individual properties,
like stacr-oc-inverted and stacr-staopc-19-20. What do you think? And
again the additional question: Should the be added as an new property or
added to the compatible property?
Please advise. Thanks.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] cpm_load_patch() - declartion conflict
Hi, The build fails with following error CC arch/powerpc/sysdev/micropatch.o arch/powerpc/sysdev/micropatch.c:625: error: conflicting types for ‘cpm_load_patch’ include/asm/commproc.h:94: error: previous declaration of ‘cpm_load_patch’ was here arch/powerpc/sysdev/micropatch.c: In function ‘cpm_load_patch’: arch/powerpc/sysdev/micropatch.c:630: warning: unused variable ‘smp’ arch/powerpc/sysdev/micropatch.c:629: warning: unused variable ‘spp’ arch/powerpc/sysdev/micropatch.c:628: warning: unused variable ‘iip’ make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1 make: *** [arch/powerpc/sysdev] Error 2 The commit f2a0bd3753dad7ea4605ebd5435716b39e9f92bb defines the function with void cpm_load_patch(cpm8xx_t *cp) prtotype and is declared as extern void cpm_load_patch(volatile immap_t *immr) in the header file. Signed-off-by: Kamalesh Babulal [EMAIL PROTECTED] -- diff --git a/include/asm-powerpc/commproc.h b/include/asm-powerpc/commproc.h index 0307c84..a2328b8 100644 --- a/include/asm-powerpc/commproc.h +++ b/include/asm-powerpc/commproc.h @@ -91,7 +91,7 @@ extern uint m8xx_cpm_hostalloc(uint size); extern int m8xx_cpm_hostfree(uint start); extern void m8xx_cpm_hostdump(void); -extern void cpm_load_patch(volatile immap_t *immr); +extern void cpm_load_patch(cpm8xx_t *cp); /* Buffer descriptors used by many of the CPM protocols. */ -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.24-rc1 on PPC64: machine check exception
Hi, I got the following exception on a 128-way PPC64 machine while running ebizzy-0.2 benchmark. cpu 0x48: Vector: 200 (Machine Check) at [c06df1bb37c0] pc: c007a26c: .exit_robust_list+0x78/0x228 lr: c007a240: .exit_robust_list+0x4c/0x228 sp: c06df1bb3a40 msr: 80109032 current = 0xc06df1725120 paca= 0xc06f4000 pid = 5950, comm = ebizzy cpu 0x78: Vector: 200 (Machine Check) at [c00e21bd37c0] pc: c007a26c: .exit_robust_list+0x78/0x228 lr: c007a240: .exit_robust_list+0x4c/0x228 sp: c00e21bd3a40 msr: 80109032 current = 0xc00e pa paca= 0xc06fb800 cidpid = 5941, comm = ebizzy = 5941,[c06df1bb3b10] c00578a8 .do_exit+0x260/0x7fc [c06df1bb3bc0] c0057ef8 .sys_exit_group+0x0/0x8 [c06df1bb3c50] c00636e0 .get_signal_to_deliver+0x45c/0x4ac [c06df1bb3d00] c0011d44 .do_signal+0x68/0x2e4 [c06df1bb3e30] c0008ae8 do_work+0x28/0x2c --- Exception: 500 (Hardware Interrupt) at 10007698 SP (40016601610) is in userspace Config file attached. I did not see any similar failure reported with 2.6.24-rc1. --Vaidy # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc1 # Mon Nov 5 02:25:46 2007 # CONFIG_PPC64=y # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=128 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 CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-sv CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_NS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_CPUSETS=y # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_PROC_PID_CPUSET=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_82xx is not set # CONFIG_PPC_83xx is not set # CONFIG_PPC_86xx is not set CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=m CONFIG_LPARCFG=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y CONFIG_MPIC=y
Re: [PATCH] ehea: add kexec support
Michael Neuling [EMAIL PROTECTED] wrote on 03.11.2007 07:06:31: DD allocates HEA resources and gets firmware_handles for these resources. To free the resources DD needs to use exactly these handles. There's no generic firmware call clean out all resources. Allocating the same resources twice does not work. Can we get a new firmware call to do this? Well, there's no simple answer to this. I'm not working on firmware. I'm trying to get an answer... but don't expect anything real soon. So a new kernel can't free the resources allocated by an old kernel, because the numeric values of the handles aren't known anymore. How many possible handles are there? Depends on system configuration, between 4 and 64 per port. If the handles are lost, is the only way to clear out the HEA resources is to reset the partition? Yes, that's exactly the problem. Potential Solution: Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown and frees all firmware resources at shutdown time of the crashed kernel. This means the crashed kernel now has to be trusted to shut down and free up the resources. Isn't trusting the crashing kernel in this way against the whole kdump idea? I would hope that if the cleanup routine only does hcalls and does not change any kernel memory areas, then the risk to damage anything else in kernel should be pretty small. This should allow to catch most cases, but as always you can imagine situations where the kernel memory is broken beyond hope to even restart the kdump kernel. crash_kexec continues and loads new kernel. The new kernel restarts the HEA driver within kdump kernel, which will work because resources have been freed before. Michael, would this work? Is ppc_md.machine_crash_shutdown the right hook? Gruss/Regards Christoph R ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH (for 2.6.25?)] adb: replace sleep notifier with platform driver suspend/resume hooks
This patch replaces the pmu sleep notifier that adb had with
suspend/resume hooks in a new platform driver/device.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Is it too early to be sending patches for 2.6.25? :) I submitted this
way back but it got held up in the controversy over whether using the
generic suspend infrastructure is desirable or not, I think, however,
that this patch is desirable regardless.
drivers/macintosh/adb.c | 96
1 file changed, 57 insertions(+), 39 deletions(-)
--- linux-2.6.orig/drivers/macintosh/adb.c 2007-11-05 12:00:10.864663465
+0100
+++ linux-2.6/drivers/macintosh/adb.c 2007-11-05 12:04:24.924655436 +0100
@@ -89,14 +89,6 @@ static int sleepy_trackpad;
static int autopoll_devs;
int __adb_probe_sync;
-#ifdef CONFIG_PM_SLEEP
-static void adb_notify_sleep(struct pmu_sleep_notifier *self, int when);
-static struct pmu_sleep_notifier adb_sleep_notifier = {
- adb_notify_sleep,
- SLEEP_LEVEL_ADB,
-};
-#endif
-
static int adb_scan_bus(void);
static int do_adb_reset_bus(void);
static void adbdev_init(void);
@@ -281,6 +273,36 @@ adb_reset_bus(void)
return 0;
}
+#ifdef CONFIG_PM
+/*
+ * notify clients before sleep
+ */
+static int adb_suspend(struct platform_device *dev, pm_message_t state)
+{
+ adb_got_sleep = 1;
+ /* We need to get a lock on the probe thread */
+ down(adb_probe_mutex);
+ /* Stop autopoll */
+ if (adb_controller-autopoll)
+ adb_controller-autopoll(0);
+ blocking_notifier_call_chain(adb_client_list, ADB_MSG_POWERDOWN, NULL);
+
+ return 0;
+}
+
+/*
+ * reset bus after sleep
+ */
+static int adb_resume(struct platform_device *dev)
+{
+ adb_got_sleep = 0;
+ up(adb_probe_mutex);
+ adb_reset_bus();
+
+ return 0;
+}
+#endif /* CONFIG_PM */
+
int __init adb_init(void)
{
struct adb_driver *driver;
@@ -313,14 +335,12 @@ int __init adb_init(void)
printk(KERN_WARNING Warning: no ADB interface detected\n);
adb_controller = NULL;
} else {
-#ifdef CONFIG_PM_SLEEP
- pmu_register_sleep_notifier(adb_sleep_notifier);
-#endif /* CONFIG_PM */
#ifdef CONFIG_PPC
if (machine_is_compatible(AAPL,PowerBook1998) ||
machine_is_compatible(PowerBook1,1))
sleepy_trackpad = 1;
#endif /* CONFIG_PPC */
+
init_completion(adb_probe_task_comp);
adbdev_init();
adb_reset_bus();
@@ -330,33 +350,6 @@ int __init adb_init(void)
__initcall(adb_init);
-#ifdef CONFIG_PM
-/*
- * notify clients before sleep and reset bus afterwards
- */
-void
-adb_notify_sleep(struct pmu_sleep_notifier *self, int when)
-{
- switch (when) {
- case PBOOK_SLEEP_REQUEST:
- adb_got_sleep = 1;
- /* We need to get a lock on the probe thread */
- down(adb_probe_mutex);
- /* Stop autopoll */
- if (adb_controller-autopoll)
- adb_controller-autopoll(0);
- blocking_notifier_call_chain(adb_client_list,
- ADB_MSG_POWERDOWN, NULL);
- break;
- case PBOOK_WAKE:
- adb_got_sleep = 0;
- up(adb_probe_mutex);
- adb_reset_bus();
- break;
- }
-}
-#endif /* CONFIG_PM */
-
static int
do_adb_reset_bus(void)
{
@@ -864,7 +857,29 @@ static const struct file_operations adb_
.release= adb_release,
};
-static void
+static struct platform_driver adb_pfdrv = {
+ .driver = {
+ .name = adb,
+ },
+#ifdef CONFIG_PM
+ .suspend = adb_suspend,
+ .resume = adb_resume,
+#endif
+};
+
+static struct platform_device adb_pfdev = {
+ .name = adb,
+};
+
+static int __init
+adb_dummy_probe(struct platform_device *dev)
+{
+ if (dev == adb_pfdev)
+ return 0;
+ return -ENODEV;
+}
+
+static void __init
adbdev_init(void)
{
if (register_chrdev(ADB_MAJOR, adb, adb_fops)) {
@@ -876,4 +891,7 @@ adbdev_init(void)
if (IS_ERR(adb_dev_class))
return;
class_device_create(adb_dev_class, NULL, MKDEV(ADB_MAJOR, 0), NULL,
adb);
+
+ platform_device_register(adb_pfdev);
+ platform_driver_probe(adb_pfdrv, adb_dummy_probe);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Don't include libfdt in global LDFLAGS
So, like, the other day David Gibson mumbled: Remove the uneccessary LDFLAGS from the top-level makefile. It only added libfdt/ to the link path. dtc doesn't need libfdt at all, and the testcases which do, already link libfdt.a by explicit path. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Don't force alignment of cell list data
So, like, the other day David Gibson mumbled: At present, defining a property as, say: foo = [abcd], ; Will cause dtc to insert 2 bytes of zeros between the abcd and the , to align the cell form data. Doing so seemed like a good idea at the time, but I don't believe there are any users who actually rely on this behaviour. Segher claims that OF has some defined bindings which include properties an unaligned subsection of which is interpreted as 32-bit ints (i.e. like cell data). Worse, this alignment will cause nothing but pain when we add expression support to dtc (when celldata is included in a larger bytestring expession, we won't know the size of the preceding chunk of the expression until it's evaluated, so we would have to carry alignment fixup information right through the expression evaluation process). Therefore, this patch kills off this alignment behaviour. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dtc: Fix the install target
So, like, the other day Emil Medve mumbled: /usr/bin/install: cannot stat `fdt.h': No such file or directory /usr/bin/install: cannot stat `libfdt.h': No such file or directory Signed-off-by: Emil Medve [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add more documentation (patch the third)
So, like, the other day David Gibson mumbled: libfdt: Add more documentation (patch the third) This patch adds documentation in libfdt.h for a few more libfdt functions. It also makes a slight update to the documentation of fdt_get_name(). Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add more documentation (patch the fourth)
So, like, the other day David Gibson mumbled: This patch documents a few more functions in libfdt.h. It also makes a slight update to the description of the FDT_ERR_INTERNAL error code. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Fix sw_tree1 testcase
So, like, the other day David Gibson mumbled: There is a bug in the sw_tree1 testcase / utility which puts two compatible properties in one node in the output tree. This patch fixes the bug, and also adds a new test checking that the sw_tree1 output is equal to test_tree1.dtb as its supposed to be, which should catch future errors of this type. Signed-off-by: David Gibson [EMAIL PROTECTED] This change appears to cause a test to fail. I've not looked into it beyond make check failed: Thanks, jdl [ snip ] nop_node rw_tree1.test.dtb: PASS setprop rw_tree1.test.dtb: PASS del_property rw_tree1.test.dtb: PASS del_node rw_tree1.test.dtb: PASS dtbs_equal_ordered test_tree1.dtb rw_tree1.test.dtb:FAILProperty name mismatch compatible != prop-str at (8, 8) truncated_property: PASS dtc.sh -I dts -O dtb -o dtc_tree1.test.dtb test_tree1.dts: PASS get_mem_rsv dtc_tree1.test.dtb: PASS root_node dtc_tree1.test.dtb: PASS [ snip ] del_node dtc_tree1.test.dtb:PASS dtbs_equal_ordered dtc_tree1.test.dtb test_tree1.dtb: PASS dtc.sh -I dts -O dtb -o dtc_escapes.test.dtb escapes.dts: PASS string_escapes dtc_escapes.test.dtb:PASS ** TEST SUMMARY * Total testcases: 1216 *PASS: 1215 *FAIL: 1 * Bad configuration: 0 * Strange test result: 0 ** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] Rework of i2c-mpc.c - Freescale i2c driver
This is my first pass at reworking the Freescale i2c driver. It
switches the driver from being a platform driver to an open firmware
one. I've checked it out on my hardware and it is working.
You can specific i2c devices on a bus by adding child nodes for them
in the device tree. It does not know how to autoload the i2c chip
driver modules.
[EMAIL PROTECTED] {
device_type = i2c;
compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
device_type = rtc;
compatible = epson,pcf8564;
reg = 51;
};
};
One side effect is that legacy style i2c drivers won't work anymore.
The rtc driver in the patch has been converted from legacy i2c style
to new i2c style. It took about ten minutes to change it and it
eliminates a lot of code. The patch uses the broad_info support in the
i2c core which does not support legacy style drivers.
The driver contains a table for mapping device tree style names to
linux kernel ones.
+static struct i2c_driver_device i2c_devices[] = {
+ {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
+ {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
+ {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
+ {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
+ {epson,pcf8564, rtc-pcf8563, pcf8564,},
+};
I'd like to get rid of this table. There are two obvious solutions,
use names in the device tree that match up with the linux device
driver names. Or push these strings into the chip drivers and modify
i2c-core to also match on the device tree style names. Without one of
these changes the table is going to need a mapping for every i2c
device on the market.
If someone can supply a fix for this I will add it:
On 10/26/07, Joakim Tjernlund [EMAIL PROTECTED] wrote:
On Fri, 2007-10-26 at 11:53 +0200, Jean Delvare wrote:
2) mpc_read(), according to the comment below it sends a STOP condition
here but
this function does not known if this is the last read or not. mpc_xfer
is
the one that knows when the transaction is over and should send the
stop,
which it already does.
/* Generate stop on last byte */
if (i == length - 1)
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
Probably correct, although I am not familiar with this specific
hardware. I guess that the same is true of mpc_write as well, which is
even worse because write + read combined transactions are very common
(while read + write are not.)
Don't think write is a problem, only read. I would have to look at the
HW spec to make sure though.
Convert i2c to of_platform_driver from platform_driver
From: Jon Smirl [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 116 -
drivers/i2c/busses/i2c-mpc.c | 193 +++--
drivers/rtc/rtc-pcf8563.c | 103 --
3 files changed, 166 insertions(+), 246 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..6f80216 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -306,122 +306,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include linux/i2c.h
-struct i2c_driver_device {
- char*of_device;
- char*i2c_driver;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
- {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
- {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
- {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node, struct
i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- strncpy(info-driver_name, i2c_devices[i].i2c_driver,
KOBJ_NAME_LEN);
- strncpy(info-type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
- return 0;
- }
- return -ENODEV;
-}
-
-static void __init of_register_i2c_devices(struct device_node
*adap_node, int bus_num)
-{
- struct device_node *node = NULL;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info;
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, reg, len);
- if (!addr || len sizeof(int) || *addr (1 10) - 1) {
- printk(KERN_WARNING fsl_ioc.c: invalid i2c device
entry\n);
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
-
[PATCH 2/5] phylib: add PHY interface modes for internal delay for tx and rx only
Allow phylib specification of cases where hardware needs to configure
PHYs for Internal Delay only on either RX or TX (not both).
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
include/linux/phy.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f0742b6..e10763d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -58,6 +58,8 @@ typedef enum {
PHY_INTERFACE_MODE_RMII,
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
+ PHY_INTERFACE_MODE_RGMII_RXID,
+ PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI
} phy_interface_t;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/5] powerpc: handle mpc8360 rev. 2.1 RGMII timing erratum
if on a rev. 2.1, adjust UCC clock and data timing characteristics
as specified in the rev.2.1 erratum #2.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 ++--
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0f3855c..0a72260 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -96,14 +96,39 @@ static void __init mpc836x_mds_setup_arch(void)
if ((np = of_find_compatible_node(NULL, network, ucc_geth))
!= NULL){
+ uint svid;
+
/* Reset the Ethernet PHY */
- bcsr_regs[9] = ~0x20;
+#define BCSR9_GETHRST 0x20
+ clrbits8(bcsr_regs[9], BCSR9_GETHRST);
udelay(1000);
- bcsr_regs[9] |= 0x20;
+ setbits8(bcsr_regs[9], BCSR9_GETHRST);
+
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
+ void __iomem *immap;
+
+ immap = ioremap(get_immrbase() + 0x14a8, 8);
+
+ /*
+* IMMR + 0x14A8[4:5] = 11 (clk delay for UCC 2)
+* IMMR + 0x14A8[18:19] = 11 (clk delay for UCC 1)
+*/
+ setbits32(immap, 0x0c003000);
+
+ /*
+* IMMR + 0x14AC[20:27] = 10101010
+* (data delay for both UCC's)
+*/
+ clrsetbits_be32(immap + 4, 0xff0, 0xaa0);
+
+ iounmap(immap);
+ }
+
iounmap(bcsr_regs);
of_node_put(np);
}
-
#endif /* CONFIG_QUICC_ENGINE */
}
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] pasemi: Broaden specific references to 1682M
I assume then that this patch will move upstream via the POWERPC path, is that
right?
Signed-off-by: Doug Thompson [EMAIL PROTECTED]
--- Olof Johansson [EMAIL PROTECTED] wrote:
[POWERPC] pasemi: Broaden specific references to 1682M
There will be more product numbers in the future than just PA6T-1682M,
but they will share much of the features. Remove some of the explicit
references and compatibility checks with 1682M, and replace most of them
with the more generic term PWRficient.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
This one touches drivers/char/hw_random and drivers/edac, but I'd prefer
to just merge it up through the powerpc merge path since the changes
are trivial.
(Michael, Doug, if you disagree let me know and I can submit separate
patches. This is 2.6.25 material anyway).
-Olof
diff --git a/arch/powerpc/platforms/pasemi/Kconfig
b/arch/powerpc/platforms/pasemi/Kconfig
index 735e153..2f4dd6e 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -17,7 +17,7 @@ config PPC_PASEMI_IOMMU
bool PA Semi IOMMU support
depends on PPC_PASEMI
help
- IOMMU support for PA6T-1682M
+ IOMMU support for PA Semi PWRficient
config PPC_PASEMI_IOMMU_DMA_FORCE
bool Force DMA engine to use IOMMU
diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c
b/arch/powerpc/platforms/pasemi/cpufreq.c
index 1cfb8b0..8caa166 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -147,7 +147,10 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
*policy)
if (!cpu)
goto out;
- dn = of_find_compatible_node(NULL, sdc, 1682m-sdc);
+ dn = of_find_compatible_node(NULL, NULL, 1682m-sdc);
+ if (!dn)
+ dn = of_find_compatible_node(NULL, NULL,
+ pasemi,pwrficient-sdc);
if (!dn)
goto out;
err = of_address_to_resource(dn, 0, res);
@@ -160,7 +163,10 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
*policy)
goto out;
}
- dn = of_find_compatible_node(NULL, gizmo, 1682m-gizmo);
+ dn = of_find_compatible_node(NULL, NULL, 1682m-gizmo);
+ if (!dn)
+ dn = of_find_compatible_node(NULL, NULL,
+ pasemi,pwrficient-gizmo);
if (!dn) {
err = -ENODEV;
goto out_unmap_sdcasr;
@@ -292,7 +298,8 @@ static struct cpufreq_driver pas_cpufreq_driver = {
static int __init pas_cpufreq_init(void)
{
- if (!machine_is_compatible(PA6T-1682M))
+ if (!machine_is_compatible(PA6T-1682M)
+ !machine_is_compatible(pasemi,pwrficient))
return -ENODEV;
return cpufreq_register_driver(pas_cpufreq_driver);
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c
b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index 95d0c78..b029804 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -333,7 +333,10 @@ int gpio_mdio_init(void)
{
struct device_node *np;
- np = of_find_compatible_node(NULL, gpio, 1682m-gpio);
+ np = of_find_compatible_node(NULL, NULL, 1682m-gpio);
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL,
+ pasemi,pwrficient-gpio);
if (!np)
return -ENODEV;
gpio_regs = of_iomap(np, 0);
diff --git a/arch/powerpc/platforms/pasemi/setup.c
b/arch/powerpc/platforms/pasemi/setup.c
index 3a5d112..aeafe98 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -362,8 +362,11 @@ static inline void pasemi_pcmcia_init(void)
static struct of_device_id pasemi_bus_ids[] = {
+ /* Unfortunately needed for legacy firmwares */
{ .type = localbus, },
{ .type = sdc, },
+ { .compatible = pasemi,localbus, },
+ { .compatible = pasemi,sdc, },
{},
};
@@ -389,7 +392,8 @@ static int __init pas_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, PA6T-1682M))
+ if (!of_flat_dt_is_compatible(root, PA6T-1682M)
+ !of_flat_dt_is_compatible(root, pasemi,pwrficient))
return 0;
hpte_init_native();
@@ -400,7 +404,7 @@ static int __init pas_probe(void)
}
define_machine(pasemi) {
- .name = PA Semi PA6T-1682M,
+ .name = PA Semi PWRficient,
.probe = pas_probe,
.setup_arch = pas_setup_arch,
.init_early = pas_init_early,
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 2d7cd48..6bbd4fa 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -98,7 +98,7 @@
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Jon Smirl wrote:
[EMAIL PROTECTED] {
device_type = i2c;
compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
device_type = rtc;
compatible = epson,pcf8564;
reg = 51;
};
};
My only comment would be that the fsl5200-clocking property is
totally redundant.
Drivers can look at the compatible property (mpc5200b-i2c and
mpc5200-i2c) to match up what special needs the driver may need.
Even if it was just fsl-i2c, it could/should be implicit that
this device is the onboard i2c and the parent node is ostensibly
going to be marked as an MPC52xx SoC.. or it can look for the
mpc5200-cdm node. There is no reason to invent a property just
so you can do a property search when it replaces code of the
same size to do a node or compatible search..
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/16] Use of_get_next_child() in eeh_restore_bars()
On Mon, Oct 29, 2007 at 02:46:13PM +1100, Michael Ellerman wrote:
On Fri, 2007-10-26 at 17:29 +1000, Stephen Rothwell wrote:
On Fri, 26 Oct 2007 16:54:43 +1000 (EST) Michael Ellerman [EMAIL
PROTECTED] wrote:
- dn = pdn-node-child;
- while (dn) {
+ for (dn = NULL; (dn = of_get_next_child(pdn-node, dn));)
Just wondering if we need
#define for_each_child_node(dn, parent) \
for (dn = of_get_next_child(parent, NULL); dn; \
dn = of_get_next_child(parent, dn))
Yes, I like this much better too, if for no other reason than
the for-loop tructure is more orthodox.
Should we perhaps make it for_each_child_device_node() ?
foreach_of_device_node_child() or
of_foreach_device_node_child()
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Jon Smirl wrote:
This is my first pass at reworking the Freescale i2c driver. It
switches the driver from being a platform driver to an open firmware
one. I've checked it out on my hardware and it is working.
We may want to hold off on this until arch/ppc goes away (or at least
all users of this driver in arch/ppc).
You can specific i2c devices on a bus by adding child nodes for them
in the device tree. It does not know how to autoload the i2c chip
driver modules.
[EMAIL PROTECTED] {
device_type = i2c;
compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
dtc supports the mpc5200b-i2c, mpc5200-i2c, fsl-i2c syntax.
cell-index = 1;
What is cell-index for?
fsl5200-clocking;
As Matt pointed out, this is redundant.
[EMAIL PROTECTED] {
device_type = rtc;
This isn't really necessary.
One side effect is that legacy style i2c drivers won't work anymore.
If you mean legacy-style client drivers, why not?
The driver contains a table for mapping device tree style names to
linux kernel ones.
Can we please put this in common code instead?
+static struct i2c_driver_device i2c_devices[] = {
+ {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
+ {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
+ {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
+ {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
+ {epson,pcf8564, rtc-pcf8563, pcf8564,},
+};
At the very least, include the entries that are already being used with
this driver in fsl_soc.c.
I'd like to get rid of this table. There are two obvious solutions,
use names in the device tree that match up with the linux device
driver names.
This was proposed and rejected a while ago. For one thing, some drivers
handle multiple chips, and we shouldn't base device tree bindings on
what groupings Linux happens to make in what driver supports what.
Or push these strings into the chip drivers and modify
i2c-core to also match on the device tree style names.
That would be ideal; it just hasn't been done yet.
A middle ground for now would be to keep one table in drivers/of or
something.
Without one of
these changes the table is going to need a mapping for every i2c
device on the market.
Nah, only one for every i2c device Linux supports. :-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..6f80216 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -306,122 +306,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include linux/i2c.h
-struct i2c_driver_device {
- char*of_device;
- char*i2c_driver;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
- {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
- {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
- {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
-};
This is obviously not based on head-of-tree -- there are several more
entries in this table.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..5ceb936 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,7 @@
#include linux/module.h
#include linux/sched.h
#include linux/init.h
-#include linux/platform_device.h
+#include asm/of_platform.h
Should be linux/of_platform.h
@@ -180,7 +182,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c-adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +194,15 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target 1), i2c-base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) 0)
- return -1;
+ if ((result = i2c_wait(i2c, timeout, 1)) 0)
+ return result;
for (i = 0; i length; i++) {
/* Write data byte */
writeb(data[i], i2c-base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) 0)
- return -1;
+ if ((result = i2c_wait(i2c, timeout, 1)) 0)
+ return result;
}
return 0;
This is a separate change from the OF-ization -- at least note it in the
changelog.
+ for (i = 0; i ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ strncpy(info-driver_name, i2c_devices[i].i2c_driver,
KOBJ_NAME_LEN);
+ strncpy(info-type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ printk(i2c driver is %s\n, info-driver_name);
Should be KERN_DEBUG, if it stays at all.
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Jon Smirl wrote: I can change it to remove fsl5200-clocking if someone can tell me if this is only needed on the mpc5200b. Well, it appears to be needed on the mpc5200 (no 'b')... This driver also supports the MPC107/Tsi107/MPC8240/MPC8245 and MPC85xx/MPC8641. You forgot mpc83xx. :-) Do any of these other chips need fsl5200-clocking? None of them have it set in arch/powerpc/boot/dts. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Jon Smirl [EMAIL PROTECTED] wrote: This is my first pass at reworking the Freescale i2c driver. It switches the driver from being a platform driver to an open firmware one. I've checked it out on my hardware and it is working. Isn't this device core also used in the fsl coldfire socs? If so, it needs to have both platform bus and of_platform bus bindings. This is easy to do as long as you keep device probing and initialization in separate routines. See drivers/serial/uartlite.c for an example. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Jon Smirl wrote: I can change it to remove fsl5200-clocking if someone can tell me if this is only needed on the mpc5200b. Well, it appears to be needed on the mpc5200 (no 'b')... What is the recommend way to check for a mpc5200 or mpc5200b? This driver also supports the MPC107/Tsi107/MPC8240/MPC8245 and MPC85xx/MPC8641. You forgot mpc83xx. :-) Do any of these other chips need fsl5200-clocking? None of them have it set in arch/powerpc/boot/dts. -Scott -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Matt Sealey [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
[EMAIL PROTECTED] {
device_type = i2c;
compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 1;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
device_type = rtc;
compatible = epson,pcf8564;
reg = 51;
};
};
My only comment would be that the fsl5200-clocking property is
totally redundant.
Drivers can look at the compatible property (mpc5200b-i2c and
mpc5200-i2c) to match up what special needs the driver may need.
Even if it was just fsl-i2c, it could/should be implicit that
this device is the onboard i2c and the parent node is ostensibly
going to be marked as an MPC52xx SoC.. or it can look for the
mpc5200-cdm node. There is no reason to invent a property just
so you can do a property search when it replaces code of the
same size to do a node or compatible search..
Yeah, I agree. Drop the fsl-clocking property. The hardware is
adequately described without it.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Jon Smirl wrote: On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Jon Smirl wrote: I can change it to remove fsl5200-clocking if someone can tell me if this is only needed on the mpc5200b. Well, it appears to be needed on the mpc5200 (no 'b')... What is the recommend way to check for a mpc5200 or mpc5200b? Just check for mpc5200-i2c -- it's listed in the mpc5200b dts as well. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 07/12] arch/ppc: Remove duplicate includes.
Signed-off-by: Lucas Woods [EMAIL PROTECTED] --- arch/ppc/kernel/setup.c |1 - arch/ppc/platforms/85xx/stx_gp3.c |1 - arch/ppc/syslib/gt64260_pic.c |1 - arch/ppc/syslib/mpc52xx_pic.c |1 - arch/ppc/syslib/mv64360_pic.c |1 - arch/ppc/syslib/ppc83xx_setup.c |1 - arch/ppc/xmon/start.c |1 - 7 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c index aac88c2..79a03d0 100644 --- a/arch/ppc/kernel/setup.c +++ b/arch/ppc/kernel/setup.c @@ -37,7 +37,6 @@ #include asm/nvram.h #include asm/xmon.h #include asm/ocp.h -#include asm/prom.h #define USES_PPC_SYS (defined(CONFIG_85xx) || defined(CONFIG_83xx) || \ defined(CONFIG_MPC10X_BRIDGE) || defined(CONFIG_8260) || \ diff --git a/arch/ppc/platforms/85xx/stx_gp3.c b/arch/ppc/platforms/85xx/stx_gp3.c index b1f5b73..731b40e 100644 --- a/arch/ppc/platforms/85xx/stx_gp3.c +++ b/arch/ppc/platforms/85xx/stx_gp3.c @@ -50,7 +50,6 @@ #include asm/irq.h #include asm/immap_85xx.h #include asm/cpm2.h -#include asm/mpc85xx.h #include asm/ppc_sys.h #include syslib/cpm2_pic.h diff --git a/arch/ppc/syslib/gt64260_pic.c b/arch/ppc/syslib/gt64260_pic.c index e84d432..3b4fcca 100644 --- a/arch/ppc/syslib/gt64260_pic.c +++ b/arch/ppc/syslib/gt64260_pic.c @@ -35,7 +35,6 @@ #include linux/interrupt.h #include linux/sched.h #include linux/signal.h -#include linux/stddef.h #include linux/delay.h #include linux/irq.h diff --git a/arch/ppc/syslib/mpc52xx_pic.c b/arch/ppc/syslib/mpc52xx_pic.c index af35a31..f58149c 100644 --- a/arch/ppc/syslib/mpc52xx_pic.c +++ b/arch/ppc/syslib/mpc52xx_pic.c @@ -20,7 +20,6 @@ #include linux/init.h #include linux/sched.h #include linux/signal.h -#include linux/stddef.h #include linux/delay.h #include linux/irq.h diff --git a/arch/ppc/syslib/mv64360_pic.c b/arch/ppc/syslib/mv64360_pic.c index 4b7a333..2dd2dc5 100644 --- a/arch/ppc/syslib/mv64360_pic.c +++ b/arch/ppc/syslib/mv64360_pic.c @@ -36,7 +36,6 @@ #include linux/init.h #include linux/sched.h #include linux/signal.h -#include linux/stddef.h #include linux/delay.h #include linux/irq.h #include linux/interrupt.h diff --git a/arch/ppc/syslib/ppc83xx_setup.c b/arch/ppc/syslib/ppc83xx_setup.c index ec466db..ea37291 100644 --- a/arch/ppc/syslib/ppc83xx_setup.c +++ b/arch/ppc/syslib/ppc83xx_setup.c @@ -41,7 +41,6 @@ #include syslib/ppc83xx_setup.h #if defined(CONFIG_PCI) -#include asm/delay.h #include syslib/ppc83xx_pci.h #endif diff --git a/arch/ppc/xmon/start.c b/arch/ppc/xmon/start.c index 8f0b953..9056fe5 100644 --- a/arch/ppc/xmon/start.c +++ b/arch/ppc/xmon/start.c @@ -10,7 +10,6 @@ #include linux/sysrq.h #include linux/bitops.h #include asm/xmon.h -#include asm/machdep.h #include asm/errno.h #include asm/processor.h #include asm/delay.h -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
This is my first pass at reworking the Freescale i2c driver. It
switches the driver from being a platform driver to an open firmware
one. I've checked it out on my hardware and it is working.
We may want to hold off on this until arch/ppc goes away (or at least
all users of this driver in arch/ppc).
How about renaming the old driver file and leaving it hooked to ppc?
Then it would get deleted when ppc goes away. That would let work
progress on the powerpc version.
I'm working on this because I'm adding codecs under powerpc that use
i2c and I want consistent device tree use.
You can specific i2c devices on a bus by adding child nodes for them
in the device tree. It does not know how to autoload the i2c chip
driver modules.
[EMAIL PROTECTED] {
device_type = i2c;
compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
dtc supports the mpc5200b-i2c, mpc5200-i2c, fsl-i2c syntax.
cell-index = 1;
What is cell-index for?
I was using it to control the bus number, is that the wrong attribute?
fsl5200-clocking;
As Matt pointed out, this is redundant.
[EMAIL PROTECTED] {
device_type = rtc;
This isn't really necessary.
Code doesn't access it. I copied it from a pre-existing device tree.
One side effect is that legacy style i2c drivers won't work anymore.
If you mean legacy-style client drivers, why not?
i2c_new_device() doesn't work with legacy-style client drivers.
The driver contains a table for mapping device tree style names to
linux kernel ones.
Can we please put this in common code instead?
+static struct i2c_driver_device i2c_devices[] = {
+ {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
+ {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
+ {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
+ {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
+ {epson,pcf8564, rtc-pcf8563, pcf8564,},
+};
At the very least, include the entries that are already being used with
this driver in fsl_soc.c.
This is the same table from fsl_soc.c it has been moved. The data
really belongs in the i2c drivers if I can figure out how to get it
there.
I'd like to get rid of this table. There are two obvious solutions,
use names in the device tree that match up with the linux device
driver names.
This was proposed and rejected a while ago. For one thing, some drivers
handle multiple chips, and we shouldn't base device tree bindings on
what groupings Linux happens to make in what driver supports what.
Or push these strings into the chip drivers and modify
i2c-core to also match on the device tree style names.
That would be ideal; it just hasn't been done yet.
This is not hard to do but the i2c people will have to agree. I need
to change the i2c_driver structure to include the additional names.
A middle ground for now would be to keep one table in drivers/of or
something.
Without one of
these changes the table is going to need a mapping for every i2c
device on the market.
Nah, only one for every i2c device Linux supports. :-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 1cf29c9..6f80216 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -306,122 +306,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include linux/i2c.h
-struct i2c_driver_device {
- char*of_device;
- char*i2c_driver;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
- {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
- {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
- {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
-};
This is obviously not based on head-of-tree -- there are several more
entries in this table.
It is based on 2.6.23. Head of tree hasn't been working very well for
me. I'll rebase it when I can get things working again.
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..5ceb936 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,7 @@
#include linux/module.h
#include linux/sched.h
#include linux/init.h
-#include linux/platform_device.h
+#include asm/of_platform.h
Should be linux/of_platform.h
changed
@@ -180,7 +182,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c-adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +194,15 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target 1), i2c-base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) 0)
-
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Jon Smirl [EMAIL PROTECTED] wrote: This is my first pass at reworking the Freescale i2c driver. It switches the driver from being a platform driver to an open firmware one. I've checked it out on my hardware and it is working. Is there any way to have the i2c chip modules match on the device tree and be automatically loaded? This is complicated by the fact that these modules are used on other platforms. If there is a way to do this for the i2c bus I can apply the same code to the audio bus as well. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Jon Smirl wrote:
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
This is my first pass at reworking the Freescale i2c driver. It
switches the driver from being a platform driver to an open firmware
one. I've checked it out on my hardware and it is working.
We may want to hold off on this until arch/ppc goes away (or at least
all users of this driver in arch/ppc).
How about renaming the old driver file and leaving it hooked to ppc?
Then it would get deleted when ppc goes away. That would let work
progress on the powerpc version.
Or we could have one driver that has two probe methods. I don't like
forking the driver.
I'm working on this because I'm adding codecs under powerpc that use
i2c and I want consistent device tree use.
We already support i2c clients in the device tree, via the code in
fsl_soc.c.
cell-index = 1;
What is cell-index for?
I was using it to control the bus number, is that the wrong attribute?
It shouldn't be specified at all -- the hardware has no concept of a
device number.
[EMAIL PROTECTED] {
device_type = rtc;
This isn't really necessary.
Code doesn't access it. I copied it from a pre-existing device tree.
I'm just trying to keep the damage from spreading. :-)
One side effect is that legacy style i2c drivers won't work anymore.
If you mean legacy-style client drivers, why not?
i2c_new_device() doesn't work with legacy-style client drivers.
No, but they should still work the old way.
Or push these strings into the chip drivers and modify
i2c-core to also match on the device tree style names.
That would be ideal; it just hasn't been done yet.
This is not hard to do but the i2c people will have to agree. I need
to change the i2c_driver structure to include the additional names.
I got a fair bit of resistance from them on the topic of multiple match
names for i2c clients.
Most of this code should be made generic and placed in drivers/of.
How so, it is specific to adding i2c drivers.
I meant generic with respect to the type of i2c controller, not generic
to all device types. :-)
It could be drivers/of/i2c.c, or drivers/i2c/of.c, etc.
We might as well just use i2c_new_device() instead of messing around
with bus numbers. Note that this is technically no longer platform
code, so it's harder to justify claiming the static numberspace.
I was allowing control of the bus number with cell-index and
i2c_add_numbered_adapter().
Should I get rid of this and switch to i2c_add_adapter()?
Yes.
+ i2c-base = ioremap((phys_addr_t)mem.start, MPC_I2C_REGION);
if (!i2c-base) {
printk(KERN_ERR i2c-mpc - failed to map controller\n);
Use of_iomap().
I didn't write this, how should it be done? MPC_I2C_REGION can be
eliminated by using mem.start - mem.end.
i2c-base = of_iomap(op-node, 0);
of_address_to_resource() and ioremap() are combined into one.
Let's take this opportunity to stop matching on device_type here
(including updating booting-without-of.txt).
Remove the .type line and leave .compatible?
Yes.
+static struct of_platform_driver mpc_i2c_driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
+ .match_table= mpc_i2c_of_match,
+ .probe = mpc_i2c_probe,
+ .remove = __devexit_p(mpc_i2c_remove),
+ .driver = {
+ .name = DRV_NAME,
},
};
Do we still need .name if we have .driver.name?
Yes, i2c-core is matching on mpc_i2c_driver.name, i2c-core would need
to be changed to use mpc_i2c_driver.driver.name.
How can i2c-core be matching on a field in an OF-specific struct?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
mmap question on ppc440
I am attempting to access the CPLD on the AMCC Sequoia board from
user-land. I open /dev/mem, and mmap it, then try to access the
resulting pointer. That works fine when accessing physical addresses
that correspond to RAM, but as soon as I try to access the CPLD at
physical address 0xc000, I get an infinite machine check.
I've done this successfully on the ARM architecture, and I've found
examples where people do this on PPC, so I would expect this to work.
Here are a few successful reads:
bash-3.00# ./mm -r -a 0
paddr , map_base 0x30018000
: c0348200
bash-3.00# ./mm -r -a 100
paddr , map_base 0x30018100
0100: 7c0004ac
And here is the machine check:
bash-3.00# ./mm -r -a c000
paddr c000, Machine check in kernel mode.
Machine check in kernel mode.
Machine check in kernel mode.
Machine check in kernel mode.
My code looks like this (I'll post the whole program if anybody wants to
see it:
if((fd = open(/dev/mem, O_RDWR | O_SYNC)) == -1) {
fprintf(stderr, cannot open\n);
exit(1);
}
offset = addr MAP_MASK;
paddr = addr ~MAP_MASK;
map_base = (unsigned long *)mmap(NULL, MAP_SIZE,
PROT_READ | PROT_WRITE, MAP_SHARED, fd, paddr);
Is it possible to access devices like this from user-land? If so, what
am I doing wrong?
Thanks,
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Replace some #includes of asm/of_platform.h with linux/of_platform.h.
From: Jon Loeliger [EMAIL PROTECTED] Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- Chip away at some janitor work. arch/powerpc/platforms/82xx/pq2fads.c |2 +- arch/powerpc/platforms/83xx/mpc832x_mds.c |2 +- arch/powerpc/platforms/83xx/mpc832x_rdb.c |2 +- arch/powerpc/platforms/83xx/mpc836x_mds.c |2 +- arch/powerpc/platforms/85xx/mpc85xx_mds.c |2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c index 4f457a9..1be5005 100644 --- a/arch/powerpc/platforms/82xx/pq2fads.c +++ b/arch/powerpc/platforms/82xx/pq2fads.c @@ -15,12 +15,12 @@ #include linux/init.h #include linux/interrupt.h #include linux/fsl_devices.h +#include linux/of_platform.h #include asm/io.h #include asm/cpm2.h #include asm/udbg.h #include asm/machdep.h -#include asm/of_platform.h #include asm/time.h #include sysdev/fsl_soc.h diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c index 972fa85..3ea59af 100644 --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c @@ -23,9 +23,9 @@ #include linux/seq_file.h #include linux/root_dev.h #include linux/initrd.h +#include linux/of_platform.h #include asm/of_device.h -#include asm/of_platform.h #include asm/system.h #include asm/atomic.h #include asm/time.h diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c index fbca336..24e6ce6 100644 --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c @@ -16,8 +16,8 @@ #include linux/pci.h #include linux/spi/spi.h +#include linux/of_platform.h -#include asm/of_platform.h #include asm/time.h #include asm/ipic.h #include asm/udbg.h diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c index 0f3855c..ec1b03b 100644 --- a/arch/powerpc/platforms/83xx/mpc836x_mds.c +++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c @@ -29,9 +29,9 @@ #include linux/seq_file.h #include linux/root_dev.h #include linux/initrd.h +#include linux/of_platform.h #include asm/of_device.h -#include asm/of_platform.h #include asm/system.h #include asm/atomic.h #include asm/time.h diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c index 61b3eed..1d81d22 100644 --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c @@ -30,9 +30,9 @@ #include linux/initrd.h #include linux/module.h #include linux/fsl_devices.h +#include linux/of_platform.h #include asm/of_device.h -#include asm/of_platform.h #include asm/system.h #include asm/atomic.h #include asm/time.h -- 1.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mmap question on ppc440
On Mon, 05 Nov 2007 16:02:59 -0500 Steven A. Falco [EMAIL PROTECTED] wrote: I am attempting to access the CPLD on the AMCC Sequoia board from user-land. I open /dev/mem, and mmap it, then try to access the resulting pointer. That works fine when accessing physical addresses that correspond to RAM, but as soon as I try to access the CPLD at physical address 0xc000, I get an infinite machine check. That's because the CPLD is actually at physical address 0x1C000. Yay for 36-bit physical addresses. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
From: Jon Loeliger [EMAIL PROTECTED]
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
---
Chip away at some janitor work.
arch/powerpc/platforms/40x/walnut.c |3 ++-
arch/powerpc/platforms/44x/bamboo.c |3 ++-
arch/powerpc/platforms/44x/ebony.c |3 ++-
arch/powerpc/platforms/44x/sequoia.c |3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/40x/walnut.c
b/arch/powerpc/platforms/40x/walnut.c
index eb0c136..ff6db24 100644
--- a/arch/powerpc/platforms/40x/walnut.c
+++ b/arch/powerpc/platforms/40x/walnut.c
@@ -17,12 +17,13 @@
*/
#include linux/init.h
+#include linux/of_platform.h
+
#include asm/machdep.h
#include asm/prom.h
#include asm/udbg.h
#include asm/time.h
#include asm/uic.h
-#include asm/of_platform.h
static struct of_device_id walnut_of_bus[] = {
{ .compatible = ibm,plb3, },
diff --git a/arch/powerpc/platforms/44x/bamboo.c
b/arch/powerpc/platforms/44x/bamboo.c
index 470e1a3..be23f11 100644
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ b/arch/powerpc/platforms/44x/bamboo.c
@@ -14,12 +14,13 @@
* option) any later version.
*/
#include linux/init.h
+#include linux/of_platform.h
+
#include asm/machdep.h
#include asm/prom.h
#include asm/udbg.h
#include asm/time.h
#include asm/uic.h
-#include asm/of_platform.h
#include 44x.h
static struct of_device_id bamboo_of_bus[] = {
diff --git a/arch/powerpc/platforms/44x/ebony.c
b/arch/powerpc/platforms/44x/ebony.c
index 40e18fc..6cd3476 100644
--- a/arch/powerpc/platforms/44x/ebony.c
+++ b/arch/powerpc/platforms/44x/ebony.c
@@ -17,12 +17,13 @@
*/
#include linux/init.h
+#include linux/of_platform.h
+
#include asm/machdep.h
#include asm/prom.h
#include asm/udbg.h
#include asm/time.h
#include asm/uic.h
-#include asm/of_platform.h
#include 44x.h
diff --git a/arch/powerpc/platforms/44x/sequoia.c
b/arch/powerpc/platforms/44x/sequoia.c
index 30700b3..21a9dd1 100644
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ b/arch/powerpc/platforms/44x/sequoia.c
@@ -14,12 +14,13 @@
* option) any later version.
*/
#include linux/init.h
+#include linux/of_platform.h
+
#include asm/machdep.h
#include asm/prom.h
#include asm/udbg.h
#include asm/time.h
#include asm/uic.h
-#include asm/of_platform.h
#include 44x.h
static struct of_device_id sequoia_of_bus[] = {
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Matt Sealey wrote: Scott Wood wrote: Jon Smirl wrote: cell-index = 1; What is cell-index for? I was using it to control the bus number, is that the wrong attribute? It shouldn't be specified at all -- the hardware has no concept of a device number. Well, all i2c devices have a chip id you can probe for, I meant a controller device number (a.k.a. bus number), which (outside of documentation) is purely a Linux invention, and which is what cell-index was being used for above. as for buses I think cell-index is a holdover from the way the PSC code is organised on the MPC5200 for example - if you have multiple buses which use the same registers, for example. It's redundant on the PSC's for programming because they all use different register offsets but if you move to other devices like the GPTs, then it is then useful for debugging (it is far more interesting to say GPT1 than GPT @ offset to match the) and in general for tweaking OTHER parts of the chip (for instance the CDM - very relevant!) which use single registers to control entire swathes of units. Right, that's what cell-index is for. This is different. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Replace some #includes of asm/of_platform.h with linux/of_platform.h.
Hi Jon, Thanks for starting this. On Mon, 05 Nov 2007 15:05:06 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: From: Jon Loeliger [EMAIL PROTECTED] Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] #include asm/of_device.h asm/of_device.h - linux/of_device.h as well? :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpVn0T1ZoBQw.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
On Mon, 05 Nov 2007 15:43:43 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: From: Jon Loeliger [EMAIL PROTECTED] Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpAwSYRf8wy0.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Jon Smirl wrote: On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Jon Smirl wrote: This is my first pass at reworking the Freescale i2c driver. It switches the driver from being a platform driver to an open firmware one. I've checked it out on my hardware and it is working. We may want to hold off on this until arch/ppc goes away (or at least all users of this driver in arch/ppc). How about renaming the old driver file and leaving it hooked to ppc? Then it would get deleted when ppc goes away. That would let work progress on the powerpc version. Or we could have one driver that has two probe methods. I don't like forking the driver. I agree. This driver can and should have multiple bus bindings. cell-index = 1; What is cell-index for? I was using it to control the bus number, is that the wrong attribute? It shouldn't be specified at all -- the hardware has no concept of a device number. cell-index is important. It describes the hardware, or more specifically the layout of the SoC. The SoC has 2 i2c busses which are numbered 0 and 1. This property should stay for the 5200. However, that is the only purpose of it. cell-index does *not* describe the system level bus number. I was allowing control of the bus number with cell-index and i2c_add_numbered_adapter(). Should I get rid of this and switch to i2c_add_adapter()? Yes. Yes, the purpose of cell-index is not to give an i2c bus number enumeration. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Matt Sealey wrote: Scott Wood wrote: Jon Smirl wrote: cell-index = 1; What is cell-index for? I was using it to control the bus number, is that the wrong attribute? It shouldn't be specified at all -- the hardware has no concept of a device number. Well, all i2c devices have a chip id you can probe for, I meant a controller device number (a.k.a. bus number), which (outside of documentation) is purely a Linux invention, and which is what cell-index was being used for above. as for buses I think cell-index is a holdover from the way the PSC code is organised on the MPC5200 for example - if you have multiple buses which use the same registers, for example. It's redundant on the PSC's for programming because they all use different register offsets but if you move to other devices like the GPTs, then it is then useful for debugging (it is far more interesting to say GPT1 than GPT @ offset to match the) Actually, it is not intended for this. cell-index is not intended to be able to say GPT1 instead of [EMAIL PROTECTED] (while that may be possible, it is not the intent). Nor is it a holdover from the PSC code design. It is designed to describe the internal structure of the SoC. The 5200 has 6 PSCs, and there are some chip registers which are shared between all the PSCs (for clocking, IO mode, etc). It is not sufficient to simply plop down a device tree node for each PSC because it doesn't give enough information about which bits to use in the shared regs. (For example, the port_config register) and in general for tweaking OTHER parts of the chip (for instance the CDM - very relevant!) which use single registers to control entire swathes of units. Right, that's what cell-index is for. This is different. :-) Yes, this is correct. 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: libfdt: Fix sw_tree1 testcase
On Mon, Nov 05, 2007 at 09:11:25AM -0600, Jon Loeliger wrote: So, like, the other day David Gibson mumbled: There is a bug in the sw_tree1 testcase / utility which puts two compatible properties in one node in the output tree. This patch fixes the bug, and also adds a new test checking that the sw_tree1 output is equal to test_tree1.dtb as its supposed to be, which should catch future errors of this type. Signed-off-by: David Gibson [EMAIL PROTECTED] This change appears to cause a test to fail. I've not looked into it beyond make check failed: Crud, I screwed up and gave you an intermediate version of the patch which tried to do the same thing for rw_tree1. For that to work, I'll need to write a dtbs_equal_notordered test. Corrected version below. libfdt: Fix sw_tree1 testcase There is a bug in the sw_tree1 testcase / utility which puts two compatible properties in one node in the output tree. This patch fixes the bug, and also adds a new test checking that the sw_tree1 output is equal to test_tree1.dtb as its supposed to be, which should catch future errors of this type. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/tests/run_tests.sh === --- dtc.orig/tests/run_tests.sh 2007-11-06 10:38:21.0 +1100 +++ dtc/tests/run_tests.sh 2007-11-06 10:39:37.0 +1100 @@ -71,6 +71,7 @@ run_test sw_tree1 tree1_tests sw_tree1.test.dtb tree1_tests unfinished_tree1.test.dtb +run_test dtbs_equal_ordered test_tree1.dtb sw_tree1.test.dtb # fdt_move tests for tree in test_tree1.dtb sw_tree1.test.dtb unfinished_tree1.test.dtb; do Index: dtc/tests/sw_tree1.c === --- dtc.orig/tests/sw_tree1.c 2007-11-05 16:59:13.0 +1100 +++ dtc/tests/sw_tree1.c2007-11-06 10:39:37.0 +1100 @@ -64,7 +64,6 @@ CHECK(fdt_begin_node(fdt, subsubnode)); CHECK(fdt_property(fdt, compatible, subsubnode1\0subsubnode, 23)); - CHECK(fdt_property_string(fdt, compatible, subsubnode1\0)); CHECK(fdt_property_typed(fdt, prop-int, TEST_VALUE_1)); CHECK(fdt_end_node(fdt)); CHECK(fdt_end_node(fdt)); -- 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] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
On Tue, 6 Nov 2007 09:40:14 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote: On Mon, 05 Nov 2007 15:43:43 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: From: Jon Loeliger [EMAIL PROTECTED] Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] Yeah, this is fine with me too. But why haven't we put a #warning in asm/of_platform.h and asm/prom.h? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Jon Smirl wrote: On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: Jon Smirl wrote: This is my first pass at reworking the Freescale i2c driver. It switches the driver from being a platform driver to an open firmware one. I've checked it out on my hardware and it is working. We may want to hold off on this until arch/ppc goes away (or at least all users of this driver in arch/ppc). How about renaming the old driver file and leaving it hooked to ppc? Then it would get deleted when ppc goes away. That would let work progress on the powerpc version. Or we could have one driver that has two probe methods. I don't like forking the driver. I agree. This driver can and should have multiple bus bindings. What non-of platform uses this driver? I believe this is the last struct platform driver left for the mpc5200. Fixing this one allows the platform bus to be removed. With a device tree there isn't any reason to keep a platform bus, everything should be on the of_platform bus. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote: One side effect is that legacy style i2c drivers won't work anymore. If you mean legacy-style client drivers, why not? i2c_new_device() doesn't work with legacy-style client drivers. No, but they should still work the old way. I'm not in favor trying to support both legacy and new style i2c drivers. It took me all of five minutes to convert an existing legacy driver to the new style. Pretty much all you need to do is delete code (about 100 lines). So I'd recommend converting the drivers we are interest in instead of trying to support both types. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
On Mon, 5 Nov 2007 17:53:41 -0600 Josh Boyer [EMAIL PROTECTED] wrote: Yeah, this is fine with me too. But why haven't we put a #warning in asm/of_platform.h and asm/prom.h? Because thee are way to many places to be fixed yet. And asm/prom.h needs to be explicitly included if you want to use the flattened device tree accessors. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpWypRt9NB9t.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: prpmc2800 - Don't trust documented memory size
It turns out that the firmware on some PrPMC2800 processor modules initializes the memory controller for 512 MB even when there is more memory. As a simple work around, set the amount of memory in the device tree passed to the kernel to the lesser of what the memory controller is set up for and the actual amount of memory. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- arch/powerpc/boot/prpmc2800.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c index 9614e1d..559c45e 100644 --- a/arch/powerpc/boot/prpmc2800.c +++ b/arch/powerpc/boot/prpmc2800.c @@ -405,7 +405,10 @@ static void prpmc2800_fixups(void) bip = prpmc2800_get_bip(); /* Get board info based on VPD */ - mem_size = (bip) ? bip-mem_size : mv64x60_get_mem_size(bridge_base); + mem_size = mv64x60_get_mem_size(bridge_base); + if (bip) + mem_size = min(mem_size, bip-mem_size); + prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */ /* If the VPD doesn't match what we know about, just use the ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote:
+static struct of_platform_driver mpc_i2c_driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
+ .match_table= mpc_i2c_of_match,
+ .probe = mpc_i2c_probe,
+ .remove = __devexit_p(mpc_i2c_remove),
+ .driver = {
+ .name = DRV_NAME,
},
};
Do we still need .name if we have .driver.name?
This is a general question, if of_platform_driver doesn't need .name
it should be removed from the structure.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] pasemi: Broaden specific references to 1682M
On Tue, Nov 06, 2007 at 02:42:08AM +0100, Segher Boessenkool wrote:
Hi Olof,
Nice cleanup! One minor thing...
static struct of_device_id pasemi_bus_ids[] = {
+/* Unfortunately needed for legacy firmwares */
{ .type = localbus, },
{ .type = sdc, },
+{ .compatible = pasemi,localbus, },
+{ .compatible = pasemi,sdc, },
The new comment is for the device_type entries only, right? You
might want to make that more clear.
Good point. I'll clarify it with a new comment above the compatible
entries. I won't repost the patch since the change is minor, but include
it for the upstream push.
Thanks,
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: prpmc2800 - Don't trust documented memory size
On Mon, Nov 05, 2007 at 06:28:05PM -0700, Mark A. Greer wrote: It turns out that the firmware on some PrPMC2800 processor modules initializes the memory controller for 512 MB even when there is more memory. As a simple work around, set the amount of memory in the device tree passed to the kernel to the lesser of what the memory controller is set up for and the actual amount of memory. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- Paul, please ignore this patch. There is still something wrong. Sorry for the noise. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] pasemi: Don't reset mpic at boot
[POWERPC] pasemi: Don't reset mpic at boot Due to an erratum, we don't want to reset the mpic at boot time. It can sometimes cause problems with lost interrupts later on while running. Signed-off-by: Olof Johansson [EMAIL PROTECTED] diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c index 857d238..bd85853 100644 --- a/arch/powerpc/platforms/pasemi/setup.c +++ b/arch/powerpc/platforms/pasemi/setup.c @@ -214,7 +214,7 @@ static __init void pas_init_IRQ(void) printk(KERN_DEBUG OpenPIC addr: %lx\n, openpic_addr); mpic = mpic_alloc(mpic_node, openpic_addr, - MPIC_PRIMARY|MPIC_LARGE_VECTORS|MPIC_WANTS_RESET, + MPIC_PRIMARY|MPIC_LARGE_VECTORS, 0, 0, PAS-OPIC ); BUG_ON(!mpic); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On Mon, 5 Nov 2007 20:34:51 -0500 Jon Smirl [EMAIL PROTECTED] wrote:
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote:
+static struct of_platform_driver mpc_i2c_driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
+ .match_table= mpc_i2c_of_match,
+ .probe = mpc_i2c_probe,
+ .remove = __devexit_p(mpc_i2c_remove),
+ .driver = {
+ .name = DRV_NAME,
},
};
Do we still need .name if we have .driver.name?
This is a general question, if of_platform_driver doesn't need .name
it should be removed from the structure.
I am in the process of doing that. However there a quite a few drivers
that need to be fixed first. In the meantime,
of_register_platform_driver will copy which ever of the name and owner
fields you fill in to the others, so we can convert over time. For new
drivers (and changing), please use the name and owner fields in the
embedded device_driver struct. (this is the same as done by the platform
drivers currently ...)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpD6Eb0OCgP6.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] reduce load time for modules with lots of relocs
Nathan Lynch wrote:
Medve Emilian-EMMEDVE1 wrote:
I have module with 36K relocation entries (I know, I know, how could
that be...) and the count_relocs() function takes ~17 seconds to crunch
through the relocation table from the .rela.text section. I don't think
I can reduce the number of entries in the relocation table (can I?) so
I'm thinking at improving the performance of count_relocs() (currently
O(n^2)). Does anybody have a simpler idea? Does anyone have any
constructive suggestion on how to improve the situation?
This seems to come up every few months. There was a patch submitted
here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
I think this comes up often enough for us to fix it (IIRC unionfs
people complained about it long ago too), and it's kind of lame to
spend 17 seconds in the kernel without scheduling. So I dug up some
old patches that should reduce the complexity to O(n logn), using the
sort() function, which IMO is preferable to doing our own hash thing
as that patch from June does. Only the 64-bit code is tested. Does
this help your situation?
arch/powerpc/kernel/module_32.c | 85 +++-
arch/powerpc/kernel/module_64.c | 80 ++---
2 files changed, 132 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 07a89a3..001b941 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -24,6 +24,7 @@
#include linux/kernel.h
#include linux/cache.h
#include linux/bug.h
+#include linux/sort.h
#include setup.h
@@ -50,26 +51,64 @@ void module_free(struct module *mod, void *module_region)
table entries. */
}
+static int reloc_cmp(const void *_a, const void *_b)
+{
+ const Elf32_Rela *a = *(Elf32_Rela **)_a, *b = *(Elf32_Rela **)_b;
+
+ if (a-r_info b-r_info)
+ return -1;
+ else if (a-r_info b-r_info)
+ return 1;
+ else if (a-r_addend b-r_addend)
+ return -1;
+ else if (a-r_addend b-r_addend)
+ return 1;
+
+ return 0;
+}
+
+
/* Count how many different relocations (different symbol, different
addend) */
static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
{
- unsigned int i, j, ret = 0;
+ unsigned int i, sorted_count = 0;
+ Elf32_Word last_info;
+ Elf32_Sword last_addend;
+ Elf32_Rela **sortbuf = NULL;
+
+ if (num == 0)
+ return 0;
+
+ sortbuf = vmalloc(num * sizeof(*sortbuf));
+
+ if (!sortbuf)
+ return -ENOMEM;
+
+ for (i = 0; i num; i++)
+ sortbuf[i] = (Elf32_Rela *)rela[i];
+
+ sort(sortbuf, i, sizeof(sortbuf[0]), reloc_cmp, NULL);
+
+ last_info = sortbuf[0]-r_info;
+ last_addend = sortbuf[0]-r_addend;
+ sorted_count = 1;
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
for (i = 0; i num; i++) {
- for (j = 0; j i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (ELF32_R_SYM(rela[i].r_info)
- == ELF32_R_SYM(rela[j].r_info)
-rela[i].r_addend == rela[j].r_addend)
- break;
- }
- if (j == i) ret++;
+ /* If this r_info,r_addend tuple matches the previous
+* entry, don't count it again
+*/
+ if (sortbuf[i]-r_info == last_info
+ sortbuf[i]-r_addend == last_addend)
+ continue;
+
+ last_info = sortbuf[i]-r_info;
+ last_addend = sortbuf[i]-r_addend;
+ sorted_count++;
}
- return ret;
+
+ vfree(sortbuf);
+ return sorted_count;
}
/* Get the potential trampolines size required of the init and
@@ -96,15 +135,19 @@ static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
continue;
if (sechdrs[i].sh_type == SHT_RELA) {
+ int count;
DEBUGP(Found relocations in section %u\n, i);
DEBUGP(Ptr: %p. Number: %u\n,
(void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela));
- ret += count_relocs((void *)hdr
+ count = count_relocs((void *)hdr
+ sechdrs[i].sh_offset,
sechdrs[i].sh_size
/ sizeof(Elf32_Rela))
* sizeof(struct ppc_plt_entry);
+ if (count 0)
+
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
On 11/5/07, Scott Wood [EMAIL PROTECTED] wrote:
Or push these strings into the chip drivers and modify
i2c-core to also match on the device tree style names.
That would be ideal; it just hasn't been done yet.
This is not hard to do but the i2c people will have to agree. I need
to change the i2c_driver structure to include the additional names.
I got a fair bit of resistance from them on the topic of multiple match
names for i2c clients.
Here's a first pass at pushing the strings back into the i2c drivers.
If this looks reasonable it can be optimized a lot more. A more
advanced version of this code would combine the alias, name, and
driver_name fields. The existing pairing of driver_name/name could be
merged into the concept of alias names for the driver.
Extend i2c-core to support lists of device tree compatible names when
matching drivers
From: Jon Smirl [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-mpc.c | 35 ---
drivers/i2c/i2c-core.c | 17 +++--
drivers/rtc/rtc-pcf8563.c|1 +
drivers/rtc/rtc-rs5c372.c|1 +
include/linux/i2c.h | 11 +--
5 files changed, 30 insertions(+), 35 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4ddebe4..6313631 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -312,34 +312,6 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
-struct i2c_driver_device {
- char*of_device;
- char*i2c_driver;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] = {
- {ricoh,rs5c372a, rtc-rs5c372, rs5c372a,},
- {ricoh,rs5c372b, rtc-rs5c372, rs5c372b,},
- {ricoh,rv5c386, rtc-rs5c372, rv5c386,},
- {ricoh,rv5c387a, rtc-rs5c372, rv5c387a,},
- {epson,pcf8564, rtc-pcf8563, pcf8564,},
-};
-
-static int of_find_i2c_driver(struct device_node *node, struct
i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- strncpy(info-driver_name, i2c_devices[i].i2c_driver,
KOBJ_NAME_LEN);
- strncpy(info-type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
- return 0;
- }
- return -ENODEV;
-}
-
static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
{
struct device_node *node = NULL;
@@ -347,6 +319,7 @@ static void of_register_i2c_devices(struct
i2c_adapter *adap, struct device_node
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info;
const u32 *addr;
+ const char *compatible;
int len;
addr = of_get_property(node, reg, len);
@@ -359,9 +332,9 @@ static void of_register_i2c_devices(struct
i2c_adapter *adap, struct device_node
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, info) 0)
- continue;
-
+ compatible = of_get_property(node, compatible, len);
+ strlcpy(info.driver_name, compatible, len);
+ info.type[0] = '\0';
info.platform_data = NULL;
info.addr = *addr;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d663e69..4128cd1 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -17,7 +17,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
/* - */
-/* With some changes from Kyösti Mälkki [EMAIL PROTECTED].
+/* With some changes from Kyï¿œsti Mï¿œlkki [EMAIL PROTECTED].
All SMBus-related things are written by Frodo Looijaard [EMAIL PROTECTED]
SMBus 2.0 support by Mark Studebaker [EMAIL PROTECTED] and
Jean Delvare [EMAIL PROTECTED] */
@@ -51,6 +51,7 @@ static int i2c_device_match(struct device *dev,
struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
+ char **alias;
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
@@ -61,7 +62,19 @@ static int i2c_device_match(struct device *dev,
struct device_driver *drv)
/* new style drivers use the same kind of driver matching policy
* as platform devices or SPI: compare device and driver IDs.
*/
- return strcmp(client-driver_name, drv-name) == 0;
+ if (strcmp(client-driver_name, drv-name) == 0)
+ return true;
+
+ /* Match against alias device tree names */
+ if (!driver-alias)
+ return 0;
+ alias = driver-alias;
+ while (*alias) {
+
Re: [RFC/PATCH] reduce load time for modules with lots of relocs
On Mon, 5 Nov 2007 20:33:55 -0600 Nathan Lynch [EMAIL PROTECTED] wrote:
static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
{
- unsigned int i, j, ret = 0;
+ unsigned int i, sorted_count = 0;
+ Elf32_Word last_info;
+ Elf32_Sword last_addend;
+ Elf32_Rela **sortbuf = NULL;
You don't need to initialise sortbuf and f you make it a const
Elf32_Rela ** ...
+ sortbuf = vmalloc(num * sizeof(*sortbuf));
+ if (!sortbuf)
+ return -ENOMEM;
+
+ for (i = 0; i num; i++)
+ sortbuf[i] = (Elf32_Rela *)rela[i];
You shouldn't need that cast.
-static unsigned int count_relocs(const Elf64_Rela *rela, unsigned int num)
+static int count_relocs(const Elf64_Rela *rela, unsigned int num)
{
unsigned int i, j, ret = 0;
+ Elf64_Xword last_info;
+ Elf64_Sxword last_addend;
+ Elf64_Rela **sortbuf = NULL;
Same here.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpnW1xiF8YKl.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] Fix rtas_ibm_suspend_me bugs
(very rfc for now, no sign-off, needs more testing)
There are a couple of bugs in the rtas_ibm_suspend_me() and
rtas_percpu_suspend_me() functions:
1. rtas_ibm_suspend_me() uses on_each_cpu() to invoke
rtas_percpu_suspend_me() via IPI:
if (on_each_cpu(rtas_percpu_suspend_me, data, 1, 0))
...
'data' is on the stack, and rtas_ibm_suspend_me() takes no measures to
ensure that all instances of rtas_percpu_suspend_me() are finished
accessing 'data' before returning. This can result in the IPI'd cpus
accessing random stack data and getting stuck in H_JOIN.
Fix this by moving rtas_suspend_me_data off the stack, and protect it
with a mutex. Use a completion to ensure that all cpus are done
accessing the data before unlocking.
2. rtas_percpu_suspend_me passes the Linux logical cpu id to the
H_PROD hypervisor method, when it should be using the platform
interrupt server value for that cpu (hard_smp_processor_id). In
practice, this probably causes problems only on partitions where
processors have been removed and added in a particular order.
---
arch/powerpc/kernel/rtas.c | 64 ---
1 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 2147807..24faaea 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -19,6 +19,9 @@
#include linux/init.h
#include linux/capability.h
#include linux/delay.h
+#include linux/mutex.h
+#include linux/completion.h
+#include linux/smp.h
#include asm/prom.h
#include asm/rtas.h
@@ -34,6 +37,7 @@
#include asm/lmb.h
#include asm/udbg.h
#include asm/syscalls.h
+#include asm/atomic.h
struct rtas_t rtas = {
.lock = SPIN_LOCK_UNLOCKED
@@ -41,10 +45,21 @@ struct rtas_t rtas = {
EXPORT_SYMBOL(rtas);
struct rtas_suspend_me_data {
+ atomic_t working; /* number of cpus accessing rtas_suspend_me_data */
long waiting;
struct rtas_args *args;
+ struct completion done; /* wait on this until working == 0 */
};
+static void rtas_suspend_me_data_init(struct rtas_suspend_me_data *rsmd,
+ struct rtas_args *args)
+{
+ atomic_set(rsmd-working, 0);
+ rsmd-waiting = 1;
+ rsmd-args = args;
+ init_completion(rsmd-done);
+}
+
DEFINE_SPINLOCK(rtas_data_buf_lock);
EXPORT_SYMBOL(rtas_data_buf_lock);
@@ -671,36 +686,49 @@ static void rtas_percpu_suspend_me(void *info)
* we set it to 0.
*/
local_irq_save(flags);
+ atomic_inc(data-working);
do {
rc = plpar_hcall_norets(H_JOIN);
smp_rmb();
} while (rc == H_SUCCESS data-waiting 0);
if (rc == H_SUCCESS)
+ /* join is complete (or there was an error) and this
+* cpu was prodded
+*/
goto out;
if (rc == H_CONTINUE) {
+ /* this cpu does the join */
data-waiting = 0;
data-args-args[data-args-nargs] =
rtas_call(ibm_suspend_me_token, 0, 1, NULL);
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD,i);
} else {
data-waiting = -EBUSY;
printk(KERN_ERR Error on H_JOIN hypervisor call\n);
}
+ /* This cpu did the join or got an error, so we need to prod
+* everyone else. Extra prods are harmless.
+*/
+ for_each_online_cpu(i)
+ plpar_hcall_norets(H_PROD, get_hard_smp_processor_id(i));
+
out:
+ if (atomic_dec_return(data-working) == 0)
+ complete(data-done);
local_irq_restore(flags);
return;
}
+static DEFINE_MUTEX(rsm_lock); /* protects rsm_data */
+static struct rtas_suspend_me_data rsm_data;
+
static int rtas_ibm_suspend_me(struct rtas_args *args)
{
- int i;
+ int err;
long state;
long rc;
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
- struct rtas_suspend_me_data data;
/* Make sure the state is valid */
rc = plpar_hcall(H_VASI_STATE, retbuf,
@@ -721,25 +749,27 @@ static int rtas_ibm_suspend_me(struct rtas_args *args)
return 0;
}
- data.waiting = 1;
- data.args = args;
+ mutex_lock(rsm_lock);
+
+ rtas_suspend_me_data_init(rsm_data, args);
- /* Call function on all CPUs. One of us will make the
-* rtas call
+ /* Call function on all CPUs. One of us (but not necessarily
+* this one) will make the ibm,suspend-me call.
*/
- if (on_each_cpu(rtas_percpu_suspend_me, data, 1, 0))
- data.waiting = -EINVAL;
+ if (on_each_cpu(rtas_percpu_suspend_me, rsm_data, 1, 0))
+ rsm_data.waiting = -EINVAL;
+
+ /* Must wait for all IPIs to complete before unlocking */
+ wait_for_completion(rsm_data.done);
- if (data.waiting != 0)
+ if
Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
Hi Jon,
On Mon, 5 Nov 2007 23:25:35 -0500 Jon Smirl [EMAIL PROTECTED] wrote:
+ compatible = of_get_property(node, compatible, len);
+ strlcpy(info.driver_name, compatible, len);
Of course, you will check len against sizeof(info.driver_name), right?
-/* With some changes from Kyösti Mälkki [EMAIL PROTECTED].
+/* With some changes from Kyï¿œsti Mï¿œlkki [EMAIL PROTECTED].
Did you mean to change this?
+ char **alias;
const char ** would be nicer.
struct i2c_driver {
int id;
unsigned int class;
+
+ /* Alias name for the driver. Used to support device trees on
+ * the PowerPC architecture. Device tree names take the form of
+ * vendor,chip. For example epson,pcf8564. Alias is a list of
+ * strings terminated by a zero entry.
+ */
+ char **alias;
const char ** would be nicer;
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpXADQEA2eM8.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mmap question on ppc440
On Monday 05 November 2007, Josh Boyer wrote:
I am attempting to access the CPLD on the AMCC Sequoia board from
user-land. I open /dev/mem, and mmap it, then try to access the
resulting pointer. That works fine when accessing physical addresses
that correspond to RAM, but as soon as I try to access the CPLD at
physical address 0xc000, I get an infinite machine check.
That's because the CPLD is actually at physical address 0x1C000.
Yay for 36-bit physical addresses.
Right. Are you using arch/ppc or arch/powerpc? If it's arch/ppc you could
give the following patch a try:
@@ -275,6 +275,14 @@
{
size_t size = vma-vm_end - vma-vm_start;
+#if defined(CONFIG_44x) !defined(CONFIG_PPC_MERGE)
+ /*
+* 2006-08-07: sr
+* Needed on 44x-er systems for 36bit addresses (like pci on 440gx)
+*/
+ vma-vm_pgoff = (fixup_bigphys_addr(vma-vm_pgoff PAGE_SHIFT, size)
PAGE_SHIFT);
+#endif
+
if (!valid_mmap_phys_addr_range(vma-vm_pgoff, size))
return -EINVAL;
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
