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
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 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
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
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
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
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
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
>>> + 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
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
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:
>> 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:
>> +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 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:
>> 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 '
> +/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:
>> 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
> + 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:
+ 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?
>>>
>
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:
>> +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
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,
>
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
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 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
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 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
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
__
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:
> 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
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
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
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.
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: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:
> 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 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 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 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 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 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:
>
> +#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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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:
> 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
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: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.
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: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
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 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 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 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 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, 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, 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
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, 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
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, 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
73 matches
Mail list logo
