Nothing much to say here other than mostly mechanical merging of OF
support code. Some of it remains a little ugly, but I'm taking the
approach of merging the code first, and refactoring it second.
I've pushed this series out to my test-devicetree branch on my git
server if anyone wants to test.
Merge common code between PowerPC and Microblaze
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Wolfram Sang w.s...@pengutronix.de
Tested-by: Michal Simek mon...@monstr.eu
---
arch/microblaze/kernel/prom.c | 32
arch/powerpc/kernel/prom.c
Merge common code between PowerPC and Microblaze
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 23 ---
arch/powerpc/kernel/prom.c| 24
drivers/of/fdt.c | 26 ++
Merge common code between PowerPC and Microblaze
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c |8
arch/powerpc/kernel/prom.c|8
drivers/of/fdt.c |8
include/linux/of_fdt.h|1 +
4 files
A cell is firmly established as a u32. No need to do an ugly typedef
to redefine it to cell_t. Eliminate the unnecessary typedef so that
it doesn't have to be added to the of_fdt header file
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 10
Merge common code between PowerPC and Microblaze. This patch
splits the arch-specific stuff out into a new function,
early_init_dt_scan_chosen_arch().
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 44 ++-
Merge common code between Microblaze and PowerPC
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 53 +++
arch/powerpc/kernel/prom.c| 94 +++--
drivers/of/fdt.c | 92
Merge common code between PowerPC and Microblaze
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 18 --
arch/powerpc/kernel/prom.c| 18 --
drivers/of/base.c | 18 ++
3 files changed,
Merge common code between PowerPC and MicroBlaze
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 74
arch/powerpc/kernel/prom.c| 73
drivers/of/base.c
Merge common code between PowerPC and Microblaze
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/include/asm/prom.h |4 --
arch/microblaze/kernel/prom.c | 59 ---
arch/powerpc/include/asm/prom.h|4 --
Microblaze only has one CPU, it isn't SMP at all. This function is
effectively just a no-op, so remove it.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/microblaze/kernel/prom.c | 54 -
1 files changed, 0 insertions(+), 54 deletions(-)
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a couple
of years. This patch renames .node to .linux_phandle for SPARC.
Note: the .node
From: Michal Simek mon...@monstr.eu
Many boards have a bug-free ns16550 compatible serial port, which we should
register as PORT_16550A. This introduces a new value ns16550a for the
compatible property of of_serial to let a firmware choose that model instead
of using the crippled PORT_16550 mode.
On Thu, Nov 19, 2009 at 02:52:16PM -0500, Neil Horman wrote:
Hey there-
Before anyone flames me for what a oddball solution this is, let me just
say I'm trying to get the ball rolling here. I think there may be better
solutions that can be impemented in reloc_64.S, but I've yet to make
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
On 24.11.2009, at 16:02, Avi Kivity wrote:
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space
we're
in and resolve addresses. While that is a big problem for migration, it's
also
unpleasent when debugging, as gdb and
On Tue, Nov 24, 2009 at 04:03:36PM +1100, Benjamin Herrenschmidt wrote:
[...]
This patch breaks my 6xx config:
/home/benh/linux-powerpc-test/arch/powerpc/platforms/83xx/mpc832x_rdb.c: In
function ‘of_fsl_spi_probe’:
/home/benh/linux-powerpc-test/arch/powerpc/platforms/83xx/mpc832x_rdb.c:77:
On 11/24/2009 05:04 PM, Alexander Graf wrote:
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is
Hi Stefano,
Thanks for trying the patches out.
On Tue, 2009-11-24 at 11:32 +0100, Stefano Babic wrote:
Peter Tyser ptyser wrote:
+uboot.fit)
+rm -f $ofile
+${MKITS} -A ppc -C gzip -a $membase -e $membase -v $version \
+ -d $srctree/$dtb -k $srctree/$vmz -o $object/uImage.its
Hi All,
Recently came across an issue which is decribed below.
Setup: Port Multiplier with 2 HDD's connected to it; Port multiplier is
connected to a SATA port of the Host Controller.
Test: HDD1 is mounted and using dd command a file of size 512MB is being
written on it.
Command: time sh -c
Michael Ellerman wrote:
Would it be acceptable to create a global var __allow_ioremap_normal_ram
that by default would have a value of 0 and would be set _only_ for those
platforms needing it?
The other solutions I see is:
- add support for discontiguous memory to powerpc 32-bits (which is
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 24 Nov 2009 01:20:05 -0700
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a
Segher Boessenkool wrote:
Hi Albert,
+asm (\n\
A file scope asm?! Please don't.
So what's your proposal then? Placing it within a fake func?
That asm snippet is the entry point. I took as an example how prpmc2800.c deals
with that, providing an own version of the (weak)
Segher Boessenkool wrote:
+ * We enter with an unknown cache, high BATs and MMU status.
What does this mean? You know the low four BATs on entry and
nothing else?
That means that we do not make assumptions regarding:
- the state of the cache (enabled vs disabled)
- if the high BATs are
Segher Boessenkool wrote:
Add a config option GAMECUBE_COMMON to be used as a dependency for all
options common to the Nintendo GameCube and Wii video game consoles.
Maybe something like GAMECUBE_OR_WII instead? COMMON is so
common it's meaningless.
I don't like either GAMECUBE_OR_WII.
Segher Boessenkool wrote:
+ If you say yes to this option, support will be included for the
+ USB Gecko adapter as an udbg console.
+ The USB Gecko is a EXI to USB Serial converter that can be plugged
+ into a memcard slot in the Nintendo GameCube/Wii.
Not a memcard
Neil Horman writes:
Before anyone flames me for what a oddball solution this is, let me just
say I'm trying to get the ball rolling here. I think there may be better
solutions that can be impemented in reloc_64.S, but I've yet to make any of
the
ones I've tried work successfully. I'm
Segher Boessenkool wrote:
You set up DBAT1 here...
+setup_usbgecko_bat:
+/* prepare a BAT for early io */
+lisr8, 0x0c00
+orir8, r8, 0x002a/* uncached, guarded ,rw */
+lisr11, 0xcc00
+orir11, r11, 0x3/* 128K */
+#ifdef CONFIG_WII
+oris
On Tue, Nov 24, 2009 at 10:37 AM, David Miller da...@davemloft.net wrote:
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 24 Nov 2009 01:20:05 -0700
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason
+asm (\n\
A file scope asm?! Please don't.
So what's your proposal then? Placing it within a fake func?
That asm snippet is the entry point. I took as an example how
prpmc2800.c deals with that, providing an own version of the (weak)
_zImage_start.
Use an assembler source file.
+ * We enter with an unknown cache, high BATs and MMU status.
What does this mean? You know the low four BATs on entry and
nothing else?
That means that we do not make assumptions regarding:
- the state of the cache (enabled vs disabled)
- if the high BATs are enabled or not
- if the MMU is
On Tue, 2009-11-24 at 09:37 -0800, David Miller wrote:
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 24 Nov 2009 01:20:05 -0700
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
Add a config option GAMECUBE_COMMON to be used as a dependency
for all
options common to the Nintendo GameCube and Wii video game consoles.
Maybe something like GAMECUBE_OR_WII instead? COMMON is so
common it's meaningless.
I don't like either GAMECUBE_OR_WII.
It looks as if it can be
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 24 Nov 2009 13:33:22 -0700
If you prefer, I can change it all to simply '.phandle'.
Please do.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
+ If you say yes to this option, support will be included
for the
+ USB Gecko adapter as an udbg console.
+ The USB Gecko is a EXI to USB Serial converter that can be
plugged
+ into a memcard slot in the Nintendo GameCube/Wii.
Not a memcard slot, only the first one, you
config GAMECUBE_COMMON
bool
select NOT_COHERENT_CACHE
+ select FLIPPER_PIC
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
+#define pr_fmt(fmt) DRV_MODULE_NAME : fmt
Unused
+/*
+ * Each interrupt has a corresponding bit in both
+static struct of_device_id gamecube_of_bus[] = {
+ { .compatible = nintendo,flipper, },
+ { },
+};
+
+static int __init gamecube_device_probe(void)
+{
+ if (!machine_is(gamecube))
+ return 0;
+
+ of_platform_bus_probe(NULL, gamecube_of_bus, NULL);
+
On Tue, Nov 24, 2009 at 2:06 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2009-11-24 at 09:37 -0800, David Miller wrote:
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 24 Nov 2009 01:20:05 -0700
In struct device_node, the phandle is named 'linux_phandle' for
+config HLWD_PIC
Are vowels too expensive? :-)
+static void hlwd_pic_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
+
+ set_bit(irq, io_base + HW_BROADWAY_ICR);
+}
Same issue as with Flipper here.
+
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a couple
of years. This patch renames both to simply .phandle.
Note: the .node also existed
Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.
'mini' is an open source IOS replacement written from scratch by
Team Twiizers.
It's not a replacement, it doesn't have any of the same functionality.
It grants full access to the hardware found on the
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/
powerpc/platforms/embedded6xx/wii.c
+#define DRV_MODULE_NAME rvl
Should this be wii?
+static enum starlet_ipc_flavour starlet_ipc_flavour;
+
+enum starlet_ipc_flavour starlet_get_ipc_flavour(void)
+{
+ return
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 24 Nov 2009 15:01:14 -0700
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a
+ model = NintendoGameCube;
+ compatible = nintendo,gamecube;
To date, we've been using the same form for both the model and
compatible properties. Specifically the vendor,model form to
maintain the namespace.
That, however, is a) useless; and b) not totally correct.
The model
On Tuesday 24 November 2009, Segher Boessenkool wrote:
This option should be used only for options applicable to both the
GAMECUBE and WII, i.e. basically those options in the WII which
where inherited from the GAMECUBE to make it retro-compatible.
If GAMECUBE_COMMON is unacceptable,
The soc node here tries to represent the big multi-function chip
that integrates most of the devices of the video game consoles
(Flipper on the Nintendo GameCube and Hollywood on the Wii).
Right. Much like many other SoCs.
It isn't a SoC, it's really just a memory bridge / I/O bridge
like
Segher Boessenkool wrote:
So what's your proposal then? Placing it within a fake func?
That asm snippet is the entry point. I took as an example how
prpmc2800.c deals with that, providing an own version of the (weak)
_zImage_start.
Use an assembler source file. You'll get much nicer syntax
Thanks. However, there needs to be a proper description of what this
patch does to go in the commit header. Can you please write one?
Thanks,
g.
On Sat, Nov 21, 2009 at 9:08 AM, Torsten Fleischer
to-fleisc...@t-online.de wrote:
On Sat, Nov 21, 2009 at 09:45:50 Grant Likely wrote:
[...]
Hey
On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
Michael Ellerman wrote:
Would it be acceptable to create a global var __allow_ioremap_normal_ram
that by default would have a value of 0 and would be set _only_ for those
platforms needing it?
The other solutions I see is:
-
In struct device_node, the phandle is named 'linux_phandle' for
PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a couple
of years. This patch renames both to simply .phandle.
Note: the .node also
On Tue, Nov 24, 2009 at 6:30 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
In struct device_node, the phandle is named 'linux_phandle' for PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a
The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a resource involves
removing the resource's node from the device tree and then returning the
This patch provides the kernel DLPAR infrastructure in a new filed named
dlpar.c. The functionality provided is for acquiring and releasing a resource
from firmware and the parsing of information returned from the
ibm,configure-connector rtas call. Additionally this exports the pSeries
Create new probe and release sysfs files to facilitate adding and removing
cpus from the system. This also creates the powerpc specific stubs to handle
the arch callouts from writes to the sysfs files.
The creation and use of these files is regulated by the
CONFIG_ARCH_CPU_PROBE_RELEASE option
Register the pseries specific handlers for the powerpc architecture handlers
for the cpu probe and release files. This also implements the cpu DLPAR
addition and removal of CPUS from the system.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
arch/powerpc/platforms/pseries/dlpar.c |
In message 4b0c8ce3.4010...@austin.ibm.com you wrote:
This patch provides the kernel DLPAR infrastructure in a new filed named
dlpar.c. The functionality provided is for acquiring and releasing a resourc
e
from firmware and the parsing of information returned from the
CPM2 Port C interrupts can be either falling edge, or either edge.
Other external interrupts are either falling edge or active low.
Signed-Off-By: Mark Ware mw...@elphinstone.net
---
arch/powerpc/sysdev/cpm2_pic.c | 29 ++---
1 files changed, 22 insertions(+), 7
In message 31581.1259115...@neuling.org you wrote:
In message 4b0c8ce3.4010...@austin.ibm.com you wrote:
This patch provides the kernel DLPAR infrastructure in a new filed named
dlpar.c. The functionality provided is for acquiring and releasing a resou
rc
e
from firmware and the
Nathan Fontenot writes:
The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a resource involves
removing the resource's node from the device
Nathan Fontenot writes:
This patch provides the kernel DLPAR infrastructure in a new filed named
dlpar.c. The functionality provided is for acquiring and releasing a resource
from firmware and the parsing of information returned from the
ibm,configure-connector rtas call. Additionally this
Nathan Fontenot writes:
Register the pseries specific handlers for the powerpc architecture handlers
for the cpu probe and release files. This also implements the cpu DLPAR
addition and removal of CPUS from the system.
...
+ /* configure-connector reports cpus as living in the base
+
Nathan Fontenot writes:
Create new probe and release sysfs files to facilitate adding and removing
cpus from the system. This also creates the powerpc specific stubs to handle
the arch callouts from writes to the sysfs files.
The creation and use of these files is regulated by the
version 2 of the patch set with updates from comments.
The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a resource involves
removing the
Paul Mackerras wrote:
Nathan Fontenot writes:
The Dynamic Logical Partitioning (DLPAR) capabilities of the powerpc pseries
platform allows for the addition and removal of resources (i.e. cpus,
memory, pci devices) from a partition. The removal of a resource involves
removing the resource's
The Dynamic Logical Partitioning capabilities of the powerpc pseries platform
allows for the addition and removal of resources (i.e. CPU's, memory, and PCI
devices) from a partition. The removal of a resource involves
removing the resource's node from the device tree and then returning the
In order to support kernel DLPAR of CPU resources we need to provide an
interface to add (probe) and remove (release) the resource from the system.
This patch Creates new generic probe and release sysfs files to facilitate
cpu probe/release. The probe/release interface provides for allowing each
This patch adds the specific routines to probe and release (add and remove)
cpu resource for the powerpc pseries platform and registers these handlers
with the ppc_md callout structure.
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
arch/powerpc/platforms/pseries/dlpar.c | 88
67 matches
Mail list logo
