* Re: [PATCH] [289/2many] MAINTAINERS - LINUX FOR POWERPC
From: Joe Perches @ 2007-08-13 17:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: paulus, akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <20070813061601.50bbefe0@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:16 -0500, Josh Boyer wrote:
> There's also the arch/ppc, include/asm-ppc directories until they get
> removed.
LINUX FOR POWERPC
P: Paul Mackerras
M: paulus@samba.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git
S: Supported
F: arch/powerpc/
F: arch/ppc/
F: include/asm-powerpc/
F: include/asm-ppc/
^ permalink raw reply
* Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
From: Joe Perches @ 2007-08-13 17:35 UTC (permalink / raw)
To: Josh Boyer; +Cc: torvalds, linux-kernel, akpm, linuxppc-embedded
In-Reply-To: <20070813061854.644e6e5e@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote:
> You're missing arch/ppc/platforms/4xx/, among other things.
> Also, we're in the middle of merging 4xx to arch/powerpc.
We can leave the whole block unmodified until you're ready.
LINUX FOR POWERPC EMBEDDED PPC4XX
P: Matt Porter
M: mporter@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
^ permalink raw reply
* Re: [PATCH] via-pmu: Fix typo in printk
From: Benjamin Herrenschmidt @ 2007-08-13 16:57 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200708122238.34985.mb@bu3sch.de>
On Sun, 2007-08-12 at 22:38 +0200, Michael Buesch wrote:
> This fixes a typo in a printk message.
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-2.6/drivers/macintosh/via-pmu.c
> ===================================================================
> --- linux-2.6.orig/drivers/macintosh/via-pmu.c 2007-05-26 19:56:27.000000000 +0200
> +++ linux-2.6/drivers/macintosh/via-pmu.c 2007-08-12 22:36:27.000000000 +0200
> @@ -410,7 +410,7 @@ static int __init via_pmu_start(void)
>
> irq = irq_of_parse_and_map(vias, 0);
> if (irq == NO_IRQ) {
> - printk(KERN_ERR "via-pmu: can't map interruptn");
> + printk(KERN_ERR "via-pmu: can't map interrupt\n");
> return -ENODEV;
> }
> if (request_irq(irq, via_pmu_interrupt, 0, "VIA-PMU", (void *)0)) {
>
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 16:52 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910708130950y38f60687ma7957cf42a758cdd@mail.gmail.com>
Another series is being posted to the Efika boards.
0001-powerpc-exports-rheap-symbol-to-modules.patch
0002-powerpc-Changes-the-config-mechanism-for-rheap.patch
0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch
0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch
0005-powerpc-BestcComm-ATA-task-support.patch
0006-powerpc-BestcComm-FEC-task-support.patch
0007-powerpc-BestcComm-GenBD-task-support.patch
0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch
0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch
0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch
0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch
0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch
0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch
0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch
0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch
0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch
0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch
0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch
0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch
0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch
0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch
0082-powerpc-pata_mpc52xx-suspend.patch
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 16:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708130934v912eda2r691d2db30a9bc17c@mail.gmail.com>
On 8/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 8/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > We're starting a new MPC5200 project and I'm trying to track down the
> > best kernel to start from. Is Sylvain's tree at
> > http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
> > from the web page don't work. Everything 5200 related in the trees at
> > Secret Labs already appears to be merged.
> >
> > Most of this work also appears to be in the Open Embedded tree's Ekifa
> > support. Is that a better place to start?
>
> It might be. The major problem with MPC5200 is the Ethernet driver.
> I believe both Domen and Sylvain have been working on drivers suitable
> for arch/powerpc inclusion.
OpenEmbedded has this series against 2.6.20
0001-powerpc-serial-Dispose-irq-mapping-when-done-in-mpc52xx_serial.c.txt
0003-powerpc-Add-device-tree-fixups-for-the-EFIKA.txt
0004-powerpc-Use-common-52xx-of_platform-probe-code-for-EFIKA.txt
0005-powerpc-Restore-proper-link-order-in-platform.txt
0006-Rework-the-OHCI-quirk-mecanism-as-suggested-by-David.txt
0007-Implement-support-for-split-endian-OHCI.txt
0008-ohci-Rework-bus-glue-integration-to-allow-several-at-once.txt
0009-ohci-Add-support-for-OHCI-controller-on-the-of_platform-bus.txt
0010-libata-Add-support-for-the-MPC52xx-ATA-controller.txt
0011-ohci-Whitespace-and-typo-fix-in-ohci-ppc-of.c.txt
0012-ata-Fix-pata_mpc52xx.c-compatible-list.txt
0013-powerpc-serial-Fix-mpc52xx_uart.c-compatible-list.txt
0014-powerpc-Small-cleanup-of-EFIKA-platform.txt
0015-powerpc-Add-a-unified-uevent-handler-for-bus-based-on-of_device.txt
0016-macintosh-Use-the-new-of_device-common-uevent-handler.txt
0017-powerpc-Add-uevent-handler-for-of_platform_bus.txt
0018-powerpc-Add-uevent-handler-for-ibmebus.txt
0019-MPC5200-Bestcomm-platform-driver.txt
0020-Fec-MPC5200-eth-driver.txt
0021-POWERPC-Copy-bestcomm-support-files-into-arch-powerpc.txt
0022-MPC52xx-PCI-now-working-on-lite5200.-ugly-but-working.txt
0023-POWERPC-Make-FEC-work-on-the-lite5200.txt
0024-Add-missing-function-prototype.txt
0025-POWERPC-Misc-EFIKA-fixups-for-rtas-chrp.txt
0026-POWERPC-Cleanup-mpc52xx-PCI-support.txt
0027-POWERPC-Change-name-of-mpc52xx-pci-support-file-in-Makefile.txt
0028-POWERPC-Change-link-order-so-mpc52xx-fec-always-shows-up-as-eth0.txt
0029-POWERPC-Fixup-pr_print-format-for-mpc52xx-pci-support.txt
0030-POWERPC-Add-mpc52xx-lite5200-PCI-support.txt
0031-sound-Add-support-for-the-MPC52xx-PSC-AC97-Link.txt
0032-POWERPC-EFIKA-Adds-missing-interrupts-from-bestcomm-node.txt
0033-EFIKA-fullduplex-prpl_aln.txt
defconfig
v4l.diff
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Grant Likely @ 2007-08-13 16:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910708130927l70163a80vf0362ee8649a6c29@mail.gmail.com>
On 8/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> We're starting a new MPC5200 project and I'm trying to track down the
> best kernel to start from. Is Sylvain's tree at
> http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
> from the web page don't work. Everything 5200 related in the trees at
> Secret Labs already appears to be merged.
>
> Most of this work also appears to be in the Open Embedded tree's Ekifa
> support. Is that a better place to start?
It might be. The major problem with MPC5200 is the Ethernet driver.
I believe both Domen and Sylvain have been working on drivers suitable
for arch/powerpc inclusion.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 16:27 UTC (permalink / raw)
To: linuxppc-embedded
We're starting a new MPC5200 project and I'm trying to track down the
best kernel to start from. Is Sylvain's tree at
http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
from the web page don't work. Everything 5200 related in the trees at
Secret Labs already appears to be merged.
Most of this work also appears to be in the Open Embedded tree's Ekifa
support. Is that a better place to start?
I need to get multiple I2S ports running with DMA.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Power Managment (mpc83xx)
From: Scott Wood @ 2007-08-13 16:11 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <6954FEB9E3130645ABAFEE8D5E2C7C141FE8B6@slydesvr.Slyde.local>
On Mon, Aug 13, 2007 at 02:44:50PM +0300, Yoni Levin wrote:
> I have mpc83xx, and I work with Linux 2.6
>
> I am trying to use power management states.
>
> I succeed to get into D1 state (echo standby > /sys/power/state),
That's actually closer to D3hot than D1. It uses sleep mode, but does
not power down the core.
> And to waked up by GPIO.
>
> But when I try tried echo mem > /sys/power/state it waked up by reset
> (that stuck in the middle)
You need u-boot support to resume from deep sleep on 831x. See the code
in the mpc8313erdb board files.
> Or echo disk > /sys/power/state didn't went to sleep at all.
There's no support for suspend-to-disk in my patchset.
-Scott
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Scott Wood @ 2007-08-13 15:57 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708130015430.3895@poirot.grange>
On Mon, Aug 13, 2007 at 12:27:30AM +0200, Guennadi Liakhovetski wrote:
> A number of Linkstation models from Buffalo Technology with PPC, ARM, and
> also MIPS (I think) CPUs have a power-management controller connected to a
> UART. Among other things that chip controlls power and reset buttons.
> Working on a standby support for one of these systems (ppc mpc8241 based),
> the only suitable wakeup source there is the power button, which means, I
> have to configure one of the two system UARTs to not be suspendsd. Using
> the device_*_wakeup API doesn't quite work because both serial ports share
> one device. The below patch proposes a new port flag UPF_MAY_WAKEUP to
> configure such UARTs. It also adds support for a new "can-wakeup" serial
> node property to the legacy_serial driver.
Shouldn't the ability to wakeup be configured through sysfs, rather than
encoded into the device tree? I'm assuming this is just a matter of
configuration, and not that the hardware supports waking from one and not
the other.
-Scott
^ permalink raw reply
* Re: Early UART setup on 2.6 kernel for mpc85xx
From: Scott Wood @ 2007-08-13 15:53 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90108D46267@EMPBEDEX.empirix.com>
On Mon, Aug 13, 2007 at 07:09:40AM -0400, Morrison, Tom wrote:
> >> In order to debug the kernel 2.6, I want setup serial port with
> >> UART on mpc85xx as early as possible. I add the register access
> >> code at the beginning of platform_init(). For example, I try
> >> to write THR register(0xe0004500). However the system just
> >> hanging there with this line.
Make sure there's a mapping in the TLB for that address.
> FWIW, you really can't debug the earliest init code
> because most of that is in assembly. Get a JTAG emulator
> (BDI or Lauterbach) and start stepping through.
It's quite possible to debug assembly code without JTAG. :-)
-Scott
^ permalink raw reply
* PCI BAR mapping problem
From: Johan Borkhuis @ 2007-08-13 14:11 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am having some problems with the initialization of BAR registers of
the PCI bus. I have a number of devices connected to the bus, which have
a BAR-size of less than PAGE_SIZE. For example:
01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
Subsystem: PLX Technology, Inc.: Unknown device 9656
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52
Memory at 00000000dfeffe00 (32-bit, non-prefetchable) [size=512]
I/O ports at e0ffff00 [size=256]
Memory at 00000000dfeffdc0 (32-bit, non-prefetchable) [size=64]
Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 0
Capabilities: [48] #00 [0080]
I want to access the PCI-areas from from user space, so I try to do an
mmap. The returned address is however rounded to multiple of PAGE_SIZE
(=0x1000). To access for example BAR0, I have to use the return-value
from mmap+0xE00. And in the above case, I am able to access the BAR0 and
BAR2 areas with only 1 mmap cal, as the 2 addresses are within one page.
The problem is that, when running my code on a I386 platform the BAR
registers are mapped at address 0x0 of the returned area.
When looking at the PCI init code (arch/ppc/syslib/pci_auto.c) I see
that the BAR-base address and/or size is not corrected for PAGE_SIZE. Is
this correct behaviour?
I could image the following line being changed from:
bar_value = (*upper_limit - bar_size) & ~(bar_size - 1);
to:
bar_value = ((*upper_limit - bar_size) & ~(bar_size - 1)) &
~(PAGE_SIZE-1);
The PCI area is assigned using a top-down method. Using this statement
the bar_value is rounded down to the first PAGE_SIZE boundary.
This gives the following output:
01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
Subsystem: PLX Technology, Inc.: Unknown device 9656
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52
Memory at 00000000dfeff000 (32-bit, non-prefetchable) [size=512]
I/O ports at e0fff000 [size=256]
Memory at 00000000dfefe000 (32-bit, non-prefetchable) [size=64]
Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 0
Capabilities: [48] #00 [0080]
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Re: [patch 10/10] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
From: Geert Uytterhoeven @ 2007-08-13 13:57 UTC (permalink / raw)
To: Michael Schmitz
Cc: linux-m68k, Dmitry Torokhov, debian-68k, linux-kernel, Finn Thain,
linuxppc-dev, linux-input, Andrew Morton, Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0708131531440.585@om.biophys.uni-duesseldorf.de>
On Mon, 13 Aug 2007, Michael Schmitz wrote:
> > > Anyone using mouseemu on m68k Mac?
> >
> > Yes, and on powermac too. It provides the paste key for gpm and I'm quite
> > fond of it. But if there's a better alternative, I'll happily try it
> > instead.
>
> Too much overhead on m68k? On powermac it never gave me trouble, but I was
> surprised to hear people use it on m68k.
>
> If it works OK, we can really drop the kernel support.
If it can be removed completely, for PowerMac, Mac/m68k, and IntelliMac (or
whatever it's called), fine for me! Please coordinate with the other
Mac people.
But for now, Linus, please apply, as the missing prototype causes a
broken Mac/m68k build.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [patch 10/10] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
From: Michael Schmitz @ 2007-08-13 13:35 UTC (permalink / raw)
To: Finn Thain
Cc: linux-m68k, Michael Schmitz, Dmitry Torokhov, debian-68k,
linux-kernel, linuxppc-dev, Geert Uytterhoeven, linux-input,
Andrew Morton, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0708132253530.21364@loopy.telegraphics.com.au>
> > Anyone using mouseemu on m68k Mac?
>
> Yes, and on powermac too. It provides the paste key for gpm and I'm quite
> fond of it. But if there's a better alternative, I'll happily try it
> instead.
Too much overhead on m68k? On powermac it never gave me trouble, but I was
surprised to hear people use it on m68k.
If it works OK, we can really drop the kernel support.
Michael
^ permalink raw reply
* Re: [patch 10/10] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
From: Finn Thain @ 2007-08-13 13:09 UTC (permalink / raw)
To: Michael Schmitz
Cc: linux-m68k, Dmitry Torokhov, debian-68k, linux-kernel,
linuxppc-dev, Geert Uytterhoeven, linux-input, Andrew Morton,
Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0708131432560.32732@om.biophys.uni-duesseldorf.de>
On Mon, 13 Aug 2007, Michael Schmitz wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
>
> With buttons emulation being available via uinput event devices, do we
> still need the kernel mouse button emulation? At least on powerpc, it
> was declared deprecated long ago ...
>
> Anyone using mouseemu on m68k Mac?
Yes, and on powermac too. It provides the paste key for gpm and I'm quite
fond of it. But if there's a better alternative, I'll happily try it
instead.
-f
>
> Michael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: MPC755 L2 Cache data parity error
From: Chuck Brown @ 2007-08-13 13:07 UTC (permalink / raw)
To: linuxppc-embedded
Did you ever solve this problem? I have a module with a similar
architecture as the one you described and I can get this same data parity
failure just by making the L2 cache private memory and copying a file into
the L2 cache.
Thanks
Chuck Brown
^ permalink raw reply
* Re: [patch 10/10] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
From: Michael Schmitz @ 2007-08-13 12:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, Dmitry Torokhov, debian-68k, linux-kernel,
linuxppc-dev, linux-input, Andrew Morton, Linus Torvalds
In-Reply-To: <20070812094119.910815432@mail.of.borg>
> From: Geert Uytterhoeven <geert@linux-m68k.org>
>
> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
With buttons emulation being available via uinput event devices, do we
still need the kernel mouse button emulation? At least on powerpc, it was
declared deprecated long ago ...
Anyone using mouseemu on m68k Mac?
Michael
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: Valentine Barshak @ 2007-08-13 12:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, David Gibson
In-Reply-To: <20070813010848.GC18526@localhost.localdomain>
David Gibson wrote:
> On Fri, Aug 03, 2007 at 04:23:46PM +1000, David Gibson wrote:
>> On Fri, Aug 03, 2007 at 02:57:05PM +1000, David Gibson wrote:
>>> On Fri, Aug 03, 2007 at 11:18:09AM +1000, Benjamin Herrenschmidt wrote:
>>>> On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
>>>>> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
>>>>>> PPC44x cascade UIC irq handler fix.
>>>>>>
>>>>>> According to PPC44x UM, if an interrupt is configured as level-sensitive,
>>>>>> and a clear is attempted on the UIC_SR, the UIC_SR field is not
>>>>>> cleared if the incoming interrupt signal is at the asserted polarity.
>>>>>> This causes us to enter a cascade handler twice, since we first ack
>>>>>> parent UIC interrupt and ack child UIC one after that.
>>>>>> The patch checks child UIC msr value and returns IRQ_HANDLED
>>>>>> if there're no pending interrupts. Otherwise we get a kernel panic
>>>>>> with a "Fatal exception in interrupt" (illegal vector).
>>>>>> The patch also fixes status flags.
>>>>>>
>>>>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>>>> Hrm... This doesn't seem like the right fix to me. Instead, I think
>>>>> the cascaded IRQ handler should ack the interrupt on the child first.
>>>>> I'm a little surprised it doesn't at the moment.
>>>> Well, we certainly do also need to make the code more solid vs.
>>>> spurrious interrupts.
>>> Actually that's true. The suggested patch is a good improvement for
>>> general robustness, but doesn't actually address the real problem.
>>>
>>>> The main thing is, if the cascade is a level interrupt, it should
>>>> probably use a smarter cascade handler that masks it, handle the child
>>>> interrupts, then unmasks it.
>>> We already have that, since I just use setup_irq() to set up a cascade
>>> handler, rather than a custom flow handler.
>>>
>>> The problem is that the standard handle_level_irq() flow handler acks
>>> before the ISR is called, whereas because of this UIC behaviour, we
>>> need to ack after the ISR has cleared the interrupt in the source.
>>> This is not specific to cascades, but is a problem for all
>>> level-triggered interrupts (i.e. basically everything).
>>>
>>> I think it means we must currently be getting a whole lot of spurious
>>> interrupts - will do some investigation in a moment.
>>>
>>> To fix this either we'll need a custom flow handler for UIC, or we can
>>> use the standard one, but clear the UIC_SR bits from the ->unmask()
>>> callback for level interrupts. I'm not entirely sure if the latter
>>> approach is safe - I *think* it is, but I could do with more
>>> convincing.
>> Ok, here's a patch which fixes up the flow handling on the UIC. It
>> needs some polish yet, but should be ok to test. Valentine, can you
>> test this on your setup, *without* your original proposed patch.
>> Eventually, for robustness, we'll want something like your original
>> patch as well for robustness, but in the meantime leaving it out
>> should tell us if my patch is actually having the intended effect.
>
> Valentine, it would be really helpful if you could test this on the
> problem you observed with the cascade interrupt. Any word on this?
>
Thanks David,
the patch works fine here (without the original one).
Don't think we really need a "fastcall" here on a powerpc though.
The original patch also fixes a minor issue with /proc/interrupts
(the the "if (trigger)" stuff).
Currently level-triggered interrupts are displayed as edge-triggered
ones and vice versa.
Thanks,
Valentine.
^ permalink raw reply
* Power Managment (mpc83xx)
From: Yoni Levin @ 2007-08-13 11:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
I have mpc83xx, and I work with Linux 2.6
I am trying to use power management states.
I succeed to get into D1 state (echo standby > /sys/power/state),
And to waked up by GPIO.
But when I try tried echo mem > /sys/power/state it waked up by reset
(that stuck in the middle)
Or echo disk > /sys/power/state didn't went to sleep at all.
There is a way to get into economic power state (less power then D1
(standby)) and to wake up fast?
[-- Attachment #2: Type: text/html, Size: 3677 bytes --]
^ permalink raw reply
* Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
From: Josh Boyer @ 2007-08-13 11:18 UTC (permalink / raw)
To: joe; +Cc: torvalds, linux-kernel, akpm, linuxppc-embedded
In-Reply-To: <46bffaaf.2ObqORfh5YL/9ILj%joe@perches.com>
On Sun, 12 Aug 2007 23:31:11 -0700
joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0862965..38810b7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2804,6 +2804,8 @@ M: mporter@kernel.crashing.org
> W: http://www.penguinppc.org/
> L: linuxppc-embedded@ozlabs.org
> S: Maintained
> +F: arch/ppc/syslib/ppc4xx_*
> +F: include/asm-ppc/ppc4xx_*
You're missing arch/ppc/platforms/4xx/, among other things. Also, we're
in the middle of merging 4xx to arch/powerpc.
josh
^ permalink raw reply
* Re: [PATCH] [289/2many] MAINTAINERS - LINUX FOR POWERPC
From: Josh Boyer @ 2007-08-13 11:16 UTC (permalink / raw)
To: joe; +Cc: paulus, akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <46bffaa9.Up0nOpoPeVCIyvqc%joe@perches.com>
On Sun, 12 Aug 2007 23:31:05 -0700
joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c643ebe..1d1da70 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2775,6 +2775,8 @@ W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git
> S: Supported
> +F: arch/powerpc
> +F: include/asm-powerpc/
There's also the arch/ppc, include/asm-ppc directories until they get
removed.
josh
^ permalink raw reply
* Re: [PATCH] [298/2many] MAINTAINERS - LINUX FOR 64BIT POWERPC
From: Josh Boyer @ 2007-08-13 11:15 UTC (permalink / raw)
To: joe
Cc: anton, linux-kernel, linuxppc-dev, paulus, anton, paulus,
torvalds, akpm
In-Reply-To: <46bffaba.dVM9Q/vXNeROaC6B%joe@perches.com>
On Sun, 12 Aug 2007 23:31:22 -0700
joe@perches.com wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6d10932..36c4960 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2857,6 +2857,9 @@ M: anton@au.ibm.com
> W: http://www.penguinppc.org/ppc64/
> L: linuxppc-dev@ozlabs.org
> S: Supported
> +F: arch/powerpc/configs/ppc64_defconfig
> +F: arch/powerpc/kernel/proc_ppc64.c
> +F: include/asm-powerpc/pgtable-ppc64.h
Erm, there's a lot more to 64-bit PowerPC than those 3 files. You're
better off just doing arch/powerpc/, include/asm-powerpc.
josh
^ permalink raw reply
* RE: Early UART setup on 2.6 kernel for mpc85xx
From: Morrison, Tom @ 2007-08-13 11:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.1.1186797602.26064.linuxppc-dev@ozlabs.org>
>> In order to debug the kernel 2.6, I want setup serial port with=20
>> UART on mpc85xx as early as possible. I add the register access=20
>> code at the beginning of platform_init(). For example, I try=20
>> to write THR register(0xe0004500). However the system just=20
>> hanging there with this line.
<snip everything else>
If you are using a relatively new kernel like I am starting=20
up with - you don't need to add anything - you can use the
"Early Debugging/Early Console" which defines PPC_EARLY_DEBUG
You can find this in the kernel hacking options when you=20
go in and configure your linux kernel.
This causes the udbg serial driver to be initialized, and=20
99% of the early debug output is already put to the screen.
This hands the serial port over to the console driver later
on in the boot, and it works great (good job whoever wrote
this piece - more than a helpful tool!).
FWIW, you really can't debug the earliest init code=20
because most of that is in assembly. Get a JTAG emulator
(BDI or Lauterbach) and start stepping through.
Tom Morrison
^ permalink raw reply
* RE: Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
From: Morrison, Tom @ 2007-08-13 11:01 UTC (permalink / raw)
To: Andy Fleming, Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <3A76C14A-4A1C-48FA-9BEA-39020A131084@freescale.com>
It turns out that Andy was right and I had not understand the=20
NEW MPIC format for the definition of the external interrupts.
This was different than the 2.6.11++ kernel...
Thank you Ben & Andy for your suggestions, unfortunately,
I had to learn the hard way that it was more fundamental
than I had imagined...
I continue to have problems, but I will itemize those in a
separate email.
Tom Morrison
-----Original Message-----
From: Andy Fleming [mailto:afleming@freescale.com]=20
Sent: Monday, August 06, 2007 2:10 PM
To: Morrison, Tom
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Trying to use Device Tree...and getting continuous
interrupts from attached 88e1145
<Snip>
>>> mdio@24520 {
>>> #address-cells =3D <1>;
>>> #size-cells =3D <0>;
>>> device_type =3D "mdio";
>>> compatible =3D "gianfar";=09
>>> reg =3D <24520 20>;
>>> phy1: ethernet-phy@1 {
>>> interrupt-parent =3D <&mpic>;
>>> interrupts =3D <37 1>;
> How recent of a kernel are you using? The current kernel assigns=20
> the external interrupts to be the low 12 interrupts, which would make
> your interrupt assignment wrong.
^ permalink raw reply
* Re: basic and stupid question on wait_event and wake_up
From: Ming Liu @ 2007-08-13 9:46 UTC (permalink / raw)
To: domen.puncer; +Cc: Linuxppc-embedded
In-Reply-To: <20070813093107.GG13994@moe.telargo.com>
Thank you so much for your explanation. Now I am quite clear on this topic.
Domen, Sorry for my misspelling of your name. That should be "Domen" not
"Momen". Sorry for that. :)
BR
Ming
>From: Domen Puncer <domen.puncer@telargo.com>
>To: Ming Liu <eemingliu@hotmail.com>
>CC: Linuxppc-embedded@ozlabs.org
>Subject: Re: basic and stupid question on wait_event and wake_up
>Date: Mon, 13 Aug 2007 11:31:07 +0200
>
>On 13/08/07 09:22 +0000, Ming Liu wrote:
> > Dear Momen,
> > OK. I see now. So you mean condition is only to judge whether a
sleeping
> > process could be waken up or not when wake_up() is executed in other
> > processes or interrupt handlers. What really wakes the process up is
still
> > the function of wake_up, right? We just execute wake_up() and then
check if
> > condition is true. If yes, the process will leave its sleeping and wake
up;
> > if not, it keep sleeping. Am I right?
>
>Right.
>
>
> Domen
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: basic and stupid question on wait_event and wake_up
From: Domen Puncer @ 2007-08-13 9:31 UTC (permalink / raw)
To: Ming Liu; +Cc: Linuxppc-embedded
In-Reply-To: <BAY138-F307C7D793CEC734113D325B2DC0@phx.gbl>
On 13/08/07 09:22 +0000, Ming Liu wrote:
> Dear Momen,
> OK. I see now. So you mean condition is only to judge whether a sleeping
> process could be waken up or not when wake_up() is executed in other
> processes or interrupt handlers. What really wakes the process up is still
> the function of wake_up, right? We just execute wake_up() and then check if
> condition is true. If yes, the process will leave its sleeping and wake up;
> if not, it keep sleeping. Am I right?
Right.
Domen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox