On Wed, Nov 25, 2009 at 7:30 PM, Gabriel Paubert wrote:
> On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
>> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
>> wrote:
>> >>> You need to be a bit more careful tho. You must not allow RAM managed by
>> >>> the kernel to be mapped non-ca
On Tuesday 24 November 2009 00:06:13 Pravin Bathija wrote:
> Description: Set PCI-E node inbound DMA ranges size to 4GB for correct
> boot up of katmai. Including only changes for PCI-E DMA ranges as
> suggested by Stefan.
>
> Signed-off-by: Pravin Bathija
> Acked-by: Feng Kan
> Acked-by: Pro
On Wed, 2009-11-25 at 23:28 -0700, M. Warner Losh wrote:
> In message:
>
> Grant Likely writes:
> : Word from Mitch is the device tree is network byte order. period.
>
> OpenFirmware defines the order to be big endian always, even on little
> endian processors.
Right, that's the on
In message:
Grant Likely writes:
: Word from Mitch is the device tree is network byte order. period.
OpenFirmware defines the order to be big endian always, even on little
endian processors.
Warner
___
Linuxppc-dev mailing list
Linuxppc-d
On Wed, Nov 25, 2009 at 10:29 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2009-11-25 at 21:38 -0700, Grant Likely wrote:
>>
>> But this isn't real OF. Real OF can generate its own valid tree.
>> This is a flat tree, and it is valid according to all users of the
>> flat tree. Besides, the last ti
On Wed, Nov 25, 2009 at 10:16 PM, David Gibson
wrote:
> Grant, this is based on your test-devicetree branch, if it could be
> merged via there would be great.
>
> Currently when processing flattened device trees, the kernel expects
> the phandle in a property called "linux,phandle". The ePAPR spe
On Wed, 2009-11-25 at 21:38 -0700, Grant Likely wrote:
>
> But this isn't real OF. Real OF can generate its own valid tree.
> This is a flat tree, and it is valid according to all users of the
> flat tree. Besides, the last time we talked about this, you told me
> that moving it to the root was
On Wed, 2009-11-25 at 21:05 -0700, Grant Likely wrote:
>
> You're right, it's not, but makes merging less complex, and then I can
> refactor properly.
Still, make them __be32 at least
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozla
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +static void hlwd_pic_mask_and_ack(unsigned int virq)
> +{
> + int irq = virq_to_hw(virq);
> + void __iomem *io_base = get_irq_chip_data(virq);
> +
> + clear_bit(irq, io_base + HW_BROADWAY_IMR);
> + set_bit(irq, io_base + H
On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
> ram check.
> But calling the stock ioremap without modifying it is not possible
> because it checks and bails out when ioremapping a region marked as
> ram (even if it
On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
> > +unsigned int flipper_pic_get_irq(void)
> > +{
> > + void __iomem *io_base = flipper_irq_host->host_data;
> > + int irq;
> > + u32 irq_status;
> > +
> > + irq_status = in_be32(io_base + FLIPPER_ICR) &
> > +
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +static void flipper_pic_mask_and_ack(unsigned int virq)
> +{
> + int irq = virq_to_hw(virq);
> + void __iomem *io_base = get_irq_chip_data(virq);
> +
> + clear_bit(irq, io_base + FLIPPER_IMR);
> + set_bit(irq, io_base + FL
Grant, this is based on your test-devicetree branch, if it could be
merged via there would be great.
Currently when processing flattened device trees, the kernel expects
the phandle in a property called "linux,phandle". The ePAPR spec -
not being Linux specific - instead requires phandles to be e
On Sun, 2009-11-22 at 23:27 +0100, Arnd Bergmann wrote:
>
> This will probably break other platforms if
> CONFIG_PPC_EARLY_DEBUG_USBGECKO
> is set. In general, we try hard to make it possible to build generic
> kernels for multiple systems, so it would be better to also add a
> runtime check here.
Hi Gautham,
> + call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
> + NULL,
> + CEDE_LATENCY_TOKEN,
> + __pa(cede_parameters),
> + CEDE_LATENCY_PARAM_MAX_LENGTH)
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> Add support for using the USB Gecko adapter via the udbg facility on
> the Nintendo GameCube and Wii video game consoles.
> The USB Gecko is a 3rd party memory card interface adapter that provides
> a EXI (External Interface) to USB serial
On Sun, 2009-11-22 at 16:21 -0700, Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz
> wrote:
> > The Nintendo GameCube and Wii video game consoles do not have PCI hardware.
> > Avoid wasting their scarce memory by not including PCI support into the
> > kernel.
> >
> > Signed-
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> The processors bundled in the Nintendo GameCube and Wii video game consoles
> require explicit cache handling when DMA engines are used.
That reminds me we really need to make that a runtime option some day...
Cheers,
Ben.
> Signed-off-b
On Tue, 2009-11-24 at 19:03 +0100, Albert Herranz wrote:
> 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"
On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
>
> We need nobats (or a hack in the mmu_mapin_ram() code) because of the
> discontiguous ram problem.
I would vote for a hack in mmu_mapin_ram() for now.
Cheers,
Ben.
___
Linuxppc-dev mailing
On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
> > +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>
> Like others have said already, don't do this. If you need
> a workaround, put it in the platform code.
>
> > +/memreserve/ 0x1000 0x0004000; /* DSP R
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DS
On Wed, Nov 25, 2009 at 9:21 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2009-11-22 at 16:02 -0700, Grant Likely wrote:
>> > +
>> > + vi...@0c002000 {
>> > + compatible = "nintendo,flipper-video";
>> > + reg = <0x0c002000 0x100>;
>> > +
On Tue, 2009-11-24 at 22:00 +0100, Segher Boessenkool wrote:
>
> Sure, the memory controllers don't do coherency. I'm slightly worried
> about two things:
> 1) Will the generic code use M=0 as well? Is it a problem if it
> doesn't?
We can make it not do it.
> 2) Do lwarx. etc. work in M=0?
On Tue, 2009-11-24 at 18:38 +0100, Albert Herranz wrote:
> 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?
Just do a .S file :-)
> That asm snippet is the entry poi
On Wed, 2009-11-25 at 19:00 +0100, Segher Boessenkool wrote:
> > + memory {
> > + device_type = "memory";
> > + /* 24M minus framebuffer memory area (640*576*2*2) */
> > + reg = <0x 0x01698000>;
>
> Put the whole 24MB here, probe the framebuffer address and
On Tue, 2009-11-24 at 23:36 +0100, Segher Boessenkool wrote:
> If you have only one interrupt controller, like here, you don't
> need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on our
part but heh ...
Cheers,
Ben.
___
On Mon, 2009-11-23 at 13:19 -0700, Grant Likely wrote:
> so the node really is
> describing the internal bus, not the entire SoC. On some chips it is
> documented as the "internally memory mapped registers", or IMMR. So,
> it is better to name this node in a way that reflects what it is (an
> int
On Sun, 2009-11-22 at 16:02 -0700, Grant Likely wrote:
> > + /* devices contained int the flipper chipset */
> > + soc {
>
> It would be better to rename this as IMMR or the bus type. This node
> doesn't actually describe the entire chip, but describes the internal
> memory mapped re
On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> Add support for using the USB Gecko adapter as a bootwrapper console on
> the Nintendo GameCube and Wii video game consoles.
> The USB Gecko is a 3rd party memory card interface adapter that provides
> a EXI (External Interface) to USB seri
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
Some of those guys might wnat to be in of_dynamic (see previous email)
Remember: We want to keep the footprint low for embedded archs that
don't want to do dynamic stuff. Really low.
Cheers,
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
>
> +#if !defined(CONFIG_SPARC) /* SPARC doesn't do ref counting (yet) */
> +/**
Make this a Kconfig symbol, something like CONFIG_OF_DYNAMIC. You need
refcounting when you can add/remove nodes dynamically. Some embedded
archs might want
On Wed, Nov 25, 2009 at 8:59 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
>> 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
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
I don't like moving this one to common code without the of_ prefix. I
think you should move it with the of_ prefix, and then add a alias in
powerpc and microblaze without of_ in a header until
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
>
> -static int __init early_init_dt_scan_cpus(unsigned long node,
> - const char *uname, int depth,
> - void *data)
> +int __init early_init_dt_scan_cpus(unsigned l
On Wed, Nov 25, 2009 at 8:54 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
>> Merge common code between PowerPC and Microblaze
>>
>> Signed-off-by: Grant Likely
>> ---
>
> Ok with that, like the precendent, however you are making global some
> symbols
On Wed, Nov 25, 2009 at 8:51 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2009-11-24 at 01:17 -0700, Grant Likely wrote:
>> Merge common code between PowerPC and Microblaze
>>
>> Signed-off-by: Grant Likely
>> Reviewed-by: Wolfram Sang
>> Tested-by: Michal Simek
>
> Acked-by: Benjamin Herrenschm
On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
> 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
> ---
I'm
On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> ---
>
> arch/microblaze/kernel/prom.c |8
> arch/powerpc/kernel/prom.c|8
> drivers/of/fdt.c |8
>
On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> ---
Ok with that, like the precendent, however you are making global some
symbols that were previously static which sucks a bit... But then they
can be made
On Tue, 2009-11-24 at 01:17 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> Reviewed-by: Wolfram Sang
> Tested-by: Michal Simek
Acked-by: Benjamin Herrenschmidt
Remind me how you want to merge that ? via my tree ?
Cheers,
Ben.
Hi Will,
> The tb_total and purr_total values reported via the hcall_stats code
> should be cumulative, rather than being replaced by the latest delta tb
> or purr value.
>
> Tested-by: Will Schmidt
> Signed-off-by: Will Schmidt
Ouch! Nice catch.
Acked-by: Anton Blanchard
Anton
> [ This
Version 3 of this patch is updated with documentation added to
Documentation/ABI. There are no changes to any of the C code from v2
of the patch.
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.
Th
Nathan Fontenot writes:
> 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 tre
Nathan Fontenot writes:
> 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 inter
Nathan Fontenot writes:
> 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
Acked-by: Paul Mackerras
__
On Fri, Oct 16, 2009 at 11:56:02AM +0530, M. Mohan Kumar wrote:
> [PATCH] Write to HVC terminal from purgatory code
>
> Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to serial
> console/VGA while executing the purgatory code. Implement this feature for
> POWERPC pseries plat
Remove the CPU from the online map to prevent smp_call_function
from sending messages to a stopped CPU.
Signed-off-by: Valentine Barshak
---
arch/powerpc/kernel/smp.c |3 +++
1 file changed, 3 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/kernel/smp.c
linux-2.6/arch/powerpc/kernel/s
On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
wrote:
> On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
>> 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.
>>
> [...]
>
> The init
On Wed, 2009-11-25 at 10:12 -0600, Will Schmidt wrote:
> Tested-by: Will Schmidt
> Signed-off-by: Will Schmidt
Isn't it assumed that the one that made the patch also tested it? Well I
would hope that is the norm.
-- Steve
___
Linuxppc-dev mailing l
On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
> 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.
>
[...]
The initialization of the chip selects is removed from the probe() function of
M. Mohan Kumar schrieb:
> Reserve memory for kdump kernel within RMO region
>
> When the kernel size exceeds 32MB(observed with some distros), memory
> for kdump kernel can not be reserved as kdump kernel base is assumed to
> be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
>
Segher Boessenkool wrote:
>> +memory {
>> +device_type = "memory";
>> +/* 24M minus framebuffer memory area (640*576*2*2) */
>> +reg = <0x 0x01698000>;
>
> Put the whole 24MB here, probe the framebuffer address and size
> in the platform code?
>
Ye
Segher Boessenkool wrote:
>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>
> Like others have said already, don't do this. If you need
> a workaround, put it in the platform code.
>
I'll do. Thanks.
>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
>
> This
Segher Boessenkool wrote:
+ i2c-video {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "virtual,i2c-gpio";
>>> There isn't a documented binding for this. Is there a driver for it?
>>>
>
> + memory {
> + device_type = "memory";
> + /* 24M minus framebuffer memory area (640*576*2*2) */
> + reg = <0x 0x01698000>;
Put the whole 24MB here, probe the framebuffer address and size
in the platform code?
> + soc {
> + #addres
Segher Boessenkool wrote:
>> 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"?
>
Ok. I'm fine with both.
>> +static enum starlet_ipc_flavour starlet_ipc_flavour;
>> +
>> +enum starle
> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
Like others have said already, don't do this. If you need
a workaround, put it in the platform code.
> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
This address is fixed in the DSP hardware, right? If not,
you
Segher Boessenkool wrote:
>> 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.
>
I didn't know '
Segher Boessenkool wrote:
>> +config HLWD_PIC
>
> Are vowels too expensive? :-)
>
Heh, you work/worked for IBM. Look at what they did with the CLI in the
AS/400...
I thought here that hollywood is a rather large prefix and there is also a
board called holly. So I came up with hlwd :)
>> +st
Segher Boessenkool wrote:
>> +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(
Segher Boessenkool wrote:
>> 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?
>
I'd prefer to not use a name that implies a specific hardware to describe tw
Segher Boessenkool wrote:
>>> Surely there is something called something like of_node_is_compatible()
>>> you can use here? You already have the node pointer, there is no need
>>> to look at all other nodes.
>>>
>>
>> I see the point.
>> I didn't find of_node_is_compatible() but I'll look what's a
Segher Boessenkool wrote:
>> If GAMECUBE_COMMON is unacceptable, maybe GAMECUBE_LEGACY or
>> GAMECUBE_COMPAT?
>
> Maybe it's best to write GAMECUBE || WII in the places that use it, then?
>
That gets messy in conditionals, like for example:
config PCI
bool "PCI support" if PPC_PCI_CHOI
>>> + i2c-video {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "virtual,i2c-gpio";
>>
>> There isn't a documented binding for this. Is there a driver for it?
>>
>
> I have a driver for it. Bu
WIMG=, are you sure? Not M=1?
>>>
>>> To be honest, I don't recall the details now.
>>> But it was tested in the very early days, the result was not the
>>> expected one and, in the end, manual cache coherency management was
>>> still needed.
>>
>> Sure, the memory controllers don't do co
Hi Stefano,
Stefano Babic wrote:
Peter Tyser
+# Create a default, fully populated DTS file
+DATA="/ {
+ description = \"Linux kernel ${VERSION}\";
+ #address-cells = <1>;
+
+ images {
+ kernel 1 {
Is the probably generated by your anti-spam mailer ? dtc seems
The tb_total and purr_total values reported via the hcall_stats code
should be cumulative, rather than being replaced by the latest delta tb
or purr value.
Tested-by: Will Schmidt
Signed-off-by: Will Schmidt
---
[ This is a touch-up to the "[3/6] powerpc: tracing: Add hypervisor call
tracepoi
Reserve memory for kdump kernel within RMO region
When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
provide the feature to reserve the
On Wed, Nov 25, 2009 at 01:12:21AM -0600, Nathan Fontenot wrote:
> 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
On Wed, Nov 25, 2009 at 04:07:46PM +0800, Li Yang wrote:
> On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
> wrote:
> >>> You need to be a bit more careful tho. You must not allow RAM managed by
> >>> the kernel to be mapped non-cachable.
> >>
> >> Even if the user explicitly sets the O_SYNC f
Hello All,
I'm unable to compile my custom kernel version 2.6.22.5 after applying real
time patch 2.6.22.1-rt9. I get following compilation errors:
In file included from arch/ppc/include/asm/hw_irq.h:121,
from include/asm/system.h:9,
from include/linux/list.h
On Sun, Nov 22, 2009 at 4:01 AM, Segher Boessenkool
wrote:
>>> You need to be a bit more careful tho. You must not allow RAM managed by
>>> the kernel to be mapped non-cachable.
>>
>> Even if the user explicitly sets the O_SYNC flag? IMHO, it's a bug of
>> the application if it uses O_SYNC on mai
73 matches
Mail list logo
