On Wed, Dec 10, 2008 at 6:04 PM, Gary Thomas <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
>> On Thu, 2008-12-04 at 06:51 -0700, Gary Thomas wrote:
>>> I have a MPC5200 based board which has an FPGA for external
>>> I/O, etc. This FPGA also funnels interrupts from the various
>>> exte
The smp code uses cache information to populate cpu_core_map; change
it to use common code for cache lookup.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/smp.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
v2: Fix refcount imbalance, thanks to sf
On Wed, 2008-12-10 at 18:28 -0600, Nathan Lynch wrote:
> The hard_smp_processor_id functions are the appropriate interfaces for
> managing physical CPU ids.
>
> Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
> ---
> arch/powerpc/platform
> -Original Message-
> From: Piepho Trent-B16872
> Sent: Wednesday, December 10, 2008 10:04 PM
> To: Liu Yu-B13201
> Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; Wood
> Scott-B07421; Gala Kumar-B11780
> Subject: Re: [PATCH] fsl-booke: declare tlbcam_index and
> num_tlbcam_entries for
> -Original Message-
> From: Ira Snyder [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 6:18 PM
> To: Ayman El-Khashab
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Help enabling PCI endpoint on 460EX, host sees disabled
>
>
> I can't help you with that exact board, but I'
On Wed, Dec 10, 2008 at 8:04 PM, Gary Thomas <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
>> On Thu, 2008-12-04 at 06:51 -0700, Gary Thomas wrote:
>>> I have a MPC5200 based board which has an FPGA for external
>>> I/O, etc. This FPGA also funnels interrupts from the various
>>> exte
On Wed, Dec 10, 2008 at 8:04 PM, Gary Thomas <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
>> On Thu, 2008-12-04 at 06:51 -0700, Gary Thomas wrote:
>>> I have a MPC5200 based board which has an FPGA for external
>>> I/O, etc. This FPGA also funnels interrupts from the various
>>> exte
Stephen Rothwell wrote:
> On Wed, 10 Dec 2008 18:46:05 -0600 Nathan Lynch <[EMAIL PROTECTED]> wrote:
> >
> > @@ -418,13 +416,7 @@ static struct device_node *cpu_to_l2cache(int cpu)
> > if (np == NULL)
> > return NULL;
> >
> > - php = of_get_property(np, "l2-cache", NULL);
> > -
> >>[EMAIL PROTECTED] {
> >>device_type = "board-control";
> >>#address-cells = <1>;
> >>#size-cells = <1>;
> >>// Note: includes sub-devices like CAN, A/D, etc
> >>reg = <0xf800 0x10>;
> >>
> >>fpga_ic: [EMAIL PRO
This patch adds support for page sizes bigger than 4K (16K/64K) on
PPC 44x.
PGDIR table is much smaller than page in case of 16K/64K pages (512
and 32 bytes resp.) so we allocate PGDIR with kzalloc() instead of
__get_free_pages().
PTE table covers rather big memory area in case of 16K/64K pages
(32
Hi Benjamin,
Benjamin Herrenschmidt wrote:
>>> I'm not sure about the above & PMD_MASK. Shouldn't we instead make it
>>> not build if (PKMAP_BASE & PMD_MASK) != 0 ?
>>>
>> We separated the !4K_PAGES case here exactly because (PKMAP_BASE &
>> PMD_MASK) != 0 [see the comment to this chunk
Hi Nathan,
On Wed, 10 Dec 2008 18:46:05 -0600 Nathan Lynch <[EMAIL PROTECTED]> wrote:
>
> @@ -418,13 +416,7 @@ static struct device_node *cpu_to_l2cache(int cpu)
> if (np == NULL)
> return NULL;
>
> - php = of_get_property(np, "l2-cache", NULL);
> - if (php == NULL)
>
Hello guys,
please discard this patch. It just doesn't compile with CONFIG_HIGHMEM
set. I'll post updated patch in a short time.
Excuse me.
Regards, Ilya.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxp
Benjamin Herrenschmidt wrote:
> On Thu, 2008-12-04 at 06:51 -0700, Gary Thomas wrote:
>> I have a MPC5200 based board which has an FPGA for external
>> I/O, etc. This FPGA also funnels interrupts from the various
>> external devices through to the CPU.
>>
>> I've defined this structure in my DTS:
On Wed, 10 Dec 2008 16:17:13 -0800 (PST)
Trent Piepho <[EMAIL PROTECTED]> wrote:
> On Wed, 10 Dec 2008, Josh Boyer wrote:
> > On Thu, 11 Dec 2008 10:46:28 +1100
> >>> +#ifdef CONFIG_PCI
> >>> +extern unsigned int ppc_pci_flags;
> >>> +#define ppc_pci_set_flags(flags) ppc_pci_flags = (flags)
> >>>
On Thu, 11 Dec 2008 11:04:05 +1100
Michael Ellerman <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-12-10 at 18:54 -0500, Josh Boyer wrote:
> > On Thu, 11 Dec 2008 10:46:28 +1100
> > Michael Ellerman <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2008-12-10 at 14:11 -0500, Josh Boyer wrote:
> > > > Curre
The smp code uses cache information to populate cpu_core_map; change
it to use common code for cache lookup.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/smp.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/
We have more than one piece of code that looks up cache nodes manually
using the "l2-cache" property. Add a common helper routine which does
this and handles ePAPR's "next-level-cache" property as well as
powermac.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/prom
Using the common code means that more complete cache information will
provided in sysfs on platforms that don't use the l2-cache property
convention.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/sysfs.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
d
The hard_smp_processor_id functions are the appropriate interfaces for
managing physical CPU ids.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/powermac/smp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/smp
smp_hw_index isn't used on 64-bit, so move it from smp.c to
setup_32.c.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup_32.c |2 ++
arch/powerpc/kernel/smp.c |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/setup_3
On Wed, Dec 10, 2008 at 05:29:53PM -0600, Ayman El-Khashab wrote:
> My system consists of a pair of 460EXs attached by way of both PCI-E and
> PCI. Ultimately my goal is to communicate between them via pci-e (is
> there anything out there that does this already?).
I can't help you with that exact
On Wed, 10 Dec 2008, Josh Boyer wrote:
> On Thu, 11 Dec 2008 10:46:28 +1100
>>> +#ifdef CONFIG_PCI
>>> +extern unsigned int ppc_pci_flags;
>>> +#define ppc_pci_set_flags(flags) ppc_pci_flags = (flags)
>>> +#define ppc_pci_add_flags(flags) ppc_pci_flags |= (flags)
>>> +#define ppc_pci_flag_is_set(fl
On Wed, 2008-12-10 at 18:54 -0500, Josh Boyer wrote:
> On Thu, 11 Dec 2008 10:46:28 +1100
> Michael Ellerman <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2008-12-10 at 14:11 -0500, Josh Boyer wrote:
> > > Currently there are a number of platforms that open code access to
> > > the ppc_pci_flags global
On Thu, 11 Dec 2008 10:46:28 +1100
Michael Ellerman <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-12-10 at 14:11 -0500, Josh Boyer wrote:
> > Currently there are a number of platforms that open code access to
> > the ppc_pci_flags global variable. However, that variable is not
> > present if CONFIG_P
On Wed, 2008-12-10 at 14:11 -0500, Josh Boyer wrote:
> Currently there are a number of platforms that open code access to
> the ppc_pci_flags global variable. However, that variable is not
> present if CONFIG_PCI is not set, which can lead to a build break.
>
> This introduces a number of accesso
My system consists of a pair of 460EXs attached by way of both PCI-E and
PCI. Ultimately my goal is to communicate between them via pci-e (is
there anything out there that does this already?). For a small step, I
am trying to get the PCI to work. I already have the PCI boot ability
of the 460EXs
> In the code that does the mapping. It's a lot cheaper to figure out if
> _PAGE_COHERENT is needed once per mapping instead of per page per fault.
What do you mean by "code that does the mapping" ?
The OR'ing or AND'ing out of one bit is pretty cheap regardless, so "a
lot cheaper" is very rela
Here is an updated patch. Doc has been moved to 4xx and amcc changed to
ibm.
Arnd: I removed your acked-by just in case you don't approve of the new
flash layout. Feel free to ack again.
Cheers,
Sean
Port of the ndfc driver to an OF platform driver.
Signed-off-by: Sean MacLennan <[EMAIL PROT
Hi Matteo,
On Wed, 10 Dec 2008 19:49:58 +0100 Matteo Fortini <[EMAIL PROTECTED]> wrote:
>
> From d500e922b750a2bea554d32d8f12937f4da9c80a Mon Sep 17 00:00:00 2001
> From: Matteo Fortini <[EMAIL PROTECTED]>
> Date: Wed, 10 Dec 2008 19:33:16 +0100
> Subject: [PATCH] Fix: put dummy byte to enable fi
On Thu, 11 Dec 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-12-10 at 11:33 -0800, Trent Piepho wrote:
>> On Wed, 10 Dec 2008, Benjamin Herrenschmidt wrote:
>>> This changes the logic so that instead, the PTE now contains
>>> _PAGE_COHERENT for all normal RAM pages tha have I = 0. The hash
>>>
On Thu, 2008-12-11 at 09:14 +1100, Paul Mackerras wrote:
> Dave Hansen writes:
> > This patch ensures that we do not touch bootmem for any node which
> > has not been initialized.
> >
> > Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
>
> So, should I be sending this to Linus for 2.6.28?
Yes, th
Paul Mackerras wrote:
Dave Hansen writes:
This patch ensures that we do not touch bootmem for any node which
has not been initialized.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
So, should I be sending this to Linus for 2.6.28?
I notice you have added a dbg() call. For a 2.6.28
I am confused about the capabilities of the PPC440SPe DMA hardware. I'm
wondering if I can use it to transfer data between system memory and a PCI
Express slave-only device. To do that, the DMA scatter-gather list entry used
by the DMA hardware would need to support addresses > 32-bits as the
Dave Hansen writes:
> This patch ensures that we do not touch bootmem for any node which
> has not been initialized.
>
> Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
So, should I be sending this to Linus for 2.6.28?
I notice you have added a dbg() call. For a 2.6.28 patch I'd somewhat
prefer
On Wed, 2008-12-10 at 09:25 -0500, Josh Boyer wrote:
> On Mon, 08 Dec 2008 16:38:14 +1100
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > > > --- linux-work.orig/arch/powerpc/platforms/40x/ppc40x_simple.c
> > > > 2008-12-08 15:51:49.0 +1100
> > > > +++ linux-work/arch/powerpc/plat
David Howells writes:
> Ummm... On powerpc, I believe rotate-left would be a division as it does the
> bit-numbering and the bit direction the opposite way to more familiar CPUs
> such as x86.
No. :)
"Left" and "right" are relative to the way those of us humans in the
Western European cultural
On Wed, 2008-12-10 at 11:33 -0800, Trent Piepho wrote:
> On Wed, 10 Dec 2008, Benjamin Herrenschmidt wrote:
> > This changes the logic so that instead, the PTE now contains
> > _PAGE_COHERENT for all normal RAM pages tha have I = 0. The hash
> > code clears it if the feature bit is not set.
>
> Wh
On Thu, 11 Dec 2008 07:03:57 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > > We still leave G=1 on the linear mapping for now, we need to
> > > stop over-mapping RAM to be able to remove it.
> >
> > Hm. Over-mapping it has the nice advantage that we use as few pinned
> > TLB ent
> > We still leave G=1 on the linear mapping for now, we need to
> > stop over-mapping RAM to be able to remove it.
>
> Hm. Over-mapping it has the nice advantage that we use as few pinned
> TLB entries as possible. For 440x6 cores with more than 256 MiB of
> DRAM, you could theoretically use a
On Wed, 2008-12-10 at 14:21 +0300, Yuri Tikhonov wrote:
>
> > I'm not sure about the above & PMD_MASK. Shouldn't we instead make it
> > not build if (PKMAP_BASE & PMD_MASK) != 0 ?
>
> We separated the !4K_PAGES case here exactly because (PKMAP_BASE &
> PMD_MASK) != 0 [see the comment to this
On Wed, 10 Dec 2008, Benjamin Herrenschmidt wrote:
> This changes the logic so that instead, the PTE now contains
> _PAGE_COHERENT for all normal RAM pages tha have I = 0. The hash
> code clears it if the feature bit is not set.
Why not check the feature bit when the PTE is made and unset _PAGE_CO
Currently there are a number of platforms that open code access to
the ppc_pci_flags global variable. However, that variable is not
present if CONFIG_PCI is not set, which can lead to a build break.
This introduces a number of accessor functions that are defined
to be empty in the case of CONFIG_
Hello Dan,
On Wednesday, December 10, 2008 you wrote:
> On Mon, 2008-12-08 at 14:08 -0700, Dan Williams wrote:
>> On Mon, 2008-12-08 at 12:14 -0700, Yuri Tikhonov wrote:
>> > The destination address may be present in the source list, so we should
>> > map the addresses from the source list firs
On Wed, 10 Dec 2008 09:25:08 -0500
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Mon, 08 Dec 2008 16:38:14 +1100
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> >
> > > > --- linux-work.orig/arch/powerpc/platforms/40x/ppc40x_simple.c
> > > > 2008-12-08 15:51:49.0 +1100
> > > > +++
On Mon, 2008-12-08 at 14:08 -0700, Dan Williams wrote:
> On Mon, 2008-12-08 at 12:14 -0700, Yuri Tikhonov wrote:
> > The destination address may be present in the source list, so we should
> > map the addresses from the source list first.
> > Otherwise, if page corresponding to destination is not
From d500e922b750a2bea554d32d8f12937f4da9c80a Mon Sep 17 00:00:00 2001
From: Matteo Fortini <[EMAIL PROTECTED]>
Date: Wed, 10 Dec 2008 19:33:16 +0100
Subject: [PATCH] Fix: put dummy byte to enable fixing EOF bug to first
place in order not to break some drivers
Use ALARM interrupt to avoid waiti
Hello Scott,
On Wednesday, December 10, 2008 you wrote:
> On Wed, Dec 10, 2008 at 01:29:12PM +0300, Yuri Tikhonov wrote:
>> On Wednesday, December 10, 2008 you wrote:
>> > x * y / z is parsed as (x * y) / z, not x * (y / z).
>>
>> Here we believe in preprocessor: since all PAGE_SIZE, 8, and
>
On Wed, Dec 10, 2008 at 01:29:12PM +0300, Yuri Tikhonov wrote:
> On Wednesday, December 10, 2008 you wrote:
> > x * y / z is parsed as (x * y) / z, not x * (y / z).
>
> Here we believe in preprocessor: since all PAGE_SIZE, 8, and
> THREAD_SIZE are the constants we expect it will calculate this.
The following patch fixes divide-by-zero error for the
cases of really big PAGE_SIZEs (e.g. 256KB on ppc44x).
Support for big page sizes on 44x is not present in the
current kernel yet, but coming soon.
Also this patch fixes the comment for the max_threads
settings, as this didn't match the thing
On Dec 10, 2008, at 8:00 AM, Norbert van Bolhuis wrote:
I'm preparing the latest (2.6.28-rc7) linux kernel for an MPC8313
based project
that's about to start.
Things seems to work great with the base 2.6.28-rc7 kernel. On our
MPC8313E-RDB
the kernel boots without problems, ethernet (with
From: Julia Lawall <[EMAIL PROTECTED]>
The return value of the remove function of a driver structure, and thus of
a platform_driver structure, is ultimately ignored, and is thus
unnecessary. This patch removes the return value for the remove function
stored in a platform_driver structure. For th
Hi Trent,
On Wed, Dec 10, 2008 at 07:41:40AM -0800, Trent Piepho wrote:
> Add bindings to support LEDs defined as of_platform devices in addition to
> the existing bindings for platform devices.
>
> New options in Kconfig allow the platform binding code and/or the
> of_platform code to be turned
Yes, there is the "default-on" trigger but there are problems with that.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when then trigg
Replace the two boolean properties default_state and keep_state with a
single tristate property that can be set to
LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP). This ends up being more complicated,
requires more code, and makes developers remember not just the name of the
field to set but also the symbolic co
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on. The of_platform code is of course only
available on archs that have OF support
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
keep this state which is otherwise unknown to Linux.
This requires that the un
On Mon, 08 Dec 2008 16:38:14 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > > --- linux-work.orig/arch/powerpc/platforms/40x/ppc40x_simple.c
> > > 2008-12-08 15:51:49.0 +1100
> > > +++ linux-work/arch/powerpc/platforms/40x/ppc40x_simple.c 2008-12-08
> > > 15:51:52.
On Wed, 10 Dec 2008, Liu Yu wrote:
> KVM on E500 platform currently utilize TLB1 entries without bothering host,
> that is using unused TLB1 entries.
>
> So, KVM needs to read tlbcam_index and num_tlbcam_entries to know exactly
> which TLB1 entry is unused.
Do you need really need num_tlbcam_entri
I'm preparing the latest (2.6.28-rc7) linux kernel for an MPC8313 based project
that's about to start.
Things seems to work great with the base 2.6.28-rc7 kernel. On our MPC8313E-RDB
the kernel boots without problems, ethernet (with eTSEC2/eth1) works and even
eTSEC1/eth0 has a 1gbit link. Most
This patch adds support for page sizes bigger than 4K (16K/64K) on
PPC 44x.
PGDIR table is much smaller than page in case of 16K/64K pages (512
and 32 bytes resp.) so we allocate PGDIR with kzalloc() instead of
__get_free_pages().
PTE table covers rather big memory area in case of 16K/64K pages
(32
The udbg console is currently always enabled for platforms selecting
the PPC_UDBG_16550 symbol (needed to create platform devices for
8250 SoC UARTs from DT).
Now, the udbg console is nice for debugging as it works so early, but
it also has a number of disadvantages:
- It doesn't respect console=
On Wed, 10 Dec 2008 16:50:50 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> After discussing with chip designers, it appears that it's not
> necessary to set G everywhere on 440 cores. The various core
> errata related to prefetch should be sorted out by firmware by
> disabling icache p
Hello David,
On Wednesday, December 10, 2008 you wrote:
> Yuri Tikhonov <[EMAIL PROTECTED]> wrote:
>> Here we believe in preprocessor: since all PAGE_SIZE, 8, and
>> THREAD_SIZE are the constants we expect it will calculate this.
> The preprocessor shouldn't be calculating this. I believe
On Wed, 10 Dec 2008, David Howells wrote:
> Yuri Tikhonov <[EMAIL PROTECTED]> wrote:
> > In any case, adding braces as follows probably would be better:
> >
> > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
>
> I think you mean brackets, not braces '{}'.
>
> > Right ?
>
> De
David Howells <[EMAIL PROTECTED]> wrote:
> Ummm... On powerpc, I believe rotate-left would be a division as it does the
> bit-numbering and the bit direction the opposite way to more familiar CPUs
> such as x86.
Actually, I'm not sure that's true. Sometimes powerpc makes my head hurt:-)
David
Yuri Tikhonov <[EMAIL PROTECTED]> wrote:
> Here we believe in preprocessor: since all PAGE_SIZE, 8, and
> THREAD_SIZE are the constants we expect it will calculate this.
The preprocessor shouldn't be calculating this. I believe it will _only_
calculate expressions for #if. In the situation yo
On Wed, 10 Dec 2008 10:07:16 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> On Wednesday 10 December 2008, Benjamin Herrenschmidt wrote:
> > > Why is there a need to have so many files? I would think you could
> > > have a single file with all the ECC monitoring implementations in it
> > > calle
Hello Ben,
On Wednesday, December 10, 2008 you wrote:
> Hi Ilya !
> Looks good overall. A few minor comments.
>> +config PPC_4K_PAGES
>> + bool "4k page size"
>> +
>> +config PPC_16K_PAGES
>> + bool "16k page size" if 44x
>> +
>> +config PPC_64K_PAGES
>> + bool "64k page size" if 4
Hello Al,
On Wednesday, December 10, 2008 you wrote:
> On Wed, Dec 10, 2008 at 01:01:13PM +0300, Yuri Tikhonov wrote:
>> >> + max_threads = mempages * PAGE_SIZE / (8 * THREAD_SIZE);
>> >
>> >> +#endif
>>
>> > Can't this overflow, e.g. on 32-bit m
On Wed, Dec 10, 2008 at 01:01:13PM +0300, Yuri Tikhonov wrote:
> >> + max_threads = mempages * PAGE_SIZE / (8 * THREAD_SIZE);
> >
> >> +#endif
>
> > Can't this overflow, e.g. on 32-bit machines with HIGHMEM?
>
> The multiplier here is not PAGE_SIZE
Hello Geert,
On Wednesday, December 10, 2008 you wrote:
> On Tue, 9 Dec 2008, Yuri Tikhonov wrote:
>> The following patch fixes divide-by-zero error for the
>> cases of really big PAGE_SIZEs (e.g. 256KB on ppc44x).
>> Support for such big page sizes on 44x is not present in the
>> current kernel
Cliff Wickman wrote:
> [EMAIL PROTECTED]
>
> Arnd Bergmann and Mijo Safradin called my attention to problems with
> libnuma's read_mask() on a big-endian 64-bit machine.
>
> In testing that function I found it to be buggy on little-endian and 32-bit
> systems as well.
>
> I propose a function th
On Wednesday 10 December 2008, Benjamin Herrenschmidt wrote:
> > Why is there a need to have so many files? I would think you could
> > have a single file with all the ECC monitoring implementations in it
> > called ppc4xx_ecc.c (or such). Surely they would share some amount
> > of code?
>
> Well
> >I thought I might leverage the definitions Stefan Roese came up with for
> >u-boot for the base memory controller:
> >
> >CONFIG_PPC4xx_IBM_SDRAM: Applicable to 405GP, 405CR, 405EP, AP1000,
> > and ML2
> >CONFIG_PPC4xx_IBM_DDR: Applicable to 440GP, 44
KVM on E500 platform currently utilize TLB1 entries without bothering host,
that is using unused TLB1 entries.
So, KVM needs to read tlbcam_index and num_tlbcam_entries to know exactly
which TLB1 entry is unused.
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/mmu-fsl-book
On Tue, 9 Dec 2008, Yuri Tikhonov wrote:
> The following patch fixes divide-by-zero error for the
> cases of really big PAGE_SIZEs (e.g. 256KB on ppc44x).
> Support for such big page sizes on 44x is not present in the
> current kernel yet, but coming soon.
>
> Also this patch fixes the comment for
On Wed, 2008-12-10 at 17:08 +1100, Benjamin Herrenschmidt wrote:
> The function flush_HPTE() is used in only one place, the implementation
> of DEBUG_PAGEALLOC on ppc32.
>
> It's actually a dup of flush_tlb_page() though it's -slightly- more
> efficient on hash based processors. We remove it and r
n Mon, 08 Dec 2008 21:57:12 -1000
"Mitch Bradley" <[EMAIL PROTECTED]> wrote:
> One address/size cell isn't enough for the next generation of NAND
> FLASH chips.
>
I am no dts expert, but I thought I could put:
nand {
#address-cells = <1>;
#siz
79 matches
Mail list logo
