[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
@@ -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(sys_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)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IRQ2-4 number to use on mpc83xx?
On Tue, 2008-09-23 at 22:18 +0200, Joakim Tjernlund wrote: On Tue, 2008-09-23 at 13:08 +0200, Joakim Tjernlund wrote: On Tue, 2008-09-23 at 11:08 +0200, Andre Schwarz wrote: I can only tell how I do on MPC834x : Table 8-6. IVEC/CVEC/MVEC Field Definition Interrupt ID Number Interrupt Meaning 17 IRQ1 18 IRQ2 19 IRQ3 20 IRQ4 21 IRQ5 22 IRQ6 23 IRQ7 48 IRQ0 Given this I can use this dts section for PCI devices connected @ IRQ0 and IRQ1 interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8 0x6000 0 0 1 ipic 0x11 0x8 0x6000 0 0 2 ipic 0x11 0x8; You should be able to use IRQ-Nr 18-20 for IRQ2-4. Yes, that makes sense. Thanks. Jocke OK, finally figured it out, see below, but I get a SEGV if I use IRQ_TYPE_EDGE_FALLING as below. IRQ_TYPE_EDGE_FALLING works. [SNIP] What am I missing? Kernel is 2.6.25 I was missing a set_irq_type(info-irq, IRQ_TYPE_EDGE_FALLING) Works now. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Merge linuxppc-embedded with linuxppc-dev
On Mon, 22 Sep 2008 18:34:37 -0500 Kumar Gala [EMAIL PROTECTED] wrote: On Sep 22, 2008, at 6:09 PM, Jeremy Kerr wrote: Hi Grant, Can we eliminate the linuxppc-embedded mailing list and merge it with linuxppc-dev? That's not really up to me - more of a community question I think. I imagine Paul would have the final decision though. I'm pretty sure I saw paul gripe about this on irc just the other day. My vote is to kill linuxppc-embedded. I agree. Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ 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
Jan-Bernd wrote: Ben, can you / your team look into the implementation of the set_irq_type functionality needed for XICS? I'm not volunteering to look at or implement any changes for how xics works with generic irq, but I'm trying to understand what the rt kernel is trying to accomplish with this statement: 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? 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 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. We used to lower the priority to allow other interrupts in, but we realized that in addition to the questionable latency in doing so, it only caused unlimited stack nesting and overflow without per-irq stacks. We currently set IPIs above other irqs so we typically only process them during a hard irq (but we return to base level after IPI and could take another base irq, a bug). So, Sebastien, with this information, is does the RT kernel have a strategy that better matches this hardware? milton ___ 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
On Tue, 2008-09-23 at 14:30 -0700, Andrew Morton wrote: Steps to reproduce: shut down the machine, see it fail. http://johannes.sipsolutions.net/files/dsc_2274.jpg That went splat in the clockevents code. This is still strange, it appears that when the CPUs fail to offline, we still call into the clockevents code and it rightfully crashes, but I'll check that out separately. I've found the problem, below is a tentative fix. The problem has been around for quite a while, here's the whole commit that caused it (because it's so short): commit 4047727e5ae33f9b8d2b7766d1994ea6e5ec2991 Author: Mark Lord [EMAIL PROTECTED] Date: Mon Oct 1 01:20:10 2007 -0700 Fix SMP poweroff hangs We need to disable all CPUs other than the boot CPU (usually 0) before attempting to power-off modern SMP machines. This fixes the hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's new toybox. Signed-off-by: Mark Lord [EMAIL PROTECTED] Acked-by: Thomas Gleixner [EMAIL PROTECTED] Cc: Rafael J. Wysocki [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] diff --git a/kernel/sys.c b/kernel/sys.c index 1b33b05..8ae2e63 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -32,6 +32,7 @@ #include linux/getcpu.h #include linux/task_io_accounting_ops.h #include linux/seccomp.h +#include linux/cpu.h #include linux/compat.h #include linux/syscalls.h @@ -878,6 +879,7 @@ void kernel_power_off(void) kernel_shutdown_prepare(SYSTEM_POWER_OFF); if (pm_power_off_prepare) pm_power_off_prepare(); + disable_nonboot_cpus(); sysdev_shutdown(); printk(KERN_EMERG Power down.\n); machine_power_off(); And here's the fix. 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 |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/arch/powerpc/kernel/idle.c +++ b/arch/powerpc/kernel/idle.c @@ -36,9 +36,7 @@ #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 HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
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 ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello. Anton Vorontsov wrote: This controller does not integrate the root hub, so this driver also fakes one-port hub. External hub is required to support more than one device. ... Please, no. What exactly 'no'? ;-) No one-port hubs I guess -- they are pointless. Though e.g. MUSB driver creates one -- I guess to impersonate a transaction translating high-speed hub... ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... I looked at the core and figured that USB core seems to use the root hub interface for port PM, etc. and expects it to bee present, so it seems unavoidable indeed... :-/ WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Move 8xxx GPIO Kconfig under the platform menu
Kumar == Kumar Gala [EMAIL PROTECTED] writes: Kumar The initial patch had the option at the top level which wasn't Kumar quite right. Moving under the platform options is a bit better. Kumar Signed-off-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Peter Korsgaard [EMAIL PROTECTED] -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello, I wrote: This controller does not integrate the root hub, so this driver also fakes one-port hub. External hub is required to support more than one device. ... Please, no. What exactly 'no'? ;-) No one-port hubs I guess -- they are pointless. Though e.g. MUSB driver creates one -- I guess to impersonate a transaction translating high-speed hub... ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... Oops, I stand corrected. Even USB 1.1 specifies that it must be a part the host... WBR, Sergei ___ 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 Sep 24, 2008, at 5:17 AM, Benjamin Herrenschmidt 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 ? 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). 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. The MPIC hardware, on the other hand, maintains a queue of pending interrupts (It has been about a decade but the number 4-5 comes to mind), and the hardware must receive the EOI on the cpu that took it. I am guessing that the handling described (take level irq, mask it, eoi it, dispatch the thread, then unmask it after processing) is a result to work within those limitations. Do you know the cell IIC to know if its mpic or xics in this regard? The other unknown is the (very few) platforms that present as xics but are really firmware on mpic. If they do a full virtual layer and don't take shortcuts but do eoi/mask like described here they should work, but I would not be surprised that does not hold true :-(. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Tue, Sep 23, 2008 at 11:07:00PM -0500, Kumar Gala wrote: On Sep 23, 2008, at 7:03 PM, Anton Vorontsov wrote: qe_gpio_set_dedicated() is a platform specific function, which is used to revert a pin to a dedicated function. Caller should have already obtained the gpio via gpio_request(). This is needed to support Freescale USB Host Controller. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- arch/powerpc/include/asm/qe.h |1 + arch/powerpc/sysdev/qe_lib/gpio.c | 46 + 2 files changed, 47 insertions(+), 0 deletions(-) what do you mean by dedicated function.. be a bit clearer in the commit log. This term is from the QE spec, I didn't invent anything. ;-) Each pin in the I/O ports can be configured as a general-purpose I/O signal or as a dedicated peripheral interface signal. ...many dedicated peripheral functions are multiplexed onto the ports. Also, does this depend on gpio_to_chip() patch? Yeah, the point of exported gpio_to_chip is to let us write this function. 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: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
Hi Milton, On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller [EMAIL PROTECTED] wrote: Jan-Bernd wrote: Ben, can you / your team look into the implementation of the set_irq_type functionality needed for XICS? I'm not volunteering to look at or implement any changes for how xics works with generic irq, but I'm trying to understand what the rt kernel is trying to accomplish with this statement: 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. 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. Here is a side by side comparison of the fasteoi flow with and without hardirq threading (sorry it's a bit wide) fasteoi flow: Non threaded hardirq| threaded hardirq | interrupt context| interrupt context hardirq thread -| - -- | | clear IRQ_REPLAY and IRQ_WAITING| clear IRQ_REPLAY and IRQ_WAITING | increment percpu interrupt count| increment percpu interrupt count | if no action or IRQ_INPROGRESS or IRQ_DISABLED | if no action or IRQ_INPROGRESS or IRQ_DISABLED | set IRQ_PENDING | set IRQ_PENDING | mask | mask | eoi | eoi | done | done | set IRQ_INPROGRESS | set IRQ_INPROGRESS | | | wakeup IRQ thread | | mask | | eoi | | done -- | \ | \ | \ | -- loop | clear IRQ_PENDING | clear IRQ_PENDING | call handle_IRQ_event | call handle_IRQ_event | | check for prempt | | until IRQ_PENDING cleared | | clear IRQ_INPROGRESS| clear IRQ_INPROGRESS | if not IRQ_DISABLED |
Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption
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. Thanks, Sebastien. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: enforce sane MAX_ORDER
powerpc uses CONFIG_FORCE_MAX_ZONEORDER, and some things depend on it being at least 10 when 64k pages are not configured (notably the dart iommu code with CONFIG_PM). The defaults are fine, but when going from a 64K pages config to one without 64K pages, MAX_ORDER stays at 9 which is too low for 4K pages. This patch makes the Kconfig enforce at least the defaults, I used 999 as the upper bound for no particular reason other than that it's plenty. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config PPC_64K_PAGES config FORCE_MAX_ZONEORDER int Maximum zone order + range 9 999 if PPC_64K_PAGES default 9 if PPC_64K_PAGES + range 13 999 if PPC64 !PPC_64K_PAGES default 13 if PPC64 !PPC_64K_PAGES + range 11 999 default 11 help The kernel memory allocator divides physically contiguous memory ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: make 64-bit hibernation depend on !64K_PAGES
For reasons I haven't tried to figure out yet, and which are quite possibly my own fault, the hibernation code doesn't work with 64K pages. Until somebody is able to figure out why (if anyone cares; I seem to be the only person on earth actually using this code once a while) make it depend on !PPC_64K_PAGES. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -194,7 +194,7 @@ config HIBERNATE_32 config HIBERNATE_64 bool - depends on BROKEN || (PPC_PMAC64 EXPERIMENTAL) + depends on BROKEN || (PPC_PMAC64 !PPC_64K_PAGES EXPERIMENTAL) default y config ARCH_HIBERNATION_POSSIBLE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Sep 24, 2008, at 6:42 AM, Anton Vorontsov wrote: On Tue, Sep 23, 2008 at 11:07:00PM -0500, Kumar Gala wrote: On Sep 23, 2008, at 7:03 PM, Anton Vorontsov wrote: qe_gpio_set_dedicated() is a platform specific function, which is used to revert a pin to a dedicated function. Caller should have already obtained the gpio via gpio_request(). This is needed to support Freescale USB Host Controller. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- arch/powerpc/include/asm/qe.h |1 + arch/powerpc/sysdev/qe_lib/gpio.c | 46 ++ ++ + 2 files changed, 47 insertions(+), 0 deletions(-) what do you mean by dedicated function.. be a bit clearer in the commit log. This term is from the QE spec, I didn't invent anything. ;-) Each pin in the I/O ports can be configured as a general-purpose I/O signal or as a dedicated peripheral interface signal. ...many dedicated peripheral functions are multiplexed onto the ports. I understand but I think 'dedicated' could be interpreted in another way (like the GPIO pin is dedicated, not that the pin is used for a dedicated SoC block). If it the commit message had said 'to a dedicated on chip peripheral' it would be clearer. Also, does this depend on gpio_to_chip() patch? Yeah, the point of exported gpio_to_chip is to let us write this function. I meant can I take this patch w/o the gpio_to_chip() patch? (not clear from your response) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix 64-bit hibernation with 64k pages
Brown paper bag patch, the fact that it didn't work is entirely my fault for hardcoding 512 in the original patch. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Contains the revert for the earlier patch just in case; probably better to not apply the earlier patch and only the first hunk of this. --- arch/powerpc/Kconfig |2 +- arch/powerpc/kernel/swsusp_asm64.S |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- wireless-testing.orig/arch/powerpc/kernel/swsusp_asm64.S2008-09-24 15:32:07.119071976 +0200 +++ wireless-testing/arch/powerpc/kernel/swsusp_asm64.S 2008-09-24 15:32:15.723824535 +0200 @@ -133,7 +133,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) cmpdi r12,0 beq-nothing_to_copy - li r15,512 + li r15,PAGE_SIZE3 copyloop: ld r13,pbe_address(r12) ld r14,pbe_orig_address(r12) --- wireless-testing.orig/arch/powerpc/Kconfig 2008-09-24 15:32:36.483825650 +0200 +++ wireless-testing/arch/powerpc/Kconfig 2008-09-24 15:32:42.837826811 +0200 @@ -194,7 +194,7 @@ config HIBERNATE_32 config HIBERNATE_64 bool - depends on BROKEN || (PPC_PMAC64 !PPC_64K_PAGES EXPERIMENTAL) + depends on BROKEN || (PPC_PMAC64 EXPERIMENTAL) default y config ARCH_HIBERNATION_POSSIBLE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce sane MAX_ORDER
On Sep 24, 2008, at 8:24 AM, Johannes Berg wrote: powerpc uses CONFIG_FORCE_MAX_ZONEORDER, and some things depend on it being at least 10 when 64k pages are not configured (notably the dart iommu code with CONFIG_PM). The defaults are fine, but when going from a 64K pages config to one without 64K pages, MAX_ORDER stays at 9 which is too low for 4K pages. This patch makes the Kconfig enforce at least the defaults, I used 999 as the upper bound for no particular reason other than that it's plenty. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config PPC_64K_PAGES config FORCE_MAX_ZONEORDER int Maximum zone order + range 9 999 if PPC_64K_PAGES default 9 if PPC_64K_PAGES + range 13 999 if PPC64 !PPC_64K_PAGES default 13 if PPC64 !PPC_64K_PAGES + range 11 999 default 11 help The kernel memory allocator divides physically contiguous memory Hope about setting the upper bound to 32 or 64. Since I believe this in effect 2^FORCE_MAX_ZONEORDER, so 999 is just insane. I'd almost prefer something like 16 since that might still be in the realm of reasonable and able to work. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Wed, Sep 24, 2008 at 09:00:03AM -0500, Kumar Gala wrote: On Sep 24, 2008, at 6:42 AM, Anton Vorontsov wrote: On Tue, Sep 23, 2008 at 11:07:00PM -0500, Kumar Gala wrote: On Sep 23, 2008, at 7:03 PM, Anton Vorontsov wrote: qe_gpio_set_dedicated() is a platform specific function, which is used to revert a pin to a dedicated function. Caller should have already obtained the gpio via gpio_request(). This is needed to support Freescale USB Host Controller. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- arch/powerpc/include/asm/qe.h |1 + arch/powerpc/sysdev/qe_lib/gpio.c | 46 ++ ++ + 2 files changed, 47 insertions(+), 0 deletions(-) what do you mean by dedicated function.. be a bit clearer in the commit log. This term is from the QE spec, I didn't invent anything. ;-) Each pin in the I/O ports can be configured as a general-purpose I/O signal or as a dedicated peripheral interface signal. ...many dedicated peripheral functions are multiplexed onto the ports. I understand but I think 'dedicated' could be interpreted in another way (like the GPIO pin is dedicated, not that the pin is used for a dedicated SoC block). If it the commit message had said 'to a dedicated on chip peripheral' it would be clearer. Ah, ok, I'll fix that. Also, does this depend on gpio_to_chip() patch? Yeah, the point of exported gpio_to_chip is to let us write this function. I meant can I take this patch w/o the gpio_to_chip() patch? (not clear from your response) No, unfortunately you can't. It would be great if we could pass the whole patchset via single tree (USB? Or -mm to Linus directly?), so Acks are more than appreciated. Thanks again, -- 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] powerpc: enforce sane MAX_ORDER
On Wed, 2008-09-24 at 09:05 -0500, Kumar Gala wrote: --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config PPC_64K_PAGES config FORCE_MAX_ZONEORDER int Maximum zone order + range 9 999 if PPC_64K_PAGES default 9 if PPC_64K_PAGES + range 13 999 if PPC64 !PPC_64K_PAGES default 13 if PPC64 !PPC_64K_PAGES + range 11 999 default 11 help The kernel memory allocator divides physically contiguous memory Hope about setting the upper bound to 32 or 64. Works for me, I'm interested in the lower bound because if you set CONFIG_PM on a machine with dart iommu and set this to 9 then the thing will BUG_ON during boot. Since I believe this in effect 2^FORCE_MAX_ZONEORDER, so 999 is just insane. Indeed it is, and no argument that it's insane. But it's not limited at all right now, so you can in theory set it to 1, write a kernel module that calls alloc_pages(1000) and have it fail because not enough memory is available, rather than failing because of the MAX_ORDER check. I'd almost prefer something like 16 since that might still be in the realm of reasonable and able to work. with 4k pages that would be 256M memory, that seems well possible to allocate. Even 20 might still be possible (4G memory) if you allocate it early enough at boot and have a lot of memory (on a 64-bit system). On the other hand, why bother limiting it? If people set it too large in their config all that will happen is that it takes a bit longer to fail to allocate such a ridiculous amount of memory. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce sane MAX_ORDER
On Sep 24, 2008, at 9:13 AM, Johannes Berg wrote: On Wed, 2008-09-24 at 09:05 -0500, Kumar Gala wrote: --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config PPC_64K_PAGES config FORCE_MAX_ZONEORDER int Maximum zone order + range 9 999 if PPC_64K_PAGES default 9 if PPC_64K_PAGES + range 13 999 if PPC64 !PPC_64K_PAGES default 13 if PPC64 !PPC_64K_PAGES + range 11 999 default 11 help The kernel memory allocator divides physically contiguous memory Hope about setting the upper bound to 32 or 64. Works for me, I'm interested in the lower bound because if you set CONFIG_PM on a machine with dart iommu and set this to 9 then the thing will BUG_ON during boot. Since I believe this in effect 2^FORCE_MAX_ZONEORDER, so 999 is just insane. Indeed it is, and no argument that it's insane. But it's not limited at all right now, so you can in theory set it to 1, write a kernel module that calls alloc_pages(1000) and have it fail because not enough memory is available, rather than failing because of the MAX_ORDER check. I'd almost prefer something like 16 since that might still be in the realm of reasonable and able to work. with 4k pages that would be 256M memory, that seems well possible to allocate. Even 20 might still be possible (4G memory) if you allocate it early enough at boot and have a lot of memory (on a 64-bit system). On the other hand, why bother limiting it? If people set it too large in their config all that will happen is that it takes a bit longer to fail to allocate such a ridiculous amount of memory. We'll I'm ok with that, but I dont think we should be values that make no sense. 64 would seem the max even in a 64-bit system. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc52xx_uart and rs485
On Thu, Aug 14, 2008 at 11:23:49AM +0200, Sinisa Denic wrote:
From bf050adbc092043c1ba6e43373563bb761bb2e40 Mon Sep 17 00:00:00 2001
From: Sinisa Denic [EMAIL PROTECTED]
Date: Wed, 13 Aug 2008 15:57:52 +0200
Subject: [PATCH] mpc52xx_uart RS485 support added
Hi Wolfgang and others,
below is patch for mpc52xx_usrt.c which add software rs485 support to
this driver.
It has worked for me and if you think it is good enough it might be
useful for someone else.
Thanks for the patch. I've made a number of comments below and it
appears that your mail client has damaged the patch. Can you please
respin after addressing the comments. When you repost, please include a
technical description of what you have done and why.
Thanks,
g.
---
drivers/serial/mpc52xx_uart.c | 47 +
+---
1 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 7a3625f..38b2751 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -62,7 +62,7 @@
* by the bootloader or in the platform init code.
*/
-#undef DEBUG
+//#undef DEBUG
Unrelated changes; please remove.
#include linux/device.h
#include linux/module.h
@@ -142,11 +142,13 @@ struct psc_ops {
int (*rx_rdy)(struct uart_port *port);
int (*tx_rdy)(struct uart_port *port);
int (*tx_empty)(struct uart_port *port);
+ int (*tx_empty_enabled)(struct uart_port *port);
void(*stop_rx)(struct uart_port *port);
void(*start_tx)(struct uart_port *port);
void(*stop_tx)(struct uart_port *port);
void(*rx_clr_irq)(struct uart_port *port);
void(*tx_clr_irq)(struct uart_port *port);
+ void(*tx_empty_clr_irq)(struct uart_port *port);
void(*write_char)(struct uart_port *port, unsigned
char c);
unsigned char (*read_char)(struct uart_port *port);
void(*cw_disable_ints)(struct uart_port *port);
@@ -169,7 +171,7 @@ static void mpc52xx_psc_fifo_init(struct uart_port
*port)
out_8(fifo-tfcntl, 0x07);
out_be16(fifo-tfalarm, 0x80);
- port-read_status_mask |= MPC52xx_PSC_IMR_RXRDY |
MPC52xx_PSC_IMR_TXRDY;
+ port-read_status_mask |= MPC52xx_PSC_IMR_RXRDY |
MPC52xx_PSC_IMR_TXRDY | MPC52xx_PSC_IMR_TXEMP;
Patch was line wrapped here by your mailer
out_be16(psc-mpc52xx_psc_imr, port-read_status_mask);
}
@@ -200,6 +202,13 @@ static int mpc52xx_psc_tx_rdy(struct uart_port *port)
MPC52xx_PSC_IMR_TXRDY;
}
+static int mpc52xx_psc_tx_empty_enabled(struct uart_port *port)
+{
+ return in_be16(PSC(port)-mpc52xx_psc_isr)
+ port-read_status_mask
+ MPC52xx_PSC_IMR_TXEMP;
+}
+
static int mpc52xx_psc_tx_empty(struct uart_port *port)
{
return in_be16(PSC(port)-mpc52xx_psc_status)
@@ -209,6 +218,7 @@ static int mpc52xx_psc_tx_empty(struct uart_port
*port)
static void mpc52xx_psc_start_tx(struct uart_port *port)
{
port-read_status_mask |= MPC52xx_PSC_IMR_TXRDY;
+ port-read_status_mask |= MPC52xx_PSC_IMR_TXEMP;
You're enabling the TXEMP interrupts unconditionally, regardless of
whether or not rs485 is used. This adds performance impact to
non-rs485 users.
out_be16(PSC(port)-mpc52xx_psc_imr, port-read_status_mask);
}
@@ -232,6 +242,11 @@ static void mpc52xx_psc_tx_clr_irq(struct uart_port
*port)
{
}
+static void mpc52xx_psc_tx_empty_clr_irq(struct uart_port *port)
+{
+ port-read_status_mask = ~MPC52xx_PSC_IMR_TXEMP;
+ out_be16(PSC(port)-mpc52xx_psc_imr, port-read_status_mask);
+}
static void mpc52xx_psc_write_char(struct uart_port *port, unsigned char
c)
{
out_8(PSC(port)-mpc52xx_psc_buffer_8, c);
@@ -275,11 +290,13 @@ static struct psc_ops mpc52xx_psc_ops = {
.rx_rdy = mpc52xx_psc_rx_rdy,
.tx_rdy = mpc52xx_psc_tx_rdy,
.tx_empty = mpc52xx_psc_tx_empty,
+ .tx_empty_enabled = mpc52xx_psc_tx_empty_enabled,
.stop_rx = mpc52xx_psc_stop_rx,
.start_tx = mpc52xx_psc_start_tx,
.stop_tx = mpc52xx_psc_stop_tx,
.rx_clr_irq = mpc52xx_psc_rx_clr_irq,
.tx_clr_irq = mpc52xx_psc_tx_clr_irq,
+ .tx_empty_clr_irq = mpc52xx_psc_tx_empty_clr_irq,
.write_char = mpc52xx_psc_write_char,
.read_char = mpc52xx_psc_read_char,
.cw_disable_ints = mpc52xx_psc_cw_disable_ints,
@@ -583,7 +600,7 @@ mpc52xx_uart_set_termios(struct uart_port *port,
struct ktermios *new,
mr2 = 0;
-
+
Unrelated whitespace change; please omit from patch
if (new-c_cflag CSTOPB)
mr2 |= MPC52xx_PSC_MODE_TWO_STOP;
else
@@ -591,7 +608,6 @@ mpc52xx_uart_set_termios(struct uart_port *port,
struct ktermios *new,
MPC52xx_PSC_MODE_ONE_STOP_5_BITS :
[PATCH v2] powerpc: enforce sane MAX_ORDER
powerpc uses CONFIG_FORCE_MAX_ZONEORDER, and some things depend on it being at least 10 when 64k pages are not configured (notably the dart iommu code with CONFIG_PM). The defaults are fine, but when going from a 64K pages config to one without 64K pages, MAX_ORDER stays at 9 which is too low for 4K pages. This patch makes the Kconfig enforce at least the defaults. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- We'll I'm ok with that, but I dont think we should be values that make no sense. 64 would seem the max even in a 64-bit system. Indeed, it makes little sense to allow you to set more than the address space, so here's a version with max 64. --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -415,8 +415,11 @@ config PPC_64K_PAGES config FORCE_MAX_ZONEORDER int Maximum zone order + range 9 64 if PPC_64K_PAGES default 9 if PPC_64K_PAGES + range 13 64 if PPC64 !PPC_64K_PAGES default 13 if PPC64 !PPC_64K_PAGES + range 11 64 default 11 help The kernel memory allocator divides physically contiguous memory ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Dienstag, 23. September 2008, Juergen Beisert wrote: Matt, On Montag, 22. September 2008, Matt Sealey wrote: Juergen Beisert wrote: Hi, $ lspci 00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) USB driver (endianess???) or oftee or hardware problem? Anyone experience with VIA USB hardware on PowerPc? The USB driver should work fine, I have an Efika (MPC5200B) with that exact USB controller and revision and it's just fine and dandy. We also used to ship Via-based USB cards in the Pegasos Open Desktop Workstation (using Marvell Discovery II northbridge). The major difference here would be that PCI tree entries were created by a real OF implementation so may have reflected some hardware better; it is dynamically created on boot to a certain point, rather than a fixed device tree which may contain some errors. There seems to be a lot less data in our tree... 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. 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
[PATCH v6] POWERPC: Allow 32-bit hashed pgtable code to support 36-bit physical
This rearranges a bit of code, and adds support for
36-bit physical addressing for configs that use a
hashed page table. The 36b physical support is not
enabled by default on any config - it must be
explicitly enabled via the config system.
This patch *only* expands the page table code to accomodate
large physical addresses on 32-bit systems and enables the
PHYS_64BIT config option for 86xx. It does *not*
allow you to boot a board with more than about 3.5GB of
RAM - for that, SWIOTLB support is also required (and
coming soon).
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
This patch depends on Kumar's recent patch
[PATCH v9 2/4] powerpc: Fixes for CONFIG_PTE_64BIT for SMP support -
we've both made modifications to set_pte_at.
arch/powerpc/include/asm/io.h|2 +-
arch/powerpc/include/asm/page_32.h |8 +++-
arch/powerpc/include/asm/pgtable-ppc32.h | 17 +-
arch/powerpc/kernel/asm-offsets.c|1 +
arch/powerpc/kernel/head_32.S|4 +-
arch/powerpc/kernel/head_fsl_booke.S |2 -
arch/powerpc/mm/hash_low_32.S| 86 --
arch/powerpc/mm/pgtable_32.c |4 +-
arch/powerpc/mm/tlb_32.c |1 +
arch/powerpc/platforms/Kconfig.cputype | 17 ---
10 files changed, 109 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 77c7fa0..08266d2 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -711,7 +711,7 @@ static inline void * phys_to_virt(unsigned long address)
/*
* Change struct page to physical address.
*/
-#define page_to_phys(page) (page_to_pfn(page) PAGE_SHIFT)
+#define page_to_phys(page) ((phys_addr_t)page_to_pfn(page) PAGE_SHIFT)
/* We do NOT want virtual merging, it would put too much pressure on
* our iommu allocator. Instead, we want drivers to be smart enough
diff --git a/arch/powerpc/include/asm/page_32.h
b/arch/powerpc/include/asm/page_32.h
index ebfae53..d77072a 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -13,10 +13,16 @@
#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
#endif
+#ifdef CONFIG_PTE_64BIT
+#define PTE_FLAGS_OFFSET 4 /* offset of PTE flags, in bytes */
+#else
+#define PTE_FLAGS_OFFSET 0
+#endif
+
#ifndef __ASSEMBLY__
/*
* The basic type of a PTE - 64 bits for those CPUs with 32 bit
- * physical addressing. For now this just the IBM PPC440.
+ * physical addressing.
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h
b/arch/powerpc/include/asm/pgtable-ppc32.h
index c2e58b4..29c83d8 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -369,7 +369,12 @@ extern int icache_44x_need_flush;
#define _PAGE_RW 0x400 /* software: user write access allowed */
#define _PAGE_SPECIAL 0x800 /* software: Special page */
+#ifdef CONFIG_PTE_64BIT
+/* We never clear the high word of the pte */
+#define _PTE_NONE_MASK (0xULL | _PAGE_HASHPTE)
+#else
#define _PTE_NONE_MASK _PAGE_HASHPTE
+#endif
#define _PMD_PRESENT 0
#define _PMD_PRESENT_MASK (PAGE_MASK)
@@ -587,6 +592,10 @@ extern int flush_hash_pages(unsigned context, unsigned
long va,
extern void add_hash_page(unsigned context, unsigned long va,
unsigned long pmdval);
+/* Flush an entry from the TLB/hash table */
+extern void flush_hash_entry(struct mm_struct *mm, pte_t *ptep,
+unsigned long address);
+
/*
* Atomic PTE updates.
*
@@ -665,9 +674,13 @@ static inline unsigned long long pte_update(pte_t *p,
static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pte)
{
-#if _PAGE_HASHPTE != 0
+#if (_PAGE_HASHPTE != 0) defined(CONFIG_SMP) !defined(CONFIG_PTE_64BIT)
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) ~_PAGE_HASHPTE);
#elif defined(CONFIG_PTE_64BIT) defined(CONFIG_SMP)
+#if _PAGE_HASHPTE != 0
+ if (pte_val(*ptep) _PAGE_HASHPTE)
+ flush_hash_entry(mm, ptep, addr);
+#endif
__asm__ __volatile__(\
stw%U0%X0 %2,%0\n\
eieio\n\
@@ -675,7 +688,7 @@ static inline void __set_pte_at(struct mm_struct *mm,
unsigned long addr,
: =m (*ptep), =m (*((unsigned char *)ptep+4))
: r (pte) : memory);
#else
- *ptep = pte;
+ *ptep = (*ptep _PAGE_HASHPTE) | (pte ~_PAGE_HASHPTE);
#endif
}
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index e9c4044..09febc5 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -352,6 +352,7 @@ int main(void)
#endif
DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE);
+ DEFINE(PTE_SIZE, sizeof(pte_t));
#ifdef CONFIG_KVM
DEFINE(TLBE_BYTES,
Re: [PATCH v2] powerpc: enforce sane MAX_ORDER
On Wed, Sep 24, 2008 at 9:29 AM, Johannes Berg [EMAIL PROTECTED] wrote: Indeed, it makes little sense to allow you to set more than the address space, so here's a version with max 64. Acked-by: Timur Tabi [EMAIL PROTECTED] However, the max is actually less than 64. Assuming a 64-bit address space, the maximum number of pages in one allocation can be 2^(64-PAGE_SHIFT). For 4KB pages, the max value for FORCE_MAX_ZONEORDER is 53. For 64KB pages, the max is 49. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
Arnd Bergmann writes: 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(sys_ni_syscall) I don't see any reason to remove the old select syscall on 32-bit kernels. I think this hunk below is the only part of the patch that we actually need: @@ -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) Paul. ___ 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 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. 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. 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 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? 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 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. We used to lower the priority to allow other interrupts in, but we realized that in addition to the questionable latency in doing so, it only caused unlimited stack nesting and overflow without per-irq stacks. We currently set IPIs above other irqs so we typically only process them during a hard irq (but we return to base level after IPI and could take another base irq, a bug). So, Sebastien, with this information, is does the RT kernel have a strategy that better matches this
Re: [PATCH] fsldma: remove internal self-test from Freescale Elo DMA driver
On Tue, Sep 23, 2008 at 1:29 PM, Timur Tabi [EMAIL PROTECTED] wrote: The Freescale Elo DMA driver runs an internal self-test before registering the channels with the DMA engine. This self-test has a fundemental flaw in that it calls the DMA engine's callback functions directly before the registration. However, the registration initializes some variables that the callback functions uses, namely the device struct. The code works today because there are two device structs: the one created by the DMA engine, and one created by the Open Firmware (OF) subsystem. The self-test currently uses the device struct created by OF. However, in the future, some of the device structs created by OF will be eliminated. This means that the self-test will only have access to the device struct created by the DMA engine. But this device struct isn't initialized when the self-test runs, and this causes a kernel panic. Since there is already a DMA test module (dmatest), the internal self-test code is not useful anyway. It is extremely unlikely that the test will fail in normal usage. It may have been helpful during development, but not any more. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch is for 2.6.28. Applied to the 'next' [1] branch. Thanks, Dan [1] http://git.kernel.org/?p=linux/kernel/git/djbw/async_tx.git;a=shortlog;h=next ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
On Wednesday 24 September 2008, Paul Mackerras wrote: 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(sys_ni_syscall) I don't see any reason to remove the old select syscall on 32-bit kernels. Well, the point I made earlier ist that the native ppc32 path should behave the same way as the compat ppc32 path. If we keep ppc_select in one way or another, we should also have a compat wrapper for that, right? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
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. 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. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3 0/4] FHCI USB Host support patches
Hi all, Thanks for the comments on the previous version, here is the updated patch set, v3: - use list_for_each*() where appropriate; - improve error checking in the fhci_start(); - improve qe_gpio_set_dedicated patch's description. -- 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/4] gpiolib: make gpio_to_chip() public
We'll need this function to write platform-specific hooks to deal
with pin's dedicated functions. Quite obviously this will work only
for the platforms with 1-to-1 GPIO to PIN mapping.
This is stopgap solution till we think out and implement a proper
api (pinlib?).
p.s. This patch actually exports gpio_desc and places gpio_to_chip
into the asm-generic/gpio.h as `static inline'. This is needed
to not cause function calls for this trivial translation.
Also, the patch does not export FLAG_*s... the names are too
generic, and nobody is using them outside of gpiolib.c.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/gpio/gpiolib.c | 16 ++--
include/asm-generic/gpio.h | 17 +
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 8d29405..fb36a90 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -40,9 +40,6 @@
*/
static DEFINE_SPINLOCK(gpio_lock);
-struct gpio_desc {
- struct gpio_chip*chip;
- unsigned long flags;
/* flag symbols are bit numbers */
#define FLAG_REQUESTED 0
#define FLAG_IS_OUT1
@@ -50,11 +47,8 @@ struct gpio_desc {
#define FLAG_EXPORT3 /* protected by sysfs_lock */
#define FLAG_SYSFS 4 /* exported via /sys/class/gpio/control */
-#ifdef CONFIG_DEBUG_FS
- const char *label;
-#endif
-};
-static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+EXPORT_SYMBOL_GPL(gpio_desc);
static inline void desc_set_label(struct gpio_desc *d, const char *label)
{
@@ -80,12 +74,6 @@ static void gpio_ensure_requested(struct gpio_desc *desc)
}
}
-/* caller holds gpio_lock *OR* gpio is marked as requested */
-static inline struct gpio_chip *gpio_to_chip(unsigned gpio)
-{
- return gpio_desc[gpio].chip;
-}
-
/* dynamic allocation of GPIOs, e.g. on a hotplugged device */
static int gpiochip_find_base(int ngpio)
{
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 0f99ad3..88962f0 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -81,6 +81,23 @@ struct gpio_chip {
unsignedexported:1;
};
+struct gpio_desc {
+ struct gpio_chip*chip;
+ unsigned long flags;
+
+#ifdef CONFIG_DEBUG_FS
+ const char *label;
+#endif
+};
+
+extern struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+
+/* caller holds gpio_lock *OR* gpio is marked as requested */
+static inline struct gpio_chip *gpio_to_chip(unsigned gpio)
+{
+ return gpio_desc[gpio].chip;
+}
+
extern const char *gpiochip_is_requested(struct gpio_chip *chip,
unsigned offset);
extern int __must_check gpiochip_reserve(int start, int ngpio);
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
qe_gpio_set_dedicated() is a platform specific function that is used
to revert a pin to a dedicated on chip peripheral function. Caller
should have already obtained the gpio via gpio_request().
This is needed to support Freescale USB Host Controller.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/include/asm/qe.h |1 +
arch/powerpc/sysdev/qe_lib/gpio.c | 46 +
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index edee15d..c926147 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -111,6 +111,7 @@ extern void __par_io_config_pin(struct qe_pio_regs __iomem
*par_io, u8 pin,
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);
+extern int qe_gpio_set_dedicated(unsigned int gpio);
/* QE internal API */
int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
index 8e5a0bc..bd7278f 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -26,6 +26,9 @@ struct qe_gpio_chip {
/* 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 +43,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 +112,43 @@ static int qe_gpio_dir_out(struct gpio_chip *gc, unsigned
int gpio, int val)
return 0;
}
+int qe_gpio_set_dedicated(unsigned int gpio)
+{
+ struct gpio_chip *gc = gpio_to_chip(gpio);
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ struct qe_pio_regs __iomem *regs = mm_gc-regs;
+ struct qe_pio_regs *sregs = qe_gc-saved_regs;
+ u8 pin = gpio - gc-base;
+ u32 mask1 = 1 (QE_PIO_PINS - (pin + 1));
+ u32 mask2 = 0x3 (QE_PIO_PINS - (pin % (QE_PIO_PINS / 2) + 1) * 2);
+ bool second_reg = pin (QE_PIO_PINS / 2) - 1;
+ unsigned long flags;
+
+ spin_lock_irqsave(qe_gc-lock, flags);
+
+ if (second_reg) {
+ clrsetbits_be32(regs-cpdir2, mask2, sregs-cpdir2 mask2);
+ clrsetbits_be32(regs-cppar2, mask2, sregs-cppar2 mask2);
+ } else {
+ clrsetbits_be32(regs-cpdir1, mask2, sregs-cpdir1 mask2);
+ clrsetbits_be32(regs-cppar1, mask2, sregs-cppar1 mask2);
+ }
+
+ if (sregs-cpdata mask1)
+ qe_gc-cpdata |= mask1;
+ else
+ qe_gc-cpdata = ~mask1;
+
+ out_be32(regs-cpdata, qe_gc-cpdata);
+ clrsetbits_be32(regs-cpodr, mask1, sregs-cpodr mask1);
+
+ spin_unlock_irqrestore(qe_gc-lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(qe_gpio_set_dedicated);
+
static int __init qe_add_gpiochips(void)
{
struct device_node *np;
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
On Sep 19, 2008, at 10:11 AM, Timur Tabi 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(). Therefore, the DMA channels must be manually probed. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- (Reposting because I forgot to CC: the maintainers) 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. drivers/dma/Kconfig | 10 ++-- drivers/dma/fsldma.c | 165 + + drivers/dma/fsldma.h |2 + 3 files changed, 119 insertions(+), 58 deletions(-) Dan, any update on this patch? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
Kumar Gala wrote: Dan, any update on this patch? I'm going to post a new version. This whole thing is more complicated than I thought. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Wednesday 24 September 2008, Anton Vorontsov wrote: what do you mean by dedicated function.. be a bit clearer in the commit log. This term is from the QE spec, I didn't invent anything. ;-) Each pin in the I/O ports can be configured as a general-purpose I/O signal or as a dedicated peripheral interface signal. ...many dedicated peripheral functions are multiplexed onto the ports. Which, to me, highlights the point I've made previously: the right abstraction for you to work with is pin, not GPIO. You need to switch a QE pin from one of its roles to the other. Evil things, like oopsing, will happen if you try to use this call on a GPIO that's not backed by a QE pin. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Tuesday 23 September 2008, Anton Vorontsov wrote:
qe_gpio_set_dedicated() is a platform specific function, which is used
to revert a pin to a dedicated function. Caller should have already
obtained the gpio via gpio_request().
Note the missing sibling function: putting the pin back into
GPIO mode!! You seem to assume that some of the GPIO calls
will be performing that pinmux function. But those calls are
explicitly defined as NOT incorporating any pinmux tasks.
Also note your nonportable assumption that GPIOs and pins are
the same concept ... they aren't.
You'd be better off calling something other than of_get_gpio()
for those three pins in of_fhci_probe() ... call something
that returns a qe_pin structure (e.g. wrapping an instance of
the misnamed qe_gpio_chip plus an offset) which holds the
pinmux primitives you need. Like this one to put the pin into
its normal mode.
When I look at patch 4 of this series I observe that only
two pins are true GPIOs: the optional POWER and SPEED pins.
(External transceiver support?)
+int qe_gpio_set_dedicated(unsigned int gpio)
+{
+ struct gpio_chip *gc = gpio_to_chip(gpio);
So the caller must already have requested it, yes -- that's a
needed for any stable mapping between GPIO and controller inside
the GPIO library.
For the record, this single call seems to be the entire reason
motivating that rather ugly patch #1. (Ugly for more than just
the confusion between pin, which is what you need, and GPIO.
There's no need to export those internal data structures.)
And in turn, the reason to want this call is so that you can
have io_port_generate_reset() generate a short reset on the
single downstream USB port. (Short meaning 45 msec below
USB spec requirements for root hub resets ...)
And to top it off ... that driver does gpio_request(), runs
those pins as GPIOs for virtually no time, and then uses
them as dedicated functions the rest of the time (after
the reset completes)!!
Which highlights the fact that these pins are fundamentally
NOT used as GPIOs. They're function pins that need brief
detours as GPIOs because, it seems, those functions only
support differential signaling (USB J and K states) instead
of the full set of USB states. (It's not quite clear from
the driver. Are the pins expected to be using a 3-wire
external transciever hookup? 4-wire? 6-wire?)
But there are other requirements for this no-kerneldoc call:
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
... it must be part of an of_mm_gpio_chip (in linux/of_gpio.h,
which might seem less odd to me if I read its supporting code).
Can you first ensure that it *is* an of_mm_gpio_chip
instance? When it isn't, this code will oops rudely.
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
... it must be the qe_gpio_chip flavor (defined only in this
very file, arch/powerpc/sysdev/qe_lib/gpio.c); IMO the code
would be cleaner if you just did
qe_gc = container_of(gpio_to_chip(gpio),
struct qe_gpio_chip, mm_gc.of_gc.gc);
and had just one pointer (not three!) for all these purposes.
(And cleaner still if it didn't require whacking the GPIO
framework out of shape to have a hope of working.)
But again: you're trusting, with no evident basis for that
trust, that it's a qe_gpio_chip instance. Oops if it isn't.
Much better for these calls to take e.g. a qe_pin parameter,
struct pointer or whatever ... not a GPIO number.
+ struct qe_pio_regs __iomem *regs = mm_gc-regs;
+ struct qe_pio_regs *sregs = qe_gc-saved_regs;
+ u8 pin = gpio - gc-base;
+ u32 mask1 = 1 (QE_PIO_PINS - (pin + 1));
+ u32 mask2 = 0x3 (QE_PIO_PINS - (pin % (QE_PIO_PINS / 2) + 1) * 2);
+ bool second_reg = pin (QE_PIO_PINS / 2) - 1;
...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
On Wednesday 24 September 2008, Sergei Shtylyov wrote: ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... Only the OHCI registers have bit positions matching what the USB spec says for hub status bits. Everything else, including musb_hdrc, has the relevant status encoded in other bits. I looked at the core and figured that USB core seems to use the root hub interface for port PM, etc. and expects it to bee present, so it seems unavoidable indeed... :-/ Or more fundamentally: for enumeration. Unavoidable is correct. ;) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller
Hello. David Brownell wrote: ... then the root hub emulation is completely pointless. It isn't. We always should emulate the root hub. The root hub is part and parcel of any USB Host. Even the one-port one. Hm, maybe that's what USB core thinks (because UHCI/OHCI/EHCI all have it) but e.g. MUSB doesn't have the root hub registers... Only the OHCI registers have bit positions matching what the USB spec says for hub status bits. Oh, didn't know that. Everything else, including musb_hdrc, has the relevant status encoded in other bits. Yes, but I thought that if there are no multiple ports, having the hub is just pointless. I looked at the core and figured that USB core seems to use the root hub interface for port PM, etc. and expects it to bee present, so it seems unavoidable indeed... :-/ Or more fundamentally: for enumeration. Unavoidable is correct. ;) Not sure what you mean here but I guess having a root hub alows an uniform model of controlling the ports... anyway, USB specifies that it must be present in the host. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] Patches to support QE USB Host Controller
On Thursday 14 August 2008, Laurent Pinchart wrote:
David, could you bear with gpio_to_chip() exported function, just as
a stopgap for a proper api?
I need gpio_to_chip() (or another 'proper API') as well for RTS/CTS
based flow control in the CPM/CPM2 UART driver.
I'l still say proper. This should be straightforward; along
the lines of
struct qe_pin {
struct ... *qe_ports; /* includes gpio_chip */
unsigned offset;
};
And instead of having the driver look up a gpio for such
non-GPIO usage, have it call something that sets up a qe_pin.
All that infrastructure exists already...
Then drivers can use calls which mux the pin into its normal
mode (QE function of some kind), or into its gpio mode.
The gpio number would be gpio_chip-base + offset, and the
gpio_chip is visible -- in a fully typesafe manner! -- from
the qe_ports structure.
No type-unsafe interfaces. No confusion between roles of a
given pin. No hidden assumption there's only one kind of GPIO
(backed by QE ports). And ... no need to change any core
structural assumptions of the GPIO framework.
- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
On Thursday 28 August 2008, Arnd Bergmann wrote: +/*- + Gadget driver register and unregister. + --*/ +int usb_gadget_register_driver(struct usb_gadget_driver *driver) +EXPORT_SYMBOL(usb_gadget_register_driver); + +int usb_gadget_unregister_driver(struct usb_gadget_driver *driver) +EXPORT_SYMBOL(usb_gadget_unregister_driver); Not addressing this driver in particular, but the USB gadget layer in general: This is a horrible interface, since every gadget driver exports the same symbols, Bad terminology. Gadget drivers are what sit on TOP of peripheral controller drivers ... only peripheral controller drivers touch the actual hardware registers. They export an abstract gadget interface. Gadget drivers are what talk *to* that abstract interface. you can never build a kernel that includes more than one gadget driver. Even if the drivers are all built as modules, simply loading one of them prevents loading another one. That's never been a particular requirement. Systems won't get USB branding if they have more than one USB peripheral (upstream) port. Supporting more than one type of controller hardware is at best a pretty esoteric configuration. If you really want to see such stuff ... -ENOPATCH. :) - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
On Thursday 28 August 2008, Arnd Bergmann wrote: If the gadget hardware drivers were registering the device with a gadget_bus_type, you could still enforce the only one protocol rule by binding every protocol to every device in that bus type. And you'd have to rewrite all the gadget drivers (protocol) to work with multiple upstream ports. That gets messy with e.g. the Ethernet links ... each would need to be configured with unique ethernet address pairs. Likewise with serial numbers. I've learned to just accept complaints in this area as sort of a price for existing. It's all complaints, no patches. So obviously the complaints don't have any requirements backing them. ;) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver
On Tuesday 02 September 2008, Li Yang-R58472 wrote: Does RNDIS work too? If not, is it possible to add or doesn't the HW support it? RNDIS is a gadget(protocol) level thing. I believe it can work with this driver although not tested myself. It should, so long as the QE hardware doesn't try to manage too many USB protocol details. Examples would be caring at all about config change events -- SET_CONFIGURATION picking between one of N configurations, and SET_INTERFACE picking between altsettings of a given interface. Noted: AFAIK, RNDIS gadget in Linux doesn't interoperate with windows well enough to be production level. Use at your own risk. Something in the past few releases broke so it may not be operating much at all, for that matter... However, it's a fair point that the interoperation requirements for RNDIS are so badly defined that non-Microsoft code has a very hard time being robust. Somewhere in the linux-usb archives is someone's fairly careful summary of a dozen extremely rude ways the MSFT RNDIS stack misbehaves. It'll do things like deciding to stop forwarding packets to certain applications for a while ... then continuing after a few minutes as if nothing was wrong. Blue screens are a possibility. Best to wait a few minutes between plugging and unplugging, while the races between the USB and NET stacks sort themselves out. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver
On Tuesday 02 September 2008, Joakim Tjernlund wrote: Noted: AFAIK, RNDIS gadget in Linux doesn't interoperate with windows well enough to be production level. Use at your own risk. I see. If one wants to connect with CDC to Windows, what drivers are there for Windows that works well with Linux? I believe MCCI has some. It also has drivers for a CDC subset, pretty much the same one Linux has used forever except wrapped with a few extra descriptors to make it practical to identify that SAFE (!) subset without needing vendor and product IDs. - Dave ___ 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
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. 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. 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 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. 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... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
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 :-) 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. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? 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 Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote: 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. No Milton, we must do it that way, because the EOI must be done on the right CPU even on XICS, or we won't get the CPU priority back properly. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Wed, Sep 24, 2008 at 5:22 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] 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 :-) 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. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? There's a nice skeleton in arch/powerpc/kernel/clock.c for tracking who is using a clock and disabling it when not in use. Nobody is using it on PowerPC. It is used all over the place on ARM. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver
On Wednesday 24 September 2008, Joakim Tjernlund wrote: I see. If one wants to connect with CDC to Windows, what drivers are there for Windows that works well with Linux? I believe MCCI has some. It also has drivers for a CDC subset, pretty much the same one Linux has used forever except wrapped with a few extra descriptors to make it practical to identify that SAFE (!) subset without needing vendor and product IDs. Thanks, had a look and it seems like I have to buy these drives. I was hoping to find some free ones, do you know of such free drivers? No, sorry. Remember MSFT is somewhat rabidly anti-Free... However, we'd be quite happy to have someone more attuned to MS-Windows sort out the remaining issues in the Linux support for RNDIS. ;) - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB support on mpc5200 broken
USB is not working my hardware, so I booted my Efika and it's not working there either. This is with linus' current git. Can anyone verify this? Or know what happened to USB? USB is loading but it is not finding anything plugged in. lsusb doesn't show anything. Last time I noticed it was working was about ten days ago. I don't use it everyday. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb ASoC version 0.31 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 audit: initializing netlink socket (disabled) type=2000 audit(192382.243:1): initialized msgmni has been set to 247 for ipc namespace c0316b94 io scheduler noop registered io scheduler deadline registered (default) Macintosh non-volatile memory driver v1.1 Serial: MPC52xx PSC UART driver f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC brd: module loaded loop: module loaded mpc52xx MII bus: probed net eth0: Using PHY at MDIO address 16 Driver 'sd' needs updating - please use bus_type methods Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. i2c /dev entries driver usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver Advanced Linux Sound Architecture Driver Version 1.0.16. tas5504_driver_init mpc52xx_i2s_driver_init digispeaker_driver_init ALSA device list: No soundcards found. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. drivers/rtc/hctosys.c: unable to open rtc device (rtc0) net eth0: attached phy 16 to driver Generic PHY Sending DHCP requests .6PHY: f0003000:10 - Link is Up - 100/Full ., OK IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.109 IP-Config: Complete: device=eth0, addr=192.168.1.109, mask=255.255.255.0, gw=192.168.1.1, host=192.168.1.109, domain=, nis-domain=(none), bootserver=192.168.1.1, rootserver=192.168.1.4, rootpath= Looking up port of RPC 13/3 on 192.168.1.4 Looking up port of RPC 15/3 on 192.168.1.4 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] Drop redundant machine type print in show_cpuinfo
For many of the embedded boards, model and Machine are printing
the same thing; remove the redundant code and allow the generic
show_cpuinfo to print the model information.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/platforms/85xx/mpc85xx_ads.c |1 -
arch/powerpc/platforms/85xx/sbc8560.c |1 -
arch/powerpc/platforms/86xx/gef_sbc610.c |8
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|8
arch/powerpc/platforms/86xx/sbc8641d.c|8
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |1 -
6 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index d17807a..0293e3d 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -213,7 +213,6 @@ static void mpc85xx_ads_show_cpuinfo(struct seq_file *m)
svid = mfspr(SPRN_SVR);
seq_printf(m, Vendor\t\t: Freescale Semiconductor\n);
- seq_printf(m, Machine\t\t: mpc85xx\n);
seq_printf(m, PVR\t\t: 0x%x\n, pvid);
seq_printf(m, SVR\t\t: 0x%x\n, svid);
diff --git a/arch/powerpc/platforms/85xx/sbc8560.c
b/arch/powerpc/platforms/85xx/sbc8560.c
index e0cf060..0c9a856 100644
--- a/arch/powerpc/platforms/85xx/sbc8560.c
+++ b/arch/powerpc/platforms/85xx/sbc8560.c
@@ -200,7 +200,6 @@ static void sbc8560_show_cpuinfo(struct seq_file *m)
svid = mfspr(SPRN_SVR);
seq_printf(m, Vendor\t\t: Wind River\n);
- seq_printf(m, Machine\t\t: SBC8560\n);
seq_printf(m, PVR\t\t: 0x%x\n, pvid);
seq_printf(m, SVR\t\t: 0x%x\n, svid);
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c
b/arch/powerpc/platforms/86xx/gef_sbc610.c
index 3543a9e..8a9dee2 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -66,19 +66,11 @@ static void __init gef_sbc610_setup_arch(void)
static void gef_sbc610_show_cpuinfo(struct seq_file *m)
{
- struct device_node *root;
uint memsize = total_memory;
- const char *model = ;
uint svid = mfspr(SPRN_SVR);
seq_printf(m, Vendor\t\t: GE Fanuc Intelligent Platforms\n);
- root = of_find_node_by_path(/);
- if (root)
- model = of_get_property(root, model, NULL);
- seq_printf(m, Machine\t\t: %s\n, model);
- of_node_put(root);
-
seq_printf(m, SVR\t\t: 0x%x\n, svid);
seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index f712d9c..2672829 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -101,19 +101,11 @@ mpc86xx_hpcn_setup_arch(void)
static void
mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
{
- struct device_node *root;
uint memsize = total_memory;
- const char *model = ;
uint svid = mfspr(SPRN_SVR);
seq_printf(m, Vendor\t\t: Freescale Semiconductor\n);
- root = of_find_node_by_path(/);
- if (root)
- model = of_get_property(root, model, NULL);
- seq_printf(m, Machine\t\t: %s\n, model);
- of_node_put(root);
-
seq_printf(m, SVR\t\t: 0x%x\n, svid);
seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
diff --git a/arch/powerpc/platforms/86xx/sbc8641d.c
b/arch/powerpc/platforms/86xx/sbc8641d.c
index 00e6fad..da677a7 100644
--- a/arch/powerpc/platforms/86xx/sbc8641d.c
+++ b/arch/powerpc/platforms/86xx/sbc8641d.c
@@ -63,19 +63,11 @@ sbc8641_setup_arch(void)
static void
sbc8641_show_cpuinfo(struct seq_file *m)
{
- struct device_node *root;
uint memsize = total_memory;
- const char *model = ;
uint svid = mfspr(SPRN_SVR);
seq_printf(m, Vendor\t\t: Wind River Systems\n);
- root = of_find_node_by_path(/);
- if (root)
- model = of_get_property(root, model, NULL);
- seq_printf(m, Machine\t\t: %s\n, model);
- of_node_put(root);
-
seq_printf(m, SVR\t\t: 0x%x\n, svid);
seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index 84e2d78..7a2ba39 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -164,7 +164,6 @@ static void __init mpc7448_hpc2_init_IRQ(void)
void mpc7448_hpc2_show_cpuinfo(struct seq_file *m)
{
seq_printf(m, vendor\t\t: Freescale Semiconductor\n);
- seq_printf(m, machine\t\t: MPC7448hpc2\n);
}
void mpc7448_hpc2_restart(char *cmd)
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] Move memory size print into common show_cpuinfo for 32-bit
Most of the platforms were printing the size of the memory
in their show_cpuinfo implementations. This moves that to
the common show_cpuinfo, so that all 32-bit platforms will
now print the size of memory. I also update the code
to deal with the fact that total_memory is now a phys_addr_t.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup-common.c |7 +++
arch/powerpc/platforms/85xx/ksi8560.c |4
arch/powerpc/platforms/85xx/mpc85xx_ads.c |4
arch/powerpc/platforms/85xx/mpc85xx_cds.c |4
arch/powerpc/platforms/85xx/sbc8548.c |4
arch/powerpc/platforms/85xx/sbc8560.c |4
arch/powerpc/platforms/85xx/tqm85xx.c |4
arch/powerpc/platforms/86xx/gef_sbc610.c |2 --
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 --
arch/powerpc/platforms/86xx/sbc8641d.c |2 --
arch/powerpc/platforms/embedded6xx/c2k.c |3 ---
arch/powerpc/platforms/embedded6xx/prpmc2800.c |3 ---
12 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 5ec56ff..705fc4b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -59,6 +59,7 @@
#include asm/mmu.h
#include asm/xmon.h
#include asm/cputhreads.h
+#include mm/mmu_decl.h
#include setup.h
@@ -190,6 +191,12 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (ppc_md.show_cpuinfo != NULL)
ppc_md.show_cpuinfo(m);
+#ifdef CONFIG_PPC32
+ /* Display the amount of memory */
+ seq_printf(m, Memory\t\t: %d MB\n,
+ (unsigned int)(total_memory / (1024 * 1024)));
+#endif
+
return 0;
}
diff --git a/arch/powerpc/platforms/85xx/ksi8560.c
b/arch/powerpc/platforms/85xx/ksi8560.c
index 8a3b117..81cee7b 100644
--- a/arch/powerpc/platforms/85xx/ksi8560.c
+++ b/arch/powerpc/platforms/85xx/ksi8560.c
@@ -193,7 +193,6 @@ static void __init ksi8560_setup_arch(void)
static void ksi8560_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -215,9 +214,6 @@ static void ksi8560_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
phid1 = mfspr(SPRN_HID1);
seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
-
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
static struct of_device_id __initdata of_bus_ids[] = {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 0293e3d..21f0090 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -207,7 +207,6 @@ static void __init mpc85xx_ads_setup_arch(void)
static void mpc85xx_ads_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -219,9 +218,6 @@ static void mpc85xx_ads_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
phid1 = mfspr(SPRN_HID1);
seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
-
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
static struct of_device_id __initdata of_bus_ids[] = {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 50d7ea8..aeb6a5b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -307,7 +307,6 @@ static void __init mpc85xx_cds_setup_arch(void)
static void mpc85xx_cds_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -320,9 +319,6 @@ static void mpc85xx_cds_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
phid1 = mfspr(SPRN_HID1);
seq_printf(m, PLL setting\t: 0x%x\n, ((phid1 24) 0x3f));
-
- /* Display the amount of memory */
- seq_printf(m, Memory\t\t: %d MB\n, memsize / (1024 * 1024));
}
diff --git a/arch/powerpc/platforms/85xx/sbc8548.c
b/arch/powerpc/platforms/85xx/sbc8548.c
index b9246ea..7ec77ce 100644
--- a/arch/powerpc/platforms/85xx/sbc8548.c
+++ b/arch/powerpc/platforms/85xx/sbc8548.c
@@ -136,7 +136,6 @@ static void __init sbc8548_setup_arch(void)
static void sbc8548_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
- uint memsize = total_memory;
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
@@ -149,9 +148,6 @@ static void sbc8548_show_cpuinfo(struct seq_file *m)
/* Display cpu Pll setting */
Please pull from 'dma' branch
Please pull from 'dma' branch of (forgot linuxppc-dev on first go around) master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git dma to receive the following updates: arch/powerpc/include/asm/device.h |3 arch/powerpc/include/asm/dma-mapping.h | 187 + arch/powerpc/include/asm/machdep.h |5 arch/powerpc/include/asm/pci.h | 14 +- arch/powerpc/include/asm/types.h|2 arch/powerpc/kernel/Makefile|4 arch/powerpc/kernel/dma-iommu.c | 103 arch/powerpc/kernel/dma.c | 127 arch/powerpc/kernel/dma_64.c| 200 arch/powerpc/kernel/of_device.c |2 arch/powerpc/kernel/pci-common.c| 48 +++ arch/powerpc/kernel/pci_32.c|7 + arch/powerpc/kernel/pci_64.c| 49 --- arch/powerpc/kernel/vio.c |2 arch/powerpc/platforms/cell/iommu.c |6 arch/powerpc/platforms/ps3/system-bus.c |2 16 files changed, 366 insertions(+), 395 deletions(-) Becky Bruce (5): powerpc: Rename dma_64.c to dma.c powerpc: Move iommu dma ops from dma.c to dma-iommu.c powerpc: Drop archdata numa_node powerpc: Merge 32 and 64-bit dma code powerpc: Make dma_addr_t a u64 if CONFIG_PHYS_64BIT is set ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'mmu' branch
Please pull from 'mmu' branch of (forgot linuxppc-dev on first go around) master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git mmu to receive the following updates: arch/powerpc/include/asm/highmem.h |2 arch/powerpc/include/asm/io.h|2 arch/powerpc/include/asm/page_32.h |8 ++ arch/powerpc/include/asm/pgtable-ppc32.h | 57 +--- arch/powerpc/include/asm/reg_booke.h |7 ++ arch/powerpc/include/asm/tlbflush.h | 13 ++-- arch/powerpc/kernel/asm-offsets.c|1 arch/powerpc/kernel/head_32.S|4 - arch/powerpc/kernel/head_fsl_booke.S |2 arch/powerpc/kernel/misc_32.S| 54 +++ arch/powerpc/kernel/ppc_ksyms.c |3 + arch/powerpc/mm/hash_low_32.S| 86 +-- arch/powerpc/mm/pgtable_32.c |4 - arch/powerpc/mm/tlb_32.c |1 arch/powerpc/platforms/Kconfig.cputype | 17 +++--- 15 files changed, 215 insertions(+), 46 deletions(-) Becky Bruce (1): POWERPC: Allow 32-bit hashed pgtable code to support 36-bit physical Kumar Gala (3): powerpc: Introduce local (non-broadcast) forms of tlb invalidates powerpc: Fixes for CONFIG_PTE_64BIT for SMP support powerpc/mm: Implement _PAGE_SPECIAL pte_special() for 32-bit ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module
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.
drivers/dma/Kconfig | 10 ++--
drivers/dma/fsldma.c | 138 --
drivers/dma/fsldma.h |1 +
3 files changed, 94 insertions(+), 55 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cd30390..904e575 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -48,13 +48,13 @@ config DW_DMAC
can be integrated in chips such as the Atmel AT32ap7000.
config FSL_DMA
- bool Freescale MPC85xx/MPC83xx DMA support
- depends on PPC
+ tristate Freescale Elo and Elo Plus DMA support
+ depends on FSL_SOC
select DMA_ENGINE
---help---
- Enable support for the Freescale DMA engine. Now, it support
- MPC8560/40, MPC8555, MPC8548 and MPC8641 processors.
- The MPC8349, MPC8360 is also supported.
+ Enable support for the Freescale Elo and Elo Plus DMA controllers.
+ The Elo is the DMA controller on some 82xx and 83xx parts, and the
+ Elo Plus is the DMA controller on 85xx and 86xx parts.
config MV_XOR
bool Marvell XOR engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index e9b2638..0b95dcc 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -370,7 +370,10 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan
*chan,
struct dma_client *client)
{
struct fsl_dma_chan *fsl_chan = to_fsl_chan(chan);
- LIST_HEAD(tmp_list);
+
+ /* Has this channel already been allocated? */
+ if (fsl_chan-desc_pool)
+ return 1;
/* We need the descriptor to be aligned to 32bytes
* for meeting FSL DMA specification requirement.
@@ -410,6 +413,8 @@ static void fsl_dma_free_chan_resources(struct dma_chan
*chan)
}
spin_unlock_irqrestore(fsl_chan-desc_lock, flags);
dma_pool_destroy(fsl_chan-desc_pool);
+
+ fsl_chan-desc_pool = NULL;
}
static struct dma_async_tx_descriptor *
@@ -786,33 +791,29 @@ static void dma_do_tasklet(unsigned long data)
fsl_chan_ld_cleanup(fsl_chan);
}
-static int __devinit of_fsl_dma_chan_probe(struct of_device *dev,
- const struct of_device_id *match)
+static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
+ struct device_node *node, u32 feature, const char *compatible)
{
- struct fsl_dma_device *fdev;
struct fsl_dma_chan *new_fsl_chan;
int err;
- fdev = dev_get_drvdata(dev-dev.parent);
- BUG_ON(!fdev);
-
/* alloc channel */
new_fsl_chan = kzalloc(sizeof(struct fsl_dma_chan), GFP_KERNEL);
if (!new_fsl_chan) {
- dev_err(dev-dev, No free memory for allocating
+ dev_err(fdev-dev, No free memory for allocating
dma channels!\n);
return -ENOMEM;
}
/* get dma channel register base */
- err = of_address_to_resource(dev-node, 0, new_fsl_chan-reg);
+ err = of_address_to_resource(node, 0, new_fsl_chan-reg);
if (err) {
- dev_err(dev-dev, Can't get %s property 'reg'\n,
- dev-node-full_name);
+ dev_err(fdev-dev, Can't get %s property 'reg'\n,
+ node-full_name);
goto err_no_reg;
}
- new_fsl_chan-feature = *(u32 *)match-data;
+ new_fsl_chan-feature = feature;
if (!fdev-feature)
fdev-feature = new_fsl_chan-feature;
@@ -822,13 +823,13 @@ static int __devinit of_fsl_dma_chan_probe(struct
of_device *dev,
*/
WARN_ON(fdev-feature != new_fsl_chan-feature);
- new_fsl_chan-dev = dev-dev;
+ new_fsl_chan-dev = new_fsl_chan-common.dev;
new_fsl_chan-reg_base = ioremap(new_fsl_chan-reg.start,
new_fsl_chan-reg.end - new_fsl_chan-reg.start + 1);
new_fsl_chan-id = ((new_fsl_chan-reg.start - 0x100) 0xfff) 7;
if (new_fsl_chan-id FSL_DMA_MAX_CHANS_PER_DEVICE) {
- dev_err(dev-dev, There is no %d channel!\n,
+ dev_err(fdev-dev, There is no %d channel!\n,
RE: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver
-Original Message- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: den 24 september 2008 22:29 To: [EMAIL PROTECTED] Cc: Li Yang-R58472; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux- [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver On Tuesday 02 September 2008, Joakim Tjernlund wrote: Noted: AFAIK, RNDIS gadget in Linux doesn't interoperate with windows well enough to be production level. Use at your own risk. I see. If one wants to connect with CDC to Windows, what drivers are there for Windows that works well with Linux? I believe MCCI has some. It also has drivers for a CDC subset, pretty much the same one Linux has used forever except wrapped with a few extra descriptors to make it practical to identify that SAFE (!) subset without needing vendor and product IDs. Thanks, had a look and it seems like I have to buy these drives. I was hoping to find some free ones, do you know of such free drivers? Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.27'
On Wed, Sep 17, 2008 at 12:29:55PM +0200, Jochen Friedrich wrote: It doesn't even tell me why not being thread-safe is a problem on a UP machine. Preemption. 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? 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. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Wed, Sep 24, 2008 at 11:54:24AM -0700, David Brownell wrote: [...] You'd be better off calling something other than of_get_gpio() for those three pins in of_fhci_probe() ... call something that returns a qe_pin structure (e.g. wrapping an instance of the misnamed qe_gpio_chip plus an offset) which holds the pinmux primitives you need. Like this one to put the pin into its normal mode. The driver anyway will have to call of_get_gpio(), because it have to use the pins as gpios. At least it have to specify a direction, luckily for this we have the gpio_set_direction call already. ;-) But true, switching a pin to a dedicated function isn't a gpio controller's job, it is a pinmuxing. When I look at patch 4 of this series I observe that only two pins are true GPIOs: the optional POWER and SPEED pins. (External transceiver support?) Yes. [...] And in turn, the reason to want this call is so that you can have io_port_generate_reset() generate a short reset on the single downstream USB port. (Short meaning 45 msec below USB spec requirements for root hub resets ...) And to top it off ... that driver does gpio_request(), runs those pins as GPIOs for virtually no time, and then uses them as dedicated functions the rest of the time (after the reset completes)!! Which highlights the fact that these pins are fundamentally NOT used as GPIOs. Well.. they are used as gpios anyway, to signal a reset. This is host's duty, and we have to support it, otherwise things won't work. There is no other way to signal a reset than turning these *pins* to a gpio state, setting the direction and then reverting them back to a dedicated function. But true, most of it isn't gpio controller's authority. [...] But there are other requirements for this no-kerneldoc call: + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc); ... it must be part of an of_mm_gpio_chip (in linux/of_gpio.h, which might seem less odd to me if I read its supporting code). Can you first ensure that it *is* an of_mm_gpio_chip instance? When it isn't, this code will oops rudely. Yeah, unfortunately. The oops thought didn't visit my mind though, because I'm still thinking it terms of this patch: http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051230.html ^^ with that patch no oops is possible, and we could detect anything you pointed out here and below in your post. Which doesn't mean that the patch above was ideologically correct, though. But you clearly pointed out the issues which ruin the whole approach. Anyway, just want to thank you for your time and persistence on this matter, you're forcing others' people brains to *work*. And since you rejected this approach too, I have no other option but to implement something else... something better. ;-) -- 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
Fix PCI in Holly device tree
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]
Index: working-2.6/arch/powerpc/boot/dts/holly.dts
===
--- working-2.6.orig/arch/powerpc/boot/dts/holly.dts2008-09-02
11:50:12.0 +1000
+++ working-2.6/arch/powerpc/boot/dts/holly.dts 2008-09-17 11:50:23.0
+1000
@@ -133,61 +133,61 @@
reg = 0x7400 0x0400;
big-endian;
};
+ };
- [EMAIL PROTECTED] {
- device_type = pci;
- compatible = tsi109-pci, tsi108-pci;
- #interrupt-cells = 1;
- #size-cells = 2;
- #address-cells = 3;
- reg = 0x1000 0x1000;
- bus-range = 0x0 0x0;
- /*+
- | PCI memory range.
- | 01 denotes I/O space
- | 02 denotes 32-bit memory space
- +*/
- ranges = 0x0200 0x 0x4000 0x4000
0x 0x1000
- 0x0100 0x 0x 0x7e00
0x 0x0001;
- clock-frequency = 13332;
- interrupt-parent = MPIC;
+ [EMAIL PROTECTED] {
+ device_type = pci;
+ compatible = tsi109-pci, tsi108-pci;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ reg = 0xc0001000 0x1000;
+ bus-range = 0x0 0x0;
+ /*+
+ | PCI memory range.
+ | 01 denotes I/O space
+ | 02 denotes 32-bit memory space
+ +*/
+ ranges = 0x0200 0x 0x4000 0x4000
0x 0x1000
+ 0x0100 0x 0x 0x7e00
0x 0x0001;
+ clock-frequency = 13332;
+ interrupt-parent = MPIC;
+ interrupts = 0x17 0x2;
+ interrupt-map-mask = 0xf800 0x0 0x0 0x7;
+ /*+
+ | The INTA, INTB, INTC, INTD are shared.
+ +*/
+ interrupt-map =
+ 0x800 0x0 0x0 0x1 RT0 0x24 0x0
+ 0x800 0x0 0x0 0x2 RT0 0x25 0x0
+ 0x800 0x0 0x0 0x3 RT0 0x26 0x0
+ 0x800 0x0 0x0 0x4 RT0 0x27 0x0
+
+ 0x1000 0x0 0x0 0x1 RT0 0x25 0x0
+ 0x1000 0x0 0x0 0x2 RT0 0x26 0x0
+ 0x1000 0x0 0x0 0x3 RT0 0x27 0x0
+ 0x1000 0x0 0x0 0x4 RT0 0x24 0x0
+
+ 0x1800 0x0 0x0 0x1 RT0 0x26 0x0
+ 0x1800 0x0 0x0 0x2 RT0 0x27 0x0
+ 0x1800 0x0 0x0 0x3 RT0 0x24 0x0
+ 0x1800 0x0 0x0 0x4 RT0 0x25 0x0
+
+ 0x2000 0x0 0x0 0x1 RT0 0x27 0x0
+ 0x2000 0x0 0x0 0x2 RT0 0x24 0x0
+ 0x2000 0x0 0x0 0x3 RT0 0x25 0x0
+ 0x2000 0x0 0x0 0x4 RT0 0x26 0x0
+ ;
+
+ RT0: [EMAIL PROTECTED] {
+ device_type = pic-router;
+ interrupt-controller;
+ big-endian;
+ clock-frequency = 0;
+ #address-cells = 0;
+ #interrupt-cells = 2;
Re: Merge linuxppc-embedded with linuxppc-dev
On Tue, Sep 23, 2008 at 6:20 AM, Grant Likely [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 4:11 PM, Mike Frysinger [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 18:08, Grant Likely [EMAIL PROTECTED] wrote: Jeremy, Can we eliminate the linuxppc-embedded mailing list and merge it with linuxppc-dev? I don't think we need two separate lists anymore and patches to linuxppc-embedded don't always get dealt with. Anyone have any objections to eliminating linuxppc-embedded? you sent this e-mail to linux-embedded instead of linuxppc-embedded -mike See! My point proven! That list just causes confusion. :-) Oops. I've cc'd the linuxppc-embedded list now. Sorry to all the non-powerpc linux-embedded folks for the noise. I agree. Given the fact that most active embedded people are already watching the linuxppc-dev list. It's a good idea for embedded people not having to subscribe two lists. But I don't know if non-embedded people would like this idea. - Leo ___ 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 Sep 24, 2008, at 4:16 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote: 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. No Milton, we must do it that way, because the EOI must be done on the right CPU even on XICS, or we won't get the CPU priority back properly. Ben and I had a online chat, and he pointed out I needed to be more specific in saying what I was thinking. I think the flows we want on xics are: (non-threaded) getirq (implicit source specific mask until eoi) handle interrupt eoi (implicit cpu priority restore) (threaded) getirq (implicit source specific mask until eoi) explicit cpu priority restore handle interrupt eoi (implicit cpu priority restore to same as explicit level) cpu takes interrupt, checks soft disabled if so, set hard disabled else call get_irq if threaded write cppr to restore this cpu irq dispatch state to non-interrupt mark irq thread as irq pending else handle interrupt eoi (cppr = base) irq thread will handle interrupt eoi wait for marked pending again The part Ben did not follow was that the cppr write to base priority is done by the interrupted cpu (like the mask and eoi in the current flow) and only the final eoi (where the mask is in the existing flow) is done on which ever cpu happens to run the irq thread. (optional) As I was discussing with Paul, when taking an irq when soft-disabled but still hard enabled, it is possible to write the cppr such that it would reject the pending irq and have it be considered for dispatch to another cpu. But it would increase pathlength on both the go-to-hard-disabled and return-from-hard-disabled and the hardware will have some latency as it will likely send it back to the io source until it retrys, so we would only want to do this if the hard-disable period is sufficiently long. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc/qe: new call to revert a gpio to a dedicated function
On Wednesday 24 September 2008, Anton Vorontsov wrote: Anyway, just want to thank you for your time and persistence on this matter, you're forcing others' people brains to *work*. And since you rejected this approach too, I have no other option but to implement something else... something better. ;-) I think you have enough pieces in place to get that something better _very_ quickly. Or I'd feel worse about abusing those poor little grey cells. ;) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
