* Re: [RFT] 8xx cpm_hostalloc patch was: allow coherent DMA API to work before main page allocator is set up
From: Pantelis Antoniou @ 2005-05-23 6:27 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050521222713.GA28813@logos.cnet>
Marcelo Tosatti wrote:
> Can someone with 8xx using the cpm_uart driver please test
> the attached patch? It should avoid corruption of the pinned
> 8Mbyte CONFIG_PIN_TLB entry, as noted by Dan.
>
You shouldn't have these discussions on the weekend :)
I'm the culprit of the code in question.
This is the second take of the code. The hack with the 'if' was
not actually in the first edition, since I had the hostalloc
function working properly before initialization by using the
remainder of the bootpage, as a backup memory area, for when
the mm is not yet ready.
Somewhere along the way, it fell through the cracks.
IMHO that's the proper way to fix it.
There were some objection on that however.
Regards
Pantelis
^ permalink raw reply
* IDMA PCI on 8250
From: Wojciech Kromer @ 2005-05-23 6:13 UTC (permalink / raw)
To: linuxppc-embedded
Do I need any hardware changes to use IDMA version of PCI driver?
^ permalink raw reply
* Re: Oops in snd-powermac on powerbook 3400
From: vinai @ 2005-05-22 17:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1115356511.28075.5.camel@gaston>
> On Thu, 2005-05-05 at 23:35 -0400, Keenan Pepper wrote:
>> I fixed it!
>>
>> I changed it to use the same device node for sound as for
>> chip->node, and it started beeping at me! Apparently sometime
>> between 2.6.8 and 2.6.12-rc3 the KIOCSOUND ioctl was implemented,
>> because it sure didn't beep before.
>>
>> BTW, this is the first time I've ever fixed a kernel bug.
>
> Ok, I think your patch was whitespace damaged, so I re-did it by hand
> ;)
>
> Here's the result. Please test. Also, other people around, please test
> if with this patch, snd-powermac works, especially on oldworld
> machines!
>
> I'll submit upstream tomorrow hopefully.
>
> Ben.
My apologies for only now replying to this, but I can confirm the patch
that originally accompanied the above e-mail also worked fine on my
8500, I'm listening to an audio CD as I type this ;-)
I just got back to playing around, and patched 2.6.11 up to 2.6.12-rc4
and did not see this patched included, so I thought I'd try to include
it myself locally. Nice work all :)
cheers
vinai
^ permalink raw reply
* [RFT] 8xx cpm_hostalloc patch was: allow coherent DMA API to work before main page allocator is set up
From: Marcelo Tosatti @ 2005-05-21 22:27 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <5d184282e7d324fb009b8dcf6e6f967d@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]
Can someone with 8xx using the cpm_uart driver please test
the attached patch? It should avoid corruption of the pinned
8Mbyte CONFIG_PIN_TLB entry, as noted by Dan.
On Sat, May 21, 2005 at 05:21:47PM -0400, Dan Malek wrote:
>
> On May 20, 2005, at 1:51 PM, Marcelo Tosatti wrote:
>
> >I must be missing something very obvious here, can you explain how
> >did you arrange things in v2.4 such that the console's ->setup
> >method is called _after_ mem_init() ?
>
> The driver used to use the serial port configuration as left by the
> boot rom until very late into the initialization. As I have said many
> times in the past, the serial driver went through three different
> levels of configuration. There was an early configuration that was
> used for kgdb, a later one used by the serial kernel printk, and
> finally a full configuration by the serial driver.
I have missed your statements about that in the past.
OK, the v2.4 driver is using the dual port RAM:
/* Allocate space for two FIFOs. We can't allocate from host
* memory yet because vm allocator isn't initialized
* during this early console init.
*/
dp_addr = m8xx_cpm_dpalloc(2*EARLY_BUF_SIZE);
mem_addr = (uint)(&cpmp->cp_dpmem[dp_addr]);
> It's sad that "moving forward" is done at a cost of throwing away
> features that were important.
Now that I think of it, no v2.6 driver should be calling
dma_alloc_coherent() before mem_init(). I was seeing the problem
because we're still using the old uart driver, which does that, and
our timer setup routine also.
> is a quick fix, but this further ensures features like pinned TLB
> entries won't work.
Actually, the quick fix to use bootmem allocator ensures that the
pinned TLB is _preserved_ (by using a pagetableentry from the consistent
DMA address space to mark as uncached and invalidate, instead of a pte
from the kernel direct mapped virtual space which blows away the 8Mbyte
entry - current v2.6 state).
Why do you say that "further ensures that features like pinned TLB
entries won't work" ?
If there is really a problem with using the bootmem allocator for
noncacheable purposes (which I can't see), it should be pretty easy
to modify cpm_uart to use dpram instead of host bootmem RAM, right?
[-- Attachment #2: 8xx.patch --]
[-- Type: text/plain, Size: 1981 bytes --]
--- linux-2.6.11.orig/arch/ppc/syslib/m8xx_setup.c 2005-05-20 13:53:17.000000000 -0300
+++ linux-2.6.11/arch/ppc/syslib/m8xx_setup.c 2005-05-20 15:59:24.000000000 -0300
@@ -57,7 +57,7 @@
extern void m8xx_ide_init(void);
extern unsigned long find_available_memory(void);
-extern void m8xx_cpm_reset(uint cpm_page);
+extern void m8xx_cpm_reset();
extern void m8xx_wdt_handler_install(bd_t *bp);
extern void rpxfb_alloc_pages(void);
extern void cpm_interrupt_init(void);
@@ -70,13 +70,9 @@
void __init
m8xx_setup_arch(void)
{
- int cpm_page;
-
- cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
-
/* Reset the Communication Processor Module.
*/
- m8xx_cpm_reset(cpm_page);
+ m8xx_cpm_reset();
#ifdef CONFIG_FB_RPX
rpxfb_alloc_pages();
--- linux-2.6.11.orig/arch/ppc/8xx_io/commproc.c 2005-05-20 13:53:17.000000000 -0300
+++ linux-2.6.11/arch/ppc/8xx_io/commproc.c 2005-05-22 00:29:42.000000000 -0300
@@ -39,8 +39,6 @@
#include <asm/tlbflush.h>
#include <asm/rheap.h>
-extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep);
-
static void m8xx_cpm_dpinit(void);
static uint host_buffer; /* One page of host buffer */
static uint host_end; /* end + 1 */
@@ -111,11 +109,10 @@
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
void
-m8xx_cpm_reset(uint bootpage)
+m8xx_cpm_reset(void)
{
volatile immap_t *imp;
volatile cpm8xx_t *commproc;
- pte_t *pte;
imp = (immap_t *)IMAP_ADDR;
commproc = (cpm8xx_t *)&imp->im_cpm;
@@ -143,17 +140,6 @@
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
- /* get the PTE for the bootpage */
- if (!get_pteptr(&init_mm, bootpage, &pte))
- panic("get_pteptr failed\n");
-
- /* and make it uncachable */
- pte_val(*pte) |= _PAGE_NO_CACHE;
- _tlbie(bootpage);
-
- host_buffer = bootpage;
- host_end = host_buffer + PAGE_SIZE;
-
/* Tell everyone where the comm processor resides.
*/
cpmp = (cpm8xx_t *)commproc;
^ permalink raw reply
* *** PayPal Security Issues ***
From: PayPal Security Service @ 2005-05-22 0:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 5426 bytes --]
^ permalink raw reply
* *** PayPal Security Issues ***
From: PayPal Security Service @ 2005-05-22 0:18 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 5426 bytes --]
^ permalink raw reply
* Re: [PATCH] allow coherent DMA API to work before main page allocator is set up
From: Dan Malek @ 2005-05-21 21:21 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050520175152.GB26221@logos.cnet>
On May 20, 2005, at 1:51 PM, Marcelo Tosatti wrote:
> I must be missing something very obvious here, can you explain how
> did you arrange things in v2.4 such that the console's ->setup
> method is called _after_ mem_init() ?
The driver used to use the serial port configuration as left by the
boot rom until very late into the initialization. As I have said many
times in the past, the serial driver went through three different
levels of configuration. There was an early configuration that was
used for kgdb, a later one used by the serial kernel printk, and
finally a full configuration by the serial driver.
It's sad that "moving forward" is done at a cost of throwing away
features that were important. The hack to allocate from boot memory
is a quick fix, but this further ensures features like pinned TLB
entries won't work.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH][PPC32] Fix an Off-By-One Error in arch/ppc/syslib/ipic.c
From: Randy Vinson @ 2005-05-21 0:40 UTC (permalink / raw)
To: linuxppc-embedded
Fix an off-by-one error in ipic_init.
There is an off-by-one error in the IPIC code that configures the
external interrupts (Edge or Level Sensitive).
Signed-off-by Randy Vinson <rvinson@mvista.com>
---
commit 0c92b569e09b94a1580cc5bae6efbdd749fec28a
tree 9c1e83adcec1bee0a700888546385444ef5f4000
parent 66e60f92518268f4d2a702a1c4ffbe1caacd6290
author Randy Vinson <rvinson@linuxbox.(none)> Fri, 20 May 2005 15:58:02 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Fri, 20 May 2005 15:58:02 -0700
arch/ppc/syslib/ipic.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: arch/ppc/syslib/ipic.c
===================================================================
--- 889a1e2919ac50253be8136a1b0855fde27fcb36/arch/ppc/syslib/ipic.c (mode:100644)
+++ 9c1e83adcec1bee0a700888546385444ef5f4000/arch/ppc/syslib/ipic.c (mode:100644)
@@ -479,7 +479,7 @@
temp = 0;
for (i = 0 ; i < senses_count ; i++) {
if ((senses[i] & IRQ_SENSE_MASK) == IRQ_SENSE_EDGE) {
- temp |= 1 << (16 - i);
+ temp |= 1 << (15 - i);
if (i != 0)
irq_desc[i + irq_offset + MPC83xx_IRQ_EXT1 - 1].status = 0;
else
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Paul Mackerras @ 2005-05-21 0:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <0b53908f87096525543bc4f660c613b6@embeddededge.com>
Dan Malek writes:
> Is there now some minimum gcc version that is required for
> using these flags?
Interestingly, gcc-2.95 seems to accept -mcpu=xxx for any xxx.
gcc-3.2 will accept -mcpu=860 but not -mcpu=8540, and gcc-3.3 and
later will accept both.
Paul.
^ permalink raw reply
* Re: DMA consistent allocation is limited to 2MB on 2.6.11 for ppc440?
From: Shawn Jin @ 2005-05-20 23:51 UTC (permalink / raw)
To: Matt Porter; +Cc: ppcembed
In-Reply-To: <20050520131620.B881@cox.net>
First of all thanks for your attention. :)
> Why are you using consistent memory for your DMA buffers?
Both CPU and IO controller (e.g. FC controller) have to be aware of
changes the other party makes on the data buffer. Some architectures
guarantee this coherence through bus snooping, which ppc440 is
unfortunately lack of. The simplest solution is to use consistent
memory.. On 2.4.x to some extent we don't need worry about how much
consistent memory is available. So the developers used consistent
mappings a lot instead of streaming DMA mappings. We would have been
more conservative to use consistent mappings had we known the
limitation earlier.
> The difference with this implementation is that it doesn't allow for
> arbitrarily huge consistent allocations by default. However, I carefully
> placed a comment at the top to point people to the advanced setup
> menu where they can tune the consistent pool to be larger than the
> 2MB default. You simply have to understand the memory map of your
I noticed your comment about the advanced settings:
CONFIG_CONSISTENT_SIZE and _START. However simply increasing the value
of CONSISTENT_SIZE won't get rid of the limiation. Right? The root
cause is in consistent_pte, which is only one page. It may be good to
have consistent_pte have more than one pages according to the
CONSISTENT_SIZE. Is it a useful fix?
> board port when setting this option. You can break things as with
> other advanced setup menu options.
OK. Have to be very careful here.
Best regards,
-Shawn.
^ permalink raw reply
* Re: [PATCH] allow coherent DMA API to work before main page allocator is set up
From: Marcelo Tosatti @ 2005-05-20 17:51 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <e503cf4ab6d2d389b29474561048f2f2@embeddededge.com>
On Fri, May 20, 2005 at 05:03:59PM -0400, Dan Malek wrote:
>
> On May 20, 2005, at 10:12 AM, Marcelo Tosatti wrote:
>
> >The following patch changes dma_alloc_coherent() to, in case the
> >main page allocator is not yet up and running, use the bootmem
> >allocator instead.
>
> I'm concerned about this ... Why did the drivers change in 2.6
> such that they now call dma_alloc_coherent() prior to the VM set up?
Well, as far as I can see, it is expected that console_init() gets called
before the main page allocator.
The startup sequence, on both v2.4 and v2.6, is:
setup_arch()
...
console_init()
console_8xx_init()
register_console()
release_console_sem()
...
mem_init()
register_console calls the driver ->setup method, and release_console_sem()
is going to ->write pending data from the log buffer to the device.
As you well know, ->setup calls m8xx_cpm_hostalloc().
I must be missing something very obvious here, can you explain how
did you arrange things in v2.4 such that the console's ->setup
method is called _after_ mem_init() ?
> >It also adds a new parameter to m8xx_cpm_hostalloc() to send back
> >the physical address to its caller.
>
> Anyone calling m8xx_cpm_hostalloc() is likely to be immediately
> calling dma_alloc_coherent(). There is some design problem here
> if we can't properly use these interfaces and get the mapping we
> need. The TLB pinning option won't work if we can't do this.
>
>
> > ..... Special casing such as
> >drivers/serial/cpm_uart/cpm_uart_cpm1.c's cpm_uart_allocbuf() can be
> >removed:
> >
> > if (is_con) {
> > mem_addr = (u8 *) m8xx_cpm_hostalloc(memsz);
> > dma_addr = 0;
> > } else
> > mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> > GFP_KERNEL);
>
> This is bogus and should not be necessary. The original serial
> driver was able to work without doing this, I spent lots of time so
> stuff like this wasn't necessary, and it's sad to see us take such
> a step backward.
Well, if you got this right in v2.4 then it must be possible to get
it right in v2.6 too...
Thanks!
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Benjamin Herrenschmidt @ 2005-05-20 22:27 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <e9d0cf12aef70d985053ec7eafb0a9db@embeddededge.com>
On Fri, 2005-05-20 at 10:30 -0400, Dan Malek wrote:
> On May 20, 2005, at 3:45 AM, Benjamin Herrenschmidt wrote:
>
> > The problem is the same as ppc64 isn't it ?, -maltivec doesn't work
> > with
> > -mcpu=power4 on gcc 3.4 does it ? That would mean no RAID6...
>
> I don't understand "doesn't work." Does power4 imply altivec?
> Do we need to add -maltivec based on the configuration option?
No, -mcpu=970 is equivalent in a way to -mcpu=power4 and -maltivec,
howevever, there is a bug in gcc 3.4 which makes -maltivec cause an
error if you have -mcpu=power4. The RAID6 code needs -maltivec. So on
gcc 3.4, we need to use -mcpu=970 instead of -mcpu=power4. However, we
must _NOT_ do that on gcc-4.0 as that causes it to implicitely generate
altivec code all over the place. (Fortunately, the bug is also fixed
there, so with gcc-4.0, we just need -mcpu=power4 and -maltivec only on
the RAID6 code)
Messy ? Yeah !
Ben.
^ permalink raw reply
* Re: [PATCH] allow coherent DMA API to work before main page allocator is set up
From: Dan Malek @ 2005-05-20 21:03 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050520141244.GD24923@logos.cnet>
On May 20, 2005, at 10:12 AM, Marcelo Tosatti wrote:
> The following patch changes dma_alloc_coherent() to, in case the
> main page allocator is not yet up and running, use the bootmem
> allocator instead.
I'm concerned about this ... Why did the drivers change in 2.6
such that they now call dma_alloc_coherent() prior to the VM set up?
> It also adds a new parameter to m8xx_cpm_hostalloc() to send back
> the physical address to its caller.
Anyone calling m8xx_cpm_hostalloc() is likely to be immediately
calling dma_alloc_coherent(). There is some design problem here
if we can't properly use these interfaces and get the mapping we
need. The TLB pinning option won't work if we can't do this.
> ..... Special casing such as
> drivers/serial/cpm_uart/cpm_uart_cpm1.c's cpm_uart_allocbuf() can be
> removed:
>
> if (is_con) {
> mem_addr = (u8 *) m8xx_cpm_hostalloc(memsz);
> dma_addr = 0;
> } else
> mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> GFP_KERNEL);
This is bogus and should not be necessary. The original serial
driver was able to work without doing this, I spent lots of time so
stuff like this wasn't necessary, and it's sad to see us take such
a step backward.
> What is your opinion on this approach?
As you can tell, I don't like it and we shouldn't need it :-)
The first call to m8xx_cpm_hostalloc() should be able to call
dma_consistent_alloc() to get a consistent page. If this isn't the
case, we have to fix the drivers so they can do this. The only
change that should be necessary is to return the physical address
from m8xx_cpm_hostalloc(), if for some reason we see some
need to get rid of the immensely useful iopa() function.
Thanks.
-- Dan
^ permalink raw reply
* Re: DMA consistent allocation is limited to 2MB on 2.6.11 for ppc440?
From: Matt Porter @ 2005-05-20 20:16 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b050520111228a6f4cd@mail.gmail.com>
On Fri, May 20, 2005 at 11:12:54AM -0700, Shawn Jin wrote:
> > My recommendation - don't do this. Why do you need to allocate this
> > big chunk of consistent memory in the first place? You can do DMA
> > _without_ allocating "consistent" memory. In fact, this is how
> > virtually all devices work in Linux. For more info about DMA API -
> > look at Documentation/DMA-API.txt.
>
> The driver stack we've been developing (already 4.0) uses consistent
> memory a lot for DMA. The stack is for many kinds of high performance
> storage IO e.g. iSCSI, FC. It works fine on 2.4.x because there is no
> such 2MB consistent pool limitation.
Why are you using consistent memory for your DMA buffers?
> > Technically, you can make consistent pool bigger, if you really insist
> > on using this approach.
>
> I want to understand the motivation and the rationale of choosing
> 'consistent_pte' on 2.6.x, what impact there would be to increase the
> consistent pool, and so on. Some pointers to articles, posts are more
> helpful.
The rationale on moving to the new implementation in 2.6 was to fix a
critical bug. The bug could not be fixed with a band-aid solution, but
required an allocation system with different semantics. After considering
a few possibilities the basic framework from ARM was selected.
The bug that was fixed was the inability to allocate consistent memory
from an interrupt context. This is allowed by the PCI DMA API and the
more general DMA API and is used by many drivers. In 2.4, these drivers
would simply BUG() on PPC4xx/8xx.
The difference with this implementation is that it doesn't allow for
arbitrarily huge consistent allocations by default. However, I carefully
placed a comment at the top to point people to the advanced setup
menu where they can tune the consistent pool to be larger than the
2MB default. You simply have to understand the memory map of your
board port when setting this option. You can break things as with
other advanced setup menu options.
-Matt
^ permalink raw reply
* [PATCH] allow coherent DMA API to work before main page allocator is set up
From: Marcelo Tosatti @ 2005-05-20 14:12 UTC (permalink / raw)
To: Dan Malek, Matt Porter; +Cc: linux-ppc-embedded
Hi Dan, Matt,
The following patch changes dma_alloc_coherent() to, in case the
main page allocator is not yet up and running, use the bootmem
allocator instead.
It also adds a new parameter to m8xx_cpm_hostalloc() to send back
the physical address to its caller.
With such modification in place it will be possible for early drivers
to rely on the coherent DMA allocator. Special casing such as
drivers/serial/cpm_uart/cpm_uart_cpm1.c's cpm_uart_allocbuf() can be
removed:
if (is_con) {
mem_addr = (u8 *) m8xx_cpm_hostalloc(memsz);
dma_addr = 0;
} else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
What is your opinion on this approach?
If virt_to_phys() usage is discouraged any different method to walk
the pagetables and retrieve the physical address can be used.
TIA
diff -Nur linux-2.6.11.orig/arch/ppc/8xx_io/commproc.c linux-2.6.11/arch/ppc/8xx_io/commproc.c
--- linux-2.6.11.orig/arch/ppc/8xx_io/commproc.c 2005-05-20 13:53:17.000000000 -0300
+++ linux-2.6.11/arch/ppc/8xx_io/commproc.c 2005-05-20 16:02:13.000000000 -0300
@@ -39,7 +39,8 @@
#include <asm/tlbflush.h>
#include <asm/rheap.h>
-extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep);
+
+phys_addr_t physaddr;
static void m8xx_cpm_dpinit(void);
static uint host_buffer; /* One page of host buffer */
@@ -111,11 +112,10 @@
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
void
-m8xx_cpm_reset(uint bootpage)
+m8xx_cpm_reset(void)
{
volatile immap_t *imp;
volatile cpm8xx_t *commproc;
- pte_t *pte;
imp = (immap_t *)IMAP_ADDR;
commproc = (cpm8xx_t *)&imp->im_cpm;
@@ -143,17 +143,6 @@
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
- /* get the PTE for the bootpage */
- if (!get_pteptr(&init_mm, bootpage, &pte))
- panic("get_pteptr failed\n");
-
- /* and make it uncachable */
- pte_val(*pte) |= _PAGE_NO_CACHE;
- _tlbie(bootpage);
-
- host_buffer = bootpage;
- host_end = host_buffer + PAGE_SIZE;
-
/* Tell everyone where the comm processor resides.
*/
cpmp = (cpm8xx_t *)commproc;
@@ -165,7 +154,6 @@
static void
alloc_host_memory(void)
{
- dma_addr_t physaddr;
/* Set the host page for allocation.
*/
@@ -325,7 +313,7 @@
* UART "fifos" and the like.
*/
uint
-m8xx_cpm_hostalloc(uint size)
+m8xx_cpm_hostalloc(uint size, phys_addr_t *handle)
{
uint retloc;
@@ -336,7 +324,9 @@
return(0);
retloc = host_buffer;
+ *handle = physaddr;
host_buffer += size;
+ physaddr += size;
return(retloc);
}
diff -Nur linux-2.6.11.orig/arch/ppc/kernel/dma-mapping.c linux-2.6.11/arch/ppc/kernel/dma-mapping.c
--- linux-2.6.11.orig/arch/ppc/kernel/dma-mapping.c 2005-05-20 13:53:17.000000000 -0300
+++ linux-2.6.11/arch/ppc/kernel/dma-mapping.c 2005-05-20 14:03:56.000000000 -0300
@@ -55,6 +55,8 @@
int map_page(unsigned long va, phys_addr_t pa, int flags);
+extern int mem_init_done;
+
#include <asm/tlbflush.h>
/*
@@ -121,7 +123,10 @@
unsigned long flags;
struct vm_region *c, *new;
- new = kmalloc(sizeof(struct vm_region), gfp);
+ if (mem_init_done)
+ new = kmalloc(sizeof(struct vm_region), gfp);
+ else
+ new = alloc_bootmem(sizeof(struct vm_region));
if (!new)
goto out;
@@ -175,10 +180,11 @@
void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, int gfp)
{
- struct page *page;
+ struct page *page = NULL;
struct vm_region *c;
unsigned long order;
u64 mask = 0x00ffffff, limit; /* ISA default */
+ void *bootmem_address = NULL;
if (!consistent_pte) {
printk(KERN_ERR "%s: not initialised\n", __func__);
@@ -199,14 +205,21 @@
if (mask != 0xffffffff)
gfp |= GFP_DMA;
- page = alloc_pages(gfp, order);
- if (!page)
- goto no_page;
+ if (mem_init_done) {
+ page = alloc_pages(gfp, order);
+ if (!page)
+ goto no_page;
+ } else {
+ bootmem_address = alloc_bootmem_pages(PAGE_SIZE << order);
+ if (!bootmem_address)
+ goto no_page;
+ }
/*
* Invalidate any data that might be lurking in the
* kernel direct-mapped region for device DMA.
*/
+ if (mem_init_done)
{
unsigned long kaddr = (unsigned long)page_address(page);
memset(page_address(page), 0, size);
@@ -226,27 +239,37 @@
/*
* Set the "dma handle"
*/
- *handle = page_to_bus(page);
+ if (mem_init_done)
+ *handle = page_to_bus(page);
+ else
+ *handle = virt_to_phys(bootmem_address);
do {
- BUG_ON(!pte_none(*pte));
+ if (mem_init_done) {
+ BUG_ON(!pte_none(*pte));
- set_page_count(page, 1);
- SetPageReserved(page);
- set_pte_at(&init_mm, vaddr,
- pte, mk_pte(page, pgprot_noncached(PAGE_KERNEL)));
- page++;
- pte++;
- vaddr += PAGE_SIZE;
+ set_page_count(page, 1);
+ SetPageReserved(page);
+ set_pte_at(&init_mm, vaddr,
+ pte, mk_pte(page, pgprot_noncached(PAGE_KERNEL)));
+ page++;
+ pte++;
+ vaddr += PAGE_SIZE;
+ } else {
+ set_pte(pte,__pte((pte_t)virt_to_phys(bootmem_address) | pgprot_val(pgprot_noncached(PAGE_KERNEL))));
+ bootmem_address += PAGE_SIZE;
+ }
} while (size -= PAGE_SIZE);
/*
* Free the otherwise unused pages.
*/
- while (page < end) {
- set_page_count(page, 1);
- __free_page(page);
- page++;
+ if (mem_init_done) {
+ while (page < end) {
+ set_page_count(page, 1);
+ __free_page(page);
+ page++;
+ }
}
return (void *)c->vm_start;
diff -Nur linux-2.6.11.orig/arch/ppc/syslib/m8xx_setup.c linux-2.6.11/arch/ppc/syslib/m8xx_setup.c
--- linux-2.6.11.orig/arch/ppc/syslib/m8xx_setup.c 2005-05-20 13:53:17.000000000 -0300
+++ linux-2.6.11/arch/ppc/syslib/m8xx_setup.c 2005-05-20 15:59:24.000000000 -0300
@@ -57,7 +57,7 @@
extern void m8xx_ide_init(void);
extern unsigned long find_available_memory(void);
-extern void m8xx_cpm_reset(uint cpm_page);
+extern void m8xx_cpm_reset();
extern void m8xx_wdt_handler_install(bd_t *bp);
extern void rpxfb_alloc_pages(void);
extern void cpm_interrupt_init(void);
@@ -70,13 +70,9 @@
void __init
m8xx_setup_arch(void)
{
- int cpm_page;
-
- cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
-
/* Reset the Communication Processor Module.
*/
- m8xx_cpm_reset(cpm_page);
+ m8xx_cpm_reset();
#ifdef CONFIG_FB_RPX
rpxfb_alloc_pages();
diff -Nur linux-2.6.11.orig/include/asm-ppc/commproc.h linux-2.6.11/include/asm-ppc/commproc.h
--- linux-2.6.11.orig/include/asm-ppc/commproc.h 2005-05-20 13:53:40.000000000 -0300
+++ linux-2.6.11/include/asm-ppc/commproc.h 2005-05-20 16:02:37.000000000 -0300
@@ -79,7 +79,7 @@
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
-extern uint m8xx_cpm_hostalloc(uint size);
+extern uint m8xx_cpm_hostalloc(uint size, phys_addr_t *handle);
extern int m8xx_cpm_hostfree(uint start);
extern void m8xx_cpm_hostdump(void);
^ permalink raw reply
* Re: DMA consistent allocation is limited to 2MB on 2.6.11 for ppc440?
From: Shawn Jin @ 2005-05-20 18:12 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <20050519020953.GB11587@gate.ebshome.net>
> My recommendation - don't do this. Why do you need to allocate this
> big chunk of consistent memory in the first place? You can do DMA
> _without_ allocating "consistent" memory. In fact, this is how
> virtually all devices work in Linux. For more info about DMA API -
> look at Documentation/DMA-API.txt.
The driver stack we've been developing (already 4.0) uses consistent
memory a lot for DMA. The stack is for many kinds of high performance
storage IO e.g. iSCSI, FC. It works fine on 2.4.x because there is no
such 2MB consistent pool limitation.
> Technically, you can make consistent pool bigger, if you really insist
> on using this approach.
I want to understand the motivation and the rationale of choosing
'consistent_pte' on 2.6.x, what impact there would be to increase the
consistent pool, and so on. Some pointers to articles, posts are more
helpful.
Thanks a lot,
-Shawn.
^ permalink raw reply
* Re: MPC8xx Platformization
From: Dan Malek @ 2005-05-20 17:51 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: PPC_LINUX
In-Reply-To: <428E2049.4010907@ru.mvista.com>
On May 20, 2005, at 1:37 PM, Andrei Konovalov wrote:
> But it still doesn't distinguish between e.g. MPC885, MPC880, MPC875,
> and MPC870
> - though the set of on-chip devices is different for the four.
I don't believe you can reliably distinguish among many of these parts.
I've had parts stamped with a number on them, but it looks like it had
remnants of other, probably non-working, peripherals from another.
Just poking at some peripheral locations to determine processor
type isn't likely to always be accurate.
I don't think we should be writing any code that relies on the proper
identification of the parts. When building the code for a real product,
you always configure specifically for it to reduce code size and run
time
start up. As a development engineer, you should know the configuration
you are using as well. The only difference is in the peripherals
supported,
so just configure what you want to use.
Thanks.
-- Dan
^ permalink raw reply
* Re: MPC8xx Platformization
From: Andrei Konovalov @ 2005-05-20 17:37 UTC (permalink / raw)
To: Jason McMullan; +Cc: PPC_LINUX
In-Reply-To: <1114609634.30649.14.camel@ad.doubleclick.net>
Hi Jason,
Jason McMullan wrote:
> The following is a rough skeleton of platformization for the mpc8xx
> series, in the same technique as Kumar's 85xx platformization.
>
> This rough cut will be followed up later with specific
> driver platformization fixes.
How is the progress on the 8xx platformization?
We are working (in the same direction) on a couple 8xx boards,
and there is an issue which is not addressed by your patch:
> ------------------------------------------------------------------------
>
> Date: Wed, 20 Apr 2005 11:11:23 -0400
> Signed-Off-By: Jason McMullan <jason.mcmullan@timesys.com>
> Description: MPC8xx platformization
>
...
> --- /dev/null
> +++ linux/arch/ppc/platforms/8xx/mpc8xx_sys.c
...
> +struct ppc_sys_spec ppc_sys_specs[] = {
> + {
> + .ppc_sys_name = "MPC885",
> + .mask = 0xFFFF0000,
> + .value = 0x00500000,
...
> --- linux-orig/arch/ppc/syslib/m8xx_setup.c
> +++ linux/arch/ppc/syslib/m8xx_setup.c
...
>
> + identify_ppc_sys_by_id(mfspr(PVR));
> +
All the MPC8xx'es have 0x0050 in the upper half of PVR.
So checking the value of PVR with .mask = 0xFFFF0000 makes no sense.
I've looked at how U-Boot detects the CPU, and the procedure is much more
complicated than just checking PVR and IMMR. U-Boot even probes (writes the
pattern to the register and reads it back) to check if the CPU has FEC.
But it still doesn't distinguish between e.g. MPC885, MPC880, MPC875, and MPC870
- though the set of on-chip devices is different for the four.
Anyone having an idea on what to pass to identify_ppc_sys_by_id() in case of MPC8xx?
Thanks,
Andrei
^ permalink raw reply
* Re: OF flat device tree for ppc32...
From: Jon Loeliger @ 2005-05-20 16:40 UTC (permalink / raw)
To: Jakob Viketoft; +Cc: Linux PPC Embedded list
In-Reply-To: <428C352E.1050002@bitsim.se>
On Thu, 2005-05-19 at 01:41, Jakob Viketoft wrote:
> Hello Jon!
>
> Any news on the port of the OF-layer to ppc32? I'd love to hear some
> more and it would be great be able to help out, even though I have some
> heavy deadlines hanging over me for the next 2 months. From what I can
> see on the list, there wasn't many comments on your first preparatory
> code, but I for one thinks it's time to move it forward anyway.
>
> What do you say?
>
> /Jakob
Folks,
I have updated my tree and patch to the latest GIT
as of last night. The new patch is available here:
http://www.jdl.com/bdt_cleanup_git.patch.gz
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Please let me know if there are difficulties retrieving it.
This patch has a few caveats associated with it.
In particular, it does not address the entire
arch/ppc/boot/simple
issue at all. And for that reason, this patch does
not yet actually remove the to-be-obsoleted ppcboot.h
that is otherwise unreferenced. I am hopeful that
someone who is muchm ore familiar with that code can
pick up from this patch and Do The Right Thing there.
This patch in no-way eliminates the U-Boot-to-Kernel
interface yet. It merely isolates it all to one location
and provides a functional interface to it.
Enjoy,
jdl
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Kumar Gala @ 2005-05-20 14:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17037.32285.607543.859030@cargo.ozlabs.ibm.com>
On May 20, 2005, at 1:05 AM, Paul Mackerras wrote:
> Here is a revised version of my patch to set the cpu type explicitly
> for gcc when compiling the kernel. Setting the cpu type is a good
> idea in any case, and particularly if you have a biarch gcc. This
> sets the type for all of the ppc cpu families we support.
>
> Any further comments? Are -mcpu=860 and -mcpu=8540 reasonable for 8xx
> and 85xx respectively? I used -mcpu=power4 rather than -mcpu=970
> because the former works with gcc-3.6.6 as in debian and the latter
> doesn't. Unfortunately -mcpu=440 doesn't work either in gcc 3.3,
> though it does in gcc 3.4 (as does -mcpu=970).
Yes, -mcpu=8540 is reasonable for 85xx.
- kumar
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Dan Malek @ 2005-05-20 14:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1116575115.5153.115.camel@gaston>
On May 20, 2005, at 3:45 AM, Benjamin Herrenschmidt wrote:
> The problem is the same as ppc64 isn't it ?, -maltivec doesn't work
> with
> -mcpu=power4 on gcc 3.4 does it ? That would mean no RAID6...
I don't understand "doesn't work." Does power4 imply altivec?
Do we need to add -maltivec based on the configuration option?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] Set cpu type explicitly, take 2
From: Dan Malek @ 2005-05-20 14:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17037.32285.607543.859030@cargo.ozlabs.ibm.com>
On May 20, 2005, at 2:05 AM, Paul Mackerras wrote:
> Any further comments? Are -mcpu=860 and -mcpu=8540 reasonable for 8xx
> and 85xx respectively?
Yes.
Is there now some minimum gcc version that is required for
using these flags?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: fix cpm_uart_int() missing interrupts
From: Dan Malek @ 2005-05-20 14:19 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <428CF8D3.2070006@mrv.com>
On May 19, 2005, at 4:36 PM, Guillaume Autran wrote:
> One thought though, if the event register is cleared _before_=A0 the=20=
> event is processed (clearing the cause),
The cause of the event is it set completion flags on the buffer=20
descriptors.
> will the cpm set the bit again (before we have time to clear the=20
> cause) ? That would generate 2 interrupts for the same event ? Am I=20
> right ?
No, it will work fine.
Thanks.
-- Dan
^ permalink raw reply
* schedule_task
From: kiran kumar @ 2005-05-20 12:02 UTC (permalink / raw)
To: linuxppc-embedded
hi,
In my module I am using schedule_task()
and passing tq_struct. 'ps -xa' reports
the status of the task. When module removed from
kernel, still 'ps -xa' reports final task is sleeping.
I called flush_scheduled_tasks(), when unloading
module. No progress. Kindly, explain how remove
process.
Thanks.
-kiran
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
^ permalink raw reply
* MPC8560ADS config for Vanilla 2.6.10
From: Turconi Ennio Angelo @ 2005-05-20 11:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
I have had some trouble in finding out the right configuration of kernel 2.6.10 for MPC8560ADS.
The fact is that "mpc8560_ads_defconfig" is included only from 2.6.11 on.
The same default configuration can be used in 2.6.10, too, without any problem.
Anyway find attached a minimum (but with useful debugging option activated) config version for 2.6.10.
I couldn't understand why not including the "math emulation" option, the kernel "works only a little".
What I can see is that the kernel is running, but the bash (running) gives no output. Anyone can tell me why?
Thanks,
Ennio
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Turconi International.vcf --]
[-- Type: text/x-vcard; name="Turconi International.vcf", Size: 482 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Turconi;Ennio
FN:Ennio Turconi
ORG:ITALTEL S.p.A.;Business Unit Products - TPD GPMSMP
TITLE:Senior Fw Designer
TEL;WORK;VOICE:+39 02 4388 5710
TEL;WORK;FAX:+39 02 4388 8705
ADR;WORK:;;Loc. Castelletto C29/1;Settimo Mil. MI;;20019;Italy
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Loc. Castelletto C29/1=0D=0ASettimo Mil. MI 20019=0D=0AItaly
URL;WORK:http://www.italtel.com
EMAIL;PREF;INTERNET:Ennio.Turconi@italtel.it
REV:20050520T105253Z
END:VCARD
[-- Attachment #3: config_mpc8560ads_nonet --]
[-- Type: application/octet-stream, Size: 10488 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.10
# Fri May 20 11:27:27 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
# General setup
#
CONFIG_LOCALVERSION="GoGoGo"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
#
# Processor
#
# CONFIG_6xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
CONFIG_E500=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
# CONFIG_SPE is not set
CONFIG_MATH_EMULATION=y
# CONFIG_CPU_FREQ is not set
CONFIG_85xx=y
CONFIG_PPC_INDIRECT_PCI_BE=y
#
# Freescale 85xx options
#
# CONFIG_MPC8540_ADS is not set
# CONFIG_MPC8555_CDS is not set
CONFIG_MPC8560_ADS=y
# CONFIG_SBC8560 is not set
CONFIG_MPC8560=y
CONFIG_FSL_OCP=y
#
# Platform options
#
CONFIG_CPM2=y
# CONFIG_PC_KEYBOARD is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_HIGHMEM is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
#
# Bus options
#
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_BOOT_LOAD=0x00800000
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=180000
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_SCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Macintosh device drivers
#
#
# Networking support
#
# CONFIG_NET is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
# CONFIG_SERIO_RAW is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SERIAL_CPM_SCC1=y
# CONFIG_SERIAL_CPM_SCC2 is not set
# CONFIG_SERIAL_CPM_SCC3 is not set
# CONFIG_SERIAL_CPM_SCC4 is not set
# CONFIG_SERIAL_CPM_SMC1 is not set
# CONFIG_SERIAL_CPM_SMC2 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_ISA is not set
CONFIG_I2C_MPC=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Misc devices
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
#
# Graphics support
#
# CONFIG_FB is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
# CONFIG_NLS is not set
#
# CPM2 Options
#
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_KGDB_CONSOLE is not set
# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
CONFIG_PPC_OCP=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
^ 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