* Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
From: Benjamin Herrenschmidt @ 2009-02-12 20:41 UTC (permalink / raw)
To: Ilya Yanok; +Cc: linuxppc-dev, wd, dzu
In-Reply-To: <49945EFE.8000401@emcraft.com>
> btw, ioremap doesn't provide useful 'caller').
I fixed that :-) (see patches I posted to the list, though that's
waiting for a patch to go upstream first that adds a
__get_vm_area_caller() that I need for ppc64).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
From: Josh Boyer @ 2009-02-12 20:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4B32B56D-9BCC-4ABA-A2AD-BCACFB30D18F@kernel.crashing.org>
On Thu, Feb 12, 2009 at 01:21:24PM -0600, Kumar Gala wrote:
>
> On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote:
>
>> The Power ISA 2.06 added power of two page sizes to the embedded MMU
>> architecture. Its done it such a way to be code compatiable with the
>> existing HW. Made the minor code changes to support both power of two
>> and power of four page sizes. Also added some new MAS bits and macros
>> that are defined as part of the 2.06 ISA.
>>
>> Note, its still invalid to try and use a page size that isn't
>> supported
>> by cpu.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> * Fixed MAS6_ISIZE macro
>>
>> arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++++++++++++++++++
>> +----------
>
> Do you want to rename asm/mmu-fsl-booke.h => mmu-booke.h (per ISA 2.06
> changes)?
Misleading perhaps. ISA 2.06 is really new and we've been calling 4xx
and FSL booke for a while now.
josh
^ permalink raw reply
* [PATCH] powerpc: rework dma-noncoherent to use generic vmalloc layer (2nd rev)
From: Ilya Yanok @ 2009-02-12 20:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: wd, dzu, Ilya Yanok
This patch rewrites consistent dma allocations support to use vmalloc
layer to allocate virtual memory space from vmalloc pool and get rid
of CONFIG_CONSISTENT_{START,SIZE}.
I still use VM_IOREMAP flag for these allocations (I'll try to post
patch adding separate VM_COHERENT_DMA flag to lkml later).
Now I save pages array in vm_struct pages field and use
__builtin_return_address(1) as 'caller' argument to get usefull info
in /proc/vmallocinfo:
-bash-3.2# cat /proc/vmallocinfo
0xe1000000-0xe1002000 8192 __ioremap+0x184/0x194 ioremap
[...]
0xe1f90000-0xe1f96000 24576 PrimeIocFifos+0x3a8/0x550 pages=5 ioremap
0xe1fa0000-0xe1fb1000 69632 __ioremap+0x184/0x194 ioremap
0xe1fc0000-0xe1fd1000 69632 __ioremap+0x184/0x194 ioremap
0xe2000000-0xe2f01000 15732736 __ioremap+0x184/0x194 ioremap
0xe2f32000-0xe2f34000 8192 __ioremap+0x184/0x194 ioremap
0xe2f38000-0xe2f3d000 20480 __ioremap+0x184/0x194 ioremap
0xe2f40000-0xe2f46000 24576 PrimeIocFifos+0x3a8/0x550 pages=5 ioremap
0xe2f80000-0xe3e81000 15732736 __ioremap+0x184/0x194 ioremap
0xe3f00000-0xe3f48000 294912 PrimeIocFifos+0x204/0x550 pages=71 ioremap
0xe3f80000-0xe3fc8000 294912 PrimeIocFifos+0x204/0x550 pages=71 ioremap
0xe3fe0000-0xe3fe6000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe3fe8000-0xe3fee000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe3fef000-0xe3ff8000 36864 bdx_open+0x10c/0x60c pages=8 vmalloc
0xe4000000-0xe4006000 24576 bdx_fifo_init+0x8c/0x12c pages=5 ioremap
0xe4007000-0xe400f000 32768 bdx_open+0x1f0/0x60c pages=7 vmalloc
0xe4010000-0xe401a000 40960 bdx_fifo_init+0x8c/0x12c pages=9 ioremap
(those ioremaps with pages=)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/powerpc/Kconfig | 25 ---
arch/powerpc/lib/dma-noncoherent.c | 299 +++++++-----------------------------
2 files changed, 53 insertions(+), 271 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 74cc312..ecae53f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -815,31 +815,6 @@ config TASK_SIZE
default "0x80000000" if PPC_PREP || PPC_8xx
default "0xc0000000"
-config CONSISTENT_START_BOOL
- bool "Set custom consistent memory pool address"
- depends on ADVANCED_OPTIONS && NOT_COHERENT_CACHE
- help
- This option allows you to set the base virtual address
- of the consistent memory pool. This pool of virtual
- memory is used to make consistent memory allocations.
-
-config CONSISTENT_START
- hex "Base virtual address of consistent memory pool" if CONSISTENT_START_BOOL
- default "0xfd000000" if (NOT_COHERENT_CACHE && 8xx)
- default "0xff100000" if NOT_COHERENT_CACHE
-
-config CONSISTENT_SIZE_BOOL
- bool "Set custom consistent memory pool size"
- depends on ADVANCED_OPTIONS && NOT_COHERENT_CACHE
- help
- This option allows you to set the size of the
- consistent memory pool. This pool of virtual memory
- is used to make consistent memory allocations.
-
-config CONSISTENT_SIZE
- hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
- default "0x00200000" if NOT_COHERENT_CACHE
-
config PIN_TLB
bool "Pinned Kernel TLBs (860 ONLY)"
depends on ADVANCED_OPTIONS && 8xx
diff --git a/arch/powerpc/lib/dma-noncoherent.c b/arch/powerpc/lib/dma-noncoherent.c
index b7dc4c1..2e321a9 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -29,121 +29,11 @@
#include <linux/types.h>
#include <linux/highmem.h>
#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
#include <asm/tlbflush.h>
/*
- * This address range defaults to a value that is safe for all
- * platforms which currently set CONFIG_NOT_COHERENT_CACHE. It
- * can be further configured for specific applications under
- * the "Advanced Setup" menu. -Matt
- */
-#define CONSISTENT_BASE (CONFIG_CONSISTENT_START)
-#define CONSISTENT_END (CONFIG_CONSISTENT_START + CONFIG_CONSISTENT_SIZE)
-#define CONSISTENT_OFFSET(x) (((unsigned long)(x) - CONSISTENT_BASE) >> PAGE_SHIFT)
-
-/*
- * This is the page table (2MB) covering uncached, DMA consistent allocations
- */
-static pte_t *consistent_pte;
-static DEFINE_SPINLOCK(consistent_lock);
-
-/*
- * VM region handling support.
- *
- * This should become something generic, handling VM region allocations for
- * vmalloc and similar (ioremap, module space, etc).
- *
- * I envisage vmalloc()'s supporting vm_struct becoming:
- *
- * struct vm_struct {
- * struct vm_region region;
- * unsigned long flags;
- * struct page **pages;
- * unsigned int nr_pages;
- * unsigned long phys_addr;
- * };
- *
- * get_vm_area() would then call vm_region_alloc with an appropriate
- * struct vm_region head (eg):
- *
- * struct vm_region vmalloc_head = {
- * .vm_list = LIST_HEAD_INIT(vmalloc_head.vm_list),
- * .vm_start = VMALLOC_START,
- * .vm_end = VMALLOC_END,
- * };
- *
- * However, vmalloc_head.vm_start is variable (typically, it is dependent on
- * the amount of RAM found at boot time.) I would imagine that get_vm_area()
- * would have to initialise this each time prior to calling vm_region_alloc().
- */
-struct ppc_vm_region {
- struct list_head vm_list;
- unsigned long vm_start;
- unsigned long vm_end;
-};
-
-static struct ppc_vm_region consistent_head = {
- .vm_list = LIST_HEAD_INIT(consistent_head.vm_list),
- .vm_start = CONSISTENT_BASE,
- .vm_end = CONSISTENT_END,
-};
-
-static struct ppc_vm_region *
-ppc_vm_region_alloc(struct ppc_vm_region *head, size_t size, gfp_t gfp)
-{
- unsigned long addr = head->vm_start, end = head->vm_end - size;
- unsigned long flags;
- struct ppc_vm_region *c, *new;
-
- new = kmalloc(sizeof(struct ppc_vm_region), gfp);
- if (!new)
- goto out;
-
- spin_lock_irqsave(&consistent_lock, flags);
-
- list_for_each_entry(c, &head->vm_list, vm_list) {
- if ((addr + size) < addr)
- goto nospc;
- if ((addr + size) <= c->vm_start)
- goto found;
- addr = c->vm_end;
- if (addr > end)
- goto nospc;
- }
-
- found:
- /*
- * Insert this entry _before_ the one we found.
- */
- list_add_tail(&new->vm_list, &c->vm_list);
- new->vm_start = addr;
- new->vm_end = addr + size;
-
- spin_unlock_irqrestore(&consistent_lock, flags);
- return new;
-
- nospc:
- spin_unlock_irqrestore(&consistent_lock, flags);
- kfree(new);
- out:
- return NULL;
-}
-
-static struct ppc_vm_region *ppc_vm_region_find(struct ppc_vm_region *head, unsigned long addr)
-{
- struct ppc_vm_region *c;
-
- list_for_each_entry(c, &head->vm_list, vm_list) {
- if (c->vm_start == addr)
- goto out;
- }
- c = NULL;
- out:
- return c;
-}
-
-/*
* Allocate DMA-coherent memory space and return both the kernel remapped
* virtual and bus address for that space.
*/
@@ -151,21 +41,21 @@ void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
{
struct page *page;
- struct ppc_vm_region *c;
unsigned long order;
+ int i;
+ unsigned int nr_pages = PAGE_ALIGN(size)>>PAGE_SHIFT;
+ unsigned int array_size = nr_pages * sizeof(struct page *);
+ struct page **pages;
+ struct page *end;
u64 mask = 0x00ffffff, limit; /* ISA default */
+ struct vm_struct *area;
- if (!consistent_pte) {
- printk(KERN_ERR "%s: not initialised\n", __func__);
- dump_stack();
- return NULL;
- }
-
+ BUG_ON(!mem_init_done);
size = PAGE_ALIGN(size);
limit = (mask + 1) & ~mask;
- if ((limit && size >= limit) || size >= (CONSISTENT_END - CONSISTENT_BASE)) {
- printk(KERN_WARNING "coherent allocation too big (requested %#x mask %#Lx)\n",
- size, mask);
+ if (limit && size >= limit) {
+ printk(KERN_WARNING "coherent allocation too big (requested "
+ "%#x mask %#Lx)\n", size, mask);
return NULL;
}
@@ -178,6 +68,8 @@ __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
if (!page)
goto no_page;
+ end = page + (1 << order);
+
/*
* Invalidate any data that might be lurking in the
* kernel direct-mapped region for device DMA.
@@ -188,48 +80,55 @@ __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
flush_dcache_range(kaddr, kaddr + size);
}
+ split_page(page, order);
+
/*
- * Allocate a virtual address in the consistent mapping region.
+ * Set the "dma handle"
*/
- c = ppc_vm_region_alloc(&consistent_head, size,
- gfp & ~(__GFP_DMA | __GFP_HIGHMEM));
- if (c) {
- unsigned long vaddr = c->vm_start;
- pte_t *pte = consistent_pte + CONSISTENT_OFFSET(vaddr);
- struct page *end = page + (1 << order);
-
- split_page(page, order);
-
- /*
- * Set the "dma handle"
- */
- *handle = page_to_phys(page);
+ *handle = page_to_phys(page);
+
+ area = get_vm_area_caller(size, VM_IOREMAP,
+ __builtin_return_address(1));
+ if (!area)
+ goto out_free_pages;
+
+ if (array_size > PAGE_SIZE) {
+ pages = vmalloc(array_size);
+ area->flags |= VM_VPAGES;
+ } else {
+ pages = kmalloc(array_size, GFP_KERNEL);
+ }
+ if (!pages)
+ goto out_free_area;
- do {
- BUG_ON(!pte_none(*pte));
+ area->pages = pages;
+ area->nr_pages = nr_pages;
- SetPageReserved(page);
- set_pte_at(&init_mm, vaddr,
- pte, mk_pte(page, pgprot_noncached(PAGE_KERNEL)));
- page++;
- pte++;
- vaddr += PAGE_SIZE;
- } while (size -= PAGE_SIZE);
+ for (i = 0; i < nr_pages; i++)
+ pages[i] = page + i;
- /*
- * Free the otherwise unused pages.
- */
- while (page < end) {
- __free_page(page);
- page++;
- }
+ if (map_vm_area(area, pgprot_noncached(PAGE_KERNEL), &pages))
+ goto out_unmap;
- return (void *)c->vm_start;
+ /*
+ * Free the otherwise unused pages.
+ */
+ page += nr_pages;
+ while (page < end) {
+ __free_page(page);
+ page++;
}
+ return area->addr;
+out_unmap:
+ vunmap(area->addr);
+ goto out_free_pages;
+out_free_area:
+ free_vm_area(area);
+out_free_pages:
if (page)
__free_pages(page, order);
- no_page:
+no_page:
return NULL;
}
EXPORT_SYMBOL(__dma_alloc_coherent);
@@ -239,104 +138,12 @@ EXPORT_SYMBOL(__dma_alloc_coherent);
*/
void __dma_free_coherent(size_t size, void *vaddr)
{
- struct ppc_vm_region *c;
- unsigned long flags, addr;
- pte_t *ptep;
-
- size = PAGE_ALIGN(size);
-
- spin_lock_irqsave(&consistent_lock, flags);
-
- c = ppc_vm_region_find(&consistent_head, (unsigned long)vaddr);
- if (!c)
- goto no_area;
-
- if ((c->vm_end - c->vm_start) != size) {
- printk(KERN_ERR "%s: freeing wrong coherent size (%ld != %d)\n",
- __func__, c->vm_end - c->vm_start, size);
- dump_stack();
- size = c->vm_end - c->vm_start;
- }
-
- ptep = consistent_pte + CONSISTENT_OFFSET(c->vm_start);
- addr = c->vm_start;
- do {
- pte_t pte = ptep_get_and_clear(&init_mm, addr, ptep);
- unsigned long pfn;
-
- ptep++;
- addr += PAGE_SIZE;
+ vfree(vaddr);
- if (!pte_none(pte) && pte_present(pte)) {
- pfn = pte_pfn(pte);
-
- if (pfn_valid(pfn)) {
- struct page *page = pfn_to_page(pfn);
- ClearPageReserved(page);
-
- __free_page(page);
- continue;
- }
- }
-
- printk(KERN_CRIT "%s: bad page in kernel page table\n",
- __func__);
- } while (size -= PAGE_SIZE);
-
- flush_tlb_kernel_range(c->vm_start, c->vm_end);
-
- list_del(&c->vm_list);
-
- spin_unlock_irqrestore(&consistent_lock, flags);
-
- kfree(c);
- return;
-
- no_area:
- spin_unlock_irqrestore(&consistent_lock, flags);
- printk(KERN_ERR "%s: trying to free invalid coherent area: %p\n",
- __func__, vaddr);
- dump_stack();
}
EXPORT_SYMBOL(__dma_free_coherent);
/*
- * Initialise the consistent memory allocation.
- */
-static int __init dma_alloc_init(void)
-{
- pgd_t *pgd;
- pud_t *pud;
- pmd_t *pmd;
- pte_t *pte;
- int ret = 0;
-
- do {
- pgd = pgd_offset(&init_mm, CONSISTENT_BASE);
- pud = pud_alloc(&init_mm, pgd, CONSISTENT_BASE);
- pmd = pmd_alloc(&init_mm, pud, CONSISTENT_BASE);
- if (!pmd) {
- printk(KERN_ERR "%s: no pmd tables\n", __func__);
- ret = -ENOMEM;
- break;
- }
-
- pte = pte_alloc_kernel(pmd, CONSISTENT_BASE);
- if (!pte) {
- printk(KERN_ERR "%s: no pte tables\n", __func__);
- ret = -ENOMEM;
- break;
- }
-
- consistent_pte = pte;
- } while (0);
-
- return ret;
-}
-
-core_initcall(dma_alloc_init);
-
-/*
* make an area consistent.
*/
void __dma_sync(void *vaddr, size_t size, int direction)
--
1.6.0.6
^ permalink raw reply related
* RE: AMCC ppc440spe 2.6.23.10 kernel boot help
From: Shubhada Pugaonkar @ 2009-02-12 20:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
Hi Wolfgang
I could get 2.6.28 version up and running after using device tree blob.
Also our customer is using Luan and our IT dept ordered Katmai.=20
So looks like the problem is solved for now (basically my company needs
to look into alternative setups)
Thanks a lot for your prompt help.
Shubhada
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]=20
Sent: Thursday, February 12, 2009 12:07 AM
To: Shubhada Pugaonkar
Cc: linuxppc-dev@ozlabs.org
Subject: Re: AMCC ppc440spe 2.6.23.10 kernel boot help
Dear Shubhada,
In message
<8A71B368A89016469F72CD08050AD33402D57545@maui.asicdesigners.com> you
wrote:
>=20
> I am kind of helpless regarding the kernel version, as our customer is
> using it and I need to replicate their environment. I just tried
2.6.28
> with katmai_defconfig file and still face the same problem.=20
You probably did not load (and use) the device tree blob which is
needed with recent (arch/powerpc based) kernel versions.
> The config file that I sent before is provided by the customer. It is
a
> working configuration for them.=20
>=20
> The exact board that I have is Katmai.
It looks broken to me for a Katmai board. Are you sure your customer
is also using Katmai?
> my printenv output is as follows.
This is obviously an old setup for old (arch/ppc only) kernel
versions, and heavily crippl^H^H^H^H^H modified from the default
environment. You might consider to restart from the default
environment settings (probably even with a recent version of U-Boot -
your's is too old and does not include full device tree support).
On the other hand, I don;t see a reason why the old (arch/ppc based)
kernel should not boot - except that it might be misconfigured for
that board.
Did you try any of the released (and well tested) kernel images on
our FTP server? See ftp://ftp.denx.de/pub/linux/images/amcc/katmai/
Best regards,
Wolfgang Denk
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Just think of a computer as hardware you can program."
- Nigel de la Tierre
^ permalink raw reply
* Re: [PATCH v2] powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines
From: Kumar Gala @ 2009-02-12 19:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1234311976-22026-1-git-send-email-galak@kernel.crashing.org>
On Feb 10, 2009, at 6:26 PM, Kumar Gala wrote:
> The Power ISA 2.06 added power of two page sizes to the embedded MMU
> architecture. Its done it such a way to be code compatiable with the
> existing HW. Made the minor code changes to support both power of two
> and power of four page sizes. Also added some new MAS bits and macros
> that are defined as part of the 2.06 ISA.
>
> Note, its still invalid to try and use a page size that isn't
> supported
> by cpu.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> * Fixed MAS6_ISIZE macro
>
> arch/powerpc/include/asm/mmu-fsl-booke.h | 54 +++++++++++++++++++
> +----------
Do you want to rename asm/mmu-fsl-booke.h => mmu-booke.h (per ISA 2.06
changes)?
- k
^ permalink raw reply
* Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
From: Ilya Yanok @ 2009-02-12 17:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, wd, dzu, Ilya Yanok
In-Reply-To: <1233722625.16867.249.camel@pasglop>
Hi Ben,
excuse me for so long time to reply.
Benjamin Herrenschmidt wrote:
>> This patch rewrites consistent dma allocations support to use vmalloc
>> layer to allocate virtual memory space from vmalloc pool and get rid
>> of CONFIG_CONSISTENT_{START,SIZE}.
>>
>
> So as commented before, please drop the defconfig updates.
>
Ok.
>> -/*
>> * Allocate DMA-coherent memory space and return both the kernel remapped
>> * virtual and bus address for that space.
>> */
>> @@ -151,19 +41,17 @@ void *
>> __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
>> {
>> struct page *page;
>> - struct vm_region *c;
>> unsigned long order;
>> + void *v;
>> + int i;
>> + struct page *pages[PAGE_ALIGN(size)>>PAGE_SHIFT];
>>
>
> I'm not -too- fan of that page list one the stack up there.
>
> I understand why you don't wantto kmalloc something here etc... but
> that's what __vmalloc_area() does and it's somewhat useful to keep track
> of the page array that way, it might prove handy in the future.
>
I don't like array being on stack too... But I fear I didn't understand
what were you talking about here...
__vmalloc_area does kmalloc or vmalloc to allocate pages array and then
allocates pages one by one but we need physically contiguous pages
here... (And that is why we don't really need to store pages array)
So I just added kmalloc/vmalloc to allocate the pages array and stored
it in vm_struct structure.
> Might even be worth adding a generic patch to add a VM_COHERENT_DMA flag
> so they can be listed as such and make sure you set the "caller" field
> yourself with your own caller.
>
I used __builtin_return_address(1) as the 'caller' so I get useful
output in /proc/vmallocinfo (btw, ioremap doesn't provide useful 'caller').
Do you think we have high chances of such a patch being accepted in
lkml? Well, I'll try to do this (for now I stick with VM_IOREMAP).
> (Hint: look at the output of /proc/vmallocinfo)
>
> Also, the mucking around with PG_Reserved shouldn't be of any use
> anymore.
>
Ok, removed.
Please review the updated patch (I'll post it as a followup).
Regards, Ilya.
^ permalink raw reply
* Re: [PATCH] PS3 ps3av_set_video_mode() make id signed
From: Geoff Levand @ 2009-02-12 17:24 UTC (permalink / raw)
To: Roel Kluin; +Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <4975F455.8020004@gmail.com>
Roel Kluin wrote:
> Make id signed so a negative id will get noticed. Error out if
> ps3av_auto_videomode() fails.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> arch/powerpc/include/asm/ps3av.h | 2 +-
> drivers/ps3/ps3av.c | 16 ++++++++++++----
> 2 files changed, 13 insertions(+), 5 deletions(-)
Just FYI, I added this to ps3-linux.git, since it is not a
critical fix, I will submit for 2.6.30.
-Geoff
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Steven Rostedt @ 2009-02-12 16:58 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212164720.GA4868@nowhere>
On Thu, 12 Feb 2009, Frederic Weisbecker wrote:
>
>
> Yes of course, I knew most of it was architecture independant but I delayed
> this TODO for future ports, and you've done it.
>
> Thanks.
>
> Just a micro detail: the ftrace_push/pop_return_trace are parts of
> the core of the entry/return probe, something that could be used
> by other users than the function graph tracer itself.
>
> Perhaps it would be better to put them in kernel/trace/ftrace.c
> What do you think?
I'll go with your above method. We'll move it when it comes to that ;-)
>
> Anyway, Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Thanks!
I'll update my repo.
-- Steve
^ permalink raw reply
* Re: request_irq return errno 38
From: Timur Tabi @ 2009-02-12 16:39 UTC (permalink / raw)
To: Vijay Nikam; +Cc: scottwood, linuxppc-dev
In-Reply-To: <f234e2140902120251t2bd3aa5dsc950cacdd6b4422a@mail.gmail.com>
On Thu, Feb 12, 2009 at 4:51 AM, Vijay Nikam <vijay.t.nikam@gmail.com> wrote:
> Also how I can read the device tree binary file ? ? ?
It would be a lot simpler if you just read the documentation (see
booting-without-of.txt) and looked at other device drivers to see what
they do.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Frederic Weisbecker @ 2009-02-12 16:47 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Andrew Morton
In-Reply-To: <alpine.DEB.1.10.0902121131150.15469@gandalf.stny.rr.com>
On Thu, Feb 12, 2009 at 11:31:44AM -0500, Steven Rostedt wrote:
>
> On Thu, 12 Feb 2009, Frederic Weisbecker wrote:
>
> > On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote:
> > >
> > > The following set of patches are RFC and not for inclusion
> > > (unless everyone is fine with them as is).
> > >
> > > This is the port to PowerPC of the function graph tracer that was written
> > > by Frederic Weisbecker for the x86 architecture. It is broken up
> > > into a series of logical steps.
> > >
> > > 1) get generic code ready for other archs
> > > 2) get PowerPC 64-bit working with just static function tracing
> > > 3) get PowerPC 64-bit working with dynamic function tracing
> > > 4) get PowerPC 32-bit working with just static function tracing
> > > 5) get PowerPC 32-bit working with dynamic function tracing
> > >
> > > (with some clean ups in between)
> > >
> >
> >
> > Thanks a lot Steven!
> > I'm sad to not having a Power Pc to test it...
>
> BTW, Can I count that as an Acked-by: for the first patch. Since the first
> patch does modify your code.
>
> -- Steve
>
Yes of course, I knew most of it was architecture independant but I delayed
this TODO for future ports, and you've done it.
Thanks.
Just a micro detail: the ftrace_push/pop_return_trace are parts of
the core of the entry/return probe, something that could be used
by other users than the function graph tracer itself.
Perhaps it would be better to put them in kernel/trace/ftrace.c
What do you think?
Anyway, Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Steven Rostedt @ 2009-02-12 16:35 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, Paul Mackerras, Frederic Weisbecker, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212011051.265346435@goodmis.org>
On Wed, 11 Feb 2009, Steven Rostedt wrote:
>
> The following set of patches are RFC and not for inclusion
> (unless everyone is fine with them as is).
>
> This is the port to PowerPC of the function graph tracer that was written
> by Frederic Weisbecker for the x86 architecture. It is broken up
> into a series of logical steps.
>
> 1) get generic code ready for other archs
> 2) get PowerPC 64-bit working with just static function tracing
> 3) get PowerPC 64-bit working with dynamic function tracing
> 4) get PowerPC 32-bit working with just static function tracing
> 5) get PowerPC 32-bit working with dynamic function tracing
>
> (with some clean ups in between)
Ben, if you get some time (no rush really), can you give an acked-by
on each of the PPC patches. The first patch is ftrace generic, so
you can ignore that one.
I'll keep it in the RFC state, until I have an ack from either you or
Paul.
I'm not sure if these changes should go via you or Ingo. I'm thinking
that, since the first change modifies core ftrace code, I'll send it
towards tip, since all the rest depends on that first change.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC
From: Steven Rostedt @ 2009-02-12 16:31 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Andrew Morton
In-Reply-To: <20090212015503.GA4697@nowhere>
On Thu, 12 Feb 2009, Frederic Weisbecker wrote:
> On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote:
> >
> > The following set of patches are RFC and not for inclusion
> > (unless everyone is fine with them as is).
> >
> > This is the port to PowerPC of the function graph tracer that was written
> > by Frederic Weisbecker for the x86 architecture. It is broken up
> > into a series of logical steps.
> >
> > 1) get generic code ready for other archs
> > 2) get PowerPC 64-bit working with just static function tracing
> > 3) get PowerPC 64-bit working with dynamic function tracing
> > 4) get PowerPC 32-bit working with just static function tracing
> > 5) get PowerPC 32-bit working with dynamic function tracing
> >
> > (with some clean ups in between)
> >
>
>
> Thanks a lot Steven!
> I'm sad to not having a Power Pc to test it...
BTW, Can I count that as an Acked-by: for the first patch. Since the first
patch does modify your code.
-- Steve
^ permalink raw reply
* Re: [PATCH] Only disable/enable LSI interrupts in EEH
From: Mike Mason @ 2009-02-12 16:06 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linasvepstas, paulus
In-Reply-To: <1234309181.8323.12.camel@localhost>
Michael Ellerman wrote:
> On Tue, 2009-02-10 at 13:12 -0800, Mike Mason wrote:
>> I'm resubmitting this patch with a couple changes
>> suggested by Michael Ellerman. 1) the new functions
>> should be static, and 2) some people may object to
>> including unrelated formating changes.
>>
>> =========================================================
>>
>> The EEH code disables and enables interrupts during the
>> device recovery process. This is unnecessary for MSI
>> and MSI-X interrupts because they are effectively disabled
>> by the DMA Stopped state when an EEH error occurs. The
>> current code is also incorrect for MSI-X interrupts. It
>> doesn't take into account that MSI-X interrupts are tracked
>> in a different way than LSI/MSI interrupts. This patch
>> ensures only LSI interrupts are disabled/enabled.
>>
>> Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
>> Acked-by: Linas Vepstas <linasvepstas@gmail.com>
>
>
> Looks good. Assuming you've tested it :)
Yes, it's been tested with network devices that use LSI, MSI and MSI-X interrupts. All recovered fine.
>
> Acked-by: Michael Ellerman <michael@ellerman.id.au>
>
>
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Jean-Michel Hautbois @ 2009-02-12 14:26 UTC (permalink / raw)
To: Pieter; +Cc: linuxppc-dev
In-Reply-To: <49942D68.7080706@vastech.co.za>
[-- Attachment #1: Type: text/plain, Size: 3670 bytes --]
2009/2/12 Pieter <phenning@vastech.co.za>
> Jean-Michel Hautbois wrote:
> > 2009/2/12 David Gibson <david@gibson.dropbear.id.au
> > <mailto:david@gibson.dropbear.id.au>>
> >
> > On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
> > > 2009/2/12 Pieter <phenning@vastech.co.za
> > <mailto:phenning@vastech.co.za>>
> > >
> > > > Jean-Michel Hautbois wrote:
> > > > > Warning (reg_format): "reg" property in
> > > > > /localbus@f0010100/flash@0,0/partition@ff800000 has invalid
> > length (8
> > > > > JM
> > > > You are missing some definitions, The #address-cells and
> > #size-cells = <1>;
> > > > tis is a snippet of teh dts i defined for my board.
> > > >
> > > > flash@0,0 {
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > > compatible = "cfi-flash";
> > > > reg = <0x0 0x0 0x08000000>;
> > > > bank-width = <4>;
> > > > device-width = <1>;
> > > >
> > > > /* set flash partition to correspond tu mtd parts in
> > > > u-boot*/
> > > > /* 0xf8000000 */
> > > > partition@0x0 {
> > > > label = "factory-image";
> > > > reg = <0x00000000 0x01000000>;
> > > > };
> > > > /* 0xf9000000 */
> > > > partition@0x01000000 {
> > > > label = "app-image-1";
> > > > reg = <0x01000000 0x01000000>;
> > > > };
> > > > cheers pieter
> > > >
> > >
> > > Hi do have these definitions, at a higher level:
> >
> > The address-cells and size-cells definitions are not inherited. They
> > cover only the immediate children of the node where they appear.
> > Otherwise the default values apply (address-cells == 2, size-cells ==
> > 1), which are not right for your case.
> >
> > --
> > David Gibson | I'll have my music baroque, and
> > my code
> > david AT gibson.dropbear.id.au <http://gibson.dropbear.id.au> |
> > minimalist, thank you. NOT _the_ _other_
> > | _way_ _around_!
> > http://www.ozlabs.org/~dgibson <http://www.ozlabs.org/%7Edgibson> <
> http://www.ozlabs.org/%7Edgibson>
> >
> > OK, so, after having tested, I can't see any changes when booting.
> > I do not have more mtd in /proc/mtd.
> >
> > JM
> have you defined the following in your kernel config
>
> CONFIG_MTD_PHYSMAP_OF=y
> CONFIG_MTD_PARTITIONS=y
> CONFIG_MTD_OF_PARTS=y
>
> cheers pieter
>
I didn't have CONFIG_MTD_OF_PARTS=y.
Know, I have this output:
Found: Intel I28F016S3
fe000000.flash: Found 4 x8 devices at 0x0 in 32-bit bank
fe000000.flash: Found an alias at 0x800000 for the chip at 0x0
fe000000.flash: Found an alias at 0x1000000 for the chip at 0x0
fe000000.flash: Found an alias at 0x1800000 for the chip at 0x0
erase region 0: offset=0x0,size=0x40000,blocks=32
RedBoot partition parsing not available
Creating 3 MTD partitions on "fe000000.flash":
0x0000ff800000-0x0000ffc00000 : "kernel"
mtd: partition "kernel" is out of reach -- disabled
mtd: Giving out device 0 to kernel
0x0000ffc00000-0x0000fff00000 : "user"
mtd: partition "sofrel" is out of reach -- disabled
mtd: Giving out device 1 to user
0x0000fff00000-0x000100000000 : "u-boot"
mtd: partition "u-boot" is out of reach -- disabled
mtd: Giving out device 2 to u-boot
I think that the problem is in the reg part, but I can't understand why.
Isn't it the RAM mpping of my MTD that is the first address ?
Thanks agains,
Regards,
JM
[-- Attachment #2: Type: text/html, Size: 6574 bytes --]
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Pieter @ 2009-02-12 14:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jean-Michel Hautbois
In-Reply-To: <8cad0aa0902120536p3303322cvf9a7307391d195b9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]
Jean-Michel Hautbois wrote:
> 2009/2/12 David Gibson <david@gibson.dropbear.id.au
> <mailto:david@gibson.dropbear.id.au>>
>
> On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
> > 2009/2/12 Pieter <phenning@vastech.co.za
> <mailto:phenning@vastech.co.za>>
> >
> > > Jean-Michel Hautbois wrote:
> > > > Warning (reg_format): "reg" property in
> > > > /localbus@f0010100/flash@0,0/partition@ff800000 has invalid
> length (8
> > > > JM
> > > You are missing some definitions, The #address-cells and
> #size-cells = <1>;
> > > tis is a snippet of teh dts i defined for my board.
> > >
> > > flash@0,0 {
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > compatible = "cfi-flash";
> > > reg = <0x0 0x0 0x08000000>;
> > > bank-width = <4>;
> > > device-width = <1>;
> > >
> > > /* set flash partition to correspond tu mtd parts in
> > > u-boot*/
> > > /* 0xf8000000 */
> > > partition@0x0 {
> > > label = "factory-image";
> > > reg = <0x00000000 0x01000000>;
> > > };
> > > /* 0xf9000000 */
> > > partition@0x01000000 {
> > > label = "app-image-1";
> > > reg = <0x01000000 0x01000000>;
> > > };
> > > cheers pieter
> > >
> >
> > Hi do have these definitions, at a higher level:
>
> The address-cells and size-cells definitions are not inherited. They
> cover only the immediate children of the node where they appear.
> Otherwise the default values apply (address-cells == 2, size-cells ==
> 1), which are not right for your case.
>
> --
> David Gibson | I'll have my music baroque, and
> my code
> david AT gibson.dropbear.id.au <http://gibson.dropbear.id.au> |
> minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson <http://www.ozlabs.org/%7Edgibson>
>
> OK, so, after having tested, I can't see any changes when booting.
> I do not have more mtd in /proc/mtd.
>
> JM
have you defined the following in your kernel config
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_OF_PARTS=y
cheers pieter
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2722 bytes --]
^ permalink raw reply
* Re: SPI-Difference between MX1 and MX31
From: Wolfram Sang @ 2009-02-12 13:58 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev, a.paterniani
In-Reply-To: <20090212130026.GC3130@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 188 bytes --]
Ooops, wrong list. Sorry!
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: PowerPC 7447A Paging table Search
From: Kumar Gala @ 2009-02-12 13:58 UTC (permalink / raw)
To: sumedh tirodkar; +Cc: linuxppc-dev
In-Reply-To: <d2b9ccd90902120159k4f6024bbl831b43073d4126f3@mail.gmail.com>
On Feb 12, 2009, at 3:59 AM, sumedh tirodkar wrote:
> How will i confirm if PowerPC 7447A processor has or does not have a
> dedicated hardware for page table search algorithm?
> If it does not have, then which interrupt handler is written for page
> address translation mechanism?
It has one and linux uses it.
- k
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Jean-Michel Hautbois @ 2009-02-12 13:36 UTC (permalink / raw)
To: Jean-Michel Hautbois, Pieter, linuxppc-dev
In-Reply-To: <20090212133037.GA3651@yookeroo.seuss>
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
2009/2/12 David Gibson <david@gibson.dropbear.id.au>
> On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
> > 2009/2/12 Pieter <phenning@vastech.co.za>
> >
> > > Jean-Michel Hautbois wrote:
> > > > Warning (reg_format): "reg" property in
> > > > /localbus@f0010100/flash@0,0/partition@ff800000 has invalid length
> (8
> > > > JM
> > > You are missing some definitions, The #address-cells and #size-cells =
> <1>;
> > > tis is a snippet of teh dts i defined for my board.
> > >
> > > flash@0,0 {
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > compatible = "cfi-flash";
> > > reg = <0x0 0x0 0x08000000>;
> > > bank-width = <4>;
> > > device-width = <1>;
> > >
> > > /* set flash partition to correspond tu mtd parts in
> > > u-boot*/
> > > /* 0xf8000000 */
> > > partition@0x0 {
> > > label = "factory-image";
> > > reg = <0x00000000 0x01000000>;
> > > };
> > > /* 0xf9000000 */
> > > partition@0x01000000 {
> > > label = "app-image-1";
> > > reg = <0x01000000 0x01000000>;
> > > };
> > > cheers pieter
> > >
> >
> > Hi do have these definitions, at a higher level:
>
> The address-cells and size-cells definitions are not inherited. They
> cover only the immediate children of the node where they appear.
> Otherwise the default values apply (address-cells == 2, size-cells ==
> 1), which are not right for your case.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_
> _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson <http://www.ozlabs.org/%7Edgibson>
>
OK, so, after having tested, I can't see any changes when booting.
I do not have more mtd in /proc/mtd.
JM
[-- Attachment #2: Type: text/html, Size: 3601 bytes --]
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: David Gibson @ 2009-02-12 13:30 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: linuxppc-dev
In-Reply-To: <8cad0aa0902120310g44a3bf3cla4ffa94ea9bf5dc6@mail.gmail.com>
On Thu, Feb 12, 2009 at 12:10:58PM +0100, Jean-Michel Hautbois wrote:
> 2009/2/12 Pieter <phenning@vastech.co.za>
>
> > Jean-Michel Hautbois wrote:
> > > Warning (reg_format): "reg" property in
> > > /localbus@f0010100/flash@0,0/partition@ff800000 has invalid length (8
> > > JM
> > You are missing some definitions, The #address-cells and #size-cells = <1>;
> > tis is a snippet of teh dts i defined for my board.
> >
> > flash@0,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > compatible = "cfi-flash";
> > reg = <0x0 0x0 0x08000000>;
> > bank-width = <4>;
> > device-width = <1>;
> >
> > /* set flash partition to correspond tu mtd parts in
> > u-boot*/
> > /* 0xf8000000 */
> > partition@0x0 {
> > label = "factory-image";
> > reg = <0x00000000 0x01000000>;
> > };
> > /* 0xf9000000 */
> > partition@0x01000000 {
> > label = "app-image-1";
> > reg = <0x01000000 0x01000000>;
> > };
> > cheers pieter
> >
>
> Hi do have these definitions, at a higher level:
The address-cells and size-cells definitions are not inherited. They
cover only the immediate children of the node where they appear.
Otherwise the default values apply (address-cells == 2, size-cells ==
1), which are not right for your case.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* SPI-Difference between MX1 and MX31
From: Wolfram Sang @ 2009-02-12 13:00 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev, a.paterniani
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Hello,
while working on a generic SPI-driver for the i.MX-platform I stumbled
over the following:
The MX1 can flush its FIFOs using the enable bit. Documentation says:
"SPI Module Enable - Enables/Disables the serial peripheral interface.
SPIEN must be asserted before an exchange is initiated. Writing 0 to
SPIEN flushes the receive and transmit FIFOs."
Furthermore it has a dedicated reset register:
"Start - Executes soft reset."
However, the MX31 does not have a reset register and the documentation
says this regarding the enable bit:
"SPI Module Enable Control - This bit enables the CSPI. This bit must be
asserted before writing to other registers or initiating an exchange.
Writing zero to this bit disables the module and resets the internal
logic with the exception of the CONREG. The module’s internal clocks are
gated off whenever the module is disabled."
So, as I read all this, disabling the enable bit on the MX31 is more
like a soft reset on MX1, right? And there does not seem to be a way to
flush the FIFOs. Can someone imagine what problems might arise if there
is no way to flush the FIFOs? At least, the check for XCH should have
ensured that the TXFIFO is empty...
Looking forward to feedback :)
Regards,
Wolfram Sang
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next Feb 10: mm/slqb build break
From: Sachin P. Sant @ 2009-02-12 11:28 UTC (permalink / raw)
To: Nick Piggin
Cc: Stephen Rothwell, LKML, linuxppc-dev, Pekka Enberg, linux-next
In-Reply-To: <20090212014503.GD30043@wotan.suse.de>
Nick Piggin wrote:
>> Actually, that's not the root cause here. You seem to have CONFIG_SMP
>> disabled but CONFIG_NUMA enabled. That's not possible on x86 which
>> makes me think it's a ppc kconfig bug. Hmm?
>>
>
> If it is really a valid config, then we should be able to make
> slqb build with it...
I am not sure if this is a valid config. According to arch/powerpc/Kconfig
NUMA depends on PPC64 and defaults to y if SMP & PPC_PSERIES is set.
If this is not a valid config then may be the make randconfig rules
need to be changed accordingly.
Ben should know. Ben ??
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH 002/002] de2104x: support for systems lacking cache coherence
From: Risto Suominen @ 2009-02-12 11:22 UTC (permalink / raw)
To: LinuxPPC-dev
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
Here is a patch that helped me to get my de2104x NIC working on my
PowerMac 5500. As an interesting side effect, it also made my mesh
module crash.
Background can be found here: http://www.spinics.net/lists/netdev/msg88488.html
Risto
Allow setting NOT_COHERENT_CACHE explicitly.
Signed-off-by: Risto Suominen <Risto.Suominen@gmail.com>
---
The testing is done on kernel version 2.6.24.
--- a/arch/powerpc/platforms/powermac/Kconfig.org 2008-01-25
00:58:37.000000000 +0200
+++ b/arch/powerpc/platforms/powermac/Kconfig 2009-02-10
17:44:24.000000000 +0200
@@ -18,4 +18,10 @@ config PPC_PMAC64
select PPC_970_NAP
default y
-
+config NOT_COHERENT_CACHE
+ bool "Incoherent cache"
+ default n
+ help
+ Setting this option may be necessary for avoiding cache-related
+ problems with some network cards on some platforms. An example is
+ 2104x and PowerMac 5500.
[-- Attachment #2: incoherent_cache.patch --]
[-- Type: text/x-diff, Size: 635 bytes --]
Allow setting NOT_COHERENT_CACHE explicitly.
Signed-off-by: Risto Suominen <Risto.Suominen@gmail.com>
---
The testing is done on kernel version 2.6.24.
--- a/arch/powerpc/platforms/powermac/Kconfig.org 2008-01-25 00:58:37.000000000 +0200
+++ b/arch/powerpc/platforms/powermac/Kconfig 2009-02-10 17:44:24.000000000 +0200
@@ -18,4 +18,10 @@ config PPC_PMAC64
select PPC_970_NAP
default y
-
+config NOT_COHERENT_CACHE
+ bool "Incoherent cache"
+ default n
+ help
+ Setting this option may be necessary for avoiding cache-related
+ problems with some network cards on some platforms. An example is
+ 2104x and PowerMac 5500.
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Jean-Michel Hautbois @ 2009-02-12 11:10 UTC (permalink / raw)
To: Pieter; +Cc: linuxppc-dev
In-Reply-To: <49940265.1020700@vastech.co.za>
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
2009/2/12 Pieter <phenning@vastech.co.za>
> Jean-Michel Hautbois wrote:
> > Warning (reg_format): "reg" property in
> > /localbus@f0010100/flash@0,0/partition@ff800000 has invalid length (8
> > JM
> You are missing some definitions, The #address-cells and #size-cells = <1>;
> tis is a snippet of teh dts i defined for my board.
>
> flash@0,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "cfi-flash";
> reg = <0x0 0x0 0x08000000>;
> bank-width = <4>;
> device-width = <1>;
>
> /* set flash partition to correspond tu mtd parts in
> u-boot*/
> /* 0xf8000000 */
> partition@0x0 {
> label = "factory-image";
> reg = <0x00000000 0x01000000>;
> };
> /* 0xf9000000 */
> partition@0x01000000 {
> label = "app-image-1";
> reg = <0x01000000 0x01000000>;
> };
> cheers pieter
>
Hi do have these definitions, at a higher level:
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0010100 0x40>;
ranges = <0x0 0x0 0xfe000000 0x2000000
0x1 0x0 0xf4500000 0x8000
0x3 0x0 0xf8200000 0x8000>;
flash@0,0 {
etc.
Regards,
JM
[-- Attachment #2: Type: text/html, Size: 3629 bytes --]
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Pieter @ 2009-02-12 11:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jean-Michel Hautbois
In-Reply-To: <8cad0aa0902120123p27cfe32fg6bf08d458178c937@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]
Jean-Michel Hautbois wrote:
> Hi everybody !
> I am currently trying to add the support of partitions for the Flash
> chip on my MPC8272ADS board (the chips are Sharp LH28F016SCT-L90).
>
> I have added this part:
>
> flash@0,0 {
> compatible = "jedec-flash";
> reg = <0x0 0x0 0x2000000>;
> bank-width = <4>;
> device-width = <1>;
>
> partition@ff800000 {
> label = "kernel";
> reg = <0xff800000 0x00400000>;
> read-only;
> };
> partition@ffc00000 {
> label = "user";
> reg = <0xffc00000 0x00300000>;
> };
> partition@fff00000 {
> label = "u-boot";
> reg = <0xfff00000 0x00100000>;
> read-only;
> };
> };
>
> But when I am compiling, I have these warnings:
> Warning (reg_format): "reg" property in
> /localbus@f0010100/flash@0,0/partition@ff800000 has invalid length (8
> bytes) (#address-cells == 2, #size-cells == 1)
> Warning (reg_format): "reg" property in
> /localbus@f0010100/flash@0,0/partition@ffc00000 has invalid length (8
> bytes) (#address-cells == 2, #size-cells == 1)
> Warning (reg_format): "reg" property in
> /localbus@f0010100/flash@0,0/partition@fff00000 has invalid length (8
> bytes) (#address-cells == 2, #size-cells == 1)
> Warning (avoid_default_addr_size): Relying on default #address-cells
> value for /localbus@f0010100/flash@0,0/partition@ff800000
> Warning (avoid_default_addr_size): Relying on default #size-cells
> value for /localbus@f0010100/flash@0,0/partition@ff800000
> Warning (avoid_default_addr_size): Relying on default #address-cells
> value for /localbus@f0010100/flash@0,0/partition@ffc00000
> Warning (avoid_default_addr_size): Relying on default #size-cells
> value for /localbus@f0010100/flash@0,0/partition@ffc00000
> Warning (avoid_default_addr_size): Relying on default #address-cells
> value for /localbus@f0010100/flash@0,0/partition@fff00000
> Warning (avoid_default_addr_size): Relying on default #size-cells
> value for /localbus@f0010100/flash@0,0/partition@fff00000
>
>
> Can anyone help me ?
> I can't understand what the "address-cells" is.
>
> Thanks in advance !
> Best Regards.
> JM
You are missing some definitions, The #address-cells and #size-cells = <1>;
tis is a snippet of teh dts i defined for my board.
flash@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x08000000>;
bank-width = <4>;
device-width = <1>;
/* set flash partition to correspond tu mtd parts in
u-boot*/
/* 0xf8000000 */
partition@0x0 {
label = "factory-image";
reg = <0x00000000 0x01000000>;
};
/* 0xf9000000 */
partition@0x01000000 {
label = "app-image-1";
reg = <0x01000000 0x01000000>;
};
cheers pieter
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2722 bytes --]
^ permalink raw reply
* Re: request_irq return errno 38
From: Vijay Nikam @ 2009-02-12 10:51 UTC (permalink / raw)
To: Brad Boyer, scottwood, linuxppc-dev
In-Reply-To: <20090211223546.GA20129@cynthia.pants.nu>
Thanks for your replies ...
I checked the irq.c and irq.h and found the prototype of
irq_of_parse_and_map() and found from the comment that it is a wrapper
function contains a chain of irq_map_one() and irq_create_mapping()
...
It means that I can use irq_create_mapping() to know the virq also the
same suggessted by michael ... what is the difference between these
two i.e. irq_create_mapping() and irq_of_parse_and_map() ... I mean in
usage what could be the difference ? ? ?
If used the irq_of_parse_and_map() then the paraments I need to pass
are device_node *dev and index irq_of_parse_and_map(struct device_node
*dev, int index) ... then how I can pass the required information i.e.
dev and index ? ? ?
Also how I can read the device tree binary file ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
On 2/12/09, Brad Boyer <flar@allandria.com> wrote:
> On Wed, Feb 11, 2009 at 03:43:26PM +0530, Vijay Nikam wrote:
> > I read in LDD book, they give directly irq no. they have given
> > parallel port example, here they have set or said irq no. defaults to
> > 7 and they have not done any irq_mapping so what is the difference ? ?
> > ? I mean how I should know when to use irq_mapping and when not ? ? ?
> >
> > Also is it some difference between writng drivers on embedded Linux
> > level and Linux PC (i386) ? ? ?
>
> The basic request_irq() function is generic, but the value of the
> arguments (especially the number for the IRQ line) is architecture
> specific in many ways. This is one difference between the i386 code
> and the powerpc code inside Linux. Most i386 hardware is standard
> PC hardware with very clearly defined interrupt sources. Because of
> this, the mapping from the numeric IRQ value to a real hardware
> interrupt source is defined pretty clearly. The powerpc architecture
> code has to support almost arbitrarily complex hardware, and the
> embedded world is the source of most of the complexity. Because of
> this, the powerpc code has to dynamically allocate those numeric
> IRQ sources and tie them to a specific hardware interrupt. There
> is functionality to take the information from your device tree and
> convert it to a virtual IRQ. That happens automatically for some types
> of devices like PCI cards, but your driver may have to do that mapping
> itself in other cases. I believe the appropriate API for this is the
> function irq_of_parse_and_map(). It takes a device node and index into
> the interrupt list for that device and gives a virtual IRQ number.
>
> Brad Boyer
> flar@allandria.com
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox