Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
On Thu, Sep 25, 2008 at 5:59 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Modify the Freescale Elo / Elo Plus DMA driver so that it can be compiled as
a module.
The primary change is to stop treating the DMA controller as a bus, and the
DMA channels as devices on the bus. This is because the Open Firmware (OF)
kernel code does not allow busses to be removed, so although we can call
of_platform_bus_probe() to probe the DMA channels, there is no
of_platform_bus_remove(). Instead, the DMA channels are manually probed,
similar to what fsl_elbc_nand.c does.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
v2: updated per comments
This patch is for the 2.6.28 kernel. This patch exposes a bug in the dmatest
module, so my other patch dmatest: properly handle duplicate DMA channels
should be applied if this patch is applied.
[snip]
+static void __exit of_fsl_dma_exit(void)
+{
+ of_unregister_platform_driver(of_fsl_dma_driver);
}
-subsys_initcall(of_fsl_dma_chan_init);
subsys_initcall(of_fsl_dma_init);
Not a critical problem. But module_init() are preferred for modules.
+module_exit(of_fsl_dma_exit);
+
+MODULE_DESCRIPTION(Freescale Elo / Elo Plus DMA driver);
+MODULE_LICENSE(GPL);
Acked-by: Li Yang [EMAIL PROTECTED]
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] powerpc: Cleanup 32/64 bit syscall int sign ext.
I noticed that our ABI says callers are responsible for sign extending. That means that all int, long or similarly signed arguments to syscalls must be explicitly sign-extended. We already have wrappers to do that for -some- syscalls in arch code. Those are in C and pretty ugly, copy/pasting a bunch of identically useless comments all over, and are missing a lot of potential candidates. sparc64 uses a nicer macro system to generate trampolines in asm. It also has a more complete list. But it's also missing some :-) Now, there is a good point to be made that we don't absolutely need to always sign extend. In many cases, the called function will just do a cmplw for example, or an and to test bits in flags, and so it looks like sign extension is not necessary. One could say that sign extending file descriptors for example isn't terribly useful But that sounds like a fragile approach to me. We don't know for sure what new tricks the compiler will learn for example. In fact, when taking the sparc64 list, I noticed that in some cases it -did- already sign extend file descriptors and flags .. and in some cases not. So I've spent a few hours combing through all of syscalls.h (and one more that seems to be missing from this file, ie, pipe2, there may be others) for anything using int, long or pid_t (which is signed, at least on our 32-bit platforms). I've then removed our old wrappers, created a new mechanism, totally untested btw, based on the sparc64 one (the idea is that we might be able to use a common table, at least for the bulk of the syscalls), and I've left in there a bunch of comments about what I found possibly missing in the sparc64 table which I added, where there are differences that warrant different bits, etc...). It's by no mean a final patch. It's for opening the discussion, and possibly for David to get a chance to update his table if he feels like it :-) Cheers, Ben. Index: linux-work/arch/powerpc/include/asm/systbl.h === --- linux-work.orig/arch/powerpc/include/asm/systbl.h 2008-09-25 13:38:28.0 +1000 +++ linux-work/arch/powerpc/include/asm/systbl.h2008-09-25 16:50:18.0 +1000 @@ -4,25 +4,25 @@ */ SYSCALL(restart_syscall) -SYSCALL(exit) +SYS32_SYS(exit) PPC_SYS(fork) SYSCALL_SPU(read) SYSCALL_SPU(write) -COMPAT_SYS_SPU(open) +SYS32_SYS_SPU(open) SYSCALL_SPU(close) -COMPAT_SYS_SPU(waitpid) -COMPAT_SYS_SPU(creat) +SYS32_SYS_SPU(waitpid) +SYS32_SYS_SPU(creat) SYSCALL_SPU(link) SYSCALL_SPU(unlink) COMPAT_SYS(execve) SYSCALL_SPU(chdir) COMPAT_SYS_SPU(time) -SYSCALL_SPU(mknod) +SYS32_SYS_SPU(mknod) SYSCALL_SPU(chmod) SYSCALL_SPU(lchown) SYSCALL(ni_syscall) OLDSYS(stat) -SYSX_SPU(sys_lseek,ppc32_lseek,sys_lseek) +SYS32_SYS_SPU(lseek) SYSCALL_SPU(getpid) COMPAT_SYS(mount) SYSX(sys_ni_syscall,sys_oldumount,sys_oldumount) @@ -36,13 +36,13 @@ COMPAT_SYS(pause) COMPAT_SYS(utime) SYSCALL(ni_syscall) SYSCALL(ni_syscall) -COMPAT_SYS_SPU(access) -COMPAT_SYS_SPU(nice) +SYS32_SYS_SPU(access) +SYS32_SYS_SPU(nice) SYSCALL(ni_syscall) SYSCALL_SPU(sync) -COMPAT_SYS_SPU(kill) +SYS32_SYS_SPU(kill) SYSCALL_SPU(rename) -COMPAT_SYS_SPU(mkdir) +SYS32_SYS_SPU(mkdir) SYSCALL_SPU(rmdir) SYSCALL_SPU(dup) SYSCALL_SPU(pipe) @@ -51,47 +51,47 @@ SYSCALL(ni_syscall) SYSCALL_SPU(brk) SYSCALL_SPU(setgid) SYSCALL_SPU(getgid) -SYSCALL(signal) +SYS32_SYS(signal) SYSCALL_SPU(geteuid) SYSCALL_SPU(getegid) SYSCALL(acct) -SYSCALL(umount) +SYS32_SYS(umount) SYSCALL(ni_syscall) COMPAT_SYS_SPU(ioctl) COMPAT_SYS_SPU(fcntl) SYSCALL(ni_syscall) -COMPAT_SYS_SPU(setpgid) +SYS32_SYS_SPU(setpgid) SYSCALL(ni_syscall) SYSX(sys_ni_syscall,sys_olduname, sys_olduname) -COMPAT_SYS_SPU(umask) +SYS32_SYS_SPU(umask) SYSCALL_SPU(chroot) SYSCALL(ustat) SYSCALL_SPU(dup2) SYSCALL_SPU(getppid) SYSCALL_SPU(getpgrp) SYSCALL_SPU(setsid) -SYS32ONLY(sigaction) +SYSX(sys_ni_syscall,sys32_sigaction,sys_sigaction) SYSCALL_SPU(sgetmask) -COMPAT_SYS_SPU(ssetmask) +SYS32_SYS_SPU(ssetmask) SYSCALL_SPU(setreuid) SYSCALL_SPU(setregid) SYS32ONLY(sigsuspend) COMPAT_SYS(sigpending) -COMPAT_SYS_SPU(sethostname) +SYS32_SYS_SPU(sethostname) COMPAT_SYS_SPU(setrlimit) COMPAT_SYS(old_getrlimit) -COMPAT_SYS_SPU(getrusage) +SYS32_SYS_SPU(getrusage) COMPAT_SYS_SPU(gettimeofday) COMPAT_SYS_SPU(settimeofday) -COMPAT_SYS_SPU(getgroups) -COMPAT_SYS_SPU(setgroups) +SYS32_SYS_SPU(getgroups) +SYS32_SYS_SPU(setgroups) SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select) SYSCALL_SPU(symlink) OLDSYS(lstat) -COMPAT_SYS_SPU(readlink) +SYS32_SYS_SPU(readlink) SYSCALL(uselib) -SYSCALL(swapon) -SYSCALL(reboot) +SYS32_SYS(swapon) +SYS32_SYS(reboot) SYSX(sys_ni_syscall,compat_sys_old_readdir,old_readdir) SYSCALL_SPU(mmap) SYSCALL_SPU(munmap) @@ -99,16 +99,16 @@ SYSCALL_SPU(truncate) SYSCALL_SPU(ftruncate) SYSCALL_SPU(fchmod) SYSCALL_SPU(fchown) -COMPAT_SYS_SPU(getpriority) -COMPAT_SYS_SPU(setpriority) +SYS32_SYS_SPU(getpriority)
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Thu, 25 Sep 2008 07:15:17 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote: Hi Ben, On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote: The per-interrupt mask and unmask calls have to go through RTAS, a single-threaded global context, which in addition to increasing path length will really limit scalability. The interrupt controller poll and reject facilities are accessed through hypervisor calls which are comparable to a fast syscall, and parallel to all cpus. Note also that the XICS code thus assumes, iirc, as does the cell IIC code, that eoi is called on the -same- cpu that fetched the interrupt initially. That assumption can be broken with IRQ threads no ? No, the fetch and the eoi are both done in interrupt context before the hardirq thread is woken up. On the other hand, the mask+eoi and the unmask may well happen on different cpus as there's only one hardirq thread per irq on the system. Don't know if this is a problem with the XICS though. Ok, that's the right approach then. It should work. I don't know what the specific problems with HEA are at this stage. Yep, except as it behaves in way that the current -rt fasteoi flow cannot handle. It doesn't seem to make sense to implement a set_irq_type(), what would it do ? The XICS doesn't expose any concept of interrupt type... That's what I gathered from looking at the sources. Thanks, Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote: Ok, that's the right approach then. It should work. I don't know what the specific problems with HEA are at this stage. Yep, except as it behaves in way that the current -rt fasteoi flow cannot handle. We probably need to make a special xics flow handler for -rt that does what Milton suggested, ie, bring down the CPU priority right away and only EOI later or something like that, instead of masking/unmasking. I don't know what are the other potential issues with the HEA though. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Thu, 25 Sep 2008 07:14:07 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: There may be some implicit assumption in that we expect the cpu priority to be returned to normal by the EOI, but there is nothing in the hardware that requires the EOI to come from the same cpu as accepted the interrupt for processing, with the exception of the IPI which is per-cpu (and the only interrupt that is per-cpu). Well, there is one fundamental one: The XIRR register we access is per-CPU, so if we are to return the right processor priority, we must make sure we write the right XIRR. That's already the case as the irq fetch (xx_xirr_info_get()) and eoi (xx_xirr_info_set()) are both done in interrupt context, therefore on the same cpu. Same with Cell, MPIC, actually and a few others. In general I'd say most fast_eoi type PICs have this requirement. It would probably mean adding the concept of the current cpu priority vs interrupts and making sure we write it to hardware at irq_exit() time when deferring the actual irq handlers. I think we need something like a special -rt variant of the fast_eoi handler that masks eoi's in ack() before the thread is spun off, and unmasks instead of eoi() when the irq processing is complete. This is what is already done in the threaded case: - fetch + mask + eoi in interrupt context - unmask in the thread when processing is complete. Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Thu, 25 Sep 2008 17:22:41 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote: Ok, that's the right approach then. It should work. I don't know what the specific problems with HEA are at this stage. Yep, except as it behaves in way that the current -rt fasteoi flow cannot handle. We probably need to make a special xics flow handler for -rt that does what Milton suggested, ie, bring down the CPU priority right away Do you mean creating a custom fasteoi handler into xics.c? Also, it's not clear to me from looking at the code how you go about changing the cpu priority. and only EOI later or something like that, instead of masking/unmasking. I don't know what are the other potential issues with the HEA though. Don't know either, but that I can test. Thanks, Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
Benjamin, On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote: On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote: On Dienstag, 23. September 2008, Juergen Beisert wrote: What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. One should enable the internal USB clock. If done, it works... In 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24. It was removed because some 5200 platform do not use USB and should not enable the internal clock. In general, it is not the kernel's job to configure clocking and pin usage on the chip. Instead, it should be set correctly at power up by U-Boot. Or by the USB host driver :-) But how to deal with platform specific things like (in this case) unknown external clock or usage of the internal clock generator (= how to setup the frequency divider)? However, if firmware *cannot* be changed, there is a workaround. You can create a new platform specific board support file in arch/powerpc/platforms/52xx/ that matches against your specific board and performs the needed fixups. An example of this is lite5200.c. Many lite5200 boards have older versions of U-Boot installed which does not correctly configure clocks or port-config. So, lite5200.c matches to the board instead of mpc5200_simple.c so that the board specific fixups can be performed easily. You should do the same for your board. I tend to thing that drivers should deal with their own clocks. ACK. But only to switch them on and off. Not to configure them. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? ACK. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
But how to deal with platform specific things like (in this case) unknown external clock or usage of the internal clock generator (= how to setup the frequency divider)? You can always use the platform feature hacks like I do on powermac but we should definitely find something better. Maybe some hook in the OF wrapper ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
Do you mean creating a custom fasteoi handler into xics.c? Also, it's not clear to me from looking at the code how you go about changing the cpu priority. Yup. I think the priority is the CPPR.. Milton can give you more details, if not, I'll pick it up tomorrow when at the office. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Thu, 25 Sep 2008 18:36:19 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Do you mean creating a custom fasteoi handler into xics.c? Also, it's not clear to me from looking at the code how you go about changing the cpu priority. Yup. I think the priority is the CPPR.. Milton can give you more details, if not, I'll pick it up tomorrow when at the office. Thanks Ben, will look into this. Nite Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pata_platform struct resource signness fix
Hi,
This patch is to pata_platform.c but at this time, it's powerpc specific
because it can only be triggerred using openfirmware, so I post the patch
here. The patch is against 2.6.26-rc8.
The problem is triggerred when ata device is populated using
pata_of_platform.c, and no irq is assigned (poll mode, such as CF card).
pata_of_platform_probe() parse device tree and
if (ret == NO_IRQ)
irq_res.start = irq_res.end = -1;
Then irq is 0x, not NULL. Probe will fail coz irq can't be
requested.
---
(irq_res-start 0) will be true even when it is (-1). When the device
has no irq, irq_res-start is assigned (-1).
Signed-off-by: Wang Jian [EMAIL PROTECTED]
---
drivers/ata/pata_platform.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index 8f65ad6..b12cd0c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -123,7 +123,7 @@ int __devinit __pata_platform_probe(struct device *dev,
/*
* And the IRQ
*/
- if (irq_res irq_res-start 0) {
+ if (irq_res irq_res-start != -1) {
irq = irq_res-start;
irq_flags = irq_res-flags;
}
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller [EMAIL PROTECTED] wrote: On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote: Hi Milton, On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller [EMAIL PROTECTED] wrote: On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue wrote: When entering the low level handler, level sensitive interrupts are masked, then eio'd in interrupt context and then unmasked at the end of hardirq processing. That's fine as any interrupt comming in-between will still be processed since the kernel replays those pending interrupts. Is this to generate some kind of software managed nesting and priority of the hardware level interrupts? No, not really. This is only to be sure to not miss interrupts coming from the same source that were received during threaded hardirq processing. Some instrumentation showed that it never seems to happen in the eHEA interrupt case, so I think we can forget this aspect. I don't trust the interrupt can never happen during hea hardirq, because I think there will be a race between their rearming the next interrupt and the unmask being called. So do I, it was just to make sure I was not hit by another interrupt while handling the previous one and thus reduce the number of hypothesis. I sure do not say that it cannot happen, just that that path is not taken when I have the eHEA hang. I was trying to understand why the mask and early eoi, but I guess its to handle other more limited interrupt controllers where the interrupts stack in hardware instead of software. Also, the problem only manifests with the eHEA RX interrupt. For example, the IBM Power Raid (ipr) SCSI exhibits absolutely no problem under an RT kernel. From this I conclude that: IPR - PCI - XICS is OK eHEA - IBMEBUS - XICS is broken with hardirq preemption. I also checked that forcing the eHEA interrupt to take the non threaded path does work. For a long period of time, XICS dealt only with level interrupts. First Micro Channel, and later PCI buses. The IPI is made level by software conventions. Recently, EHCA, EHEA, and MSI interrupts were added which by their nature are edge based. The logic that converts those interrupts to the XICS layer is responsible for the resend when no cpu can accept them, but not to retrigger after an EOI. OK Here is a side by side comparison of the fasteoi flow with and without hardirq threading (sorry it's a bit wide) (removed) the non-threaded flow does (in interrupt context): mask Whoops, my bad, in the non threaded case, there's no mask at all, only an unmask+eoi at the end, maybe that's an oversight! handle interrupt unmask eoi the threaded flow does: mask eoi handle interrupt unmask If I remove the mask() call, then the eHEA is no longer hanging. Hmm, I guess I'm confused. You are saying the irq does not appear if it occurs while it is masked? Looks like it is, but I cannot say for sure, the only observable effect is that I do not get any more interrupts coming from the eHEA. Well, in that case, I would guess that the hypervisor is checking if the irq is previously pending while it was masked and resetting it as part of the unmask. It can't do it on level, but can on the true edge sources. I would further say the justification for this might be the hardware might make it pending from some previous stale event that might result in the false interrupt on startup were it not to do this clear. The reason I ask is the xics controller can do unlimited nesting of hardware interrupts. In fact, the hardware has 255 levels of priority, of which 16 or so are reserved by the hypervisor, leaving over 200 for the os to manage. Higher numbers are lower in priority, and the hardware will only dispatch an interrupt to a given cpu if it is currenty at a lower priority. If it is at a higher priority and the interrupt is not bound to a specific cpu it will look for another cpu to dispatch it. The hardware will not re-present an irq until the it is EOId (managed by a small state machine per interrupt at the source, which also handles no cpu available try again later), but software can return its cpu priority to the previous level to recieve other interrupt sources at the same level. The hardware also supports lazy update of the cpu priority register when an interrupt is presented; as long as the cpu is hard-irq enabled it can take the irq then write is real priority and let the hw decide if the irq is still pending or it must defer or try another cpu in the rejection scenerio. The only restriction is that the EOI can not cause an interrupt reject by raising the priority while sending the EOI command. The per-interrupt mask and unmask calls have to go through RTAS, a single-threaded
Re: Please pull from 'for-2.6.27'
Hi Scott, This isn't a regression since the stuff is new in 2.6.27. IMHO this can wait until 2.6.28. It would be a bug in 2.6.27 that did not exist in 2.6.26... is there anything that used to use another mechanism that now uses this? No, GPIO support on CPM1/CPM2 is new in 2.6.27. Before, dedicated platform drivers were needed to drive hardware connected to an GPIO pin. That's not to say that it's necessarily critical enough this late in the process, but in general I'm not very comfortable with not being able to fix newly added code as soon as the merge window closes because it's not a regression. If i understood Linus correctly, this fix will have to wait for 2.6.28, but then it can also enter the 2.6.27 stable series (like 2.6.27.1). Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
The alternative fix can be.
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 408da30..1f18ad9 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct of_device
*ofdev,
ret = of_irq_to_resource(dn, 0, irq_res);
if (ret == NO_IRQ)
- irq_res.start = irq_res.end = -1;
+ irq_res.start = irq_res.end = 0;
else
irq_res.flags = 0;
I just didn't spend much time to see which is better.
Wang Jian wrote:
Hi,
This patch is to pata_platform.c but at this time, it's powerpc specific
because it can only be triggerred using openfirmware, so I post the patch
here. The patch is against 2.6.26-rc8.
The problem is triggerred when ata device is populated using
pata_of_platform.c, and no irq is assigned (poll mode, such as CF card).
pata_of_platform_probe() parse device tree and
if (ret == NO_IRQ)
irq_res.start = irq_res.end = -1;
Then irq is 0x, not NULL. Probe will fail coz irq can't be
requested.
---
(irq_res-start 0) will be true even when it is (-1). When the device
has no irq, irq_res-start is assigned (-1).
Signed-off-by: Wang Jian [EMAIL PROTECTED]
---
drivers/ata/pata_platform.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index 8f65ad6..b12cd0c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -123,7 +123,7 @@ int __devinit __pata_platform_probe(struct device *dev,
/*
* And the IRQ
*/
- if (irq_res irq_res-start 0) {
+ if (irq_res irq_res-start != -1) {
irq = irq_res-start;
irq_flags = irq_res-flags;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down
I wrote: And here's the fix. Well, that should of course remove that comment there too. New version below. From: Johannes Berg [EMAIL PROTECTED] Subject: powerpc: fix shutdown I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out to be due to the system_state being SYSTEM_POWER_OFF, which this code doesn't take as a valid state for shutting off CPUs in. This has never made sense to me, but when I added hotplug code to implement hibernate I only made it work and did not question the need to check the system_state. Thomas Gleixner helped me dig, but the only thing we found is that it was added with the original commit that added CPU hotplug support. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Cc: Thomas Gleixner [EMAIL PROTECTED] Cc: Joel Schopp [EMAIL PROTECTED] Cc: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/kernel/idle.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) --- everything.orig/arch/powerpc/kernel/idle.c 2008-09-01 12:28:37.0 +0200 +++ everything/arch/powerpc/kernel/idle.c 2008-09-25 10:55:45.0 +0200 @@ -34,11 +34,7 @@ #include asm/smp.h #ifdef CONFIG_HOTPLUG_CPU -/* this is used for software suspend, and that shuts down - * CPUs even while the system is still booting... */ -#define cpu_should_die() (cpu_is_offline(smp_processor_id()) \ - (system_state == SYSTEM_RUNNING \ -|| system_state == SYSTEM_BOOTING)) +#define cpu_should_die() cpu_is_offline(smp_processor_id()) #else #define cpu_should_die() 0 #endif ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
On Thu, Sep 25, 2008 at 4:36 PM, Wang Jian [EMAIL PROTECTED] wrote: Hi, This patch is to pata_platform.c but at this time, it's powerpc specific because it can only be triggerred using openfirmware, so I post the patch here. The patch is against 2.6.26-rc8. Powerpc isn't the only arch to use openfirmware. Anyway, you have to cc [EMAIL PROTECTED] if you want the patch to be merged. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
As I said, I didn't spend much time on the issue, so I don't know which patch is better. (But I do think the patch to pata_of_platform.c is better ATM). AFAIK, powerpc is the only consumer of pata_of_platform.c, so I think this list is better for discussion. I should cc: Anton Vorontsov [EMAIL PROTECTED] but last time I cc: him I got bounced. Leo Li wrote: On Thu, Sep 25, 2008 at 4:36 PM, Wang Jian [EMAIL PROTECTED] wrote: Hi, This patch is to pata_platform.c but at this time, it's powerpc specific because it can only be triggerred using openfirmware, so I post the patch here. The patch is against 2.6.26-rc8. Powerpc isn't the only arch to use openfirmware. Anyway, you have to cc [EMAIL PROTECTED] if you want the patch to be merged. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powerpc/boot: add kernel,end node to the cuboot target
Milton Miller wrote: On Wed Sep 24 at about 05:54:04 EST 2008, Sebastian Siewior wrote: this could be used by the kexec userland code. NACK. [...] Thanks for explanation. I just went through the kexec user land code and saw that the 64bit code uses the device tree to obtain some address and 32bit returns a hard coded struct on game cube (unless it was another console I mixed it up) and nothing on every other platform. Therefore I tried to add the missing nodes. If you have any questions about kdump or what needs to happen, please feel free to contact me either by email or on irc (sometimes I use mdm other times the email login as my nick, and when connected I tend to leave it well past the hours I am at the computer). Thanks for the offer. milton Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powerpc/boot: compare _start against ei.loadsize instead ei.memsize
Milton Miller wrote:
My current (working) solution is to move cuImage from 4 MiB to 8 MiB.
Something similar has been done for pSeries in 9b09c6d powerpc: Change
the default link address for pSeries zImage kernels. Would it be
appropriate to move initial address to 64 MiB as the default loading
address or do we have here some boards which have only 64 MiB of memory?
I think there are some boards that have even less (8xx?). Is the
link address a wrapper option yet?
Nope. The wrapper script distinguishes between platforms. Default is 4MiB,
pSeries has 64MiB, coff does 5MiB and the PS3 has other magic.
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -56,7 +56,7 @@ static struct addr_range prep_kernel(void)
if (platform_ops.vmlinux_alloc) {
addr = platform_ops.vmlinux_alloc(ei.memsize);
} else {
- if ((unsigned long)_start ei.memsize)
+ if ((unsigned long)_start ei.loadsize)
I think this needs to be a two part test (add approprate casts):
_start ei.loadsize || _end ei.memsize
.. and a comment explaining why.
okay.
We could do better if we kept allocating more memory until we got
above it, but the current code has no such provision. (prpmc2800, or
one of those, actually decompresses the header to peek at memsize
before starting the simple_alloc code).
I don't thing I can follow. Do you want to move the bootwrapper code above
the limit and recall it?
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian [EMAIL PROTECTED] wrote:
The alternative fix can be.
This one is better as 0 is defined as 'invalid irq' for all
architectures. Added linux-ide and Anton to cc.
- Leo
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 408da30..1f18ad9 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct
of_device *ofdev,
ret = of_irq_to_resource(dn, 0, irq_res);
if (ret == NO_IRQ)
- irq_res.start = irq_res.end = -1;
+ irq_res.start = irq_res.end = 0;
else
irq_res.flags = 0;
I just didn't spend much time to see which is better.
Wang Jian wrote:
Hi,
This patch is to pata_platform.c but at this time, it's powerpc specific
because it can only be triggerred using openfirmware, so I post the patch
here. The patch is against 2.6.26-rc8.
The problem is triggerred when ata device is populated using
pata_of_platform.c, and no irq is assigned (poll mode, such as CF card).
pata_of_platform_probe() parse device tree and
if (ret == NO_IRQ)
irq_res.start = irq_res.end = -1;
Then irq is 0x, not NULL. Probe will fail coz irq can't be
requested.
---
(irq_res-start 0) will be true even when it is (-1). When the device
has no irq, irq_res-start is assigned (-1).
Signed-off-by: Wang Jian [EMAIL PROTECTED]
---
drivers/ata/pata_platform.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index 8f65ad6..b12cd0c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -123,7 +123,7 @@ int __devinit __pata_platform_probe(struct device
*dev,
/*
* And the IRQ
*/
- if (irq_res irq_res-start 0) {
+ if (irq_res irq_res-start != -1) {
irq = irq_res-start;
irq_flags = irq_res-flags;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
On Thu, Sep 25, 2008 at 06:40:59PM +0800, Li Yang wrote: On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian [EMAIL PROTECTED] wrote: The alternative fix can be. This one is better as 0 is defined as 'invalid irq' for all architectures. Added linux-ide and Anton to cc. Thanks for the correct Cc. I've sent a patch to fix the issue more than a month ago. http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg22851.html Jeff, could you apply the patch? Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix PCI in Holly device tree
On Thu, 25 Sep 2008 12:39:04 +1000 David Gibson [EMAIL PROTECTED] wrote: The PCI bridge on the Holly board is current incorrectly represented in the device tree. The current device tree node for the PCI bridge sits under the tsi-bridge node. That's not obviously wrong, but the PCI bridge translated some PCI spaces into CPU address ranges which were not translated by the tsi-bridge node. We used to get away with this problem because the PCI bridge discovery code was also buggy, assuming incorrectly that PCI host bridge nodes were always directly under the root bus and treating the translated addresses as raw CPU addresses, rather than parent bus addresses. This has since been fixed, breaking Holly. This could be fixed by adding extra translations to the tsi-bridge node, but this patch instead moves the Holly PCI bridge out of the tsi-bridge node to the root bus. This makes the tsi-bridge node represent only the built-in IO devices in the bridge, with a more-or-less contiguous address range. This is the same convention used on Freescale SoC chips, where the soc node represents only the IMMR region, and the PCI and other bus bridges are separate nodes under the root bus. Signed-off-by: David Gibson [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Paul, I can include this in my 'next' branch if you aren't opposed. I'll have another set of patches going in there today/tomorrow. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fix PCI in Holly device tree
On Thu, Sep 25, 2008 at 08:11:29AM -0400, Josh Boyer wrote: On Thu, 25 Sep 2008 12:39:04 +1000 David Gibson [EMAIL PROTECTED] wrote: The PCI bridge on the Holly board is current incorrectly represented in the device tree. The current device tree node for the PCI bridge sits under the tsi-bridge node. That's not obviously wrong, but the PCI bridge translated some PCI spaces into CPU address ranges which were not translated by the tsi-bridge node. We used to get away with this problem because the PCI bridge discovery code was also buggy, assuming incorrectly that PCI host bridge nodes were always directly under the root bus and treating the translated addresses as raw CPU addresses, rather than parent bus addresses. This has since been fixed, breaking Holly. This could be fixed by adding extra translations to the tsi-bridge node, but this patch instead moves the Holly PCI bridge out of the tsi-bridge node to the root bus. This makes the tsi-bridge node represent only the built-in IO devices in the bridge, with a more-or-less contiguous address range. This is the same convention used on Freescale SoC chips, where the soc node represents only the IMMR region, and the PCI and other bus bridges are separate nodes under the root bus. Signed-off-by: David Gibson [EMAIL PROTECTED] Acked-by: Josh Boyer [EMAIL PROTECTED] Paul, I can include this in my 'next' branch if you aren't opposed. I'll have another set of patches going in there today/tomorrow. Er... on second thought, this actually fixes a regression on Holly. So I'll amend my offer to put it in my 'next' branch to be contingent on you not wanting to get it into 2.6.27 this late. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Li Yang wrote: -subsys_initcall(of_fsl_dma_chan_init); subsys_initcall(of_fsl_dma_init); Not a critical problem. But module_init() are preferred for modules. This was intentional. When compiled as a module, subsys_initcall becomes module_init(). When compiled in-kernel, this code is initialized before most drivers, so it's ready when the drivers are loaded. Acked-by: Li Yang [EMAIL PROTECTED] Thanks. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
purpose of definition of linux,memory-limit property
Can anyone tell me if linux,memory-limit is specified anywhere. and if so where and if not what its intent is? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
docs for various linux, properties in the device tree?
In search our code base we have the following set of properties: linux,boot-cpu linux,boot-display linux,bootx-addr linux,bootx-depth linux,bootx-height linux,bootx-linebytes linux,bootx-width linux,crashkernel-base linux,crashkernel-size linux,drconf-usable-memory linux,htab-base linux,htab-size linux,initrd-end linux,initrd-start linux,iommu-force-on linux,iommu-off linux,kernel-end linux,memory-limit linux,opened linux,pci-assign-all-buses linux,pci-probe-only linux,phandle linux,rtas-base linux,rtas-entry linux,stdout-package linux,stdout-path linux,tce-alloc-end linux,tce-alloc-start linux,tce-base linux,tce-size linux,unit_address linux,usable-memory Some of these are spec'd in booting-with-of. what about the others? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
Li Yang wrote:
On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian [EMAIL PROTECTED] wrote:
The alternative fix can be.
This one is better as 0 is defined as 'invalid irq' for all
architectures. Added linux-ide and Anton to cc.
However, this is not very true. Just git grep #define NO_IRQ and see. It
seems that the NO_IRQ is in transition from (-1) to (0).
I happened to code the same 2 patches as Anton Vorontsov [EMAIL PROTECTED]
had done without knowing his earlier work. I think he was also confused by (-1)
and (0).
- Leo
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 408da30..1f18ad9 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct
of_device *ofdev,
ret = of_irq_to_resource(dn, 0, irq_res);
if (ret == NO_IRQ)
- irq_res.start = irq_res.end = -1;
+ irq_res.start = irq_res.end = 0;
else
irq_res.flags = 0;
I just didn't spend much time to see which is better.
Wang Jian wrote:
Hi,
This patch is to pata_platform.c but at this time, it's powerpc specific
because it can only be triggerred using openfirmware, so I post the patch
here. The patch is against 2.6.26-rc8.
The problem is triggerred when ata device is populated using
pata_of_platform.c, and no irq is assigned (poll mode, such as CF card).
pata_of_platform_probe() parse device tree and
if (ret == NO_IRQ)
irq_res.start = irq_res.end = -1;
Then irq is 0x, not NULL. Probe will fail coz irq can't be
requested.
---
(irq_res-start 0) will be true even when it is (-1). When the device
has no irq, irq_res-start is assigned (-1).
Signed-off-by: Wang Jian [EMAIL PROTECTED]
---
drivers/ata/pata_platform.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index 8f65ad6..b12cd0c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -123,7 +123,7 @@ int __devinit __pata_platform_probe(struct device
*dev,
/*
* And the IRQ
*/
- if (irq_res irq_res-start 0) {
+ if (irq_res irq_res-start != -1) {
irq = irq_res-start;
irq_flags = irq_res-flags;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Fix bugs in fdt_get_path()
The current implementation of fdt_get_path() has a couple of bugs, fixed by this patch. First, contrary to its documentation, on success it returns the length of the node's path, rather than 0. The testcase is correspondingly wrong, and the patch fixes this as well. Second, in some circumstances, it will return -FDT_ERR_BADOFFSET instead of -FDT_ERR_NOSPACE when given insufficient buffer space. Specifically this happens when there is insufficient space even to hold the path's second last component. This behaviour is corrected, and the testcase updated to check it. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_platform struct resource signness fix
On Thu, Sep 25, 2008 at 11:33:35PM +0800, Wang Jian wrote: Li Yang wrote: On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian [EMAIL PROTECTED] wrote: The alternative fix can be. This one is better as 0 is defined as 'invalid irq' for all architectures. Added linux-ide and Anton to cc. However, this is not very true. Just git grep #define NO_IRQ and see. It seems that the NO_IRQ is in transition from (-1) to (0). Yeah, there is a mess, but it gets better as time goes by. The platforms/drivers should be fixed, since 0 is the only invalid VIRQ. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
On Fri, Sep 19, 2008 at 01:46:49PM -0500, Kumar Gala wrote: You are correct we try to avoid this, but than I suggest we do it by family. I think its confusing to show 8610 and 8349 in the same dev tree. I don't think it's confusing (at least, not moreso than picking an arbitrary chip within the same family), if it really is compatible and there is nothing new in the 86xx GPIO that warrants having a common compatible for them. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs
On Fri, Sep 19, 2008 at 05:11:15PM +0200, Peter Korsgaard wrote: Anton This is purposely. We also need support for 8610, and maybe Anton later we'll find another chip with the same unit. So, to not touch Anton the Kconfig for every new chip I just made it PPC32-wide. Other Anton option is to depend on FSL_SOC, but the driver really does not Anton depend on any fsl_soc stuff... Adding another symbol to the Kconfig once it is verified that a new SoC is compatible doesn't seem like a big deal - Figuring out all the knobs we already have is, without having options for stuff that is known to be irrelevant for the SoC. I agree with Anton; it's a lot less of a headache to say no to some unfamiliar kconfig option than it is to hunt around and figure out why you're not being given the option. I'd be OK with depending on FSL_SOC. The other 83xx specific drivers also depend on PPC_83xx. As pointed out above, this isn't 83xx-specific. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 07:22:25AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote: On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote: On Dienstag, 23. September 2008, Juergen Beisert wrote: What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. One should enable the internal USB clock. If done, it works... In 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24. It was removed because some 5200 platform do not use USB and should not enable the internal clock. In general, it is not the kernel's job to configure clocking and pin usage on the chip. Instead, it should be set correctly at power up by U-Boot. Or by the USB host driver :-) I hadn't really wanted to go down this route because the calculation of the clock, or the decision to use an external clock or calculate an internal clock is very board specific. I'll need to take another look to decide if it is reasonable to encode it into the device tree. I tend to thing that drivers should deal with their own clocks. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? Yeah, but in this case the clock can't actually be turned off. It's just a select bit between internal or external clock and a calculation value on the divider. Since it's a one-time board level setup config in a big block of shared chip level registers I'd rather just leave it in the domain of firmware. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote: Benjamin, On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote: On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote: On Dienstag, 23. September 2008, Juergen Beisert wrote: What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. One should enable the internal USB clock. If done, it works... In 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24. It was removed because some 5200 platform do not use USB and should not enable the internal clock. In general, it is not the kernel's job to configure clocking and pin usage on the chip. Instead, it should be set correctly at power up by U-Boot. Or by the USB host driver :-) But how to deal with platform specific things like (in this case) unknown external clock or usage of the internal clock generator (= how to setup the frequency divider)? The external clock would need to be encoded in the device tree. Internal clock would need to read/detect the CDM config and make a decision based on that. Certainly possible, but I just don't think that it is really important. (And even if it is, I think it should be done in common platform setup code, not the driver, because it is very MPC5200 SoC specific). g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] GPIO-Watchdog in devicetree
On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
For example:
/ {
model = pengutronix,super-sexy-board;
#address-cells = 1;
#size-cells = 1;
super-sexy-board,watchdog-gpio = gpio_simple 19 0;
...
}
Why as a property of the root node, and not as a node with a very
specific compatible property?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 12:57 PM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote: Benjamin, On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote: On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote: On Dienstag, 23. September 2008, Juergen Beisert wrote: What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. One should enable the internal USB clock. If done, it works... In 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24. It was removed because some 5200 platform do not use USB and should not enable the internal clock. In general, it is not the kernel's job to configure clocking and pin usage on the chip. Instead, it should be set correctly at power up by U-Boot. I got the attached diagram from Freescale on how to program the divider. It's not in the user manual. Freescale is recommending a 33.333Mhz crystal for the mpc5200 now. If you use 33.Mhz you won't be able to set a 48Mhz internal clock. Closest you can get is 48.4848Mhz. Sticking with a 33Mhz crystal allow an accurate 48Mhz clock. Clocking USB at the wrong clock rate will make some devices not function or get errors. The new mpc5200 datasheet has removed the option of using a 16x multiplier on a 33Mhz crystal and running the core at 528Mhz. The new datasheet only allows up to 400Mhz for the core. Anyone know what is going on? -- Jon Smirl [EMAIL PROTECTED] fractinal_div.pdf Description: Adobe PDF document ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] GPIO-Watchdog in devicetree
On Thu, Sep 25, 2008 at 11:59 AM, Scott Wood [EMAIL PROTECTED] wrote:
On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
For example:
/ {
model = pengutronix,super-sexy-board;
#address-cells = 1;
#size-cells = 1;
super-sexy-board,watchdog-gpio = gpio_simple 19 0;
...
}
Why as a property of the root node, and not as a node with a very
specific compatible property?
Because the root node is the only logical board-level node we have
right now. However, I'm not deeply committed to this approach. The
only question I have about putting it in another node is choosing the
parent node. I don't think it fits to make it a child of the SoC node
or any other bus node.
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
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 12:02 PM, Jon Smirl [EMAIL PROTECTED] wrote: The new mpc5200 datasheet has removed the option of using a 16x multiplier on a 33Mhz crystal and running the core at 528Mhz. The new datasheet only allows up to 400Mhz for the core. Anyone know what is going on? You mean other than the 5200b being a slighly dodgy chip to work with? -- 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
Re: [RFC] powerpc/boot: compare _start against ei.loadsize instead ei.memsize
On Tue, Sep 23, 2008 at 10:38:57PM +0200, Sebastian Siewior wrote: My current (working) solution is to move cuImage from 4 MiB to 8 MiB. Something similar has been done for pSeries in 9b09c6d powerpc: Change the default link address for pSeries zImage kernels. Would it be appropriate to move initial address to 64 MiB as the default loading address or do we have here some boards which have only 64 MiB of memory? Does someone have another idea? We have at least one supported board with only 8 MiB. Some options: 1. Dynamically relocate the wrapper to the top of RAM. 2. Relink based on the uncompressed size of the image bing wrapped. 3. Try to fall back on regular malloc() rather than fail if there's no vmlinux_alloc() and there's no room at zero. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] GPIO-Watchdog in devicetree
Grant Likely wrote:
On Thu, Sep 25, 2008 at 11:59 AM, Scott Wood [EMAIL PROTECTED] wrote:
On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
For example:
/ {
model = pengutronix,super-sexy-board;
#address-cells = 1;
#size-cells = 1;
super-sexy-board,watchdog-gpio = gpio_simple 19 0;
...
}
Why as a property of the root node, and not as a node with a very
specific compatible property?
Because the root node is the only logical board-level node we have
right now. However, I'm not deeply committed to this approach. The
only question I have about putting it in another node is choosing the
parent node. I don't think it fits to make it a child of the SoC node
or any other bus node.
A child of the gpio controller node seems most logical, though a child
of the root node would be OK. It was the freefloating property that
struck me as a little odd.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 0/2] QE Pin Multiplexing API
Here is the sketch, only for RFC. It is tested to work, but there could be silly thinkos anyway. I'll review the changes once again later... Anyhow... David, is this approach looks ok? Or I'm hopeless..? ;-) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] OF: new helper: of_parse_phandles_with_args()
Factored out of of_get_gpio(). Will be used by the QE pin multiplexing
functions (they need to parse the gpios = too).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/of/base.c | 111
drivers/of/gpio.c | 77 +++
include/linux/of.h |3 +
3 files changed, 130 insertions(+), 61 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..51e0fce 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -473,3 +473,114 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
}
EXPORT_SYMBOL_GPL(of_modalias_node);
+/**
+ * of_parse_phandles_with_args - Find a node pointed by phandle in a list
+ * @np:pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name:property name that specifies phandles' arguments count
+ * @index: index of a phandle to parse out
+ * @out_node: pointer to device_node struct pointer (will be filled)
+ * @out_args: pointer to arguments pointer (will be filled)
+ *
+ * This function is useful to parse lists of phandles and their arguments.
+ * Returns 0 on success and fills out_node and out_args, on error returns
+ * appropriate errno value.
+ *
+ * Example:
+ *
+ * phandle1: node1 {
+ * #list-cells = 2;
+ * }
+ *
+ * phandle2: node2 {
+ * #list-cells = 1;
+ * }
+ *
+ * node3 {
+ * list = phandle1 1 2 phandle2 3;
+ * }
+ *
+ * To get a device_node of the `node2' you may call this:
+ * of_parse_phandles_with_args(node3, list, #list-cells, 2, node2, args);
+ */
+int of_parse_phandles_with_args(struct device_node *np, const char *list_name,
+ const char *cells_name, int index,
+ struct device_node **out_node,
+ const void **out_args)
+{
+ int ret = -EINVAL;
+ const u32 *list;
+ u32 list_cells;
+ int size;
+ int i;
+ int cur_index = 0;
+ struct device_node *node;
+ const void *args;
+
+ list = of_get_property(np, list_name, size);
+ if (!list) {
+ ret = -ENOENT;
+ goto err0;
+ }
+ list_cells = size / sizeof(u32);
+
+ for (i = 0; i list_cells; cur_index++) {
+ const u32 *cells;
+ const phandle *phandle;
+
+ phandle = list + i;
+ args = phandle + 1;
+
+ /* one cell hole in the list = ; */
+ if (!*phandle) {
+ if (cur_index == index)
+ return -ENOENT;
+ i++;
+ continue;
+ }
+
+ node = of_find_node_by_phandle(*phandle);
+ if (!node) {
+ pr_debug(%s: could not find phandle\n,
+np-full_name);
+ goto err0;
+ }
+
+ cells = of_get_property(node, cells_name, size);
+ if (!cells || size != sizeof(*cells)) {
+ pr_debug(%s: could not get %s for %s\n,
+np-full_name, cells_name, node-full_name);
+ goto err1;
+ }
+
+ /* Next phandle is at phandle cells + #cells */
+ i += sizeof(*phandle) / sizeof(u32) + *cells;
+ if (i = list_cells + 1) {
+ pr_debug(%s: insufficient arguments length\n,
+np-full_name);
+ goto err1;
+ }
+
+ if (cur_index == index)
+ break;
+
+ node = NULL;
+ of_node_put(node);
+ }
+
+ if (!node) {
+ ret = -ENOENT;
+ goto err0;
+ }
+
+ *out_node = node;
+ *out_args = args;
+
+ return 0;
+err1:
+ of_node_put(node);
+err0:
+ pr_debug(%s exited with status %d\n, __func__, ret);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_parse_phandles_with_args);
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 1c9cab8..6d6e4c0 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -28,78 +28,33 @@
*/
int of_get_gpio(struct device_node *np, int index)
{
- int ret = -EINVAL;
+ int ret;
struct device_node *gc;
struct of_gpio_chip *of_gc = NULL;
int size;
- const u32 *gpios;
- u32 nr_cells;
- int i;
const void *gpio_spec;
const u32 *gpio_cells;
- int gpio_index = 0;
- gpios = of_get_property(np, gpios, size);
- if (!gpios) {
- ret = -ENOENT;
+ ret = of_parse_phandles_with_args(np, gpios, #gpio-cells, index,
+ gc, gpio_spec);
+ if (ret) {
+ pr_debug(%s: can't parse gpios property\n, __func__);
[PATCH 2/2] powerpc/QE: implement QE Pin Multiplexing API
Today the API is still based on a fact that QE gpio controllers
are registered. If they aren't, the API won't work (gracefully
though).
There is one caveat though: if anybody occupied the node-data
before us, or overwrote it, then bad things will happen. Luckily
this is all in the platform code that we fully control, so this
should never happen.
I could implement more checks (for example we could create a list
of successfully registered QE controllers, and compare the node-data
in the qe_pin_get()), but this is unneeded if nobody is going to do
silly things behind our back.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
p.s. I should probably change qe_pin_get() to allocate and return
struct qe_pin instead of accepting already allocated one.
arch/powerpc/include/asm/qe.h | 20 +
arch/powerpc/sysdev/qe_lib/gpio.c | 167 +
2 files changed, 187 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index edee15d..3f15b2f 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -112,6 +112,26 @@ extern int par_io_config_pin(u8 port, u8 pin, int dir, int
open_drain,
int assignment, int has_irq);
extern int par_io_data_set(u8 port, u8 pin, u8 val);
+/*
+ * Pin multiplexing functions.
+ */
+struct qe_gpio_chip;
+
+struct qe_pin {
+ /*
+* The qe_gpio_chip name is unfortunate, we should change that to
+* something like qe_pio_controller. Someday.
+*/
+ struct qe_gpio_chip *controller;
+ int num;
+};
+
+extern int qe_pin_get(struct device_node *np, int index,
+ struct qe_pin *qe_pin);
+extern void qe_pin_put(struct qe_pin *qe_pin);
+extern void qe_pin_set_gpio(struct qe_pin *qe_pin);
+extern void qe_pin_set_dedicated(struct qe_pin *pin);
+
/* QE internal API */
int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
enum qe_clock qe_clock_source(const char *source);
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
index 8e5a0bc..f0d504b 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -24,8 +24,14 @@ struct qe_gpio_chip {
struct of_mm_gpio_chip mm_gc;
spinlock_t lock;
+#define QE_PIN_REQUESTED 0
+ unsigned long pin_flags[QE_PIO_PINS];
+
/* shadowed data register to clear/set bits safely */
u32 cpdata;
+
+ /* saved_regs used to restore dedicated functions */
+ struct qe_pio_regs saved_regs;
};
static inline struct qe_gpio_chip *
@@ -40,6 +46,12 @@ static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
struct qe_pio_regs __iomem *regs = mm_gc-regs;
qe_gc-cpdata = in_be32(regs-cpdata);
+ qe_gc-saved_regs.cpdata = qe_gc-cpdata;
+ qe_gc-saved_regs.cpdir1 = in_be32(regs-cpdir1);
+ qe_gc-saved_regs.cpdir2 = in_be32(regs-cpdir2);
+ qe_gc-saved_regs.cppar1 = in_be32(regs-cppar1);
+ qe_gc-saved_regs.cppar2 = in_be32(regs-cppar2);
+ qe_gc-saved_regs.cpodr = in_be32(regs-cpodr);
}
static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
@@ -103,6 +115,161 @@ static int qe_gpio_dir_out(struct gpio_chip *gc, unsigned
int gpio, int val)
return 0;
}
+/**
+ * qe_pin_get - Get a QE pin from the device tree
+ * @np:device node to get a pin from
+ * @index: index of a pin in the device tree
+ * @qe_pin:pointer to the allocated qe_pin structure
+ *
+ * This function finds a pin from the device in the device tree and fills
+ * the qe_pin structure so that you could use it with the rest of QE Pin
+ * Multiplexing API.
+ */
+int qe_pin_get(struct device_node *np, int index, struct qe_pin *qe_pin)
+{
+ struct device_node *gc;
+ struct of_gpio_chip *of_gc = NULL;
+ struct of_mm_gpio_chip *mm_gc;
+ struct qe_gpio_chip *qe_gc;
+ int ret;
+ int size;
+ const void *gpio_spec;
+ const u32 *gpio_cells;
+ unsigned long flags;
+
+ ret = of_parse_phandles_with_args(np, gpios, #gpio-cells, index,
+ gc, gpio_spec);
+ if (ret) {
+ pr_debug(%s: can't parse gpios property\n, __func__);
+ return ret;
+ }
+
+ if (!of_device_is_compatible(gc, fsl,mpc8323-qe-pario-bank)) {
+ pr_debug(%s: tried to get a non-qe pin\n, __func__);
+ ret = -EINVAL;
+ goto err1;
+ }
+
+ of_gc = gc-data;
+ if (!of_gc) {
+ pr_debug(%s: gpio controller %s isn't registered\n,
+np-full_name, gc-full_name);
+ goto err1;
+ }
+
+ gpio_cells = of_get_property(gc, #gpio-cells, size);
+ if (!gpio_cells || size != sizeof(*gpio_cells) ||
+ *gpio_cells != of_gc-gpio_cells) {
+ pr_debug(%s: wrong #gpio-cells for
take in count O_NONBLOCK flag for rtas log
rtas_log_read() doesn't check file flags for O_NONBLOCK and blocks
non-blocking reader of /proc/ppc64/rtas/error_log if there's no data
available. This patch fixes the problem.
Signed-off-by: Vitaly Mayatskikh [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/pseries/rtasd.c
b/arch/powerpc/platforms/pseries/rtasd.c
index c9ffd8c..4f76e3b 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -295,19 +295,29 @@ static ssize_t rtas_log_read(struct file * file, char
__user * buf,
if (!tmp)
return -ENOMEM;
-
spin_lock_irqsave(rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 logging_enabled)
- nvram_clear_error_log();
- spin_unlock_irqrestore(rtasd_log_lock, s);
+ while (rtas_log_size == 0) {
+ if (file-f_flags O_NONBLOCK) {
+ spin_unlock_irqrestore(rtasd_log_lock, s);
+ error = -EAGAIN;
+ goto out;
+ }
+ if (!logging_enabled) {
+ spin_unlock_irqrestore(rtasd_log_lock, s);
+ error = -ENODATA;
+ goto out;
+ } else
+ nvram_clear_error_log();
- error = wait_event_interruptible(rtas_log_wait, rtas_log_size);
- if (error)
- goto out;
+ spin_unlock_irqrestore(rtasd_log_lock, s);
+ error = wait_event_interruptible(rtas_log_wait, rtas_log_size);
+ if (error)
+ goto out;
+ spin_lock_irqsave(rtasd_log_lock, s);
+ }
- spin_lock_irqsave(rtasd_log_lock, s);
offset = rtas_error_log_buffer_max * (rtas_log_start LOG_NUMBER_MASK);
memcpy(tmp, rtas_log_buf[offset], count);
--
wbr, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
On Thu, Sep 25, 2008 at 08:54:30AM -0500, Timur Tabi wrote: Li Yang wrote: -subsys_initcall(of_fsl_dma_chan_init); subsys_initcall(of_fsl_dma_init); Not a critical problem. But module_init() are preferred for modules. This was intentional. When compiled as a module, subsys_initcall becomes module_init(). When compiled in-kernel, this code is initialized before most drivers, so it's ready when the drivers are loaded. If there's a dependency there, how will it work when this is built as a module? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
On Thu, Sep 25, 2008 at 1:40 PM, Scott Wood [EMAIL PROTECTED] wrote: If there's a dependency there, how will it work when this is built as a module? There are no dependencies. fsldma registers with the DMA engine, which is always built in-kernel. The DMA engine is what handles linking DMA clients to DMA drivers. The DMA clients get a callback whenever a DMA driver registers with the DMA engine. If the DMA driver is already registered when the client registers, then the client will get a callback immediately after it registers. I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are loaded/initialized and register. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Cleanup 32/64 bit syscall int sign ext.
On Thu, Sep 25, 2008 at 05:01:36PM +1000, Benjamin Herrenschmidt wrote: +#define XGLUE(a,b) a##b +#define GLUE(a,b) XGLUE(a,b) GLUE() doesn't appear to be used. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Timur Tabi wrote: There are no dependencies. fsldma registers with the DMA engine, which is always built in-kernel. The DMA engine is what handles linking DMA clients to DMA drivers. The DMA clients get a callback whenever a DMA driver registers with the DMA engine. If the DMA driver is already registered when the client registers, then the client will get a callback immediately after it registers. I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are loaded/initialized and register. If there's no dependency, why does it matter whether fsldma is already present? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Scott Wood wrote: I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are loaded/initialized and register. If there's no dependency, why does it matter whether fsldma is already present? Re-read my explanation, please. Technically, it doesn't *matter* in that nothing will break, but so what? It's nicer if the DMA driver is already available when the client drivers load, so that they can use the DMA facilities right away. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powerpc/boot: compare _start against ei.loadsize instead ei.memsize
- Original Message Follows -
From: Sebastian Siewior [EMAIL PROTECTED]
To: Milton Miller [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org, David Gibson
[EMAIL PROTECTED], Grant Likely
[EMAIL PROTECTED]
Subject: Re: [RFC] powerpc/boot: compare _start against
ei.loadsize instead ei.memsize
Date: Thu, 25 Sep 2008 12:21:41 +0200
Milton Miller wrote:
My current (working) solution is to move cuImage from 4
MiB to 8 MiB. Something similar has been done for
pSeries in 9b09c6d powerpc: Change the default link
address for pSeries zImage kernels. Would it be
appropriate to move initial address to 64 MiB as the
default loading address or do we have here some boards
which have only 64 MiB of memory?
I think there are some boards that have even less
(8xx?). Is the link address a wrapper option yet?
Nope. The wrapper script distinguishes between platforms.
Default is 4MiB, pSeries has 64MiB, coff does 5MiB and
the PS3 has other magic.
ok. I think some of the embedded boards have less than
64M. On the other hand, my (64 bit with drivers) kernel
static load is over 8M (close to 9). The needed size
is obviously configuration dependent.
There has been talk of reading the size to determine a
suitable address, but its all talk so far.
There are two approaches: one is to make it self-
configuring to the minimum for the image you build,
the other other is to make it a command line option
to the wrapper and then put platform selections in
Kconfig, hidden with embedded for most people.
Or we can change the default to say 16M and hope its
enough but not too much for most and not can decode
the platforms for the rest.
We could also add a link time check, but we need to
know which platforms, like the OF ones, have a non-
default vmlinux_alloc and don't put the kernel in
place directly (and hence need to skip the check).
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -56,7 +56,7 @@ static struct addr_range
prep_kernel(void) if (platform_ops.vmlinux_alloc)
{ addr =
platform_ops.vmlinux_alloc(ei.memsize); } else {
-if ((unsigned long)_start ei.memsize)
+if ((unsigned long)_start ei.loadsize)
I think this needs to be a two part test (add
appropriate
casts): _start ei.loadsize || _end ei.memsize
.. and a comment explaining why.
okay.
We could do better if we kept allocating more memory
until we got above it, but the current code has no such
provision. (prpmc2800, or one of those, actually
decompresses the header to peek at memsize before
starting the simple_alloc code).
I don't thing I can follow. Do you want to move the
bootwrapper code above the limit and recall it?
I'm saying the code could be changed to do better, but
am not currently requesting any change.
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Timur Tabi wrote: Scott Wood wrote: I chose subsys_initcall() to increase the probability that fsldma is already present when DMA clients are loaded/initialized and register. If there's no dependency, why does it matter whether fsldma is already present? Re-read my explanation, please. I read it just fine the first time. Technically, it doesn't *matter* in that nothing will break, but so what? It's nicer if the DMA driver is already available when the client drivers load, so that they can use the DMA facilities right away. It's not nicer to people reading the code and wondering why, or to people who use it as a module and execute less-well-tested code paths, and I doubt it's a significant addition to boot time to do things in the normal way. I'm not particularly worried about the code going on strike because we're not being nice to it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] remove bogus ppc_select syscall
I have tested the provided patch on PPC32 with little modifications.
Test passed on the PPC32.
Modification to Arnd's Patch:
In systbl.h you have changed
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(sys_ni_syscall)
That has to be
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(ni_syscall)
Which failed the kernel build. It's a typo from your side I think.
After fixing it build went fine.
Signed-off-by: Halesh Sadashiv [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
diff --git a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
index e07d0c7..46107cc 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -92,7 +92,7 @@
#define __NR_settimeofday 79
#define __NR_getgroups 80
#define __NR_setgroups 81
-#define __NR_select 82
+/* Number 82 was the old (pre-1.3.x) select */
#define __NR_symlink83
#define __NR_oldlstat 84
#define __NR_readlink 85
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch/powerpc/include/asm/systbl.h
index f6cc7a4..5a69b32 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -85,7 +85,7 @@ COMPAT_SYS_SPU(gettimeofday)
COMPAT_SYS_SPU(settimeofday)
COMPAT_SYS_SPU(getgroups)
COMPAT_SYS_SPU(setgroups)
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(ni_syscall)
SYSCALL_SPU(symlink)
OLDSYS(lstat)
COMPAT_SYS_SPU(readlink)
@@ -145,7 +145,7 @@ SYSCALL_SPU(setfsuid)
SYSCALL_SPU(setfsgid)
SYSCALL_SPU(llseek)
COMPAT_SYS_SPU(getdents)
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
SYSCALL_SPU(flock)
SYSCALL_SPU(msync)
COMPAT_SYS_SPU(readv)
diff --git a/arch/powerpc/kernel/syscalls.c
b/arch/powerpc/kernel/syscalls.c index c04832c..c2e6a74 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -183,31 +183,6 @@ unsigned long sys_mmap(unsigned long addr, size_t
len,
return do_mmap2(addr, len, prot, flags, fd, offset, PAGE_SHIFT);
}
-#ifdef CONFIG_PPC32
-/*
- * Due to some executables calling the wrong select we sometimes
- * get wrong args. This determines how the args are being passed
- * (a single ptr to them all args passed) then calls
- * sys_select() with the appropriate args. -- Cort
- */
-int
-ppc_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set
__user *exp, struct timeval __user *tvp) -{
- if ( (unsigned long)n = 4096 )
- {
- unsigned long __user *buffer = (unsigned long __user
*)n;
- if (!access_ok(VERIFY_READ, buffer, 5*sizeof(unsigned
long))
- || __get_user(n, buffer)
- || __get_user(inp, ((fd_set __user * __user
*)(buffer+1)))
- || __get_user(outp, ((fd_set __user * __user
*)(buffer+2)))
- || __get_user(exp, ((fd_set __user * __user
*)(buffer+3)))
- || __get_user(tvp, ((struct timeval __user * __user
*)(buffer+4
- return -EFAULT;
- }
- return sys_select(n, inp, outp, exp, tvp);
-}
-#endif
-
#ifdef CONFIG_PPC64
long ppc64_personality(unsigned long personality) {
Thanks
Halesh
-Original Message-
From: Arnd Bergmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 12:09 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Sadashiiv, Halesh;
linuxppc-dev@ozlabs.org
Subject: [PATCH] remove bogus ppc_select syscall
The ppc_select function was introduced in linux-2.3.48 in order to
support
code confusing the legacy select() calling convention with the standard
one.
Even 11 years ago, all correctly built code should not have done this
and
could have easily been phased out. Nothing that was compiled later
should
actually try to use the old_select interface, and it would have been
broken
already on all ppc64 kernels with the syscall emulation layer.
This patch brings the 32 bit compat ABI and the native 32 bit ABI for
powerpc into a consistent state, by removing support for both the
old_select system call number and the handler for it.
The bug report triggering this came from Halesh Sadashiiv
[EMAIL PROTECTED], who discovered that the 32 bit
implementation of ppc_select would in case of a negative number
of file descriptors incorrectly return -EFAULT instead of -EINVAL.
There seems to be no way to fix this problem in a way that would
keep broken pre-1997 binaries running.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Cc: Halesh Sadashiiv [EMAIL PROTECTED]
---
Halesh, please test this patch to make sure it fixes the problem
you reported. I do not have a ppc32 machine I can try this on.
diff --git a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
index e07d0c7..46107cc 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@
RE: [PATCH] remove bogus ppc_select syscall
One more thing noticed while building the kernel, it gave warning
kernel/power/Kconfig:97:warning: 'select' used by config symbol
'PM_SLEEP_SMP' refers to undefined symbol 'HOTPLUG_CPU'
Thanks
Halesh
-Original Message-
From: Sadashiiv, Halesh
Sent: Wednesday, September 24, 2008 2:42 PM
To: 'Arnd Bergmann'; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: RE: [PATCH] remove bogus ppc_select syscall
I have tested the provided patch on PPC32 with little modifications.
Test passed on the PPC32.
Modification to Arnd's Patch:
In systbl.h you have changed
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(sys_ni_syscall)
That has to be
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(ni_syscall)
Which failed the kernel build. It's a typo from your side I think.
After fixing it build went fine.
Signed-off-by: Halesh Sadashiv [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
diff --git a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
index e07d0c7..46107cc 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -92,7 +92,7 @@
#define __NR_settimeofday 79
#define __NR_getgroups 80
#define __NR_setgroups 81
-#define __NR_select 82
+/* Number 82 was the old (pre-1.3.x) select */
#define __NR_symlink83
#define __NR_oldlstat 84
#define __NR_readlink 85
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch/powerpc/include/asm/systbl.h
index f6cc7a4..5a69b32 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -85,7 +85,7 @@ COMPAT_SYS_SPU(gettimeofday)
COMPAT_SYS_SPU(settimeofday)
COMPAT_SYS_SPU(getgroups)
COMPAT_SYS_SPU(setgroups)
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(ni_syscall)
SYSCALL_SPU(symlink)
OLDSYS(lstat)
COMPAT_SYS_SPU(readlink)
@@ -145,7 +145,7 @@ SYSCALL_SPU(setfsuid)
SYSCALL_SPU(setfsgid)
SYSCALL_SPU(llseek)
COMPAT_SYS_SPU(getdents)
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
SYSCALL_SPU(flock)
SYSCALL_SPU(msync)
COMPAT_SYS_SPU(readv)
diff --git a/arch/powerpc/kernel/syscalls.c
b/arch/powerpc/kernel/syscalls.c index c04832c..c2e6a74 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -183,31 +183,6 @@ unsigned long sys_mmap(unsigned long addr, size_t
len,
return do_mmap2(addr, len, prot, flags, fd, offset, PAGE_SHIFT);
}
-#ifdef CONFIG_PPC32
-/*
- * Due to some executables calling the wrong select we sometimes
- * get wrong args. This determines how the args are being passed
- * (a single ptr to them all args passed) then calls
- * sys_select() with the appropriate args. -- Cort
- */
-int
-ppc_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set
__user
*exp, struct timeval __user *tvp) -{
- if ( (unsigned long)n = 4096 )
- {
- unsigned long __user *buffer = (unsigned long __user
*)n;
- if (!access_ok(VERIFY_READ, buffer, 5*sizeof(unsigned
long))
- || __get_user(n, buffer)
- || __get_user(inp, ((fd_set __user * __user
*)(buffer+1)))
- || __get_user(outp, ((fd_set __user * __user
*)(buffer+2)))
- || __get_user(exp, ((fd_set __user * __user
*)(buffer+3)))
- || __get_user(tvp, ((struct timeval __user * __user
*)(buffer+4
- return -EFAULT;
- }
- return sys_select(n, inp, outp, exp, tvp);
-}
-#endif
-
#ifdef CONFIG_PPC64
long ppc64_personality(unsigned long personality) {
Thanks
Halesh
-Original Message-
From: Arnd Bergmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 12:09 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Sadashiiv, Halesh;
linuxppc-dev@ozlabs.org
Subject: [PATCH] remove bogus ppc_select syscall
The ppc_select function was introduced in linux-2.3.48 in order to
support
code confusing the legacy select() calling convention with the
standard
one.
Even 11 years ago, all correctly built code should not have done this
and
could have easily been phased out. Nothing that was compiled later
should
actually try to use the old_select interface, and it would have been
broken
already on all ppc64 kernels with the syscall emulation layer.
This patch brings the 32 bit compat ABI and the native 32 bit ABI for
powerpc into a consistent state, by removing support for both the
old_select system call number and the handler for it.
The bug report triggering this came from Halesh Sadashiiv
[EMAIL PROTECTED], who discovered that the 32 bit
implementation of ppc_select would in case of a negative number
of file descriptors incorrectly return -EFAULT instead of -EINVAL.
There seems to be no way to fix this problem in a way that would
keep broken
Re: MPC5200 PCI interrupt routing
I hadn't really wanted to go down this route because the calculation of the clock, or the decision to use an external clock or calculate an internal clock is very board specific. I'll need to take another look to decide if it is reasonable to encode it into the device tree. Could be done using the feature call mechanism that I have for powermac... though using a proper clock framework might be better in the long run. I tend to thing that drivers should deal with their own clocks. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? Yeah, but in this case the clock can't actually be turned off. It's just a select bit between internal or external clock and a calculation value on the divider. Since it's a one-time board level setup config in a big block of shared chip level registers I'd rather just leave it in the domain of firmware. Ah ok, makes more sense to keep it there then, or in platform init. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: Cleanup 32/64 bit syscall int sign ext.
On Thu, 2008-09-25 at 13:52 -0500, Scott Wood wrote: On Thu, Sep 25, 2008 at 05:01:36PM +1000, Benjamin Herrenschmidt wrote: +#define XGLUE(a,b) a##b +#define GLUE(a,b) XGLUE(a,b) GLUE() doesn't appear to be used. Yup, obsolete remains from an earlier variant. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powerpc/boot: compare _start against ei.loadsize instead ei.memsize
* Milton Miller | 2008-09-23 20:46:18 [-0500]:
On Wed Sep 24 at about 06:38:57 EST in 2008, Sebastian Siewior wrote:
My mylinux binary incl. bss is ~5 MiB without bss less than 4 MiB.
Therefore I though that I could replace ei.memsize with ei.loadsize. It
didn't work. I'm not sure why it did not work but I guess that the
memset() of bss in the initial kernel code overwrote the cuimage code
which is required for some reason. Maybe some device-tree callbacks.
probably because the bss extended beyond the cuboot _end to include
where your device tree was copied (just a malloc and we start
simple_malloc at the boot _end on most platforms).
Right, the bss section went past _dtb_start, moving the device tree
helps.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
arch/powerpc/boot/libfdt-wrapper.c | 16
arch/powerpc/boot/main.c | 12 +++-
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/libfdt-wrapper.c
b/arch/powerpc/boot/libfdt-wrapper.c
index c541fd8..1daa73f 100644
--- a/arch/powerpc/boot/libfdt-wrapper.c
+++ b/arch/powerpc/boot/libfdt-wrapper.c
@@ -165,6 +165,7 @@ static unsigned long fdt_wrapper_finalize(void)
void fdt_init(void *blob)
{
int err;
+ int bufsize;
dt_ops.finddevice = fdt_wrapper_finddevice;
dt_ops.getprop = fdt_wrapper_getprop;
@@ -178,16 +179,15 @@ void fdt_init(void *blob)
/* Make sure the dt blob is the right version and so forth */
fdt = blob;
- err = fdt_open_into(fdt, fdt, fdt_totalsize(blob));
- if (err == -FDT_ERR_NOSPACE) {
- int bufsize = fdt_totalsize(fdt) + 4;
- buf = malloc(bufsize);
- err = fdt_open_into(fdt, buf, bufsize);
- }
+ bufsize = fdt_totalsize(fdt) + 4;
+ buf = malloc(bufsize);
+ if(!buf)
+ fatal(malloc failed. can't relocate the device tree\n\r);
+
+ err = fdt_open_into(fdt, buf, bufsize);
if (err != 0)
fatal(fdt_init(): %s\n\r, fdt_strerror(err));
- if (buf)
- fdt = buf;
+ fdt = buf;
}
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index 45a81c3..f5fcd14 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -56,9 +56,19 @@ static struct addr_range prep_kernel(void *chosen)
if (platform_ops.vmlinux_alloc) {
addr = platform_ops.vmlinux_alloc(ei.memsize);
} else {
+ /*
+* Check if the kernel image (without bss) would overwrite the
+* bootwrapper. The device tree has been moved in fdt_init()
+* to an area allocated with malloc() (somewhere past _end).
+*/
if ((unsigned long)_start ei.loadsize)
fatal(Insufficient memory for kernel at address 0!
- (_start=%p)\n\r, _start);
+ (_start=%p, uncomressed size=%08x)\n\r,
+ _start, ei.loadsize);
+
+ if ((unsigned long)_end ei.memsize)
+ fatal(The final kernel image would overwrite the
+ device tree\n\r);
}
/* Finally, gunzip the kernel */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
(I trimmed the cc list for the implementation discussion). On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller [EMAIL PROTECTED] wrote: On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote: Hi Milton, On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller [EMAIL PROTECTED] wrote: On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue wrote: When entering the low level handler, level sensitive interrupts are masked, then eio'd in interrupt context and then unmasked at the end of hardirq processing. That's fine as any interrupt comming in-between will still be processed since the kernel replays those pending interrupts. Is this to generate some kind of software managed nesting and priority of the hardware level interrupts? No, not really. This is only to be sure to not miss interrupts coming from the same source that were received during threaded hardirq processing. Some instrumentation showed that it never seems to happen in the eHEA interrupt case, so I think we can forget this aspect. I don't trust the interrupt can never happen during hea hardirq, because I think there will be a race between their rearming the next interrupt and the unmask being called. So do I, it was just to make sure I was not hit by another interrupt while handling the previous one and thus reduce the number of hypothesis. I sure do not say that it cannot happen, just that that path is not taken when I have the eHEA hang. I was trying to understand why the mask and early eoi, but I guess its to handle other more limited interrupt controllers where the interrupts stack in hardware instead of software. Also, the problem only manifests with the eHEA RX interrupt. For example, the IBM Power Raid (ipr) SCSI exhibits absolutely no problem under an RT kernel. From this I conclude that: IPR - PCI - XICS is OK eHEA - IBMEBUS - XICS is broken with hardirq preemption. I also checked that forcing the eHEA interrupt to take the non threaded path does work. For a long period of time, XICS dealt only with level interrupts.First Micro Channel, and later PCI buses. The IPI is made level by software conventions. Recently, EHCA, EHEA, and MSI interrupts were added which by their nature are edge based. The logic that converts those interrupts to the XICS layer is responsible for the resend when no cpu can accept them, but not to retrigger after an EOI. OK Here is a side by side comparison of the fasteoi flow with and without hardirq threading (sorry it's a bit wide) (removed) the non-threaded flow does (in interrupt context): mask Whoops, my bad, in the non threaded case, there's no mask at all, only an unmask+eoi at the end, maybe that's an oversight! No, not an oversight. The point is, don't mask/unmask between ack/eoi while handling the interrupt. For many irq controllers, the eoi must be done from the same cpu, hence the mask and eoi before actually handling the interrupt in the general case. Its a feature of xics that we don't have to play that game, but can do the cpu and device eoi separately. handle interrupt unmask eoi the threaded flow does: mask eoi handle interrupt unmask If I remove the mask() call, then the eHEA is no longer hanging. Hmm, I guess I'm confused. You are saying the irq does not appear if it occurs while it is masked? Looks like it is, but I cannot say for sure, the only observable effect is that I do not get any more interrupts coming from the eHEA. (removed features of xics) That may be, but I'm only looking at the code (read no specifications at hand) and it looks like a black box to me. PowerPC External Interrupt Architecture is defined in appendix A of Power.org Standard for Power Architecture Platform Requirements (Workstation, Server), available to Power.org members. The developer-level membership in Power.org is free. (see www.power.org). That said, it likely won't mention the eHEA in enough detail to note that the interrupt gets cleared on unmask. On the other hand, I have actually seen the source to implementations of the xics logic, so I have a very good understanding of it (and know of a few implementation features, shall we say). The path lengh for mask and unmask is always VERY slow and single threaded global lock and single context in xics. It is designed and tuned to run at driver startup and shutdown (and adapter reset and reinitalize during pci error processing), not during normal irq processing. Now, that is quite interesting then. Those mask() and unmask() should then be called shutdown() and startup() and not at each interrupt or am I misunderstanding you. Basically, yes. but linux likes to let drivers mask at other times, and that
Re: [RFC] GPIO-Watchdog in devicetree
On Mon, Sep 22, 2008 at 09:43:57PM +0200, Wolfram Sang wrote:
Hello all,
I understood that the device-tree is for describing hardware and should
not contain driver specific information. I have problems drawing this
line right now. I made a driver for watchdogs which are pinged by
toggling a gpio. Currently the device-tree entry looks like this:
[EMAIL PROTECTED] {
compatible = gpio-watchdog;
gpios = gpio_simple 19 0;
};
This certainly isn't right. The unit address should be based on the
'reg' property. If there's no 'reg' property, there should be no unit
address.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] GPIO-Watchdog in devicetree
On Thu, Sep 25, 2008 at 01:21:23PM -0500, Scott Wood wrote:
Grant Likely wrote:
On Thu, Sep 25, 2008 at 11:59 AM, Scott Wood [EMAIL PROTECTED] wrote:
On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
For example:
/ {
model = pengutronix,super-sexy-board;
#address-cells = 1;
#size-cells = 1;
super-sexy-board,watchdog-gpio = gpio_simple 19 0;
...
}
Why as a property of the root node, and not as a node with a very
specific compatible property?
Because the root node is the only logical board-level node we have
right now. However, I'm not deeply committed to this approach. The
only question I have about putting it in another node is choosing the
parent node. I don't think it fits to make it a child of the SoC node
or any other bus node.
A child of the gpio controller node seems most logical, though a child
of the root node would be OK. It was the freefloating property that
struck me as a little odd.
I concur.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
