Re: [PATCH] ps3: vuart: semaphore to mutex
On Thu, 10 Jan 2008, Daniel Walker wrote: This probe_mutex conforms to the new struct mutex type. This patch converts it from the old semaphore to the new struct mutex. The PS3 tree already has this change. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PCI Failed to allocate mem for PCI ROM
Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
Hi Jon, On Wed, 19 Dec 2007 23:41:36 -0500, Jon Smirl wrote: Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed. Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading. The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. Now that I have read all the previous versions of this patch series and, more importantly, all objections that were raised on the way, I can start reviewing the latest iteration of your patches. I'll also do some testing, although I have no powerpc stuff here, but at least I want to make sure that there are no regressions introduced by your patches on x86. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote: On 01/11/2008 09:29 AM, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Kernel version, please. Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ps3: vuart: semaphore to mutex
On Fri, 2008-01-11 at 09:20 +0100, Geert Uytterhoeven wrote: On Thu, 10 Jan 2008, Daniel Walker wrote: This probe_mutex conforms to the new struct mutex type. This patch converts it from the old semaphore to the new struct mutex. The PS3 tree already has this change. With kind regards, Ok, thanks.. Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH, ppc64] improve dedotify()
This completely untested patch is intended to be a suggestion only:
Code inspection for an entirely different purpose made me stumble
across this, and I think that modifying the string table of an ELF
object is a bad idea, since there's nothing disallowing a linker to
merge strings inside the table, which would result in this code
possibly, but unintentionally screwing up other symbol names.
Besides that, the presented alternative is both smaller and faster.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
---
arch/powerpc/kernel/module_64.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
--- linux-2.6.24-rc7/arch/powerpc/kernel/module_64.c2007-02-04
19:44:54.0 +0100
+++ 2.6.24-rc7-ppc64-dedotify/arch/powerpc/kernel/module_64.c 2008-01-08
13:32:33.0 +0100
@@ -154,16 +154,14 @@ static void dedotify_versions(struct mod
}
/* Undefined symbols which refer to .funcname, hack to funcname */
-static void dedotify(Elf64_Sym *syms, unsigned int numsyms, char *strtab)
+static void dedotify(Elf64_Sym *syms, unsigned int numsyms, const char *strtab)
{
unsigned int i;
for (i = 1; i numsyms; i++) {
- if (syms[i].st_shndx == SHN_UNDEF) {
- char *name = strtab + syms[i].st_name;
- if (name[0] == '.')
- memmove(name, name+1, strlen(name));
- }
+ if (syms[i].st_shndx == SHN_UNDEF
+strtab[syms[i].st_name] == '.')
+ syms[i].st_name++;
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Hi Sean,
On Fri, 11 Jan 2008 02:10:45 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
Stephen Rothwell wrote:
On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
No comments? I really thought I would get raked over the coals for this
one.
Ah ha! A challenge! :-)
I hoped somebody would respond to that ;)
Glad to oblige.
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
no externs in C code - put it in a header file.
I didn't know where to put this extern. It is fairly specific to this
driver, although a generic function... if that makes sense. It returns
the exact contents of the register rather than doing any conversion.
Any recommendations for a location gladly accepted.
I don't where that function is actually defined - I assume it is in one
of the other recent patch sets.
/me searches ...
/me reads ad7414 driver email ...
/me notes spaces missing there as well :-)
Tricky. You have something that can only be built in (pika_dtm_thread in
warp.c) calling something that might be a module ... I think you need to
think of a new way of organizing these pieces.
While I am looking, the return type of ioremap is void __iomem *, so
you need to annotate your fpga variable appropriately and the parameter
to pika_dtm_thread.
And below has all the above mentioned fixes, except the extern.
You seem to have forgotten some of the spaces after ifs, switchs and
whiles.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp55h0LF512Z.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On 01/11/2008 09:29 AM, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Kernel version, please. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On 01/11/2008 10:07 AM, Kumar Gala wrote: On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote: On 01/11/2008 09:29 AM, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Kernel version, please. Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25 Could you try this patch? http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob_plain;f=pci/pci-remove-default-pci-expansion-rom-memory-allocation.patch Greg: is this 2.6.25 material, please? We need this for SP2. thanks, -- Jiri Slaby Faculty of Informatics, Masaryk University Suse Labs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] ps3fb fixes for 2.6.24
Hi Linus, Andrew, Here are 2 more fixes for ps3fb: [1] ps3fb: prevent use after free of fb_info [2] ps3fb: fix deadlock on kexec() The first one fixes a potential use after free. The second one fixes a lockup when using kexec or shutdown while /dev/fb0 is open (e.g. when using the petitboot graphical bootloader to load the second stage kernel). Can we please get these in 2.6.24? Thanks! With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-virtex.git
On Wed, 9 Jan 2008 08:03:31 -0700 Grant Likely [EMAIL PROTECTED] wrote: Gah; teach me to pick up patches right before bed. I shouldn't have picked up the ulite console changes patch just yet. I've dropped it from the series until I have a chance to rework it. Sorry. Here's the new pull request The following changes since commit 4f43143f9fbbb679c38d2ff99e44d3aaa00d0fe1: Paul Mackerras (1): Merge branch 'for-2.6.25' of git://git.kernel.org/.../olof/pasemi are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.25 Stephen Neuendorffer (5): [POWERPC] Xilinx: update compatible list for interrupt controller [POWERPC] Xilinx: Add correct compatible list for device tree bus bindings. [POWERPC] Xilinx: Update booting-without-of. [POWERPC] Xilinx: updated device tree compatibility to match uboot bsp generator. [POWERPC] Xilinx uartlite: Section type fixups Pulled and pushed out. I'll ask Paul to pull after I finish chasing the Warp patches Sean is working on, and the RTC patch from David. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add fdt_set_name() function
So, like, the other day Josh Boyer mumbled: On Fri, 11 Jan 2008 07:44:33 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: So, like, the other day David Gibson mumbled: This patch adds an fdt_set_name() function to libfdt, mirroring fdt_get_name(). This is a r/w function which alters the name of a given device tree node. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Awesome. Now if we could just get that into the kernel and usable in the wrappers... :) I've pushed it out now. I guess we'll try to get the real v1.1.0 into the kernel then? Maybe at 2.6.25? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add fdt_set_name() function
On Fri, 11 Jan 2008 07:44:33 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: So, like, the other day David Gibson mumbled: This patch adds an fdt_set_name() function to libfdt, mirroring fdt_get_name(). This is a r/w function which alters the name of a given device tree node. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Awesome. Now if we could just get that into the kernel and usable in the wrappers... :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Am Donnerstag, den 10.01.2008, 19:41 +0100 schrieb Heiko Schocher: Hello Scott, Scott Wood wrote: Heiko Schocher wrote: diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c index f2a4d39..f432a18 100644 --- a/drivers/net/fs_enet/fs_enet-main.c +++ b/drivers/net/fs_enet/fs_enet-main.c @@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev) if (fep-fpi-use_napi) napi_enable(fep-napi); +/* to initialize the fep-cur_rx,... */ +/* not doing this, will cause a crash in fs_enet_rx_napi */ +fs_init_bds(fep-ndev); We should do this just before napi_enable() rather than just after, to eliminate any chance of a race window. Yes, you are right. Here is the new patch: It works fine. Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
Olof Johansson wrote: Having been in a similar situation myself (needing to share resources between DMA, ethernet and function offload), I recommend creating a separate small library that all those drivers use, instead of making some sort of dependency between drivers in completely different parts of the kernel. Well, the DMA driver should be in soon. Actually, it should be in now, because I saw a blurb in this month's Linux Journal about it. As soon as I find it :-), I'll post a new patch that adds arbitration. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] ps3fb: prevent use after free of fb_info
From: Jeremy Kerr [EMAIL PROTECTED]
In ps3fb_shutdown, freeing the framebuffer will cause fb_info (in
dev-core.driver_data) to be free()ed, which we potentially access
from the ps3fbd kthread.
This change frees the framebuffer after stopping the ps3fbd kthread.
Signed-off-by: Jeremy Kerr [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
drivers/video/ps3fb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -1234,12 +1234,6 @@ static int ps3fb_shutdown(struct ps3_sys
ps3fb_flip_ctl(0, ps3fb); /* flip off */
ps3fb.dinfo-irq.mask = 0;
- if (info) {
- unregister_framebuffer(info);
- fb_dealloc_cmap(info-cmap);
- framebuffer_release(info);
- }
-
ps3av_register_flip_ctl(NULL, NULL);
if (ps3fb.task) {
struct task_struct *task = ps3fb.task;
@@ -1250,6 +1244,12 @@ static int ps3fb_shutdown(struct ps3_sys
free_irq(ps3fb.irq_no, dev-core);
ps3_irq_plug_destroy(ps3fb.irq_no);
}
+ if (info) {
+ unregister_framebuffer(info);
+ fb_dealloc_cmap(info-cmap);
+ framebuffer_release(info);
+ info = dev-core.driver_data = NULL;
+ }
iounmap((u8 __iomem *)ps3fb.dinfo);
status = lv1_gpu_context_free(ps3fb.context_handle);
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] ps3fb: fix deadlock on kexec()
From: Jeremy Kerr [EMAIL PROTECTED]
Since the introduction of the acquire_console_sem calls in
0333d83509c7d8496c8965b5ba9bc0c98e83c259, kexecing can cause the
kernel to deadlock:
ps3fb_shutdown()
- unregister_framebuffer()
- fb_notifier_call_chain(FB_EVENT_FB_UNBIND)
- fbcon_fb_unbind()
- unbind_con_driver()
- bind_con_driver()
[ acquires console_sem ]
- fbcon_deinit()
- fbops-fb_release(newinfo, 0)
- ps3fb_release()
- ps3fb_sync()
[ acquires console_sem ]
This change avoids the deadlock by moving the acquire_console_sem()
out of ps3fb_sync(), and puts it into the two other callsites, leaving
ps3fb_release() to call ps3fb_sync() without the console semaphore.
[Geert]
- Corrected call sequence above
- ps3fb_release() may be called with and without console_sem held. This is an
inconsistency that should be fixed at the fb level, but for now, try to
acquire console_sem in ps3fb_release().
I think it's safer to let ps3fb_release() try to acquire console_sem and
not refresh the screen if it fails, than to call ps3fb_sync() without
holding console_sem, as ps3fb_par may be modified at the same time, causing
crashes or lockups.
Besides, ps3fb_release() only calls ps3fb_sync() to refresh the screen
when display flipping is disabled, which is an uncommon case (except during
shutdown/kexec).
Signed-off-by: Jeremy Kerr [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/video/ps3fb.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -443,8 +443,6 @@ static int ps3fb_sync(struct fb_info *in
u32 ddr_line_length, xdr_line_length;
u64 ddr_base, xdr_base;
- acquire_console_sem();
-
if (frame par-num_frames - 1) {
dev_dbg(info-device, %s: invalid frame number (%u)\n,
__func__, frame);
@@ -464,7 +462,6 @@ static int ps3fb_sync(struct fb_info *in
xdr_line_length);
out:
- release_console_sem();
return error;
}
@@ -479,7 +476,10 @@ static int ps3fb_release(struct fb_info
if (atomic_dec_and_test(ps3fb.f_count)) {
if (atomic_read(ps3fb.ext_flip)) {
atomic_set(ps3fb.ext_flip, 0);
- ps3fb_sync(info, 0);/* single buffer */
+ if (!try_acquire_console_sem()) {
+ ps3fb_sync(info, 0);/* single buffer */
+ release_console_sem();
+ }
}
}
return 0;
@@ -865,7 +865,9 @@ static int ps3fb_ioctl(struct fb_info *i
break;
dev_dbg(info-device, PS3FB_IOCTL_FSEL:%d\n, val);
+ acquire_console_sem();
retval = ps3fb_sync(info, val);
+ release_console_sem();
break;
default:
@@ -885,7 +887,9 @@ static int ps3fbd(void *arg)
set_current_state(TASK_INTERRUPTIBLE);
if (ps3fb.is_kicked) {
ps3fb.is_kicked = 0;
+ acquire_console_sem();
ps3fb_sync(info, 0);/* single buffer */
+ release_console_sem();
}
schedule();
}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On 1/11/08, Jean Delvare [EMAIL PROTECTED] wrote: Hi Jon, On Wed, 19 Dec 2007 23:41:36 -0500, Jon Smirl wrote: Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed. Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading. The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. Now that I have read all the previous versions of this patch series and, more importantly, all objections that were raised on the way, I can start reviewing the latest iteration of your patches. I'll also do some testing, although I have no powerpc stuff here, but at least I want to make sure that there are no regressions introduced by your patches on x86. Various people were worried about x86. Around version 15 I altered the patches so that they only impacted PowerPC. If they impact x86 in current form that is a bug. When x86 is ready for it I do think dynamic module loading should be implemented there also. -- Jean Delvare -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On Jan 11, 2008, at 3:13 AM, Jiri Slaby wrote: On 01/11/2008 10:07 AM, Kumar Gala wrote: On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote: On 01/11/2008 09:29 AM, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Kernel version, please. Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25 Could you try this patch? http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob_plain;f=pci/pci-remove-default-pci-expansion-rom-memory-allocation.patch Greg: is this 2.6.25 material, please? We need this for SP2. I saw that patch, but if you notice that its just x86 specific and I'm having the issue on a powerpc 32-bit system. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On 10/01/2008, Nathan Lynch [EMAIL PROTECTED] wrote: Mike Strosaker wrote: At the risk of repeating what others have already said, the PHYP-assistance method provides some advantages that the kexec method cannot: - Availability of the system for production use before the dump data is collected. As was mentioned before, some production systems may choose not to operate with the limited memory initially available after the reboot, but it sure is nice to provide the option. I'm more concerned that this design encourages the user to resume a workload *which is almost certainly known to result in a system crash* before collection of crash data is complete. Maybe the gamble will pay off most of the time, but I wouldn't want to be working support when it doesn't. Workloads that cause crashes within hours of startup tend to be weeded-out/discovered during pre-production test of the system to be deployed. Since its pre-production test, dumps can be taken in a leisurely manner. Heck, even a session at the xmon prompt can be contemplated. The problem is when the crash only reproduces after days or weeks of uptime, on a production machine. Since the machine is in production, its got to be brought back up ASAP. Since its crashing only after days/weeks, the dump should have plenty of time to complete. (And if it crashes quickly after that reboot ... well, support people always welcome ways in which a bug can be reproduced more quickly/easily). --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
Kumar Gala napsal(a): I saw that patch, but if you notice that its just x86 specific and I'm having the issue on a powerpc 32-bit system. My bad, sorry. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Rune Torgersen Finally got it (sort-of) working. Turned out that for some reason the console init is setting the baudrate to 9600 the options string passed in to the console init fuunction is NULL. Any idea oon how this should be passed in from u-boot? Ok, needed a valid console= line on the command line. WHen we tried that, we had a typo, so it was not recognized. Our old 2.6.18 arch/ppc kernel didn't need a console parameter, it got the baudrate from u-boot somehow. Anyway of doing that here too? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
On Fri, 11 Jan 2008 02:10:45 -0500
Sean MacLennan [EMAIL PROTECTED] wrote:
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool PCI support if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x !CPM2 !8xx !PPC_83xx \
!PPC_85xx !PPC_86xx
default PCI_PERMEDIA if !4xx !CPM2 !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool PIKA Warp
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus
VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the PIKA for Computer
+ Telephony Developers link for more information.
+
#config LUAN
#bool Luan
#depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..c1733c0 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA)+= sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER)+= rainier.o
+obj-$(CONFIG_WARP) += warp.o
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-11 02:08:20.0 -0500
@@ -0,0 +1,244 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * 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.
+ */
+#include linux/init.h
+#include linux/of_platform.h
+#include linux/kthread.h
+
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/time.h
+#include asm/uic.h
+
+#include 44x.h
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
This should be in the device tree...
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if (gpio_base == NULL) {
+ gpio_base = ioremap(WARP_GPIO_BASE, 0x148);
... and you should get the resource for it from there instead of using
the #define.
+ if (gpio_base == NULL) {
+ printk(ERROR: Unable to remap GPIO base.\n);
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
Do you really want readl here? That will byte-swap.
+
+ switch(green) {
+ case 0: leds = ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds = ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
Same here.
+}
+EXPORT_SYMBOL(warp_set_power_leds);
Hm... does this really need to be exported?
+// SAM not yet #define NAND_FLASH
+#ifdef NAND_FLASH
+/* --- All of this code is for the NAND flash */
Perhaps you could split this out into warp-nand.c instead of ifdefing
it here. That way it can be left uncompiled until we figure out the
NAND situation in general.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
On Fri, 11 Jan 2008 01:15:48 -0500
Sean MacLennan [EMAIL PROTECTED] wrote:
David Gibson wrote:
Or possibly what you actually want is:
[EMAIL PROTECTED],0 {
reg = 2 0 2200;
...
};
That is what I want. I was missing a call to
ibm4xx_fixup_ebc_ranges(/plb/opb/ebc); (see updated patch3/5 to follow.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
This looks pretty darn good, minus the missing GPIO node (see comment
in patch 1).
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
Hello, Eugene, The h/w snooping mechanism you are talking about is limited to the Low Latency (LL) segment of the PLB bus in ppc440sp and ppc440spe chips (see section 7.2.7 L2 Cache Coherency of the ppc440spe spec), whereas DMA and XOR engines use the High Bandwidth (HB) segment of PLB bus (see section 1.1.2 Internal Buses of the ppc440spe spec). Thus, the h/w snooping mechanism is not able to trace the results of operations performed by DMA and XOR engines and keep L2-cache coherent with SDRAM, because the data flow through the HB PLB segment. This leads to, for example, incorrect results of RAID-parity calculations if one uses the h/w accelerated ppc440spe ADMA driver with L2-cache enabled. The s/w synchronization algorithms proposed in my patches has no LL PLB limitations as opposed to h/w snooping, but, probably, this is not the best way of how it might be implemented. Even though with these patches the h/w accelerated RAID starts to operate correctly (with L2-cache enabled) there is a performance degradation (induced by loops in the L2-cache synchronization routines) observed in the most cases. So, as a result, there is no benefit from using L2-cache for these, RAID, cases at all. Regards, Yuri On Wednesday 28 November 2007 22:50, Eugene Surovegin wrote: On Wed, Nov 07, 2007 at 01:40:10AM +0300, Yuri Tikhonov wrote: Hello all, Here is a patch-set for support L2-cache synchronization routines for the ppc44x processors family. I know that the ppc branch is for bug-fixing only, thus the patch-set is just FYI [though enabled but non-coherent L2-cache may appear as a bug for someone who uses one of the boards listed below :)]. [PATCH 1/2] [PPC 4xx] invalidate_l2cache_range() implementation for ppc44x; [PATCH 2/2] [PPC 44x] enable L2-cache for the following ppc44x-based boards: ALPR, Katmai, Ocotea, and Taishan. Why is this all needed? IIRC ibm440gx_l2c_enable() configures 64G snoop region for L2C. Did AMCC made non-only-coherent L2C chips recently? -- Eugene -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RFC: Only deal with apple fix if res is memory
Ben,
Will this impact the apple fix? I'm getting some _IO cases hitting this.
- k
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index d394d41..42a9dab 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -807,6 +807,7 @@ static void __devinit __pcibios_fixup_bus(struct pci_bus
*bus)
* their size is smaller than 1M.
*/
if (res-start == hose-pci_mem_offset
+ res-flags IORESOURCE_MEM
res-end 0x10) {
printk(KERN_INFO
PCI: Closing bogus Apple Firmware
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add fdt_set_name() function
So, like, the other day David Gibson mumbled: This patch adds an fdt_set_name() function to libfdt, mirroring fdt_get_name(). This is a r/w function which alters the name of a given device tree node. 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: PCI Failed to allocate mem for PCI ROM
On Fri, Jan 11, 2008 at 02:29:28AM -0600, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Nope, sorry, any help debugging this is appreciated, pci resource allocation is tricky :) thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
On Fri, Jan 11, 2008 at 06:24:46PM +0300, Yuri Tikhonov wrote: Hello, Eugene, The h/w snooping mechanism you are talking about is limited to the Low Latency (LL) segment of the PLB bus in ppc440sp and ppc440spe chips (see section 7.2.7 L2 Cache Coherency of the ppc440spe spec), whereas DMA and XOR engines use the High Bandwidth (HB) segment of PLB bus (see section 1.1.2 Internal Buses of the ppc440spe spec). Thus, the h/w snooping mechanism is not able to trace the results of operations performed by DMA and XOR engines and keep L2-cache coherent with SDRAM, because the data flow through the HB PLB segment. This leads to, for example, incorrect results of RAID-parity calculations if one uses the h/w accelerated ppc440spe ADMA driver with L2-cache enabled. The s/w synchronization algorithms proposed in my patches has no LL PLB limitations as opposed to h/w snooping, but, probably, this is not the best way of how it might be implemented. Even though with these patches the h/w accelerated RAID starts to operate correctly (with L2-cache enabled) there is a performance degradation (induced by loops in the L2-cache synchronization routines) observed in the most cases. So, as a result, there is no benefit from using L2-cache for these, RAID, cases at all. Thanks a lot for explanation, Yuri. I'd never imagine they were so stupid to make new chips with such behaviour. -- Eugene ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC PATCH] Remove const from dtc_file::dir.
So, like, the other day Scott Wood mumbled: Signed-off-by: Scott Wood [EMAIL PROTECTED] --- srcpos.c |4 ++-- srcpos.h |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Oh yeah. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote: Ok, needed a valid console= line on the command line. WHen we tried that, we had a typo, so it was not recognized. Our old 2.6.18 arch/ppc kernel didn't need a console parameter, it got the baudrate from u-boot somehow. Anyway of doing that here too? You could add something to the cuboot code to fill in current-speed based on the value in the bd_t. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 1/5] Implement module aliasing for i2c to translate from device tree names
Hi Jon,
On Wed, 19 Dec 2007 23:41:38 -0500, Jon Smirl wrote:
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Your patch adds compilation warnings on several i2c drivers:
drivers/hwmon/f75375s.c:135: warning: initialization from incompatible pointer
type
drivers/i2c/chips/ds1682.c:241: warning: initialization from incompatible
pointer type
drivers/i2c/chips/tps65010.c:590: warning: initialization from incompatible
pointer type
drivers/i2c/chips/tsl2550.c:461: warning: initialization from incompatible
pointer type
drivers/rtc/rtc-ds1307.c:538: warning: initialization from incompatible pointer
type
drivers/rtc/rtc-ds1374.c:430: warning: initialization from incompatible pointer
type
drivers/rtc/rtc-m41t80.c:897: warning: initialization from incompatible pointer
type
drivers/rtc/rtc-rs5c372.c:652: warning: initialization from incompatible
pointer type
And there may be more drivers affected that just happen to not build on
x86_64 so I did not spot them. Please check this and fix them all.
I see that 4 of these warnings are fixed in the next patch of this
series, but that's not sufficient: each patch must be correct by
itself, so that bisections can be performed safely.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/i2c/i2c-core.c | 32 ++--
include/linux/i2c.h |9 -
include/linux/mod_devicetable.h | 20
scripts/mod/file2alias.c| 19 +++
4 files changed, 69 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..fce06fd 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,10 +47,25 @@ static DEFINE_IDR(i2c_adapter_idr);
/* -
*/
-static int i2c_device_match(struct device *dev, struct device_driver *drv)
+static const struct i2c_device_id *i2c_device_match(const struct
i2c_device_id *id, struct i2c_client *client)
Line too long, please fold.
Following the pci and usb examples, this function would be named
i2c_match_id.
+{
+ /* only powerpc drivers implement the id_table,
+ * it is empty on other platforms */
+ if (id) {
+ while (id-name[0]) {
+ if (strcmp(client-driver_name, id-name) == 0)
This doesn't look right to me. You should be comparing client-name,
not client-driver_name, with id-name. Where id_table is implemented,
client-driver_name might not even be set. I see that the next patch in
the series makes use of client-driver_name as well, so your code
works... but this ain't correct still.
+ return id;
+ id++;
+ }
+ }
+ return NULL;
+}
+
+static int i2c_bus_match(struct device *dev, struct device_driver *drv)
And this function would be named i2c_device_match (i.e. don't change
the name.)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
+ const struct i2c_device_id *found_id;
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
@@ -58,9 +73,11 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
if (!is_newstyle_driver(driver))
return 0;
- /* new style drivers use the same kind of driver matching policy
- * as platform devices or SPI: compare device and driver IDs.
- */
This comment still applies to the last part of the function.
+ /* match on an id table if there is one */
+ found_id = i2c_device_match(driver-id_table, client);
+ if (found_id)
+ return 1;
If the driver has an id_table but the device doesn't match any entry,
you fallback to the string comparison below. Is this really what you
want? Why not return 0 right away instead? Again, client-driver_name
might not even be set.
+
return strcmp(client-driver_name, drv-name) == 0;
}
@@ -89,12 +106,15 @@ static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(dev-driver);
+ const struct i2c_device_id *id;
if (!driver-probe)
return -ENODEV;
client-driver = driver;
dev_dbg(dev, probe\n);
- return driver-probe(client);
+
+ id = i2c_device_match(driver-id_table, client);
+ return driver-probe(client, id);
}
static int i2c_device_remove(struct device *dev)
@@ -189,7 +209,7 @@ static struct device_attribute i2c_dev_attrs[] = {
static struct bus_type i2c_bus_type = {
.name =
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote: From: Scott Wood You could add something to the cuboot code to fill in current-speed based on the value in the bd_t. Ahh.. That was what I'm missing. Where in the devicetree is that supposed to be at? In the serial node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On Fri, 11 Jan 2008 10:52:56 -0500, Jon Smirl wrote: On 1/11/08, Jean Delvare wrote: Now that I have read all the previous versions of this patch series and, more importantly, all objections that were raised on the way, I can start reviewing the latest iteration of your patches. I'll also do some testing, although I have no powerpc stuff here, but at least I want to make sure that there are no regressions introduced by your patches on x86. Various people were worried about x86. Around version 15 I altered the patches so that they only impacted PowerPC. If they impact x86 in current form that is a bug. When x86 is ready for it I do think dynamic module loading should be implemented there also. I agree, and I am doing some testing on x86 to make sure that your patch will work fine there as well once we decide to go that way. Your patch set really contains two different parts which should be clearly identified and discussed separately. Firstly, it lets i2c drivers export module aliases so that the rest of the world knows which devices they support. This part I think everybody agrees is needed, so that platform code no longer needs to specify the driver name for every I2C device. Secondly, it promotes OF device names as acceptable aliases. This I don't think I agree with. While I see some value in moving the OF name - Linux name translation to the drivers themselves (even though I don't see this as a mandatory move either), this doesn't imply that OF names should be used as aliases. I don't like the idea that different architectures will name the same device differently in a visible way. This could easily break user-space code that makes assumptions on the device names (libsensors comes to mind.) So, I think that this part will need some more discussion. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[DTC PATCH] Remove const from dtc_file::dir.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
srcpos.c |4 ++--
srcpos.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/srcpos.c b/srcpos.c
index 7d0f0a7..c8eaa1e 100644
--- a/srcpos.c
+++ b/srcpos.c
@@ -104,7 +104,7 @@ struct dtc_file *dtc_open_file(const char *fname,
}
out:
- free((void *)file-dir);
+ free(file-dir);
free(file);
return NULL;
}
@@ -114,6 +114,6 @@ void dtc_close_file(struct dtc_file *file)
if (fclose(file-file))
die(Error closing \%s\: %s\n, file-name, strerror(errno));
- free((void *)file-dir);
+ free(file-dir);
free(file);
}
diff --git a/srcpos.h b/srcpos.h
index 8108539..3ed2334 100644
--- a/srcpos.h
+++ b/srcpos.h
@@ -25,7 +25,7 @@
#include stdio.h
struct dtc_file {
- const char *dir;
+ char *dir;
const char *name;
FILE *file;
};
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
On 1/11/08, Jean Delvare [EMAIL PROTECTED] wrote: Secondly, it promotes OF device names as acceptable aliases. This I don't think I agree with. While I see some value in moving the OF name - Linux name translation to the drivers themselves (even though I don't see this as a mandatory move either), this doesn't imply that OF names should be used as aliases. I don't like the idea that different architectures will name the same device differently in a visible way. This could easily break user-space code that makes assumptions on the device names (libsensors comes to mind.) So, I think that this part will need some more discussion. They're aliases. On the x86 my e1000 Ethernet driver loads using this alias name: pci:v8086d1010sv*sd*bc*sc*i* In fact, the e1000 driver has 63 alias names in addition to e1000 But it's still the e1000 driver after it is loaded. [EMAIL PROTECTED]:/home/linux/drivers/net/e1000$ lsmod | grep e1000 e1000 115968 0 Loading a I2C driver with an OF alias name is not going to change the module name after it is loaded. In fact, once the module is in memory there's no way to tell what name was used to load it. OF device names are set by the Open Firmware committee. It is not reasonable to force the Linux names back into Open Firmware since this would force the other operating systems using Open Firmware to adopt the Linux names. This issue hasn't been visible before since there was a global table in the PowerPC code mapping all known Open Firmware names into linux names. Keeping this as a global table doesn't scale. The mapping needs to be done by each device individually. -- Jean Delvare -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
The reg property in fsl soc nodes should be removed.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..7502e03 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -54,10 +54,18 @@ phys_addr_t get_immrbase(void)
soc = of_find_node_by_type(NULL, soc);
if (soc) {
int size;
- const void *prop = of_get_property(soc, reg, size);
+ u32 naddr;
+ const u32 *prop = of_get_property(soc, #address-cells, size);
+
+ if (prop size == 4)
+ naddr = *prop;
+ else
+ naddr = 2;
+
+ prop = of_get_property(soc, ranges, size);
+ if (prop)
+ immrbase = of_translate_address(soc, prop + naddr);
- if (prop)
- immrbase = of_translate_address(soc, prop);
of_node_put(soc);
}
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On Jan 11, 2008, at 11:50 AM, Greg KH wrote: On Fri, Jan 11, 2008 at 02:29:28AM -0600, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Nope, sorry, any help debugging this is appreciated, pci resource allocation is tricky :) I'm happy to debug, is the fact that the resno == 9 ok or does that seem wrong? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Stephen Rothwell wrote: I don't where that function is actually defined - I assume it is in one of the other recent patch sets. /me searches ... /me reads ad7414 driver email ... /me notes spaces missing there as well :-) I didn't write the ad7414 driver and wanted to change the original code as little as possible. Tricky. You have something that can only be built in (pika_dtm_thread in warp.c) calling something that might be a module ... I think you need to think of a new way of organizing these pieces. The DTM is a very small, but important part of the taco. Basically it controls the fan. I could have wrapped it in a CONFIG_AD7414, but I would rather have a compile time error and ship people the ad7414.c. That said, I could just slam a CONFIG_AD7414 around the DTM code. It would just mean that the fan would run at high speed all the time if you didn't have it. I really don't want to have to write a driver just to get one register from the temperature chip. And we want the DTM running ASAP on startup. I think forcing taco users to build in the i2c and ad7414 drivers is not a hardship. And we do ship a working kernel with the taco. And as a special bonus to readers of this thread, an exclusive, never before seen, picture of tigger, my development taco. I have to point out it is a development prototype and not the final product. ftp://ftp.seanm.ca/stuff/tigger.jpg or http://ftp.seanm.ca/stuff/tigger.jpg . Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
This board is also resold by Freescale under the names
QUICCStart MPC8248 Evaluation System and CWH-PPC-8248N-VE.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |3 +-
arch/powerpc/boot/dts/ep8248e.dts | 205
arch/powerpc/boot/ep8248e.c| 55 +++
arch/powerpc/boot/wrapper |2 +-
arch/powerpc/configs/ep8248e_defconfig | 821
arch/powerpc/platforms/82xx/Kconfig| 13 +
arch/powerpc/platforms/82xx/Makefile |1 +
arch/powerpc/platforms/82xx/ep8248e.c | 325 +
include/asm-powerpc/mpc8260.h |1 +
9 files changed, 1424 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/ep8248e.dts
create mode 100644 arch/powerpc/boot/ep8248e.c
create mode 100644 arch/powerpc/configs/ep8248e_defconfig
create mode 100644 arch/powerpc/platforms/82xx/ep8248e.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 08bf7aa..fcca455 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c
holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c redboot-8xx.c
+ cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -195,6 +195,7 @@ image-$(CONFIG_PPC_8xx) += cuImage.8xx
image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
image-$(CONFIG_EP405) += zImage.ep405
image-$(CONFIG_8260) += cuImage.pq2
+image-$(CONFIG_EP8248E)+= zImage.ep8248e
image-$(CONFIG_PPC_MPC52xx)+= cuImage.52xx
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
diff --git a/arch/powerpc/boot/dts/ep8248e.dts
b/arch/powerpc/boot/dts/ep8248e.dts
new file mode 100644
index 000..f5b058c
--- /dev/null
+++ b/arch/powerpc/boot/dts/ep8248e.dts
@@ -0,0 +1,205 @@
+/*
+ * Device Tree for the Embedded Planet EP8248E board running PlanetCore.
+ *
+ * Copyright 2007 Freescale Semiconductor 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.
+ */
+
+/dts-v1/;
+/ {
+ model = EP8248E;
+ compatible = fsl,ep8248e;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ planetcore-SMC1 = smc1;
+ planetcore-SCC1 = scc1;
+ enet0 = eth0;
+ enet1 = eth1;
+ serial0 = smc1;
+ serial1 = scc1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 16384;
+ i-cache-size = 16384;
+ timebase-frequency = 0;
+ clock-frequency = 0;
+ };
+ };
+
+ localbus {
+ compatible = fsl,mpc8248-localbus,
+fsl,pq2-localbus,
+simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xf0010100 0x40;
+
+ ranges = 0 0 0xfc00 0x0400
+ 1 0 0xfa00 0x8000;
+
+ [EMAIL PROTECTED],380 {
+ compatible = cfi-flash;
+ reg = 0 0x380 0x80;
+ bank-width = 4;
+ device-width = 2;
+ };
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 1 0 0x10;
+ compatible = fsl,ep8248e-bcsr;
+ ranges;
+
+ mdio {
+ device_type = mdio;
+ compatible = fsl,ep8248e-mdio-bitbang;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 1 8 1;
+
+ PHY0: [EMAIL PROTECTED] {
+ interrupt-parent = PIC;
+ reg = 0;
+
Re: [PATCH 3/5] Warp Base Platform
On Fri, 11 Jan 2008 01:17:51 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: Update based on fixes to warp.dts. Signed-off-by: Sean MacLennan [EMAIL PROTECTED] Looks good. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] nand base: Don't panic if a controller driver does ecc its own way.
Some hardware, such as the enhanced local bus controller used on some
mpc83xx chips, does ecc transparently when reading and writing data, rather
than providing a generic calculate/correct mechanism that can be exported to
the nand subsystem.
The subsystem should not BUG() when calculate, correct, or hwctl are
missing, if the methods that call them have been overridden.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
drivers/mtd/nand/nand_base.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index e29c1da..85a7283 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2469,8 +2469,12 @@ int nand_scan_tail(struct mtd_info *mtd)
chip-ecc.write_oob = nand_write_oob_std;
case NAND_ECC_HW_SYNDROME:
- if (!chip-ecc.calculate || !chip-ecc.correct ||
- !chip-ecc.hwctl) {
+ if ((!chip-ecc.calculate || !chip-ecc.correct ||
+!chip-ecc.hwctl)
+ (!chip-ecc.read_page ||
+chip-ecc.read_page == nand_read_page_hwecc) ||
+!chip-ecc.write_page ||
+chip-ecc.write_page == nand_write_page_hwecc) {
printk(KERN_WARNING No ECC functions supplied,
Hardware ECC not possible\n);
BUG();
--
1.5.3.8
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote: On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote: Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- Do we have the numbers ? Did they also measure latency ? I hoped this question would not come. ;) No, unfortunately I don't have any numbers. Just the recommendation from AMCC to always use 256 buffers. This cannot be true for all chips. Default numbers I selected weren't random. In particular, 256 for Tx doesn't make a lot of sense for 405. You just gonna waste memory. I'd be quite reluctant to follow such advices from AMCC without actual details. -- Eugene ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood You could add something to the cuboot code to fill in current-speed based on the value in the bd_t. Ahh.. That was what I'm missing. Where in the devicetree is that supposed to be at? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On Fri, Jan 11, 2008 at 10:13:23AM +0100, Jiri Slaby wrote: On 01/11/2008 10:07 AM, Kumar Gala wrote: On Jan 11, 2008, at 2:41 AM, Jiri Slaby wrote: On 01/11/2008 09:29 AM, Kumar Gala wrote: Greg, I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. It appears that pci_bus_assign_resources() is trying to call pci_assign_resource() for the ROM and the resource for the ROM is [10:1f] where the PHB is [c000:dfff]. It seems like the resno that pci_assign_resource is getting called with is wrong and thus pci_update_resource() doesn't get called. any ideas? Kernel version, please. Sorry, its 2.6.24-rc7 + some ppc patches queued for 2.6.25 Could you try this patch? http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob_plain;f=pci/pci-remove-default-pci-expansion-rom-memory-allocation.patch Greg: is this 2.6.25 material, please? We need this for SP2. Yes, this is queued up for 2.6.25, and I have no objection to adding it for SLE10 SP2 if needed. But I think there is another patch in the series that also goes with this, ask IBM, they know what is needed here. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] Update .gitignore for dtc.
Signed-off-by: Scott Wood [EMAIL PROTECTED] --- arch/powerpc/boot/.gitignore |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore index a424be6..c89cf13 100644 --- a/arch/powerpc/boot/.gitignore +++ b/arch/powerpc/boot/.gitignore @@ -36,3 +36,7 @@ zImage.vmode zconf.h zlib.h zutil.h +dtc +*.lex.c +*.tab.c +*.tab.h -- 1.5.3.8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Device Tree PCI
Hi.
We're trying to port 2.6.24-rc7 to a board.
Right now wr're battling with the device tree and PCI.
Our board is somewhat loosely based on a 8266ADS/pq2fads board
We have a PCI interrupt mux in a fpga.
We have a disk controller and a pci bridge on the primary side, and four
TI dsp's on the secondary side.
All the interrupts are hardwired to the int mux in our FPGA.
THe PCI code does not seem happy:
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
irq_create_mapping called for NULL host, hwirq=0
[ cut here ]
Badness at arch/powerpc/kernel/irq.c:661
NIP: c0006048 LR: c0006048 CTR:
REGS: ef821d40 TRAP: 0700 Not tainted (2.6.24-rc7-gdcbd768b-dirty)
MSR: 00029032 EE,ME,IR,DR CR: 24022022 XER:
TASK = ef812000[1] 'swapper' THREAD: ef82
GPR00: c0006048 ef821df0 ef812000 0034 0001 0001
c0306c30
GPR08: c02f 24022082 10019684 0ffce000
0040092c
GPR16: 0001 ef821f60 c02d c02d c02d 0071f3a0
0001
GPR24: c030e000 ef818100 0001 ef818114
NIP [c0006048] irq_create_mapping+0xa8/0x100
LR [c0006048] irq_create_mapping+0xa8/0x100
Call Trace:
[ef821df0] [c0006048] irq_create_mapping+0xa8/0x100 (unreliable)
[ef821e10] [c001225c] pci_read_irq_line+0x84/0xfc
[ef821e60] [c00117c8] pcibios_fixup_bus+0xe8/0x24c
[ef821e90] [c013b784] pci_scan_child_bus+0x78/0x118
[ef821eb0] [c013bb24] pci_scan_bridge+0x300/0x42c
[ef821ef0] [c013b7d4] pci_scan_child_bus+0xc8/0x118
[ef821f10] [c013beb4] pci_scan_bus_parented+0x20/0x3c
[ef821f20] [c02ba754] pcibios_init+0x68/0x250
[ef821f50] [c02b68ac] kernel_init+0x108/0x2e0
[ef821ff0] [c00100d8] kernel_thread+0x44/0x60
here is our device tree:
/*
* Device Tree for the ApMax board with an MPC8280 chip.
*
* Copyright 2007 Freescale Semiconductor Inc.
* Copyright 2008 Innovative Systems, LLC
*
* 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.
*/
/ {
model = pq2fads;
compatible = fsl,pq2fads;
#address-cells = 1;
#size-cells = 1;
cpus {
#address-cells = 1;
#size-cells = 0;
[EMAIL PROTECTED] {
device_type = cpu;
reg = 0;
d-cache-line-size = d#32;
i-cache-line-size = d#32;
d-cache-size = d#16384;
i-cache-size = d#16384;
timebase-frequency = 0;
clock-frequency = 0;
};
};
memory {
device_type = memory;
reg = 0 0;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8280-localbus,
fsl,pq2-localbus;//
Change to our own apmax-localbus
#address-cells = 2;
#size-cells = 1;
reg = f0010100 60;
// CS 0 BaseAddress length
look
ranges = 0 0 ff80 0080 // CPU1
8MB Flash
5 0 f810 8000 // FPGA
registers
6 0 f880 0020
// ARM FIFO in FPGA
8 0 f900 0080
// CPU2 8MB Flash
9 0 f840 0002;
// CPU1 128K SRAM
[EMAIL PROTECTED],0 {
compatible = jedec-flash;
reg = 0 0 80;
bank-width = 2;
device-width = 2;
};
PCI_INT: [EMAIL PROTECTED],10 {
#interrupt-cells = 1;
interrupt-controller;
reg = 5 10 4; //
Chip select, offset, length
compatible = apmax-pciintmux;
interrupt-parent = PIC;
interrupts = 19 8;//
IRQ7, interrupt#25
};
};
[EMAIL PROTECTED] {
device_type = pci;
reg = f0010800 10c f00101ac 8 f00101c4 8;
compatible = fsl,mpc8280-pci, fsl,pq2-pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
clock-frequency = d#49766400; // For our
board.
interrupt-map-mask = f800 0 0 7;// Anded
with the interrupt-map values
interrupt-map =
/* IDSEL 0x11 */
8800 0 0 1 PCI_INT 5;
Re: [i2c] [PATCH 0/5] Version 17, series to add device tree naming to i2c
Hi Jon, The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. Now that I have read all the previous versions of this patch series and, more importantly, all objections that were raised on the way, I can start reviewing the latest iteration of your patches. I'll also do some testing, although I have no powerpc stuff here, but at least I want to make sure that there are no regressions introduced by your patches on x86. Various people were worried about x86. Around version 15 I altered the patches so that they only impacted PowerPC. If they impact x86 in current form that is a bug. I can only second this. The latest version of i2c-cpm (http://patchwork.ozlabs.org/linuxppc/patch?person=1023id=15902) makes use of this patch, as well. On the dbox2, loading and unloading of modules in any order just works fine. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Fri, 2008-01-11 at 09:48 -0800, Eugene Surovegin wrote: On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote: On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote: Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- Do we have the numbers ? Did they also measure latency ? I hoped this question would not come. ;) No, unfortunately I don't have any numbers. Just the recommendation from AMCC to always use 256 buffers. This cannot be true for all chips. Default numbers I selected weren't random. In particular, 256 for Tx doesn't make a lot of sense for 405. You just gonna waste memory. I'd be quite reluctant to follow such advices from AMCC without actual details. I think we can make defaults based on other config options nowadays. Not very nice but we could do things like default 128 if PPC_40x default 256 Or even more detailed. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] mtd: Factor out OF partition support from the NOR driver.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
drivers/mtd/Kconfig|8
drivers/mtd/Makefile |1 +
drivers/mtd/maps/physmap_of.c | 89
drivers/mtd/ofpart.c | 70 +++
include/linux/mtd/partitions.h |9 -
5 files changed, 114 insertions(+), 63 deletions(-)
create mode 100644 drivers/mtd/ofpart.c
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 661eac0..e850334 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -150,6 +150,14 @@ config MTD_AFS_PARTS
for your particular device. It won't happen automatically. The
'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
+config MTD_OF_PARTS
+ tristate Flash partition map based on OF description
+ depends on PPC_OF MTD_PARTITIONS
+ help
+ This provides a partition parsing function which derives
+ the partition map from the children of the flash node,
+ as described in Documentation/powerpc/booting-without-of.txt.
+
comment User Modules And Translation Layers
config MTD_CHAR
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 7f0b04b..538e33d 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
+obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
# 'Users' - code which presents functionality to userspace.
obj-$(CONFIG_MTD_CHAR) += mtdchar.o
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index d4bcd3f..49acd41 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -80,65 +80,6 @@ static int parse_obsolete_partitions(struct of_device *dev,
return nr_parts;
}
-
-static int __devinit parse_partitions(struct of_flash *info,
- struct of_device *dev)
-{
- const char *partname;
- static const char *part_probe_types[]
- = { cmdlinepart, RedBoot, NULL };
- struct device_node *dp = dev-node, *pp;
- int nr_parts, i;
-
- /* First look for RedBoot table or partitions on the command
-* line, these take precedence over device tree information */
- nr_parts = parse_mtd_partitions(info-mtd, part_probe_types,
- info-parts, 0);
- if (nr_parts 0)
- return nr_parts;
-
- /* First count the subnodes */
- nr_parts = 0;
- for (pp = of_get_next_child(dp, NULL); pp;
-pp = of_get_next_child(dp, pp))
- nr_parts++;
-
- if (nr_parts == 0)
- return parse_obsolete_partitions(dev, info, dp);
-
- info-parts = kzalloc(nr_parts * sizeof(*info-parts),
- GFP_KERNEL);
- if (!info-parts)
- return -ENOMEM;
-
- for (pp = of_get_next_child(dp, NULL), i = 0; pp;
-pp = of_get_next_child(dp, pp), i++) {
- const u32 *reg;
- int len;
-
- reg = of_get_property(pp, reg, len);
- if (!reg || (len != 2*sizeof(u32))) {
- of_node_put(pp);
- dev_err(dev-dev, Invalid 'reg' on %s\n,
- dp-full_name);
- kfree(info-parts);
- info-parts = NULL;
- return -EINVAL;
- }
- info-parts[i].offset = reg[0];
- info-parts[i].size = reg[1];
-
- partname = of_get_property(pp, label, len);
- if (!partname)
- partname = of_get_property(pp, name, len);
- info-parts[i].name = (char *)partname;
-
- if (of_get_property(pp, read-only, len))
- info-parts[i].mask_flags = MTD_WRITEABLE;
- }
-
- return nr_parts;
-}
#else /* MTD_PARTITIONS */
#defineOF_FLASH_PARTS(info)(0)
#define parse_partitions(info, dev)(0)
@@ -213,6 +154,10 @@ static struct mtd_info * __devinit obsolete_probe(struct
of_device *dev,
static int __devinit of_flash_probe(struct of_device *dev,
const struct of_device_id *match)
{
+#ifdef CONFIG_MTD_PARTITIONS
+ static const char *part_probe_types[]
+ = { cmdlinepart, RedBoot, NULL };
+#endif
struct device_node *dp = dev-node;
struct resource res;
struct of_flash *info;
@@ -275,13 +220,33 @@ static int __devinit of_flash_probe(struct of_device *dev,
}
info-mtd-owner = THIS_MODULE;
- err = parse_partitions(info, dev);
+#ifdef CONFIG_MTD_PARTITIONS
+ /* First look for RedBoot table or partitions on the command
+* line, these take precedence over device
[PATCH 3/3] Freescale enhanced Local Bus Controller FCM NAND support.
Signed-off-by: Nick Spence [EMAIL PROTECTED]
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
drivers/mtd/nand/Kconfig |9 +
drivers/mtd/nand/Makefile|1 +
drivers/mtd/nand/fsl_elbc_nand.c | 1243 ++
3 files changed, 1253 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/fsl_elbc_nand.c
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 0a840d5..4a3c675 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -321,4 +321,13 @@ config MTD_NAND_ORION
No board specific support is done by this driver, each board
must advertise a platform_device for the driver to attach.
+config MTD_NAND_FSL_ELBC
+ tristate NAND support for Freescale eLBC controllers
+ depends on MTD_NAND PPC_OF
+ help
+ Various Freescale chips, including the 8313, include a NAND Flash
+ Controller Module with built-in hardware ECC capabilities.
+ Enabling this option will enable you to use this to control
+ external NAND devices.
+
endif # MTD_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index e35f5ea..80d575e 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -31,5 +31,6 @@ obj-$(CONFIG_MTD_NAND_PLATFORM) += plat_nand.o
obj-$(CONFIG_MTD_ALAUDA) += alauda.o
obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
obj-$(CONFIG_MTD_NAND_ORION) += orion_nand.o
+obj-$(CONFIG_MTD_NAND_FSL_ELBC)+= fsl_elbc_nand.o
nand-objs := nand_base.o nand_bbt.o
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
new file mode 100644
index 000..2a05bf9
--- /dev/null
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -0,0 +1,1243 @@
+/* Freescale Enhanced Local Bus Controller NAND driver
+ *
+ * Copyright (c) 2006-2007 Freescale Semiconductor
+ *
+ * Authors: Nick Spence [EMAIL PROTECTED],
+ * Scott Wood [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/string.h
+#include linux/ioport.h
+#include linux/of_platform.h
+#include linux/slab.h
+#include linux/interrupt.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/nand_ecc.h
+#include linux/mtd/partitions.h
+
+#include asm/io.h
+
+
+#define MAX_BANKS 8
+#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */
+#define FCM_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait for FCM */
+
+struct elbc_bank {
+ __be32 br; /** Base Register */
+#define BR_BA 0x8000
+#define BR_BA_SHIFT 15
+#define BR_PS 0x1800
+#define BR_PS_SHIFT 11
+#define BR_PS_8 0x0800 /* Port Size 8 bit */
+#define BR_PS_160x1000 /* Port Size 16 bit */
+#define BR_PS_320x1800 /* Port Size 32 bit */
+#define BR_DECC 0x0600
+#define BR_DECC_SHIFT9
+#define BR_DECC_OFF 0x /* HW ECC checking and generation off */
+#define BR_DECC_CHK 0x0200 /* HW ECC checking on, generation off */
+#define BR_DECC_CHK_GEN 0x0400 /* HW ECC checking and generation on */
+#define BR_WP 0x0100
+#define BR_WP_SHIFT 8
+#define BR_MSEL 0x00E0
+#define BR_MSEL_SHIFT5
+#define BR_MS_GPCM 0x /* GPCM */
+#define BR_MS_FCM 0x0020 /* FCM */
+#define BR_MS_SDRAM 0x0060 /* SDRAM */
+#define BR_MS_UPMA 0x0080 /* UPMA */
+#define BR_MS_UPMB 0x00A0 /* UPMB */
+#define BR_MS_UPMC 0x00C0 /* UPMC */
+#define BR_V0x0001
+#define BR_V_SHIFT 0
+#define BR_RES ~(BR_BA|BR_PS|BR_DECC|BR_WP|BR_MSEL|BR_V)
+
+ __be32 or; /** Base Register */
+#define OR0 0x5004
+#define OR1 0x500C
+#define OR2 0x5014
+#define OR3 0x501C
+#define OR4 0x5024
+#define OR5 0x502C
+#define OR6 0x5034
+#define OR7 0x503C
+
+#define OR_FCM_AM 0x8000
+#define OR_FCM_AM_SHIFT 15
+#define OR_FCM_BCTLD0x1000
+#define OR_FCM_BCTLD_SHIFT 12
+#define OR_FCM_PGS
Re: [PATCH 2/5] Warp Base Platform - dts
Josh Boyer wrote:
On Fri, 11 Jan 2008 01:15:48 -0500
Sean MacLennan [EMAIL PROTECTED] wrote:
This looks pretty darn good, minus the missing GPIO node (see comment
in patch 1).
Thanks. I have added the gpio and tested it.
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/dts/warp.dts 2008-01-11 15:58:03.0 -0500
@@ -0,0 +1,234 @@
+/*
+ * Device Tree Source for PIKA Warp
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = pika,warp;
+ compatible = pika,warp;
+ dcr-parent = /cpus/[EMAIL PROTECTED];
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,440EP;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by zImage */
+ timebase-frequency = 0; /* Filled in by zImage */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 8000;
+ d-cache-size = 8000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440ep;
+ dcr-reg = 00e 002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440ep;
+ dcr-reg = 00c 002;
+ };
+
+ plb {
+ compatible = ibm,plb-440ep, ibm,plb-440gp, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-440ep, ibm,sdram-405gp;
+ dcr-reg = 010 2;
+ };
+
+ DMA0: dma {
+ compatible = ibm,dma-440ep, ibm,dma-440gp;
+ dcr-reg = 100 027;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-440ep, ibm,mcmal-440gp,
ibm,mcmal;
+ dcr-reg = 180 62;
+ num-tx-chans = 4;
+ num-rx-chans = 2;
+ interrupt-parent = MAL0;
+ interrupts = 0 1 2 3 4;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = /*TXEOB*/ 0 UIC0 a 4
+ /*RXEOB*/ 1 UIC0 b 4
+ /*SERR*/ 2 UIC1 0 4
+ /*TXDE*/ 3 UIC1 1 4
+ /*RXDE*/ 4 UIC1 2 4;
+ };
+
+ POB0: opb {
+ compatible = ibm,opb-440ep, ibm,opb-440gp,
ibm,opb;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 8000
+ 8000 0 8000 8000;
+ interrupt-parent = UIC1;
+ interrupts = 7 4;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = ibm,ebc-440ep, ibm,ebc-440gp,
ibm,ebc;
+ dcr-reg = 012 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ clock-frequency = 0; /* Filled in by zImage */
+
Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
The s/w synchronization algorithms proposed in my patches has no LL PLB limitations as opposed to h/w snooping, but, probably, this is not the best way of how it might be implemented. Even though with these patches the h/w accelerated RAID starts to operate correctly (with L2-cache enabled) there is a performance degradation (induced by loops in the L2-cache synchronization routines) observed in the most cases. So, as a result, there is no benefit from using L2-cache for these, RAID, cases at all. Thanks a lot for explanation, Yuri. I'd never imagine they were so stupid to make new chips with such behaviour. Indeed. Now the question is do we want to make that configurable by the platform so it can select whether to enable snooping, or use this mechanism (in which case we can disable snooping on the L2) ? Another option would be to make the dma_ops smart enough to know whether a given device is on the snooped portion of the bus, which would be easier to do after I merge 32 and 64 bits DMA ops, so we get the ability to change the dma-ops per bus or per device even. What do you guys think ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
On Sat, Jan 12, 2008 at 09:05:35AM +1100, Benjamin Herrenschmidt wrote: The s/w synchronization algorithms proposed in my patches has no LL PLB limitations as opposed to h/w snooping, but, probably, this is not the best way of how it might be implemented. Even though with these patches the h/w accelerated RAID starts to operate correctly (with L2-cache enabled) there is a performance degradation (induced by loops in the L2-cache synchronization routines) observed in the most cases. So, as a result, there is no benefit from using L2-cache for these, RAID, cases at all. Thanks a lot for explanation, Yuri. I'd never imagine they were so stupid to make new chips with such behaviour. Indeed. Now the question is do we want to make that configurable by the platform so it can select whether to enable snooping, or use this mechanism (in which case we can disable snooping on the L2) ? I don't think we should panish platforms with sane L2 caches, because there are some brain-dead ones. Another option would be to make the dma_ops smart enough to know whether a given device is on the snooped portion of the bus, which would be easier to do after I merge 32 and 64 bits DMA ops, so we get the ability to change the dma-ops per bus or per device even. What do you guys think ? I like the idea of having smart DMA routines with different per-bus/device behaviour. -- Eugene ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Josh Boyer wrote:
+if (gpio_base == NULL) {
+printk(ERROR: Unable to remap GPIO base.\n);
+return;
+}
+}
+
+leds = readl(gpio_base + 0x100);
Do you really want readl here? That will byte-swap.
According to the docs I got from the hardware guys, this is correct.
That does *not* mean they didn't get it wrong. Unfortunately, it was
just on a piece of paper and I don't know if I still have it.
+}
+EXPORT_SYMBOL(warp_set_power_leds);
Hm... does this really need to be exported?
There is lots of talk about using the power leds to mean signal all
sorts of things. But I basically wrote this routine to use for
debugging. I exported it so my little standalone test modules could use
it. Currently, this function is never used which is why I put the gpio
mapping in the function. If it is not used, the gpios are never mapped.
+// SAM not yet #define NAND_FLASH
+#ifdef NAND_FLASH
+/* --- All of this code is for the NAND flash */
Perhaps you could split this out into warp-nand.c instead of ifdefing
it here. That way it can be left uncompiled until we figure out the
NAND situation in general.
Done. See the new warp-nand.c file and the commented out line in the
Makefile.
I also make the DTM conditional on ad7414.
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool PCI support if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x !CPM2 !8xx !PPC_83xx \
!PPC_85xx !PPC_86xx
default PCI_PERMEDIA if !4xx !CPM2 !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool PIKA Warp
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus
VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the PIKA for Computer
+ Telephony Developers link for more information.
+
#config LUAN
# bool Luan
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..7aaee9d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
+#obj-$(CONFIG_WARP)+= warp-nand.o
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp-nand.c 2008-01-11 18:04:10.0
-0500
@@ -0,0 +1,85 @@
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/map.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mtd/ndfc.h
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = nand,
+ .offset = 0,
+ .size = MTDPART_SIZ_FULL,
+ }
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x8000,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = ndfc-nand,
+ .id = 0,
+ .dev = {
+ .platform_data = warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset =
Re: RFC: Only deal with apple fix if res is memory
On Fri, 2008-01-11 at 10:38 -0600, Kumar Gala wrote:
Ben,
Will this impact the apple fix? I'm getting some _IO cases hitting this.
No, your fix is right, it's a bug to compare against pci_mem_offset and
not check if it's a memory resource in the first place. I would suggest
that you do the res-flags test first in the if () statement for clarity
though.
Cheers,
Ben.
- k
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index d394d41..42a9dab 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -807,6 +807,7 @@ static void __devinit __pcibios_fixup_bus(struct pci_bus
*bus)
* their size is smaller than 1M.
*/
if (res-start == hose-pci_mem_offset
+ res-flags IORESOURCE_MEM
res-end 0x10) {
printk(KERN_INFO
PCI: Closing bogus Apple Firmware
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
StorCenter Help?
Folks, Anyone out there with an 8241 board such as the IoMega StorCenter who would be willing to help me debug my arch/powerpc cuImage problems? I feel like I am missing something very basic in my port... like, Did you map this memory right? or Did you set _this_ magic bit? I have posted the 3 patches that provide the basic port and cuImage support as well. The U-Boot that I have is still legacy, so I'd like to get linux working first via the cuImage, and then work on U-Boot. The problem is that as soon as U-Boot uncompresses the cuImage and loads it, I get no further console output. The failing log follows. And I don't have a BDI-2000 or JTAG thing I can use here. Which is sort of why I'm tossing this out for general help. Thanks, jdl CPU: MPC8241 Revision 1.4 at 199.999 MHz: 16 kB I-Cache 16 kB D-Cache Board: StorCenter PICR1 is now 00141b98 PICR2 is now 00040605 AMBOR is now c1 DRAM: 64 MB FLASH: 8 MB In:serial Out: serial Err: serial Net: PCI device RTL8169#0: unknown chip version, assuming RTL-8169 PCI device: TxConfig = 0x0 RTL8169#0 Hit any key to stop autoboot: 0 IOMEGA= IOMEGA= IOMEGA= IOMEGA= IOMEGA= setenv serverip 192.168.0.10 IOMEGA= setenv ipaddr 192.168.0.25 IOMEGA= tftp 10 cuImage.824x TFTP from server 192.168.0.10; our IP address is 192.168.0.25 Filename 'cuImage.824x'. Load address: 0x10 Loading: # # # # ## done Bytes transferred = 1337749 (146995 hex) IOMEGA= bootm 10 ## Booting image at 0010 ... Image Name: Linux-2.6.24-rc6-g550234b0-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1337685 Bytes = 1.3 MB Load Address: 0040 Entry Point: 00400544 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Loading kernel .. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: StorCenter Help?
On 1/11/08, Jon Loeliger [EMAIL PROTECTED] wrote: Folks, Anyone out there with an 8241 board such as the IoMega StorCenter who would be willing to help me debug my arch/powerpc cuImage problems? I feel like I am missing something very basic in my port... like, Did you map this memory right? or Did you set _this_ magic bit? I have posted the 3 patches that provide the basic port and cuImage support as well. The U-Boot that I have is still legacy, so I'd like to get linux working first via the cuImage, and then work on U-Boot. The problem is that as soon as U-Boot uncompresses the cuImage and loads it, I get no further console output. The failing log follows. And I don't have a BDI-2000 or JTAG thing I can use here. Which is sort of why I'm tossing this out for general help. Since you're getting absolutely no output after uncompression it probably means that you're failing in the boot wrapper... which means mmu is off, and the serial port is already set up by u-boot. You should be able to add direct writes to the uart fifo register from within the bootwrapper code to see how far you get in the progress. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Quick Engine Support on Kernel 2.4
Hi All, Is there any BSP on Linux Kernel 2.4 support Quick Engine of MPC8568? If not, which BSP shall I start the porting? The BSP(on Kernel2.6) of MPC8568MDS from Freescale supports CPM2, but not QE. What the difference between CPM2 and QE? Thanks, ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: StorCenter Help?
On 1/11/08, Jon Loeliger [EMAIL PROTECTED] wrote: So, like, the other day Grant Likely mumbled: Since you're getting absolutely no output after uncompression it probably means that you're failing in the boot wrapper... Or not getting to the boot wrapper... Hmm, yet it boots a regular uImage? which means mmu is off, and the serial port is already set up by u-boot. You should be able to add direct writes to the uart fifo register from within the bootwrapper code to see how far you get in the progress. Tried that. Didn't work at all. I think I have some variant of BAT setup failure or so. weird... Can you get *any* custom code to run *at all*? Even if it's just a loop that writes a char to the serial port? jdl -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get two more bug fixes for powerpc, as listed below. Thanks, Paul. arch/powerpc/kernel/prom_init.c | 39 ++ arch/powerpc/mm/slb.c|8 + arch/powerpc/platforms/pseries/hotplug-cpu.c |2 + arch/powerpc/platforms/pseries/lpar.c|1 + include/asm-powerpc/mmu-hash64.h |1 + 5 files changed, 51 insertions(+), 0 deletions(-) commit 473980a99316c0e788bca50996375a2815124ce1 Author: Michael Neuling [EMAIL PROTECTED] Date: Fri Jan 11 14:02:47 2008 +1100 [POWERPC] Fix CPU hotplug when using the SLB shadow buffer Before we register the SLB shadow buffer, we need to invalidate the entries in the buffer, otherwise we can end up stale entries from when we previously offlined the CPU. This does this invalidate as well as unregistering the buffer with PHYP before we offline the cpu. Tested and fixes crashes seen on 970MP (thanks to tonyb) and POWER5. Signed-off-by: Michael Neuling [EMAIL PROTECTED] Signed-off-by: Paul Mackerras [EMAIL PROTECTED] commit 6f4347c969674ed45de7d08d4b26d6326a95b959 Author: Olaf Hering [EMAIL PROTECTED] Date: Thu Jan 10 01:06:08 2008 +1100 [POWERPC] efika: add phy-handle property for fec_mpc52xx The new network driver fec_mpc52xx will not work on efika because the firmware does not provide all required properties. http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to create more properties. But only the phy stuff is required to get a working network. This should go into the kernel because its appearently impossible to boot the script via tftp and then load the real boot binary (yaboot or zimage). Signed-off-by: Olaf Hering [EMAIL PROTECTED] Signed-off-by: Grant Likely [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
On Fri, 2008-01-11 at 14:38 -0800, Eugene Surovegin wrote: On Sat, Jan 12, 2008 at 09:05:35AM +1100, Benjamin Herrenschmidt wrote: The s/w synchronization algorithms proposed in my patches has no LL PLB limitations as opposed to h/w snooping, but, probably, this is not the best way of how it might be implemented. Even though with these patches the h/w accelerated RAID starts to operate correctly (with L2-cache enabled) there is a performance degradation (induced by loops in the L2-cache synchronization routines) observed in the most cases. So, as a result, there is no benefit from using L2-cache for these, RAID, cases at all. Thanks a lot for explanation, Yuri. I'd never imagine they were so stupid to make new chips with such behaviour. Indeed. Now the question is do we want to make that configurable by the platform so it can select whether to enable snooping, or use this mechanism (in which case we can disable snooping on the L2) ? I don't think we should panish platforms with sane L2 caches, because there are some brain-dead ones. I agree, which is why I'm thinking about making it some kind of explicit thing that a give platform would call from it's setup_arch() callbacks to turn on manual L2 sycnhronization. Another option would be to make the dma_ops smart enough to know whether a given device is on the snooped portion of the bus, which would be easier to do after I merge 32 and 64 bits DMA ops, so we get the ability to change the dma-ops per bus or per device even. What do you guys think ? I like the idea of having smart DMA routines with different per-bus/device behaviour. That would be longer term. When I merge the dma ops, I'll look into a way to provide 44x specific DMA ops that handle that case, and then a way for devices to be tagged (maybe via the device-tree) on whether they are on an L2 coherent or non-L2 coherent segment of the bus. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Hi Sean, On Fri, 11 Jan 2008 18:39:15 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: +++ arch/powerpc/platforms/44x/warp-nand.c2008-01-11 18:04:10.0 -0500 @@ -0,0 +1,85 @@ You need a copyright/license notice. The only other concern I have left is the extern in the C file, but that can be dealt with later. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpA2gsQG0Vh2.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 19 2/5] Modify several rtc drivers to use the alias names list property of i2c
This patch modifies the ds1307, ds1374, and rs5c372 i2c drivers to support
device tree names using the new i2c mod alias support
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 44 -
drivers/rtc/rtc-ds1307.c | 18 +
drivers/rtc/rtc-ds1374.c |7 +
drivers/rtc/rtc-m41t80.c | 55 -
drivers/rtc/rtc-rs5c372.c | 14 ++
5 files changed, 81 insertions(+), 57 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..94e5c73 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,48 +320,12 @@ 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,},
- {dallas,ds1307, rtc-ds1307, ds1307,},
- {dallas,ds1337, rtc-ds1307, ds1337,},
- {dallas,ds1338, rtc-ds1307, ds1338,},
- {dallas,ds1339, rtc-ds1307, ds1339,},
- {dallas,ds1340, rtc-ds1307, ds1340,},
- {stm,m41t00, rtc-ds1307, m41t00},
- {dallas,ds1374, rtc-ds1374, rtc-ds1374,},
-};
-
-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;
- if (strlcpy(info-driver_name, i2c_devices[i].i2c_driver,
- KOBJ_NAME_LEN) = KOBJ_NAME_LEN ||
- strlcpy(info-type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) = I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
static void __init of_register_i2c_devices(struct device_node *adap_node,
int bus_num)
{
struct device_node *node = NULL;
+ const char *compatible;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info = {};
@@ -378,8 +342,12 @@ static void __init of_register_i2c_devices(struct
device_node *adap_node,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, info) 0)
+ compatible = of_get_property(node, compatible, len);
+ if (!compatible) {
+ printk(KERN_WARNING i2c-mpc.c: invalid entry, missing
compatible attribute\n);
continue;
+ }
+ strncpy(info.type, compatible, sizeof(info.type));
info.addr = *addr;
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 9b0eab9..d4874ff 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -139,6 +139,17 @@ static inline const struct chip_desc *find_chip(const char
*s)
return NULL;
}
+static struct i2c_device_id ds1307_id[] = {
+ OF_I2C_ID(dallas,ds1307, ds_1307)
+ OF_I2C_ID(dallas,ds1337, ds_1337)
+ OF_I2C_ID(dallas,ds1338, ds_1338)
+ OF_I2C_ID(dallas,ds1339, ds_1339)
+ OF_I2C_ID(dallas,ds1340, ds_1340)
+ OF_I2C_ID(stm,m41t00, m41t00)
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ds1307_id);
+
static int ds1307_get_time(struct device *dev, struct rtc_time *t)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
@@ -334,7 +345,11 @@ static int __devinit ds1307_probe(struct i2c_client
*client, const struct i2c_de
const struct chip_desc *chip;
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
- chip = find_chip(client-name);
+ if (id)
+ chip = chips[id-driver_data];
+ else
+ chip = find_chip(client-name);
+
if (!chip) {
dev_err(client-dev, unknown chip type '%s'\n,
client-name);
@@ -537,6 +552,7 @@ static struct i2c_driver ds1307_driver = {
},
.probe = ds1307_probe,
.remove = __devexit_p(ds1307_remove),
+ .id_table = ds1307_id,
};
static int __init ds1307_init(void)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index dab6008..6dc05c4 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -41,6 +41,12 @@
#define DS1374_REG_SR_AF 0x01 /* Alarm Flag */
#define DS1374_REG_TCR 0x09 /* Trickle Charge */
+static struct i2c_device_id ds1374_id[] = {
+
[PATCH 19 3/5] Clean up error returns
Return errors that were being ignored in the mpc-i2c driver
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-mpc.c | 30 +-
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..7c35a8f 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -180,7 +180,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 +192,17 @@ 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;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result 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;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result 0)
+ return result;
}
return 0;
@@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c-adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target 1) | 1, i2c-base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i length; i++) {
- if (i2c_wait(i2c, timeout, 0) 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 0);
+ if (result 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -321,9 +325,9 @@ static int fsl_i2c_probe(struct platform_device *pdev)
pdata = (struct fsl_i2c_platform_data *) pdev-dev.platform_data;
- if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
+ i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
return -ENOMEM;
- }
i2c-irq = platform_get_irq(pdev, 0);
if (i2c-irq 0) {
@@ -381,7 +385,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(i2c-adap);
platform_set_drvdata(pdev, NULL);
- if (i2c-irq != 0)
+ if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
iounmap(i2c-base);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 19 4/5] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
Convert MPC i2c driver from being a platform_driver to an open firmware
version. Error returns were improved. Routine names were changed from fsl_ to
mpc_ to make them match the file name.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 96 --
drivers/i2c/busses/i2c-mpc.c | 183 -
2 files changed, 180 insertions(+), 99 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 94e5c73..d6ef264 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -318,102 +318,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include linux/i2c.h
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
- const char *compatible;
-
- 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_soc.c: invalid i2c device
entry\n);
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- compatible = of_get_property(node, compatible, len);
- if (!compatible) {
- printk(KERN_WARNING i2c-mpc.c: invalid entry, missing
compatible attribute\n);
- continue;
- }
- strncpy(info.type, compatible, sizeof(info.type));
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *i2c_dev;
- int ret;
-
- for (np = NULL, i = 0;
-(np = of_find_compatible_node(np, i2c, fsl-i2c)) != NULL;
-i++) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(r, 0, sizeof(r));
- memset(i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, r[1]);
-
- i2c_dev = platform_device_register_simple(fsl-i2c, i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, dfsrr, NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, fsl5200-clocking, NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, i2c_data,
-sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
-
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
{
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7c35a8f..91fa73c 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 linux/of_platform.h
#include asm/io.h
#include linux/fsl_devices.h
@@ -25,13 +25,13 @@
#include linux/interrupt.h
#include linux/delay.h
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME mpc-i2c
+
#define MPC_I2C_FDR0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -316,6 +316,181 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
+struct i2c_driver_device {
+ char*of_device;
+ char*i2c_driver;
+ char*i2c_type;
+};
+
+#ifdef CONFIG_PPC_MERGE
+
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct
[PATCH 19 1/5] Implement module aliasing for i2c to translate from device tree names
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/hwmon/f75375s.c |4 ++--
drivers/i2c/chips/ds1682.c |2 +-
drivers/i2c/chips/menelaus.c|2 +-
drivers/i2c/chips/tps65010.c|2 +-
drivers/i2c/chips/tsl2550.c |2 +-
drivers/i2c/i2c-core.c | 24 +++-
drivers/rtc/rtc-ds1307.c|2 +-
drivers/rtc/rtc-ds1374.c|2 +-
drivers/rtc/rtc-m41t80.c|2 +-
drivers/rtc/rtc-rs5c372.c |2 +-
include/linux/i2c.h |5 ++---
include/linux/mod_devicetable.h | 19 +++
scripts/mod/file2alias.c| 14 ++
13 files changed, 68 insertions(+), 14 deletions(-)
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 6892f76..2247de6 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -117,7 +117,7 @@ struct f75375_data {
static int f75375_attach_adapter(struct i2c_adapter *adapter);
static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
static int f75375_detach_client(struct i2c_client *client);
-static int f75375_probe(struct i2c_client *client);
+static int f75375_probe(struct i2c_client *client, const struct i2c_device_id
*id);
static int f75375_remove(struct i2c_client *client);
static struct i2c_driver f75375_legacy_driver = {
@@ -628,7 +628,7 @@ static void f75375_init(struct i2c_client *client, struct
f75375_data *data,
}
-static int f75375_probe(struct i2c_client *client)
+static int f75375_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct f75375_data *data = i2c_get_clientdata(client);
struct f75375s_platform_data *f75375s_pdata = client-dev.platform_data;
diff --git a/drivers/i2c/chips/ds1682.c b/drivers/i2c/chips/ds1682.c
index 9e94542..93c0441 100644
--- a/drivers/i2c/chips/ds1682.c
+++ b/drivers/i2c/chips/ds1682.c
@@ -200,7 +200,7 @@ static struct bin_attribute ds1682_eeprom_attr = {
/*
* Called when a ds1682 device is matched with this driver
*/
-static int ds1682_probe(struct i2c_client *client)
+static int ds1682_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
int rc;
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 2dea012..89ef9b6 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -1149,7 +1149,7 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
static struct i2c_driver menelaus_i2c_driver;
-static int menelaus_probe(struct i2c_client *client)
+static int menelaus_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct menelaus_chip*menelaus;
int rev = 0, val;
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e320994..6b13642 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -465,7 +465,7 @@ static int __exit tps65010_remove(struct i2c_client *client)
return 0;
}
-static int tps65010_probe(struct i2c_client *client)
+static int tps65010_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct tps65010 *tps;
int status;
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
index 3de4b19..27c553d 100644
--- a/drivers/i2c/chips/tsl2550.c
+++ b/drivers/i2c/chips/tsl2550.c
@@ -364,7 +364,7 @@ static int tsl2550_init_client(struct i2c_client *client)
*/
static struct i2c_driver tsl2550_driver;
-static int __devinit tsl2550_probe(struct i2c_client *client)
+static int __devinit tsl2550_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
struct tsl2550_data *data;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..5f62230 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,6 +47,19 @@ static DEFINE_IDR(i2c_adapter_idr);
/* - */
+static const struct i2c_device_id *i2c_match_id(
+ const struct i2c_device_id *id, struct i2c_client *client)
+{
+ /* only powerpc drivers implement the id_table,
+* it is empty on other platforms */
+ while (id-name[0]) {
+ if (strcmp(client-name, id-name) == 0)
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -58,6 +71,10 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
if
[PATCH 19 0/5] Version 18, series to add device tree naming to i2c
Updated to reflect comments in: http://lkml.org/lkml/2008/1/11/272 Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed. Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading. http://lkml.org/lkml/2007/12/17/493 The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 19 5/5] Convert pfc8563 i2c driver from old style to new style
Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/rtc/rtc-pcf8563.c | 107 +++--
1 files changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0242d80..e1ea2a0 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST10x00 /* status */
#define PCF8563_REG_ST20x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,52 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ OF_I2C_ID(philips,pcf8563, 0)
+ OF_I2C_ID(epson,rtc8564, 0)
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = pcf8563,
+ .name = rtc-pcf8563,
},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = pcf8563_attach,
- .detach_client = pcf8563_detach,
+ .probe = pcf8563_probe,
+ .remove = pcf8563_remove,
+ .id_table = pcf8563_id,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
- int err = 0;
-
- dev_dbg(adapter-dev, %s\n, __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = pcf8563-client;
- client-addr = address;
- client-driver = pcf8563_driver;
- client-adapter = adapter;
-
- strlcpy(client-name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind 0) {
- if (pcf8563_validate_client(client) 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(client-dev, chip found, driver version DRV_VERSION \n);
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
rtc = rtc_device_register(pcf8563_driver.driver.name, client-dev,
pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device Tree PCI
On Fri, Jan 11, 2008 at 12:17:41PM -0600, Rune Torgersen wrote:
PCI_INT: [EMAIL PROTECTED],10 {
#interrupt-cells = 1;
interrupt-controller;
reg = 5 10 4; //
Chip select, offset, length
compatible = apmax-pciintmux;
interrupt-parent = PIC;
interrupts = 19 8;//
IRQ7, interrupt#25
};
Is this interrupt controller getting registered before the PCI bus gets
probed?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
On Sat, Jan 12, 2008 at 01:40:05PM +1100, Stephen Rothwell wrote: Hi Sean, On Fri, 11 Jan 2008 18:39:15 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: +++ arch/powerpc/platforms/44x/warp-nand.c 2008-01-11 18:04:10.0 -0500 @@ -0,0 +1,85 @@ You need a copyright/license notice. Maybe your employer requires you to attach one with the files you create, but it's not a requirement to get code accepted into the kernel. The implied project-wide license is GPL. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Stephen Rothwell wrote: Hi Sean, On Fri, 11 Jan 2008 18:39:15 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: +++ arch/powerpc/platforms/44x/warp-nand.c 2008-01-11 18:04:10.0 -0500 @@ -0,0 +1,85 @@ You need a copyright/license notice. The only other concern I have left is the extern in the C file, but that can be dealt with later. Oops, meant to reply to everybody. Thanks for the copyright catch. Do I need the GPL blurb, or is just a copyright ok? I notice Linux does not seem to put the GPL blurb. For example sched.c. And I also don't like the extern, but I don't see a good solution right now. And while I have everybody's attention... The FPGA contains a simple watchdog timer. Would it be ok to put that in the platform/44x/warp.c file? It is a bit too specific to the taco to ever be accepted in the drivers/watchdog. Or I could do a warp-watchdog.c . Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Olof Johansson wrote: On Sat, Jan 12, 2008 at 01:40:05PM +1100, Stephen Rothwell wrote: Hi Sean, On Fri, 11 Jan 2008 18:39:15 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: +++ arch/powerpc/platforms/44x/warp-nand.c 2008-01-11 18:04:10.0 -0500 @@ -0,0 +1,85 @@ You need a copyright/license notice. Maybe your employer requires you to attach one with the files you create, but it's not a requirement to get code accepted into the kernel. The implied project-wide license is GPL. -Olof I guess this implies I don't need the GPL blurb. I noticed that the blurb I have used mentions GPL2 or later and I know Linus doesn't like GPL3. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool PCI support if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x !CPM2 !8xx !PPC_83xx \
!PPC_85xx !PPC_86xx
default PCI_PERMEDIA if !4xx !CPM2 !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool PIKA Warp
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus
VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the PIKA for Computer
+ Telephony Developers link for more information.
+
#config LUAN
# bool Luan
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..7aaee9d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
+#obj-$(CONFIG_WARP)+= warp-nand.o
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp-nand.c 2008-01-11 21:56:02.0
-0500
@@ -0,0 +1,92 @@
+/*
+ * PIKA Warp(tm) NAND flash specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ */
+
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/map.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mtd/ndfc.h
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = nand,
+ .offset = 0,
+ .size = MTDPART_SIZ_FULL,
+ }
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x8000,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = ndfc-nand,
+ .id = 0,
+ .dev = {
+ .platform_data = warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset = 8, .length = 16} }
+};
+
+static struct platform_nand_chip warp_nand_chip0 = {
+ .nr_chips = 1,
+ .chip_offset = CS_NAND_0,
+ .nr_partitions = ARRAY_SIZE(nand_parts),
+ .partitions = nand_parts,
+ .chip_delay = 50,
+ .ecclayout = nand_oob_16,
+ .priv = warp_chip0_settings,
+};
+
+static struct platform_device warp_nand_device = {
+ .name = ndfc-chip,
+ .id = 0,
+ .num_resources = 1,
+ .resource = warp_ndfc,
+ .dev = {
+ .platform_data = warp_nand_chip0,
+ .parent = warp_ndfc_device.dev,
+ }
+};
+
+static int warp_setup_nand_flash(void)
+{
+ platform_device_register(warp_ndfc_device);
+ platform_device_register(warp_nand_device);
+
+ return 0;
+}
+device_initcall(warp_setup_nand_flash);
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-11 20:20:17.0 -0500
@@ -0,0 +1,175 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public
Re: [i2c] [PATCH 19 1/5] Implement module aliasing for i2c to translate from device tree names
Comment was wrong, I2C_OF_MODULE_PREFIX was needed. Add it back.
Implement module aliasing for i2c to translate from device tree names
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/hwmon/f75375s.c |4 ++--
drivers/i2c/chips/ds1682.c |2 +-
drivers/i2c/chips/menelaus.c|2 +-
drivers/i2c/chips/tps65010.c|2 +-
drivers/i2c/chips/tsl2550.c |2 +-
drivers/i2c/i2c-core.c | 24 +++-
drivers/rtc/rtc-ds1307.c|2 +-
drivers/rtc/rtc-ds1374.c|2 +-
drivers/rtc/rtc-m41t80.c|2 +-
drivers/rtc/rtc-rs5c372.c |2 +-
include/linux/i2c.h |5 ++---
include/linux/mod_devicetable.h | 20
scripts/mod/file2alias.c| 12
13 files changed, 67 insertions(+), 14 deletions(-)
diff --git a/drivers/hwmon/f75375s.c b/drivers/hwmon/f75375s.c
index 6892f76..2247de6 100644
--- a/drivers/hwmon/f75375s.c
+++ b/drivers/hwmon/f75375s.c
@@ -117,7 +117,7 @@ struct f75375_data {
static int f75375_attach_adapter(struct i2c_adapter *adapter);
static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
static int f75375_detach_client(struct i2c_client *client);
-static int f75375_probe(struct i2c_client *client);
+static int f75375_probe(struct i2c_client *client, const struct
i2c_device_id *id);
static int f75375_remove(struct i2c_client *client);
static struct i2c_driver f75375_legacy_driver = {
@@ -628,7 +628,7 @@ static void f75375_init(struct i2c_client *client,
struct f75375_data *data,
}
-static int f75375_probe(struct i2c_client *client)
+static int f75375_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct f75375_data *data = i2c_get_clientdata(client);
struct f75375s_platform_data *f75375s_pdata = client-dev.platform_data;
diff --git a/drivers/i2c/chips/ds1682.c b/drivers/i2c/chips/ds1682.c
index 9e94542..93c0441 100644
--- a/drivers/i2c/chips/ds1682.c
+++ b/drivers/i2c/chips/ds1682.c
@@ -200,7 +200,7 @@ static struct bin_attribute ds1682_eeprom_attr = {
/*
* Called when a ds1682 device is matched with this driver
*/
-static int ds1682_probe(struct i2c_client *client)
+static int ds1682_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
int rc;
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 2dea012..89ef9b6 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -1149,7 +1149,7 @@ static inline void menelaus_rtc_init(struct
menelaus_chip *m)
static struct i2c_driver menelaus_i2c_driver;
-static int menelaus_probe(struct i2c_client *client)
+static int menelaus_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct menelaus_chip*menelaus;
int rev = 0, val;
diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c
index e320994..6b13642 100644
--- a/drivers/i2c/chips/tps65010.c
+++ b/drivers/i2c/chips/tps65010.c
@@ -465,7 +465,7 @@ static int __exit tps65010_remove(struct i2c_client *client)
return 0;
}
-static int tps65010_probe(struct i2c_client *client)
+static int tps65010_probe(struct i2c_client *client, const struct
i2c_device_id *id)
{
struct tps65010 *tps;
int status;
diff --git a/drivers/i2c/chips/tsl2550.c b/drivers/i2c/chips/tsl2550.c
index 3de4b19..27c553d 100644
--- a/drivers/i2c/chips/tsl2550.c
+++ b/drivers/i2c/chips/tsl2550.c
@@ -364,7 +364,7 @@ static int tsl2550_init_client(struct i2c_client *client)
*/
static struct i2c_driver tsl2550_driver;
-static int __devinit tsl2550_probe(struct i2c_client *client)
+static int __devinit tsl2550_probe(struct i2c_client *client, const
struct i2c_device_id *id)
{
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
struct tsl2550_data *data;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..5f62230 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,6 +47,19 @@ static DEFINE_IDR(i2c_adapter_idr);
/* - */
+static const struct i2c_device_id *i2c_match_id(
+ const struct i2c_device_id *id, struct i2c_client *client)
+{
+ /* only powerpc drivers implement the id_table,
+* it is empty on other platforms */
+ while (id-name[0]) {
+ if (strcmp(client-name, id-name) == 0)
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client =
Re: [PATCH 1/5] Warp Base Platform
On Fri, Jan 11, 2008 at 09:55:54PM -0500, Sean MacLennan wrote: I guess this implies I don't need the GPL blurb. I noticed that the blurb I have used mentions GPL2 or later and I know Linus doesn't like GPL3. You don't need it but people tend to include it by habit. The two versions are essentially up to personal discretion. Some people include the (or later) text, others do not. There are good arguments both for and against. If you're in doubt, ask your company lawyer. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH 19 1/5] Implement module aliasing for i2c to translate from device tree names
Hi Jon,
On Fri, 11 Jan 2008 22:00:42 -0500 Jon Smirl [EMAIL PROTECTED] wrote:
+++ b/drivers/hwmon/f75375s.c
@@ -117,7 +117,7 @@ struct f75375_data {
static int f75375_attach_adapter(struct i2c_adapter *adapter);
static int f75375_detect(struct i2c_adapter *adapter, int address, int kind);
static int f75375_detach_client(struct i2c_client *client);
-static int f75375_probe(struct i2c_client *client);
+static int f75375_probe(struct i2c_client *client, const struct
i2c_device_id *id);
Looks like your mail client has wrapped this. Also in various later
spots.
+++ b/drivers/i2c/i2c-core.c
@@ -47,6 +47,19 @@ static DEFINE_IDR(i2c_adapter_idr);
/* -
*/
+static const struct i2c_device_id *i2c_match_id(
+ const struct i2c_device_id *id, struct i2c_client *client)
Any reason that the client argument is not const as well?
+++ b/include/linux/i2c.h
@@ -141,11 +141,10 @@ struct i2c_driver {
struct device_driver driver;
struct list_head list;
+ struct i2c_device_id *id_table;
Any reason that this is not const? Making it const would allow divers to
make their tables const.
These are just small things (apart from the wrapping) that can be fixed
up with followup patches.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpGxwZHVl0n1.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 19 4/5] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
Hi Jon,
On Fri, 11 Jan 2008 21:47:46 -0500 Jon Smirl [EMAIL PROTECTED] wrote:
+++ b/drivers/i2c/busses/i2c-mpc.c
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
We have for_each_child_of_node(adap_node, node) now for this (and it
means you don't need to initialize the node above).
+ struct i2c_board_info info;
+ const u32 *addr;
+ const char *compatible;
+ int len;
+
+ addr = of_get_property(node, reg, len);
+ if (!addr || len sizeof(int) || *addr (1 10) - 1) {
+ printk(KERN_ERR i2c-mpc.c: invalid entry, missing reg
attribute\n);
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ compatible = of_get_property(node, compatible, len);
+ if (!compatible) {
+ printk(KERN_ERR i2c-mpc.c: invalid entry, missing
compatible attribute\n);
+ continue;
You may need to clean up from the irq_of_pase_and_map().
+ }
+
+ /* need full alias i2c:NOF,vendor,device */
+ strcpy(info.type, I2C_OF_MODULE_PREFIX);
+ strncat(info.type, compatible, sizeof(info.type));
+ request_module(info.type);
+
+ /* need module alias OF,vendor,device */
+ strcpy(info.type, OF_I2C_PREFIX);
+ strncat(info.type, compatible, sizeof(info.type));
+
+ info.driver_name[0] = '\0';
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ if (!i2c_new_device(adap, info)) {
+ printk(KERN_ERR i2c-mpc.c: Failed to load driver for
%s\n, info.type);
+ continue;
And again.
+ }
+ }
+}
+
+static int mpc_i2c_probe(struct of_device *op, const struct of_device_id
*match)
+{
+ dev_set_drvdata(op-dev, i2c);
+
+ i2c-adap = mpc_ops;
+ i2c_set_adapdata(i2c-adap, i2c);
+ i2c-adap.dev.parent = op-dev;
+
+ result = i2c_add_adapter(i2c-adap);
+ if (result 0) {
+ printk(KERN_ERR i2c-mpc - failed to add adapter\n);
+ goto fail_add;
+ }
+
+ of_register_i2c_devices(i2c-adap, op-node);
+
+ return result;
+
+fail_add:
dev_set_dvdata(op-dev, NULL);
+ free_irq(i2c-irq, i2c);
+fail_request:
+ irq_dispose_mapping(i2c-irq);
+fail_irq:
+ iounmap(i2c-base);
+fail_map:
+ kfree(i2c);
+ return result;
+};
+static struct of_device_id mpc_i2c_of_match[] = {
const, please.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp8GVFyhJlad.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Device Tree PCI
From: Scott Wood
Sent: Fri 1/11/2008 1:02 PM
To: Rune Torgersen
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Device Tree PCI
On Fri, Jan 11, 2008 at 12:17:41PM -0600, Rune Torgersen wrote:
PCI_INT: [EMAIL PROTECTED],10 {
#interrupt-cells = 1;
interrupt-controller;
reg = 5 10 4; //
Chip select, offset, length
compatible = apmax-pciintmux;
interrupt-parent = PIC;
interrupts = 19 8;//
IRQ7, interrupt#25
};
Is this interrupt controller getting registered before the PCI bus gets
probed?
Yes, and we got the disk controller on the primary side to work fully.
The kernel is still spitting those messages out, and we have determined it does
so when scanning the secondary side of the bridge, so we're suspecting our
bridge node in the device tree is not correct.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
On Saturday 12 January 2008, Sean MacLennan wrote:
Josh Boyer wrote:
+ if (gpio_base == NULL) {
+ printk(ERROR: Unable to remap GPIO base.\n);
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
Do you really want readl here? That will byte-swap.
According to the docs I got from the hardware guys, this is correct.
That does *not* mean they didn't get it wrong. Unfortunately, it was
just on a piece of paper and I don't know if I still have it.
You are accessing the 440EP GPIO controller here right? Then you really should
use big endian access routines. From you code I assume that you have
connected the LED signals to GPIO00 and GPIO01. I suggest to use code that
looks like this:
#define LED_GREEN (0x8000 0)
#define LED_RED (0x8000 1)
leds = in_be32(gpio_base);
switch (green) {
case 0: leds = ~LED_GREEN; break;
case 1: leds |= LED_GREEN; break;
}
switch (red) {
case 0: leds = ~LED_RED; break;
case 1: leds |= LED_RED; break;
}
outbe32(leds, gpio_base);
And when you change the dts to describe both GPIO controllers you should map
the 2nd one and remove the 0x100 offset above as I have done above.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Stefan Roese wrote:
On Saturday 12 January 2008, Sean MacLennan wrote:
Josh Boyer wrote:
+ if (gpio_base == NULL) {
+ printk(ERROR: Unable to remap GPIO base.\n);
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
Do you really want readl here? That will byte-swap.
According to the docs I got from the hardware guys, this is correct.
That does *not* mean they didn't get it wrong. Unfortunately, it was
just on a piece of paper and I don't know if I still have it.
You are accessing the 440EP GPIO controller here right? Then you really
should
use big endian access routines. From you code I assume that you have
connected the LED signals to GPIO00 and GPIO01. I suggest to use code that
looks like this:
#define LED_GREEN (0x8000 0)
#define LED_RED (0x8000 1)
leds = in_be32(gpio_base);
switch (green) {
case 0: leds = ~LED_GREEN; break;
case 1: leds |= LED_GREEN; break;
}
switch (red) {
case 0: leds = ~LED_RED; break;
case 1: leds |= LED_RED; break;
}
outbe32(leds, gpio_base);
And when you change the dts to describe both GPIO controllers you should map
the 2nd one and remove the 0x100 offset above as I have done above.
Best regards,
Stefan
Ok. I will look into that. What is the best practice for looking up the
second GPIO controller? I have been using of_find_compatible_type. I
could call it a second time with a from arg.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Friday 11 January 2008, Benjamin Herrenschmidt wrote: On Fri, 2008-01-11 at 09:48 -0800, Eugene Surovegin wrote: On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote: On Saturday 05 January 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote: Performance tests done by AMCC have shown that 256 buffer increase the performance of the Linux EMAC driver. So let's update the default values to match this setup. Signed-off-by: Stefan Roese [EMAIL PROTECTED] --- Do we have the numbers ? Did they also measure latency ? I hoped this question would not come. ;) No, unfortunately I don't have any numbers. Just the recommendation from AMCC to always use 256 buffers. This cannot be true for all chips. Default numbers I selected weren't random. In particular, 256 for Tx doesn't make a lot of sense for 405. You just gonna waste memory. This may be the case with the old 405 PPC's. But with the new ones coming out right now, like the up to 666MHz 405EX with GBit support, 256 could be an improvement. I still owe you figures though. Will try to do some testing in a short while. I'd be quite reluctant to follow such advices from AMCC without actual details. I think we can make defaults based on other config options nowadays. Not very nice but we could do things like default 128 if PPC_40x default 256 Or even more detailed. We shouldn't make it too complicated. We can always select different settings in the defconfig file. My thinking here is to better wast a little memory with a potential performance improvement. Just me 0.02$ Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI Failed to allocate mem for PCI ROM
On Fri, Jan 11, 2008 at 02:27:16PM -0600, Kumar Gala wrote: I'm getting the following message from the kernel on an embedded ppc32 system: PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0 The HW setup is a PCIe host controller and an e1000 NIC card. ... I'm happy to debug, is the fact that the resno == 9 ok or does that seem wrong? That is fine for the Bridge. See include/linux/pci.h : #define PCI_ROM_RESOURCE6 #define PCI_BRIDGE_RESOURCES7 #define PCI_NUM_RESOURCES 11 IIRC, Bridges may have two 32-bit or one 64-bit BAR, Expansion ROM BAR and three range registers: IO Port, MMIO (Prefetchable and non-prefetchable). The BRIDGE_RESOURCES (7-10) are what failed to be assigned for some reason. Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that: [7] is IO Range. [8] is MMIO [9] is Prefetchable MMIO [10] no clue...maybe used by host PCI bus controllers. 0x10 is 1MB and would be the minimum MMIO range that can be allocated. So that looks right too. Probably need to find out what is allocating 0xe000 instead. hth, grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
On Sat, 2008-01-12 at 08:26 +0100, Stefan Roese wrote: We shouldn't make it too complicated. We can always select different settings in the defconfig file. My thinking here is to better wast a little memory with a potential performance improvement. Just me 0.02$ If it gets really critical, then we can move those settings to the device-tree. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
