* Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
From: Andreas Schwab @ 2010-05-31 9:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev
In-Reply-To: <FAE73713-EE73-4FA6-B1C6-88D38E230F01@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote:
>
>> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote:
>>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> ---
>>> arch/powerpc/kernel/ppc_ksyms.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> Alex, this is just a temporary fix to remove the build breakage for 40x
>> etc... but please, update KVM to just build-in its own.
>
> What's the bad part in reusing the existing code?
The bad part is that KVM is wasting a ridiculous amount of stack space
by allocating multiple instances of struct task_struct on it. I have a
patch removing all of it, but I haven't tested it yet.
Andreas.
--
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
From: Alexander Graf @ 2010-05-31 9:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1275271231.1931.547.camel@pasglop>
On 31.05.2010, at 04:00, Benjamin Herrenschmidt wrote:
> On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote:
>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> ---
>> arch/powerpc/kernel/ppc_ksyms.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Alex, this is just a temporary fix to remove the build breakage for 40x
> etc... but please, update KVM to just build-in its own.
What's the bad part in reusing the existing code?
> Don't we have .o's that are always built into modules nowadays ?
I don't think I understand what you mean.
Alex
^ permalink raw reply
* Re: halt the system without any broadcast message on the console
From: Benjamin Herrenschmidt @ 2010-05-31 9:17 UTC (permalink / raw)
To: Bosi Daniele; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <531B6536C9F737458807DF75064873C8BE62B40C49@mta-digimail.MTA.INT>
On Thu, 2010-05-27 at 17:39 +0200, Bosi Daniele wrote:
>
> I'd like to avoid this message on the console I'm using because at
> production time this has to be a simple serial port for external
> peripheral connection. (to do this on the command line we'll leave
> empty the "console" field).
I'm not sure I understand.
If the serial port has to talk to an external periph, then you don't
want the console on it, in which case it will not have the broadcast
messages. If it's a console, then it will get them ... along with
everything else a console gets.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
From: Peter Zijlstra @ 2010-05-31 8:33 UTC (permalink / raw)
To: Michael Neuling
Cc: Suresh Siddha, Gautham R Shenoy, linux-kernel, linuxppc-dev,
Ingo Molnar
In-Reply-To: <1271426308.1674.429.camel@laptop>
On Fri, 2010-04-16 at 15:58 +0200, Peter Zijlstra wrote:
>=20
>=20
> Hrmm, my brain seems muddled but I might have another solution, let me
> ponder this for a bit..
>=20
Right, so the thing I was thinking about is taking the group capacity
into account when determining the capacity for a single cpu.
Say the group contains all the SMT siblings, then use the group capacity
(usually larger than 1024) and then distribute the capacity over the
group members, preferring CPUs with higher individual cpu_power over
those with less.
So suppose you've got 4 siblings with cpu_power=3D294 each, then we assign
capacity 1 to the first member, and the remaining 153 is insufficient,
and thus we stop and the rest lives with 0 capacity.
Now take the example that the first sibling would be running a heavy RT
load, and its cpu_power would be reduced to say, 50, then we still got
nearly 933 left over the others, which is still sufficient for one
capacity, but because the first sibling is low, we'll assign it 0 and
instead assign 1 to the second, again, leaving the third and fourth 0.
If the group were a core group, the total would be much higher and we'd
likely end up assigning 1 to each before we'd run out of capacity.
For power savings, we can lower the threshold and maybe use the maximal
individual cpu_power in the group to base 1 capacity from.
So, suppose the second example, where sibling0 has 50 and the others
have 294, you'd end up with a capacity distribution of: {0,1,1,1}.
^ permalink raw reply
* Re: [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
From: Benjamin Herrenschmidt @ 2010-05-31 2:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexander Graf
In-Reply-To: <1275270628.1931.540.camel@pasglop>
On Mon, 2010-05-31 at 11:50 +1000, Benjamin Herrenschmidt wrote:
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/ppc_ksyms.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Alex, this is just a temporary fix to remove the build breakage for 40x
etc... but please, update KVM to just build-in its own.
Don't we have .o's that are always built into modules nowadays ?
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch (or not...)
From: Benjamin Herrenschmidt @ 2010-05-31 1:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
So some of these you might decide are too late, in which case I'll just
make this branch my -next for the next cycle and cherry pick a few bug
fixes.
It's some embedded changes, not all fixes, that are late mostly because
I forgot to pull from Josh (the stuff was submitted and reviewed ages
ago and is pretty low risk), and in the case of Kumar, because his a
manager now which sucks :-)
I think they are ok in that they only have a potential to break their
respective embedded platforms, but I'll let you judge.
Cheers,
Ben.
The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linus Torvalds (1):
Linux 2.6.35-rc1
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
Anatolij Gustschin (1):
powerpc/44x: icon: select SM502 and frame buffer console support
Andy Fleming (1):
powerpc/85xx: Enable support for ports 3 and 4 on 8548 CDS
Anton Vorontsov (1):
powerpc/fsl-booke: Add hibernation support for FSL BookE processors
Benjamin Herrenschmidt (4):
powerpc/44x: Fix UART clocks on 440SPe
Merge commit 'jwb/next' into next
Merge commit 'kumar/next' into next
powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
Haiying Wang (1):
powerpc/85xx: Add P1021MDS board support
Lan Chunhe-B25806 (1):
powerpc/fsl_msi: Add multiple MSI bank support
Li Yang (5):
powerpc/fsl_msi: fix the conflict of virt_msir's chip_data
powerpc/fsl_msi: enable msi allocation in all banks
powerpc/fsl_msi: enable msi sharing through AMP OSes
powerpc/fsl_msi: add removal path and probe failing path
powerpc/85xx: Change MPC8572DS camp dtses for MSI sharing
Scott Wood (1):
powerpc/e500mc: Implement machine check handler.
Sebastian Andrzej Siewior (3):
powerpc/fsl-booke: fix the case where we are not in the first page
powerpc/fsl-booke: Move the entry setup code into a seperate file
powerpc/kexec: Add support for FSL-BookE
Stefan Roese (2):
powerpc/44x: Add reset-type to katmai.dts
powerpc/44x: Add basic ICON PPC440SPe board support
Tirumala Marri (1):
powerpc/44x: Adding PCI-E support for PowerPC 460SX based SOC.
arch/powerpc/Kconfig | 2 +-
arch/powerpc/boot/4xx.c | 12 +-
arch/powerpc/boot/dts/icon.dts | 447 ++++++++
arch/powerpc/boot/dts/katmai.dts | 1 +
arch/powerpc/boot/dts/mpc8548cds.dts | 4 -
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 15 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 7 +-
arch/powerpc/boot/dts/p1021mds.dts | 698 ++++++++++++
arch/powerpc/boot/dts/redwood.dts | 122 ++
arch/powerpc/configs/44x/icon_defconfig | 1451 ++++++++++++++++++++++++
arch/powerpc/include/asm/cputable.h | 1 +
arch/powerpc/include/asm/kexec.h | 13 +
arch/powerpc/include/asm/reg_booke.h | 33 +-
arch/powerpc/kernel/Makefile | 8 +-
arch/powerpc/kernel/cputable.c | 2 +-
arch/powerpc/kernel/crash.c | 4 +
arch/powerpc/kernel/fsl_booke_entry_mapping.S | 237 ++++
arch/powerpc/kernel/head_fsl_booke.S | 200 +----
arch/powerpc/kernel/misc_32.S | 17 +
arch/powerpc/kernel/ppc_ksyms.c | 2 +-
arch/powerpc/kernel/swsusp_booke.S | 193 ++++
arch/powerpc/kernel/traps.c | 88 ++-
arch/powerpc/platforms/44x/Kconfig | 11 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 3 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 102 ++-
arch/powerpc/sysdev/fsl_msi.c | 117 ++-
arch/powerpc/sysdev/fsl_msi.h | 3 +
arch/powerpc/sysdev/ppc4xx_pci.c | 119 ++
arch/powerpc/sysdev/ppc4xx_pci.h | 58 +
29 files changed, 3712 insertions(+), 258 deletions(-)
create mode 100644 arch/powerpc/boot/dts/icon.dts
create mode 100644 arch/powerpc/boot/dts/p1021mds.dts
create mode 100644 arch/powerpc/configs/44x/icon_defconfig
create mode 100644 arch/powerpc/kernel/fsl_booke_entry_mapping.S
create mode 100644 arch/powerpc/kernel/swsusp_booke.S
^ permalink raw reply
* [PATCH] powerpc: Don't export cvt_fd & _df when CONFIG_PPC_FPU is not set
From: Benjamin Herrenschmidt @ 2010-05-31 1:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexander Graf
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/ppc_ksyms.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index bc9f39d..3b4dcc8 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -101,7 +101,7 @@ EXPORT_SYMBOL(pci_dram_offset);
EXPORT_SYMBOL(start_thread);
EXPORT_SYMBOL(kernel_thread);
-#ifndef CONFIG_BOOKE
+#ifdef CONFIG_PPC_FPU
EXPORT_SYMBOL_GPL(cvt_df);
EXPORT_SYMBOL_GPL(cvt_fd);
#endif
^ permalink raw reply related
* Re: mmio_nvram.c users ?
From: Benjamin Herrenschmidt @ 2010-05-30 5:13 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <201005300254.22984.arnd@arndb.de>
On Sun, 2010-05-30 at 02:54 +0200, Arnd Bergmann wrote:
> The reason we have the driver is so that we're able to use the kernel
> internal functions for arch/powerpc/kernel/nvram_64.c on it, which
> operated on the well-defined interface for partitions inside of the
> nvram memory.
>
> mtd/phram provides a completely different abstraction, which is normally
> used for block- or file system based access. They also both have
> the character device, but that's not really the main point.
>
> The part that is unfortunate is the device_type matching in the driver,
> which was a result of clueluess firmware and Linux developers (i.e. me)
> at the time.
Right. Which is why I want to change it to be a platform device, so that
platforms explicitely instanciate it, which is probably the best thing
for now. That way, platforms that don't want the ppc specific nvram
stuff don't have to instanciate it, or platforms who want to use the mtd
bits, etc...
Cheers,
Ben.
^ permalink raw reply
* Re: mmio_nvram.c users ?
From: Benjamin Herrenschmidt @ 2010-05-29 23:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20100529134143.GL24511@zod.rchland.ibm.com>
On Sat, 2010-05-29 at 09:41 -0400, Josh Boyer wrote:
>
> Probably. Maybe we shouldn't have duplicated a driver in our platform
> code to begin with.
I believe our nvram infrastructure predates it by a long shot :-)
powerpc /dev/nvram stuff is very very very ancient.
Cheers,
Ben.
^ permalink raw reply
* Re: mmio_nvram.c users ?
From: Arnd Bergmann @ 2010-05-30 0:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20100529134143.GL24511@zod.rchland.ibm.com>
On Saturday 29 May 2010, Josh Boyer wrote:
> On Sat, May 29, 2010 at 01:45:04PM +1000, Benjamin Herrenschmidt wrote:
> >On Tue, 2010-05-25 at 07:00 -0400, Josh Boyer wrote:
> >> On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
> >> >Hi folks !
> >> >
> >> >Anybody aware of anything other than Cell using that driver ?
> >> >
> >> >I'd like to make it a platform driver instead of having something that
> >> >pokes at anything that has a "device_type" set to "nvram" (which is
> >> >gross and bogus). But I need to know what platforms to fixup...
> >>
> >> Why bother? You could just use either drivers/mtd/devices/{phram.c or slram.c}
> >> and get the same functionality at that point, couldn't you?
> >
> >Won't that break existing userspace ?
>
> Probably. Maybe we shouldn't have duplicated a driver in our platform code to
> begin with.
The reason we have the driver is so that we're able to use the kernel
internal functions for arch/powerpc/kernel/nvram_64.c on it, which
operated on the well-defined interface for partitions inside of the
nvram memory.
mtd/phram provides a completely different abstraction, which is normally
used for block- or file system based access. They also both have
the character device, but that's not really the main point.
The part that is unfortunate is the device_type matching in the driver,
which was a result of clueluess firmware and Linux developers (i.e. me)
at the time.
Arnd
^ permalink raw reply
* Re: mmio_nvram.c users ?
From: Josh Boyer @ 2010-05-29 13:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <1275104704.1931.528.camel@pasglop>
On Sat, May 29, 2010 at 01:45:04PM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2010-05-25 at 07:00 -0400, Josh Boyer wrote:
>> On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
>> >Hi folks !
>> >
>> >Anybody aware of anything other than Cell using that driver ?
>> >
>> >I'd like to make it a platform driver instead of having something that
>> >pokes at anything that has a "device_type" set to "nvram" (which is
>> >gross and bogus). But I need to know what platforms to fixup...
>>
>> Why bother? You could just use either drivers/mtd/devices/{phram.c or slram.c}
>> and get the same functionality at that point, couldn't you?
>
>Won't that break existing userspace ?
Probably. Maybe we shouldn't have duplicated a driver in our platform code to
begin with.
josh
^ permalink raw reply
* Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
From: Albert Cahalan @ 2010-05-29 10:31 UTC (permalink / raw)
To: linux-kernel, sukadev, randy.dunlap, linuxppc-dev
Sukadev Bhattiprolu writes:
> Randy Dunlap [randy.dunlap at oracle.com] wrote:
>>> base of the region allocated for stack. These architectures
>>> must pass in the size of the stack-region in ->child_stack_size.
>>
>> stack region
>>
>> Seems unfortunate that different architectures use
>> the fields differently.
>
> Yes and no. The field still has a single purpose, just that
> some architectures may not need it. We enforce that if unused
> on an architecture, the field must be 0. It looked like
> the easiest way to keep the API common across architectures.
Yuck. You're forcing userspace to have #ifdef messes or,
more likely, just not work on all architectures. There is
no reason to have field usage vary by architecture. The
original clone syscall was not designed with ia64 and hppa
in mind, and has been causing trouble ever since. Let's not
perpetuate the problem.
Given code like this: stack_base = malloc(stack_size);
stack_base and stack_size are what the kernel needs.
I suspect that you chose the defective method for some reason
related to restarting processes that were created with the
older system calls. I can't say most of us even care, but in
that broken-already case your process restarter can make up
some numbers that will work. (for i386, the base could be the
lowest address in the vma in which %esp lies, or even address 0)
A related issue is that stack allocation and deallocation can
be quite painful: it is difficult (some assembly required) to
free one's own stack, and impossible if one is already dead.
We could use a flag to let the kernel handle allocation, with
the stack getting freed just after any ptracer gets a last look.
This issue is especially troublesome for me because the syscall
essentially requires per-thread memory to work; it is currently
extremely difficult to use the syscall in code which lacks that.
^ permalink raw reply
* Re: [PATCH] fs_enet: Adjust BDs after tx error
From: David Miller @ 2010-05-29 7:16 UTC (permalink / raw)
To: mware; +Cc: linuxppc-dev, vbordug, netdev
In-Reply-To: <4BFDC6EC.9090804@elphinstone.net>
From: Mark Ware <mware@elphinstone.net>
Date: Thu, 27 May 2010 11:12:12 +1000
> This patch fixes an occasional transmit lockup in the mac-fcc which
> occurs after a tx error. The test scenario had the local port set
> to autoneg and the other end fixed at 100FD, resulting in a large
> number of late collisions.
>
> According to the MPC8280RM 30.10.1.3 (also 8272RM 29.10.1.3), after
> a tx error occurs, TBPTR may sometimes point beyond BDs still marked
> as ready. This patch walks back through the BDs and points TBPTR to
> the earliest one marked as ready.
>
> Tested on a custom board with a MPC8280.
>
> Signed-off-by: Mark Ware <mware@elphinstone.net>
Applied, thanks.
^ permalink raw reply
* Linux 2.6.x: arch powerpc: PCI DMA allocation misunderstandings
From: Laurent Lagrange @ 2010-05-28 14:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <000901caab49$98517d00$a501a8c0@GEGE6600V>
Hello,
I use a 82xx or 85xx host platform with a Linux 2.6.24 or 2.2.31.
On this host, I want to write a PCI driver for a target PMC device
wich only supports 30bits (1GB) DMA addressing.
The PMC device is the master of the DMA transfers from/to the host memory.
In the host driver, I begin to set the two DMA masks with
- pci_set_dma_mask(pdev, DMA_BIT_MASK(30)) and
- pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(30))
Then I allocate DMA buffers in the host memory with
- pci_alloc_consistent or
- pci_pool_create and pci_pool_alloc
My problem is that the alloc functions return physical addresses
which are coherent with 32bits but not with the wanted 30bits.
The allocations seem to work like a kmalloc with a GFP_DMA flag.
On powerpc architecture, GFP_DMA preserves the allocations on 32bits
unlike on x86 architecture which restrict the allocations on 24bits.
I don't understand why it is recommended to use the PCI DMA API
with the DMA masks if the final allocator is only able to
use a GFP_DMA-like restriction and not a real provided mask.
Surely I missed something...
Any idea would be welcome.
Thanks
Laurent
^ permalink raw reply
* Re: mmio_nvram.c users ?
From: Benjamin Herrenschmidt @ 2010-05-29 3:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20100525110050.GH24511@zod.rchland.ibm.com>
On Tue, 2010-05-25 at 07:00 -0400, Josh Boyer wrote:
> On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
> >Hi folks !
> >
> >Anybody aware of anything other than Cell using that driver ?
> >
> >I'd like to make it a platform driver instead of having something that
> >pokes at anything that has a "device_type" set to "nvram" (which is
> >gross and bogus). But I need to know what platforms to fixup...
>
> Why bother? You could just use either drivers/mtd/devices/{phram.c or slram.c}
> and get the same functionality at that point, couldn't you?
Won't that break existing userspace ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC: Remove hardcoded BAT configuration of IMMR in CPM early debug console
From: Benjamin Herrenschmidt @ 2010-05-29 3:37 UTC (permalink / raw)
To: Scott Wood; +Cc: Martyn Welch, linuxppc-dev
In-Reply-To: <4BFFECF1.9060809@freescale.com>
On Fri, 2010-05-28 at 11:18 -0500, Scott Wood wrote:
> Only the physical address should depend on where IMMR is. We should
> use
> fixmap instead of an arbitrary address for the effective address.
> There's a existing FIX_EARLY_DEBUG_BASE, but it's only 128 KiB so
> we'll
> have to either grow it, or map only a subset of IMMR.
>
> Plus, CONFIG_PPC_EARLY_DEBUG_CPM_ADDR points to the TX descriptor,
> not
> to the beginning of IMMR, so you should mask off the lower 20 bits
> (the
> offset is probably less than 64K, and the BAT might just ignore the
> extra bits anyway, but why take chances?).
BAT has other advantages such as limiting TLB usage for things that are
used often. I think we might want to revive Grant work on early ioremap
here :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3] powerpc: Add i8042 keyboard and mouse irq parsing
From: Benjamin Herrenschmidt @ 2010-05-29 3:35 UTC (permalink / raw)
To: Grant Likely
Cc: Martyn Welch, linuxppc-dev, devicetree-discuss, Dmitry Torokhov,
linux-input
In-Reply-To: <AANLkTikve-ZghgpVl3cyjjgWAch-oCJ0EiYK2127f5gS@mail.gmail.com>
> The patch looks okay to me.
>
> BTW, where is the i8042 binding documented? Ben, is this location of
> the kbd/mouse irq historical, or is it just something that we happened
> to get when the .dts files were first created? Having the irq
> specified directly in the kbd or aux nodes would make a lot more
> sense, and if this isn't something already nailed down, then it
> probably does make sense to move the irq specification, fall back to
> the parent node to still support older trees, and with the hard coded
> irq numbers as the last resort.
That's just ISA crap. It should be in the existing OF bindings.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3] powerpc: Add i8042 keyboard and mouse irq parsing
From: Benjamin Herrenschmidt @ 2010-05-29 3:35 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev, Dmitry Torokhov, linux-input
In-Reply-To: <20100525080834.29149.70967.stgit@ES-J7S4D2J.amer.consind.ge.com>
O
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index 48f0a00..3d169bb 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -94,6 +94,10 @@ struct screen_info screen_info = {
> .orig_video_points = 16
> };
>
> +/* Variables required to store legacy IO irq routing */
> +int of_i8042_kbd_irq;
> +int of_i8042_aux_irq;
Is there a reasonable ifdef to use for the above or we don't care ?
> #ifdef __DO_IRQ_CANON
> /* XXX should go elsewhere eventually */
> int ppc_do_canonicalize_irqs;
> @@ -567,6 +571,15 @@ int check_legacy_ioport(unsigned long base_port)
> np = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
> if (np) {
> parent = of_get_parent(np);
> +
> + of_i8042_kbd_irq = irq_of_parse_and_map(parent, 0);
> + if (!of_i8042_kbd_irq)
> + of_i8042_kbd_irq = 1;
> +
> + of_i8042_aux_irq = irq_of_parse_and_map(parent, 1);
> + if (!of_i8042_aux_irq)
> + of_i8042_aux_irq = 12;
> +
> of_node_put(np);
> np = parent;
> break;
> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
> index 847f4aa..5d48bb6 100644
> --- a/drivers/input/serio/i8042-io.h
> +++ b/drivers/input/serio/i8042-io.h
> @@ -27,6 +27,11 @@
> #include <asm/irq.h>
> #elif defined(CONFIG_SH_CAYMAN)
> #include <asm/irq.h>
> +#elif defined(CONFIG_PPC)
> +extern int of_i8042_kbd_irq;
> +extern int of_i8042_aux_irq;
> +# define I8042_KBD_IRQ of_i8042_kbd_irq
> +# define I8042_AUX_IRQ of_i8042_aux_irq
> #else
> # define I8042_KBD_IRQ 1
> # define I8042_AUX_IRQ 12
Now while that works, I do tend to dislike global variables like that.
_Maybe_ a better approach would be to have those #define resolve to
functions:
#define I8042_KBD_IRQ of_find_i8042_kbd_irq()
Or something like that ?
That means ending up having 2 functions which more/less reproduce the
loop to find the driver in the device-tree but that's a minor
inconvenience.
Now, maybe the variables are less bloat here. What do you think ? Which
way do you prefer ?
Cheers,
Ben.
^ permalink raw reply
* [tip:perf/urgent] tracing, powerpc: Fix for tracepoint API change
From: tip-bot for Stephen Rothwell @ 2010-05-28 18:27 UTC (permalink / raw)
To: linux-tip-commits
Cc: sfr, peterz, linuxppc-dev, linux-kernel, srostedt, mingo, anton,
hpa, tglx, torvalds, mingo
In-Reply-To: <20100528150842.d5a751ba.sfr@canb.auug.org.au>
Commit-ID: a578f4255763514dc9d0c4f2a60cf5b9323e0b6b
Gitweb: http://git.kernel.org/tip/a578f4255763514dc9d0c4f2a60cf5b9323e0b6b
Author: Stephen Rothwell <sfr@canb.auug.org.au>
AuthorDate: Fri, 28 May 2010 15:08:42 +1000
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 28 May 2010 16:27:11 +0200
tracing, powerpc: Fix for tracepoint API change
Commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e "tracing: Let
tracepoints have data passed to tracepoint callbacks" requires
this fixup to the powerpc code.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Steven Rostedt <srostedt@redhat.com>
Cc: Linus <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: paulus@samba.org
Cc: Anton Blanchard ZZ <anton@samba.org>
LKML-Reference: <20100528150842.d5a751ba.sfr@canb.auug.org.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/platforms/pseries/hvCall_inst.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c b/arch/powerpc/platforms/pseries/hvCall_inst.c
index 1fefae7..e19ff02 100644
--- a/arch/powerpc/platforms/pseries/hvCall_inst.c
+++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
@@ -102,7 +102,7 @@ static const struct file_operations hcall_inst_seq_fops = {
#define CPU_NAME_BUF_SIZE 32
-static void probe_hcall_entry(unsigned long opcode, unsigned long *args)
+static void probe_hcall_entry(void *ignored, unsigned long opcode, unsigned long *args)
{
struct hcall_stats *h;
@@ -114,7 +114,7 @@ static void probe_hcall_entry(unsigned long opcode, unsigned long *args)
h->purr_start = mfspr(SPRN_PURR);
}
-static void probe_hcall_exit(unsigned long opcode, unsigned long retval,
+static void probe_hcall_exit(void *ignored, unsigned long opcode, unsigned long retval,
unsigned long *retbuf)
{
struct hcall_stats *h;
@@ -140,11 +140,11 @@ static int __init hcall_inst_init(void)
if (!firmware_has_feature(FW_FEATURE_LPAR))
return 0;
- if (register_trace_hcall_entry(probe_hcall_entry))
+ if (register_trace_hcall_entry(probe_hcall_entry, NULL))
return -EINVAL;
- if (register_trace_hcall_exit(probe_hcall_exit)) {
- unregister_trace_hcall_entry(probe_hcall_entry);
+ if (register_trace_hcall_exit(probe_hcall_exit, NULL)) {
+ unregister_trace_hcall_entry(probe_hcall_entry, NULL);
return -EINVAL;
}
^ permalink raw reply related
* Re: [PATCH] PowerPC: Remove hardcoded BAT configuration of IMMR in CPM early debug console
From: Scott Wood @ 2010-05-28 16:18 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20100528151836.5889.10393.stgit@ES-J7S4D2J.amer.consind.ge.com>
On 05/28/2010 10:18 AM, Martyn Welch wrote:
> The CPM early debug console hardcodes the BAT to cover the IMMR at
> 0xf0000000. The IMMR (on the mpc8270 at the very least) can be set to a
> number of locations with bootstrap configuration, which are outside the
> hardcoded BAT configuration.
>
> This patch determines the correct location at which to configure a BAT
> during the boot process from the supplied PPC_EARLY_DEBUG_CPM_ADDR.
>
> Signed-off-by: Martyn Welch<martyn.welch@ge.com>
> ---
>
> arch/powerpc/kernel/head_32.S | 5 +++--
> arch/powerpc/sysdev/cpm_common.c | 4 +++-
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
> index e025e89..861cace 100644
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -1194,12 +1194,13 @@ setup_disp_bat:
> #endif /* CONFIG_BOOTX_TEXT */
>
> #ifdef CONFIG_PPC_EARLY_DEBUG_CPM
> +#define PPC_EARLY_DEBUG_CPM_ADDR ASM_CONST(CONFIG_PPC_EARLY_DEBUG_CPM_ADDR)
> setup_cpm_bat:
> - lis r8, 0xf000
> + lis r8, PPC_EARLY_DEBUG_CPM_ADDR@ha
> ori r8, r8, 0x002a
> mtspr SPRN_DBAT1L, r8
>
> - lis r11, 0xf000
> + lis r11, PPC_EARLY_DEBUG_CPM_ADDR@ha
> ori r11, r11, (BL_1M << 2) | 2
> mtspr SPRN_DBAT1U, r11
Only the physical address should depend on where IMMR is. We should use
fixmap instead of an arbitrary address for the effective address.
There's a existing FIX_EARLY_DEBUG_BASE, but it's only 128 KiB so we'll
have to either grow it, or map only a subset of IMMR.
Plus, CONFIG_PPC_EARLY_DEBUG_CPM_ADDR points to the TX descriptor, not
to the beginning of IMMR, so you should mask off the lower 20 bits (the
offset is probably less than 64K, and the BAT might just ignore the
extra bits anyway, but why take chances?).
-Scott
^ permalink raw reply
* [PATCH] PowerPC: Remove hardcoded BAT configuration of IMMR in CPM early debug console
From: Martyn Welch @ 2010-05-28 15:18 UTC (permalink / raw)
To: galak, benh; +Cc: scottwood, linuxppc-dev
The CPM early debug console hardcodes the BAT to cover the IMMR at
0xf0000000. The IMMR (on the mpc8270 at the very least) can be set to a
number of locations with bootstrap configuration, which are outside the
hardcoded BAT configuration.
This patch determines the correct location at which to configure a BAT
during the boot process from the supplied PPC_EARLY_DEBUG_CPM_ADDR.
Signed-off-by: Martyn Welch <martyn.welch@ge.com>
---
arch/powerpc/kernel/head_32.S | 5 +++--
arch/powerpc/sysdev/cpm_common.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index e025e89..861cace 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -1194,12 +1194,13 @@ setup_disp_bat:
#endif /* CONFIG_BOOTX_TEXT */
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
+#define PPC_EARLY_DEBUG_CPM_ADDR ASM_CONST(CONFIG_PPC_EARLY_DEBUG_CPM_ADDR)
setup_cpm_bat:
- lis r8, 0xf000
+ lis r8, PPC_EARLY_DEBUG_CPM_ADDR@ha
ori r8, r8, 0x002a
mtspr SPRN_DBAT1L, r8
- lis r11, 0xf000
+ lis r11, PPC_EARLY_DEBUG_CPM_ADDR@ha
ori r11, r11, (BL_1M << 2) | 2
mtspr SPRN_DBAT1U, r11
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 88b9812..984614f 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -57,7 +57,9 @@ void __init udbg_init_cpm(void)
{
if (cpm_udbg_txdesc) {
#ifdef CONFIG_CPM2
- setbat(1, 0xf0000000, 0xf0000000, 1024*1024, PAGE_KERNEL_NCG);
+#define EARLY_DEBUG_CPM_BAT (CONFIG_PPC_EARLY_DEBUG_CPM_ADDR&0xfff00000)
+ setbat(1, EARLY_DEBUG_CPM_BAT, EARLY_DEBUG_CPM_BAT, 1024*1024,
+ PAGE_KERNEL_NCG);
#endif
udbg_putc = udbg_putc_cpm;
}
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (linus' tree related)
From: Steven Rostedt @ 2010-05-28 12:50 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, ppc-dev, linux-kernel, linux-next, paulus,
Anton Blanchard ZZ, H. Peter Anvin, Thomas Gleixner, Linus,
Ingo Molnar
In-Reply-To: <20100528150842.d5a751ba.sfr@canb.auug.org.au>
On Fri, 2010-05-28 at 15:08 +1000, Stephen Rothwell wrote:
> Hi Steven,
>
> After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this:
>
> arch/powerpc/platforms/pseries/hvCall_inst.c: In function 'hcall_inst_init':
> arch/powerpc/platforms/pseries/hvCall_inst.c:143: warning: passing argument 1 of 'register_trace_hcall_entry' from incompatible pointer type
> arch/powerpc/include/asm/trace.h:100: note: expected 'void (*)(void *, long unsigned int, long unsigned int *)' but argument is of type 'void (*)(long unsigned int, long unsigned int *)'
> arch/powerpc/platforms/pseries/hvCall_inst.c:143: error: too few arguments to function 'register_trace_hcall_entry'
> arch/powerpc/platforms/pseries/hvCall_inst.c:146: warning: passing argument 1 of 'register_trace_hcall_exit' from incompatible pointer type
> arch/powerpc/include/asm/trace.h:122: note: expected 'void (*)(void *, long unsigned int, long unsigned int, long unsigned int *)' but argument is of type 'void (*)(long unsigned int, long unsigned int, long unsigned int *)'
> arch/powerpc/platforms/pseries/hvCall_inst.c:146: error: too few arguments to function 'register_trace_hcall_exit'
> arch/powerpc/platforms/pseries/hvCall_inst.c:147: warning: passing argument 1 of 'unregister_trace_hcall_entry' from incompatible pointer type
> arch/powerpc/include/asm/trace.h:100: note: expected 'void (*)(void *, long unsigned int, long unsigned int *)' but argument is of type 'void (*)(long unsigned int, long unsigned int *)'
> arch/powerpc/platforms/pseries/hvCall_inst.c:147: error: too few arguments to function 'unregister_trace_hcall_entry'
>
> Probably caused by commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e
> ("tracing: Let tracepoints have data passed to tracepoint callbacks").
>
> I applied this patch which builds (but may be incorrect).
>
Looks good to me.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 28 May 2010 15:05:00 +1000
> Subject: [PATCH] tracing: fix for tracepoint API change
>
> Commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e "tracing: Let tracepoints
> have data passed to tracepoint callbacks" requires this fixup to the
> powerpc code.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/platforms/pseries/hvCall_inst.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c b/arch/powerpc/platforms/pseries/hvCall_inst.c
> index 1fefae7..e19ff02 100644
> --- a/arch/powerpc/platforms/pseries/hvCall_inst.c
> +++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
> @@ -102,7 +102,7 @@ static const struct file_operations hcall_inst_seq_fops = {
> #define CPU_NAME_BUF_SIZE 32
>
>
> -static void probe_hcall_entry(unsigned long opcode, unsigned long *args)
> +static void probe_hcall_entry(void *ignored, unsigned long opcode, unsigned long *args)
> {
> struct hcall_stats *h;
>
> @@ -114,7 +114,7 @@ static void probe_hcall_entry(unsigned long opcode, unsigned long *args)
> h->purr_start = mfspr(SPRN_PURR);
> }
>
> -static void probe_hcall_exit(unsigned long opcode, unsigned long retval,
> +static void probe_hcall_exit(void *ignored, unsigned long opcode, unsigned long retval,
> unsigned long *retbuf)
> {
> struct hcall_stats *h;
> @@ -140,11 +140,11 @@ static int __init hcall_inst_init(void)
> if (!firmware_has_feature(FW_FEATURE_LPAR))
> return 0;
>
> - if (register_trace_hcall_entry(probe_hcall_entry))
> + if (register_trace_hcall_entry(probe_hcall_entry, NULL))
> return -EINVAL;
>
> - if (register_trace_hcall_exit(probe_hcall_exit)) {
> - unregister_trace_hcall_entry(probe_hcall_entry);
> + if (register_trace_hcall_exit(probe_hcall_exit, NULL)) {
> + unregister_trace_hcall_entry(probe_hcall_entry, NULL);
> return -EINVAL;
> }
>
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: [PATCH]Device tree update for the 460ex DWC SATA
From: Sergei Shtylyov @ 2010-05-28 12:32 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linux-ide, rsarmah, sr, linux-kernel, linuxppc-dev
In-Reply-To: <201005281215.o4SCFKNi025548@amcc.com>
Hello.
Rupjyoti Sarmah wrote:
> Device tree update for the Applied micro processor 460ex on-chip SATA.
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
[...]
> diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
> index cd56bb5..d3b2c99 100644
> --- a/arch/powerpc/boot/dts/canyonlands.dts
> +++ b/arch/powerpc/boot/dts/canyonlands.dts
> @@ -163,6 +163,14 @@
> interrupts = <0x1e 4>;
> };
>
> + SATA0: sata@bffd1000 {
> + compatible = "amcc,sata-460ex";
> + reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
> + interrupt-parent = <&UIC3>;
> + interrupts = <0x0 0x4 /* SATA */
> + 0x5 0x4>; /* AHBDMA */
Please indent only using tabs consistently.
WBR, Sergei
^ permalink raw reply
* [PATCH]Device tree update for the 460ex DWC SATA
From: Rupjyoti Sarmah @ 2010-05-28 12:15 UTC (permalink / raw)
To: linux-ide, linux-kernel; +Cc: linuxppc-dev, rsarmah, sr
Device tree update for the Applied micro processor 460ex on-chip SATA.
Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index cd56bb5..d3b2c99 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -163,6 +163,14 @@
interrupts = <0x1e 4>;
};
+ SATA0: sata@bffd1000 {
+ compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+ interrupt-parent = <&UIC3>;
+ interrupts = <0x0 0x4 /* SATA */
+ 0x5 0x4>; /* AHBDMA */
+ };
+
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
--
1.5.6.3
^ permalink raw reply related
* Re: [Patch 3/4] PPC64-HWBKPT: Handle concurrent alignment interrupts
From: K.Prasad @ 2010-05-28 7:41 UTC (permalink / raw)
To: Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, linuxppc-dev@ozlabs.org,
Alan Stern, Roland McGrath
In-Reply-To: <20100527062044.GB4105@drongo>
On Thu, May 27, 2010 at 04:20:44PM +1000, Paul Mackerras wrote:
> On Tue, May 25, 2010 at 02:44:35PM +0530, K.Prasad wrote:
>
> > An alignment interrupt may intervene between a DSI/hw-breakpoint exception
> > and the single-step exception. Enable the alignment interrupt (through
> > modifications to emulate_single_step()) to notify the single-step exception
> > handler for proper restoration of hw-breakpoints.
> >
> > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/kernel/traps.c | 7 ++-----
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > Index: linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
> > ===================================================================
> > --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/traps.c
> > +++ linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
> > @@ -602,7 +602,7 @@ void RunModeException(struct pt_regs *re
> >
> > void __kprobes single_step_exception(struct pt_regs *regs)
> > {
> > - regs->msr &= ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
> > + clear_single_step(regs);
> >
> > if (notify_die(DIE_SSTEP, "single_step", regs, 5,
> > 5, SIGTRAP) == NOTIFY_STOP)
> > @@ -621,10 +621,7 @@ void __kprobes single_step_exception(str
> > */
> > static void emulate_single_step(struct pt_regs *regs)
> > {
> > - if (single_stepping(regs)) {
> > - clear_single_step(regs);
> > - _exception(SIGTRAP, regs, TRAP_TRACE, 0);
> > - }
> > + single_step_exception(regs);
> > }
>
> We still need the if (single_stepping(regs)) in emulate_single_step.
> We don't want to send the process a SIGTRAP every time it gets an
> alignment interrupt. :)
>
> Paul.
Agreed, and made changes to that effect in version XXII (as seen in
patch linuxppc-dev message-id: 20100528064017.GD8679@in.ibm.com).
Thanks,
K.Prasad
^ 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