Josh:
In working through the PPC4XX "memory-controller","ibm,sdram-4xx-ddr2"
adapter driver for the EDAC MC driver, there are a substantial number of
indirect DCR accesses.
Ideally, I would use the address and data DCRs implied from the SDRAM0
dcr-reg device tree property; however, the mtdcri and
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 replace it by
a direct call to the hash flush code on those processors and t
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 prefetching in CCR0. We add the workaround to
the kernel however just in case ld firmwares
Currently, we never set _PAGE_COHERENT in the PTEs, we just OR it in
in the hash code based on some CPU feature bit. We also manipulate
_PAGE_NO_CACHE and _PAGE_GUARDED by hand in all sorts of places.
This changes the logic so that instead, the PTE now contains
_PAGE_COHERENT for all normal RAM pa
On Wed, 3 Dec 2008, Richard Purdie wrote:
> On Sun, 2008-11-23 at 13:31 +0100, Pavel Machek wrote:
>> On Thu 2008-11-20 17:05:56, Trent Piepho wrote:
>>> I thought of that, but it ends up being more complex. Instead of just
>>> using:
>>> static const struct gpio_led myled = {
>>> .name = "som
On 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>;
#size-cells = <
On Mon, Dec 8, 2008 at 5:41 PM, Yuri Tikhonov <[EMAIL PROTECTED]> wrote:
> On Tuesday, December 9, 2008 you wrote:
>
>> On Mon, Dec 8, 2008 at 2:55 PM, Yuri Tikhonov <[EMAIL PROTECTED]> wrote:
>>> Using src_list argument of async_xor() as a storage for dma addresses
>>> implies sizeof(dma_addr_t) <
On Tue, 2008-12-09 at 22:47 +0300, Anton Vorontsov wrote:
> The `have_of' variable is a relic from the arch/ppc time, it isn't
> useful nowadays.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/include/asm/processo
Steven A. Falco wrote:
> Stefan Roese wrote:
>> This adds a SPI driver for the SPI controller found in the IBM/AMCC
>> 4xx PowerPC's.
>>
>> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
>> Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
>> Acked-by: Josh Boyer <[EMAIL PROTECTED]>
>> ---
>
> How
On Tue, 2008-12-09 at 21:23 +0300, Ilya Yanok wrote:
> Defining the start virtual address of the consistent memory
> in configs leads to overlapping of the consistent area with
> the other virtual regions (fixmap, pkmap, vmalloc). Defaults from
> current kernel just set consistent memory area to be
Quoting Dave Hansen ([EMAIL PROTECTED]):
>
> I'm debating whether this is worth it. It makes this a bit more clean
> looking, but doesn't seriously enhance readability. But, I do think
> it helps a bit.
>
> Thoughts?
Absolutely. do_init_bootmem_node() is *still* a bit largish,
but far better b
Stefan Roese wrote:
> This adds a SPI driver for the SPI controller found in the IBM/AMCC
> 4xx PowerPC's.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
> Acked-by: Josh Boyer <[EMAIL PROTECTED]>
> ---
I have a question as to how to use th
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 44x || PPC64
> + select PPC_HAS_HASH_64K if PPC64
I'd rather if t
On Tue, 2008-12-09 at 07:17 -0600, Kumar Gala wrote:
> > There are some semingly unrelated patches in the pile as they
> > are dependencies of the main ones so I'm including them in.
>
> You'll be happy to know these patches at least boot on real 85xx SMP HW.
Ah excellent !
Now time for you to
On Tue, 2008-12-09 at 07:10 -0600, Kumar Gala wrote:
> > +void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long
> > vmaddr)
> > +{
> > + unsigned int pid;
> > +
> > + preempt_disable();
> > + pid = vma ? vma->vm_mm->context.id : 0;
> > + if (pid != MMU_NO_CONTEXT)
> > +
The `have_of' variable is a relic from the arch/ppc time, it isn't
useful nowadays.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/processor.h |2 --
arch/powerpc/kernel/pci-common.c |2 --
arch/powerpc/kernel/pci_32.c |7 +--
arch/powe
Defining the start virtual address of the consistent memory
in configs leads to overlapping of the consistent area with
the other virtual regions (fixmap, pkmap, vmalloc). Defaults from
current kernel just set consistent memory area to be somewhere
high in the vmalloc area and then you need to pra
If we fail a bootmem allocation, the bootmem code itself
panics. No need to redo it here.
Also change the wording of the other panic. We don't
strictly have to allocate memory on the specified node.
It is just a hint and that node may not even *have* any
memory on it. In that case we can and d
As I said earlier, I'm trying to restrict the use of NODE_DATA()
since it can easily be referenced too early otherwise.
free_bootmem_with_active_regions() does not in practice need to
deal with multiple nodes. I already audited all of its callers.
This patch makes it take a pgdat instead of doi
The use of NODE_DATA() in the ppc init code is fragile. We use
it for some nodes as we are initializing others. As the loop
initializing them has gotten more complex and broken out into
several functions it gets harder and harder to remember how
this goes.
This was recently the cause of a bug
careful_allocation() was calling into the bootemem allocator for
nodes which had not been fully initialized and caused a previous
bug. http://patchwork.ozlabs.org/patch/10528/ So, I merged a
few broken out loops in do_init_bootmem() to fix it. That changed
the code ordering.
I think this bug i
Both users of careful_allocation() immediately memset() the
result. So, just do it in one place.
Also give careful_allocation() a 'z' prefix to bring it in
line with kzmalloc() and friends.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.git-dave/arch/powerpc/mm/numa.c | 11 +++
Since we memset() the result in both of the uses here,
just make careful_alloc() return a virtual address.
Also, add a separate variable to store the physial
address that comes back from the lmb_alloc() functions.
This makes it less likely that someone will screw it up
forgetting to convert before
I'm debating whether this is worth it. It makes this a bit more clean
looking, but doesn't seriously enhance readability. But, I do think
it helps a bit.
Thoughts?
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.git-dave/arch/powerpc/mm/numa.c | 104 +++--
The behavior in careful_allocation() really confused me
at first. Add a comment to hopefully make it easier
on the next doofus that looks at it.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
linux-2.6.git-dave/arch/powerpc/mm/numa.c | 12 ++--
1 file changed, 10 insertions(+), 2
The first patch in this series is a genuine bug fix. The rest
are really just an RFC.
Jon introduced a bug a while ago. I introduced another when
trying to fix Jon's bug. I refuse to accept personal blame for
this and, instead, blame the code. :)
The reset of the series are "cleanups" that I t
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 the max_threads
settings, as this didn't match the
Guillaume Knispel wrote:
> blk = NULL; at the end of the loop is what is done in the more used
> rh_alloc_align(), so for consistency either we change both or we use
> the same construction here.
> I also think that testing for &info->free_list is harder to understand
> because you must have the l
On Tue, 09 Dec 2008 09:03:19 -0600
Timur Tabi <[EMAIL PROTECTED]> wrote:
> Guillaume Knispel wrote:
> > There is an error in rh_alloc_fixed() of the Remote Heap code:
> > If there is at least one free block blk won't be NULL at the end of the
> > search loop, so -ENOMEM won't be returned and the e
Guillaume Knispel wrote:
> There is an error in rh_alloc_fixed() of the Remote Heap code:
> If there is at least one free block blk won't be NULL at the end of the
> search loop, so -ENOMEM won't be returned and the else branch of
> "if (bs == s || be == e)" will be taken, corrupting the management
There is an error in rh_alloc_fixed() of the Remote Heap code:
If there is at least one free block blk won't be NULL at the end of the
search loop, so -ENOMEM won't be returned and the else branch of
"if (bs == s || be == e)" will be taken, corrupting the management
structures.
Signed-off-by: Guil
On Mon, 8 Dec 2008 19:34:55 -0800
Trent Piepho <[EMAIL PROTECTED]> wrote:
> Some assembly code in head_fsl_booke.S hard-coded the size of struct tlbcam
> to 20 when it indexed the TLBCAM table. Anyone changing the size of struct
> tlbcam would not know to expect that.
>
> The kernel already has
On Dec 7, 2008, at 11:39 PM, Benjamin Herrenschmidt wrote:
This series of patches is aimed at supporting SMP on non-hash
based processors. It consists of a rework of the MMU context
management and TLB management, clearly splitting hash32, hash64
and nohash in both cases, adding SMP safe context
+void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long
vmaddr)
+{
+ unsigned int pid;
+
+ preempt_disable();
+ pid = vma ? vma->vm_mm->context.id : 0;
+ if (pid != MMU_NO_CONTEXT)
+ _tlbil_va(vmaddr, pid);
+ preempt_enable();
+}
+EXPORT_S
On Tue, 9 Dec 2008 07:10:27 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> On Tuesday 09 December 2008, Sean MacLennan wrote:
> > On Thu, 4 Dec 2008 09:01:07 -0500
> >
> > "Josh Boyer" <[EMAIL PROTECTED]> wrote:
> > > In addition to an example DTS patch (probably to warp itself), could
> > > you
One address/size cell isn't enough for the next generation of NAND FLASH
chips.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
36 matches
Mail list logo
