* Re: BDI and 85xx
From: Dan Malek @ 2005-11-07 17:17 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Edson Seabra, linux-ppc-embedded
In-Reply-To: <20051107112424.GE15522@logos.cnet>
On Nov 7, 2005, at 6:24 AM, Marcelo Tosatti wrote:
> Edson had to patch this in to get BDI to work on 85xx with 2.6.14.
How about we just change MSR_KERNEL and MSR_USER
in the include file #define instead of all of this run-time code?
Or, change the code so it preserves DE in general, so we don't
need a special kernel configuration just for the BDI?
The original reason I did the BDI_SWITCH was due to the
overhead of tracking user PTE switches in the context switch
code. I don't like the way this has been overloaded to mean
"BDI general operation." We should be able to attach a BDI2000
to any kernel configuration and always get kernel debugging
capability. The BDI_SWITCH was to enable the extra feature
(with some overhead) of debugging into user applications,
it never should have affected any kernel debug operation.
It's unfortunate that Book-E is such a PITA for debuggers,
but let's please find a better way of using these features.
Separate kernel configurations to enable hardware
debugging isn't acceptable.
Thanks.
-- Dan
^ permalink raw reply
* BDI2000 and Linux 2.6 kernel
From: Marcelo Tosatti @ 2005-11-07 12:11 UTC (permalink / raw)
To: linux-ppc-embedded, support
Hi,
Currently gdb over BDI (and I've seen other reports on this list) fails to
translate virtual->physical addresses on PPC 8xx:
*** MMU: address translation for 0xC000C66C failed
*** MMU: address translation for 0xC000C66C failed
Thats because the v2.6 kernel was changed to use physical addresses on the
first level page.
Dan informed me there might be a firmware update available to address
this problem. Is this true?
With the following the kernel stores the virtual address on the PMD
getting the BDI "to work".
A newer firmware would be much better though.
--- linux-2.6.14-rc4.orig/arch/ppc/kernel/head_8xx.S 2005-10-18 16:59:34.000000000 -0500
+++ linux-2.6.14-rc4/arch/ppc/kernel/head_8xx.S 2005-11-01 05:45:00.000000000 -0600
@@ -320,11 +320,12 @@ InstructionTLBMiss:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, don't try to find a pte */
+ tophys(r11,r11)
/* We have a pte table, so load the MI_TWC with the attributes
* for this "segment."
*/
- ori r11,r11,1 /* Set valid bit */
+ /*ori r11,r11,1 Set valid bit */
DO_8xx_CPU6(0x2b80, r3)
mtspr SPRN_MI_TWC, r11 /* Set segment attributes */
DO_8xx_CPU6(0x3b80, r3)
@@ -379,6 +380,7 @@ DataStoreTLBMiss:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, don't try to find a pte */
+ tophys(r11,r11)
/* We have a pte table, so load fetch the pte from the table.
*/
@@ -493,6 +495,7 @@ DataTLBError:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, bail */
+ tophys(r11,r11)
/* We have a pte table, so fetch the pte from the table.
*/
diff -Nur -p --exclude-from=linux-2.6.14-rc4/Documentation/dontdiff linux-2.6.14-rc4.orig/include/asm-ppc/pgalloc.h linux-2.6.14-rc4/include/asm-ppc/pgalloc.h
--- linux-2.6.14-rc4.orig/include/asm-ppc/pgalloc.h 2005-10-18 17:00:09.000000000 -0500
+++ linux-2.6.14-rc4/include/asm-ppc/pgalloc.h 2005-11-01 08:02:08.000000000 -0600
@@ -19,16 +19,16 @@ extern void pgd_free(pgd_t *pgd);
#define __pmd_free_tlb(tlb,x) do { } while (0)
#define pgd_populate(mm, pmd, pte) BUG()
-#ifndef CONFIG_BOOKE
+#if defined(CONFIG_BOOKE) || defined(CONFIG_8xx)
#define pmd_populate_kernel(mm, pmd, pte) \
- (pmd_val(*(pmd)) = __pa(pte) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (unsigned long)pte | _PMD_PRESENT)
#define pmd_populate(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (page_to_pfn(pte) << PAGE_SHIFT) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (unsigned long)page_to_virt(pte) | _PMD_PRESENT)
#else
#define pmd_populate_kernel(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (unsigned long)pte | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = __pa(pte) | _PMD_PRESENT)
#define pmd_populate(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (unsigned long)page_to_virt(pte) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (page_to_pfn(pte) << PAGE_SHIFT) | _PMD_PRESENT)
#endif
extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
diff -Nur -p --exclude-from=linux-2.6.14-rc4/Documentation/dontdiff linux-2.6.14-rc4.orig/include/asm-ppc/pgtable.h linux-2.6.14-rc4/include/asm-ppc/pgtable.h
--- linux-2.6.14-rc4.orig/include/asm-ppc/pgtable.h 2005-10-18 17:00:09.000000000 -0500
+++ linux-2.6.14-rc4/include/asm-ppc/pgtable.h 2005-11-01 08:01:34.000000000 -0600
@@ -719,16 +719,16 @@ extern pgprot_t phys_mem_access_prot(str
* handler). On everything else the pmd contains the physical address
* of the pte page. -- paulus
*/
-#ifndef CONFIG_BOOKE
+#if defined (CONFIG_BOOKE) || defined CONFIG_8xx
#define pmd_page_kernel(pmd) \
- ((unsigned long) __va(pmd_val(pmd) & PAGE_MASK))
+ ((unsigned long) (pmd_val(pmd) & PAGE_MASK))
#define pmd_page(pmd) \
- (mem_map + (pmd_val(pmd) >> PAGE_SHIFT))
+ (mem_map + (__pa(pmd_val(pmd)) >> PAGE_SHIFT))
#else
#define pmd_page_kernel(pmd) \
- ((unsigned long) (pmd_val(pmd) & PAGE_MASK))
+ ((unsigned long) __va(pmd_val(pmd) & PAGE_MASK))
#define pmd_page(pmd) \
- (mem_map + (__pa(pmd_val(pmd)) >> PAGE_SHIFT))
+ (mem_map + (pmd_val(pmd) >> PAGE_SHIFT))
#endif
/* to find an entry in a kernel page-table-directory */
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Dan Malek @ 2005-11-07 17:25 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <20051107163144.GF3839@smtp.west.cox.net>
On Nov 7, 2005, at 11:31 AM, Tom Rini wrote:
> ..... If everything going forward ships from the hw
> vendor with U-Boot,
You can't make that assumption. Very few production
systems ship with U-Boot, whether we like it or not.
For those of us that developed all of this "boot wrapper"
code and remember why it was done, all of those reasons
still exist. More people are using U-Boot, but it's mostly
during development. The other embedded software we
are trying to displace with Linux sometimes doesn't have
the rom space, and there is the "we didn't have it before"
mentality that is hard to change.
Don't cast this old boot code too far away, people still use it.
Thanks.
-- Dan
^ permalink raw reply
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-07 18:14 UTC (permalink / raw)
To: Tom Rini, Marcelo Tosatti; +Cc: linuxppc-embedded, Dan Malek, gtolstolytkin
> -----Original Message-----
> From: Tom Rini [mailto:trini@kernel.crashing.org]=20
> Sent: 07 November 2005 16:52
> To: Marcelo Tosatti
> Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;=20
> linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
>=20
> On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > Joakim!
> >=20
> > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > Hi Marcelo
> > >=20
> > > [SNIP]=20
> > > > The root of the problem are the changes against the 8xx TLB=20
> > > > handlers introduced
> > > > during v2.6. What happens is the TLBMiss handlers load the=20
> > > > zeroed pte into
> > > > the TLB, causing the TLBError handler to be invoked (thats=20
> > > > two TLB faults per=20
> > > > pagefault), which then jumps to the generic MM code to=20
> setup the pte.
> > > >=20
> > > > The bug is that the zeroed TLB is not invalidated (the=20
> same reason
> > > > for the "dcbst" misbehaviour), resulting in infinite=20
> TLBError faults.
> > > >=20
> > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > >=20
> > > This is one reason why it is the way it is:
> > >=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > This details are little fuzzy ATM, but I think the reason for the
> > > current
> > > impl. was only that it was less intrusive to impl.
> >=20
> > Ah, I see. I wonder if the bug is processor specific: we=20
> don't have such
> > changes in our v2.4 tree and never experienced such problem.
> >=20
> > It should be pretty easy to hit it right? (instruction=20
> pagefaults should
> > fail).
> >=20
> > Grigori, Tom, can you enlight us about the issue on the URL=20
> above. How
> > can it be triggered?
>=20
> So after looking at the code in 2.6.14 and current git, I think the
> above URL isn't relevant, unless there was a change I missed (which
> could totally be possible) that reverted the patch there and=20
> fixed that
> issue in a different manner. But since I didn't figure that=20
> out until I
> had finished researching it again:
I wasn't clear enough. What I meant was that the above patch made me
think and
the result was that I came up with a simpler fix, the "two exception"
fix that
is in current kernels. See
http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
1.19?nav=3Dindex.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|his=
t
/arch/ppc/kernel/head_8xx.S
It appears this fix has some other issues :(
How do the other ppc arches do? I am guessing that they don't double
fault, but bails
out to do_page_fault from the TLB Miss handler, like 8xx used to do.
>=20
> Switching hats for a minute, this came from a bug a customer of
> MontaVista found, so I can't give out the testcase :(
>=20
> To repeat what Joakim said back then:
> "I think I have figured this out. The first TLB misses that happen at
> app startup is Data TLB misses. These will then hit the NULL L1 entry
> and end up in do_page_fault() which will populate the L1=20
> entry. But when
> you have a very large app that spans more than one L1 entry (16 MB I
> think) it may happen that you will have I-TLB Miss first one of the L1
> entrys which will make the I-TLB handler bail out to=20
> do_page_fault() and
> the app craches(SEGV)."
This still stands I think.
>=20
> Looking at the patch again, what I don't see is why I talk=20
> about fudging
> I-TLB Miss at 0x400 when it's I-TLB Error we fudge at being there, but
> then get hung up that there can be a slight diff between the=20
> two ("This
> is because we check bit 4 of SRR1 in both cases, but in the case of an
> I-TLB Miss, this bit is always set, and it only indicates a protection
> fault on an I-TLB Error.") so instead of 0x1300 jumping to the handler
> at 0x400, we treat it like a regular exception so we know=20
> where we came
> from, and perhaps missed fixing a case somewhere?
Didn't look into this part of your patch, sorry.
Jocke
^ permalink raw reply
* Re: [patch 2.6.14] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
From: John W. Linville @ 2005-11-07 18:20 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: netdev, linux-kernel, linuxppc-embedded
In-Reply-To: <436F07F5.1030206@intracom.gr>
On Mon, Nov 07, 2005 at 09:53:25AM +0200, Pantelis Antoniou wrote:
> John W. Linville wrote:
> >@@ -1,6 +1,6 @@
> > config FEC_8XX
> > tristate "Motorola 8xx FEC driver"
> >- depends on NET_ETHERNET
> >+ depends on NET_ETHERNET && 8xx
> > select MII
> >
> > config FEC_8XX_GENERIC_PHY
>
> Yes, this is the correct approach. Please disregard the other
> patches floating about.
Pretty sure you are right. However, a broken version already got
committed. It added FEC as a dependency. That keeps it from breaking
everyone else, but it make the driver available for Coldfire rather
than for PPC 8xx...
I'll reform that patch and repost.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Tom Rini @ 2005-11-07 18:22 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Dan Malek, linuxppc-embedded, gtolstolytkin
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5C5@tmnt04.transmode.se>
On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > Sent: 07 November 2005 16:52
> > To: Marcelo Tosatti
> > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> >
> > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > > Joakim!
> > >
> > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > > Hi Marcelo
> > > >
> > > > [SNIP]
> > > > > The root of the problem are the changes against the 8xx TLB
> > > > > handlers introduced
> > > > > during v2.6. What happens is the TLBMiss handlers load the
> > > > > zeroed pte into
> > > > > the TLB, causing the TLBError handler to be invoked (thats
> > > > > two TLB faults per
> > > > > pagefault), which then jumps to the generic MM code to
> > setup the pte.
> > > > >
> > > > > The bug is that the zeroed TLB is not invalidated (the
> > same reason
> > > > > for the "dcbst" misbehaviour), resulting in infinite
> > TLBError faults.
> > > > >
> > > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > > >
> > > > This is one reason why it is the way it is:
> > > >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > > This details are little fuzzy ATM, but I think the reason for the
> > > > current
> > > > impl. was only that it was less intrusive to impl.
> > >
> > > Ah, I see. I wonder if the bug is processor specific: we
> > don't have such
> > > changes in our v2.4 tree and never experienced such problem.
> > >
> > > It should be pretty easy to hit it right? (instruction
> > pagefaults should
> > > fail).
> > >
> > > Grigori, Tom, can you enlight us about the issue on the URL
> > above. How
> > > can it be triggered?
> >
> > So after looking at the code in 2.6.14 and current git, I think the
> > above URL isn't relevant, unless there was a change I missed (which
> > could totally be possible) that reverted the patch there and
> > fixed that
> > issue in a different manner. But since I didn't figure that
> > out until I
> > had finished researching it again:
>
> I wasn't clear enough. What I meant was that the above patch made me
> think and
> the result was that I came up with a simpler fix, the "two exception"
> fix that
> is in current kernels. See
> http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
> 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|hist
> /arch/ppc/kernel/head_8xx.S
> It appears this fix has some other issues :(
>
> How do the other ppc arches do? I am guessing that they don't double
> fault, but bails
> out to do_page_fault from the TLB Miss handler, like 8xx used to do.
Assuming Dan doesn't come up with a more simple & better fix, maybe we
should go back to the original patch I made?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [patch 2.6.14 (take #2)] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
From: John W. Linville @ 2005-11-07 18:24 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded, netdev, linux-kernel
In-Reply-To: <20051107182031.GC13797@tuxdriver.com>
Change CONFIG_FEC_8XX to depend on CONFIG_8xx instead of CONFIG_FEC.
CONFIG_FEC depends on ColdFire CPUs, which does not apply for the
PPC 8xx processors.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/fec_8xx/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index 94e7a9a..a84c232 100644
--- a/drivers/net/fec_8xx/Kconfig
+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
config FEC_8XX
tristate "Motorola 8xx FEC driver"
- depends on NET_ETHERNET && FEC
+ depends on NET_ETHERNET && 8xx
select MII
config FEC_8XX_GENERIC_PHY
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-07 18:37 UTC (permalink / raw)
To: Tom Rini; +Cc: Dan Malek, gtolstolytkin, linuxppc-embedded
>=20
> On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > -----Original Message-----
> > > From: Tom Rini [mailto:trini@kernel.crashing.org]=20
> > > Sent: 07 November 2005 16:52
> > > To: Marcelo Tosatti
> > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;=20
> > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > >=20
> > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > > > Joakim!
> > > >=20
> > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim=20
> Tjernlund wrote:
> > > > > Hi Marcelo
> > > > >=20
> > > > > [SNIP]=20
> > > > > > The root of the problem are the changes against the 8xx TLB=20
> > > > > > handlers introduced
> > > > > > during v2.6. What happens is the TLBMiss handlers load the=20
> > > > > > zeroed pte into
> > > > > > the TLB, causing the TLBError handler to be invoked (thats=20
> > > > > > two TLB faults per=20
> > > > > > pagefault), which then jumps to the generic MM code to=20
> > > setup the pte.
> > > > > >=20
> > > > > > The bug is that the zeroed TLB is not invalidated (the=20
> > > same reason
> > > > > > for the "dcbst" misbehaviour), resulting in infinite=20
> > > TLBError faults.
> > > > > >=20
> > > > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > > > >=20
> > > > > This is one reason why it is the way it is:
> > > > >=20
> > >=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > > > This details are little fuzzy ATM, but I think the=20
> reason for the
> > > > > current
> > > > > impl. was only that it was less intrusive to impl.
> > > >=20
> > > > Ah, I see. I wonder if the bug is processor specific: we=20
> > > don't have such
> > > > changes in our v2.4 tree and never experienced such problem.
> > > >=20
> > > > It should be pretty easy to hit it right? (instruction=20
> > > pagefaults should
> > > > fail).
> > > >=20
> > > > Grigori, Tom, can you enlight us about the issue on the URL=20
> > > above. How
> > > > can it be triggered?
> > >=20
> > > So after looking at the code in 2.6.14 and current git, I=20
> think the
> > > above URL isn't relevant, unless there was a change I=20
> missed (which
> > > could totally be possible) that reverted the patch there and=20
> > > fixed that
> > > issue in a different manner. But since I didn't figure that=20
> > > out until I
> > > had finished researching it again:
> >=20
> > I wasn't clear enough. What I meant was that the above patch made me
> > think and
> > the result was that I came up with a simpler fix, the "two=20
> exception"
> > fix that
> > is in current kernels. See
> >=20
> http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/h
> ead_8xx.S@
> >=20
> 1.19?nav=3Dindex.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> ernel|hist
> > /arch/ppc/kernel/head_8xx.S
> > It appears this fix has some other issues :(
> >=20
> > How do the other ppc arches do? I am guessing that they don't double
> > fault, but bails
> > out to do_page_fault from the TLB Miss handler, like 8xx used to do.
>=20
> Assuming Dan doesn't come up with a more simple & better fix, maybe we
> should go back to the original patch I made?
That was what I was thinking too(or some variation of your patch)
I wonder if that would solve the misbehaving dcbst problem Marcelo found
some time ago too?
Jocke
^ permalink raw reply
* [PATCH] ppc32: fix perf_irq extern on e500
From: Matt Porter @ 2005-11-07 19:49 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Add an extern reference to perf_irq on e500.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
index 16adde6..ff1bdc2 100644
--- a/arch/ppc/kernel/traps.c
+++ b/arch/ppc/kernel/traps.c
@@ -888,6 +888,8 @@ void altivec_assist_exception(struct pt_
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_E500
+extern perf_irq_t perf_irq;
+
void performance_monitor_exception(struct pt_regs *regs)
{
perf_irq(regs);
^ permalink raw reply related
* [PATCH] ppc32: Fix RapidIO build on 85xx
From: Matt Porter @ 2005-11-07 19:51 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Fixes mismerged Makefile that prevented the ppc85xx rapidio support
from being built.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 5bd33ba..5b7f2b8 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -33,7 +33,6 @@ obj-$(CONFIG_PPC4xx_DMA) += ppc4xx_dma.o
obj-$(CONFIG_PPC4xx_EDMA) += ppc4xx_sgdma.o
ifeq ($(CONFIG_40x),y)
obj-$(CONFIG_PCI) += pci_auto.o ppc405_pci.o
-obj-$(CONFIG_RAPIDIO) += ppc85xx_rio.o
endif
endif
obj-$(CONFIG_8xx) += m8xx_setup.o ppc8xx_pic.o $(wdt-mpc8xx-y) \
@@ -96,6 +95,7 @@ obj-$(CONFIG_85xx) += open_pic.o ppc85x
ifeq ($(CONFIG_85xx),y)
obj-$(CONFIG_PCI) += pci_auto.o
endif
+obj-$(CONFIG_RAPIDIO) += ppc85xx_rio.o
obj-$(CONFIG_83xx) += ipic.o ppc83xx_setup.o ppc_sys.o \
mpc83xx_sys.o mpc83xx_devices.o
ifeq ($(CONFIG_83xx),y)
^ permalink raw reply related
* [PATCH] ppc32: Fix STx GP3 build
From: Matt Porter @ 2005-11-07 19:53 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Add missing include file to fix STx GP3 build.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/ppc/platforms/85xx/stx_gp3.h b/arch/ppc/platforms/85xx/stx_gp3.h
index 95fdf4b..7bcc6c3 100644
--- a/arch/ppc/platforms/85xx/stx_gp3.h
+++ b/arch/ppc/platforms/85xx/stx_gp3.h
@@ -21,6 +21,7 @@
#include <linux/config.h>
#include <linux/init.h>
+#include <linux/seq_file.h>
#include <asm/ppcboot.h>
#define BOARD_CCSRBAR ((uint)0xe0000000)
^ permalink raw reply related
* Linux 2.6.14 and ALSA
From: Giuliano Pochini @ 2005-11-07 20:10 UTC (permalink / raw)
To: LinuxPPC-dev
I know there is a big ppc32-ppc64 merge in progress. Anyway, with Linux
2.6.14 alsa-driver doesn't compile anymore. The configure script cannot
compile many of its mini test programs because it cannot find the following
headers. This is not a bug report. This is just a (incomplete?) list of
files that have still to be moved in order to make alsa compile. I hope it
helps.
/usr/src/linux//include/asm/delay.h:5:23: asm/param.h: No such file or directory
/usr/src/linux//include/asm/machdep.h:9:23: asm/setup.h: No such file or directory
/usr/src/linux//include/linux/errno.h:4:23: asm/errno.h: No such file or directory
/usr/src/linux//include/linux/fcntl.h:4:23: asm/fcntl.h: No such file or directory
/usr/src/linux//include/linux/ioctl.h:4:23: asm/ioctl.h: No such file or directory
/usr/src/linux//include/linux/jiffies.h:9:23: asm/div64.h: No such file or directory
/usr/src/linux//include/linux/linkage.h:5:25: asm/linkage.h: No such file or directory
/usr/src/linux//include/linux/module.h:21:23: asm/local.h: No such file or directory
/usr/src/linux//include/linux/module.h:23:24: asm/module.h: No such file or directory
/usr/src/linux//include/linux/percpu.h:7:24: asm/percpu.h: No such file or directory
/usr/src/linux//include/linux/resource.h:68:26: asm/resource.h: No such file or directory
/usr/src/linux//include/linux/sched.h:24:25: asm/cputime.h: No such file or directory
/usr/src/linux//include/linux/sched.h:4:36: asm/param.h: No such file or directory
/usr/src/linux//include/linux/sem.h:36:24: asm/sembuf.h: No such file or directory
/usr/src/linux//include/linux/signal.h:7:25: asm/siginfo.h: No such file or directory
/usr/src/linux//include/linux/string.h:24:24: asm/string.h: No such file or directory
/usr/src/linux//include/linux/termios.h:5:25: asm/termios.h: No such file or directory
/usr/src/linux//include/linux/timex.h:60:23: asm/param.h: No such file or directory
/usr/src/linux//include/linux/timex.h:61:23: asm/timex.h: No such file or directory
/usr/src/linux//include/linux/topology.h:34:26: asm/topology.h: No such file or directory
The whole config.log is here: http://www.webalice.it/g_pochini/config.log
--
Giuliano.
^ permalink raw reply
* fix swapping on 8xx?
From: Marcelo Tosatti @ 2005-11-07 15:10 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
Hi,
The following is an attempt to fix swapping on 8xx by not touching
_PAGE_ACCESSED bit if the page is not present.
Dan, what do you think?
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index de09787..4451828 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -41,6 +41,22 @@
#else
#define DO_8xx_CPU6(val, reg)
#endif
+
+/* can't overwrite the _PAGE_ACCESSED bit of a non-present page (might
+ contain swap data). */
+#ifdef CONFIG_SWAP
+#define SET_PAGE_ACCESSED(reg, destreg, tmpreg) \
+ andi. tmpreg, reg, _PAGE_PRESENT; \
+ beq 9f; \
+ ori reg, reg, _PAGE_ACCESSED; \
+ stw r10, 0(destreg); \
+9:
+#else
+#define SET_PAGE_ACCESSED(reg, destreg, tmpreg) \
+ ori reg, reg, _PAGE_ACCESSED; \
+ stw reg, 0(destreg);
+#endif
+
.text
.globl _stext
_stext:
@@ -332,8 +348,7 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
- ori r10, r10, _PAGE_ACCESSED
- stw r10, 0(r11)
+ SET_PAGE_ACCESSED(r10, r11, r3)
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 21, 22 and 28 must be clear.
@@ -399,8 +414,7 @@ DataStoreTLBMiss:
mtspr SPRN_MD_TWC, r11
mfspr r11, SPRN_MD_TWC /* get the pte address again */
- ori r10, r10, _PAGE_ACCESSED
- stw r10, 0(r11)
+ SET_PAGE_ACCESSED(r10, r11, r3) /* and update pte in table */
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 21, 22 and 28 must be clear.
@@ -507,9 +521,9 @@ DataTLBError:
/* Update 'changed', among others.
*/
- ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
+ ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
mfspr r11, SPRN_MD_TWC /* Get pte address again */
- stw r10, 0(r11) /* and update pte in table */
+ SET_PAGE_ACCESSED(r10, r11, r3) /* and update pte in table */
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 21, 22 and 28 must be clear.
^ permalink raw reply related
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Benjamin Herrenschmidt @ 2005-11-07 20:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded, Dan Malek
In-Reply-To: <20051107084431.GA15180@logos.cnet>
On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
>
> The bug is that the zeroed TLB is not invalidated (the same reason
> for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
I see, so you are in the same situation as ia64 which has valid but
unmapped TLBs ?
> Dan, I wonder why we just don't go back to v2.4 behaviour. It is not very
> clear to me that "two exception" speedup offsets the additional code required
> for "one exception" version. Have you actually done any measurements?
What do you mean by "one exception" version ? You probably get 3 in fact
since after you have serviced the fault in the common code, you take
another fault to fill the PTE.
In fact, you could even go back to one exception by pre-filling the TLB
in update_mmu_cache :)
> There is chance that the additional code ends up in the same cacheline,
> which would mean no huge gain by the "two exception" approach. Might be
> even harmful for performance (you need two exceptions instead of one
> after all).
>
> The "two exception" approach requires a TLB flush (to nuke the zeroed)
> at each PTE update for correct behaviour (which BTW is another slowdown):
I think the current code, even with your fix, is sub-optimal. But of
course, the only way to be sure is to do real measurements
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Pantelis Antoniou @ 2005-11-07 20:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <1131396000.4652.24.camel@gaston>
On Monday 07 November 2005 22:39, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
>
> >
> > The bug is that the zeroed TLB is not invalidated (the same reason
> > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
>
> I see, so you are in the same situation as ia64 which has valid but
> unmapped TLBs ?
>
> > Dan, I wonder why we just don't go back to v2.4 behaviour. It is not very
> > clear to me that "two exception" speedup offsets the additional code required
> > for "one exception" version. Have you actually done any measurements?
>
> What do you mean by "one exception" version ? You probably get 3 in fact
> since after you have serviced the fault in the common code, you take
> another fault to fill the PTE.
>
> In fact, you could even go back to one exception by pre-filling the TLB
> in update_mmu_cache :)
>
Yep. That should be the target. Remember the poor 8xx is not exactly a
speed demon :).
> > There is chance that the additional code ends up in the same cacheline,
> > which would mean no huge gain by the "two exception" approach. Might be
> > even harmful for performance (you need two exceptions instead of one
> > after all).
> >
> > The "two exception" approach requires a TLB flush (to nuke the zeroed)
> > at each PTE update for correct behaviour (which BTW is another slowdown):
>
> I think the current code, even with your fix, is sub-optimal. But of
> course, the only way to be sure is to do real measurements
>
> Ben.
>
>
The TLB flush is bogus IMO. I'm going to try the last patch by marcelo to
see if it works for me.
Pantelis.
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-07 21:00 UTC (permalink / raw)
To: Charles-Edouard Ruault; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <436F1A9E.80105@idtect.com>
> i've applied your patch and it seems that when i put my powerbook to
> sleep ( by closing the lid ) the kernel just crashes since everytime i
> come back, the machine is turned off. I had a look at the logs and i see
> that i'm having a reboot almost immediateley after the lid is closed.
> However i've got no trace of a kernel panic .....
> my conf:
What about this patch ?
Index: linux-2.6.14-benh/drivers/usb/core/hcd-pci.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/core/hcd-pci.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/core/hcd-pci.c 2005-11-07 17:14:47.000000000 +1100
@@ -32,6 +32,13 @@
#include <linux/usb.h>
#include "hcd.h"
+#ifdef CONFIG_PPC_PMAC
+#include <asm/machdep.h>
+#include <asm/pmac_feature.h>
+#include <asm/pci-bridge.h>
+#include <asm/prom.h>
+#endif
+
/* PCI-based HCs are common, but plenty of non-PCI HCs are used too */
@@ -278,6 +285,18 @@
break;
}
+#ifdef CONFIG_PPC_PMAC
+ if (retval == 0 && _machine == _MACH_Pmac) {
+ struct device_node *of_node;
+
+ /* Disable USB PAD & cell clock */
+ of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.
+ controller));
+ if (of_node)
+ pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
+ }
+#endif /* CONFIG_PPC_PMAC */
+
/* update power_state **ONLY** to make sysfs happier */
if (retval == 0)
dev->dev.power.power_state = message;
@@ -303,6 +322,18 @@
return 0;
}
+#ifdef CONFIG_PPC_PMAC
+ if (_machine == _MACH_Pmac) {
+ struct device_node *of_node;
+
+ /* Re-enable USB PAD & cell clock */
+ of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.
+ controller));
+ if (of_node)
+ pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 1);
+ }
+#endif /* CONFIG_PPC_PMAC */
+
/* NOTE: chip docs cover clean "real suspend" cases (what Linux
* calls "standby", "suspend to RAM", and so on). There are also
* dirty cases when swsusp fakes a suspend in "shutdown" mode.
Index: linux-2.6.14-benh/drivers/usb/core/hcd.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/core/hcd.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/core/hcd.c 2005-11-07 17:14:10.000000000 +1100
@@ -1600,7 +1600,8 @@
struct usb_hcd *hcd = __hcd;
int start = hcd->state;
- if (start == HC_STATE_HALT)
+ if (start == HC_STATE_HALT ||
+ !test_bit(HC_FLAG_IRQ_ON, &hcd->bitflags))
return IRQ_NONE;
if (hcd->driver->irq (hcd, r) == IRQ_NONE)
return IRQ_NONE;
@@ -1736,6 +1737,9 @@
if (hcd->driver->irq) {
char buf[8], *bufp = buf;
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ mb();
+
#ifdef __sparc__
bufp = __irq_itoa(irqnum);
#else
Index: linux-2.6.14-benh/drivers/usb/core/hcd.h
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/core/hcd.h 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/core/hcd.h 2005-11-07 17:13:22.000000000 +1100
@@ -71,6 +71,9 @@
/*
* hardware info/state
*/
+ unsigned long bitflags; /* various single-bit flags */
+#define HC_FLAG_IRQ_ON 0
+
const struct hc_driver *driver; /* hw-specific hooks */
unsigned saw_irq : 1;
unsigned can_wakeup:1; /* hw supports wakeup? */
Index: linux-2.6.14-benh/drivers/usb/host/ehci-hcd.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/ehci-hcd.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/ehci-hcd.c 2005-11-07 17:49:24.000000000 +1100
@@ -750,6 +750,12 @@
if (time_before (jiffies, ehci->next_statechange))
msleep (100);
+ /* Disable emission of interrupts during suspend */
+ writel(0, &ehci->regs->intr_enable);
+ mb();
+ clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ synchronize_irq(to_pci_dev(hcd->self.controller)->irq);
+
#ifdef CONFIG_USB_SUSPEND
(void) usb_suspend_device (hcd->self.root_hub, message);
#else
@@ -776,6 +782,8 @@
if (time_before (jiffies, ehci->next_statechange))
msleep (100);
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+
/* If any port is suspended (or owned by the companion),
* we know we can/must resume the HC (and mustn't reset it).
*/
Index: linux-2.6.14-benh/drivers/usb/host/ehci-q.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/ehci-q.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/ehci-q.c 2005-11-07 17:15:55.000000000 +1100
@@ -926,6 +926,11 @@
#endif
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ return -ESHUTDOWN;
+ }
+
qh = qh_append_tds (ehci, urb, qtd_list, epnum, &ep->hcpriv);
/* Control/bulk operations through TTs don't need scheduling,
Index: linux-2.6.14-benh/drivers/usb/host/ehci-sched.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/ehci-sched.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/ehci-sched.c 2005-11-07 17:16:39.000000000 +1100
@@ -602,6 +602,11 @@
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ return -ESHUTDOWN;
+ }
+
/* get qh and force any scheduling errors */
INIT_LIST_HEAD (&empty);
qh = qh_append_tds (ehci, urb, &empty, epnum, &ep->hcpriv);
@@ -1456,6 +1461,11 @@
/* schedule ... need to lock */
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ status = -ESHUTDOWN;
+ goto done;
+ }
status = iso_stream_schedule (ehci, urb, stream);
if (likely (status == 0))
itd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
@@ -1815,6 +1825,11 @@
/* schedule ... need to lock */
spin_lock_irqsave (&ehci->lock, flags);
+ if (HC_IS_SUSPENDED(ehci_to_hcd(ehci)->state)) {
+ spin_unlock_irqrestore (&ehci->lock, flags);
+ status = -ESHUTDOWN;
+ goto done;
+ }
status = iso_stream_schedule (ehci, urb, stream);
if (status == 0)
sitd_link_urb (ehci, urb, ehci->periodic_size << 3, stream);
Index: linux-2.6.14-benh/drivers/usb/host/ohci-hcd.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/ohci-hcd.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/ohci-hcd.c 2005-11-07 17:17:04.000000000 +1100
@@ -252,6 +252,10 @@
spin_lock_irqsave (&ohci->lock, flags);
+ if (HC_IS_SUSPENDED(hcd->state)) {
+ retval = -ESHUTDOWN;
+ goto fail;
+ }
/* don't submit to a dead HC */
if (!HC_IS_RUNNING(hcd->state)) {
retval = -ENODEV;
Index: linux-2.6.14-benh/drivers/usb/host/ohci-hub.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/ohci-hub.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/ohci-hub.c 2005-11-07 17:18:00.000000000 +1100
@@ -219,13 +219,6 @@
/* Sometimes PCI D3 suspend trashes frame timings ... */
periodic_reinit (ohci);
- /* interrupts might have been disabled */
- ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
- if (ohci->ed_rm_list)
- ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
- ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
- &ohci->regs->intrstatus);
-
/* Then re-enable operations */
ohci_writel (ohci, OHCI_USB_OPER, &ohci->regs->control);
(void) ohci_readl (ohci, &ohci->regs->control);
@@ -241,6 +234,13 @@
/* TRSMRCY */
msleep (10);
+ /* interrupts might have been disabled */
+ ohci_writel (ohci, OHCI_INTR_INIT, &ohci->regs->intrenable);
+ if (ohci->ed_rm_list)
+ ohci_writel (ohci, OHCI_INTR_SF, &ohci->regs->intrenable);
+ ohci_writel (ohci, ohci_readl (ohci, &ohci->regs->intrstatus),
+ &ohci->regs->intrstatus);
+
/* keep it alive for ~5x suspend + resume costs */
ohci->next_statechange = jiffies + msecs_to_jiffies (250);
Index: linux-2.6.14-benh/drivers/usb/host/ohci-pci.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/ohci-pci.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/ohci-pci.c 2005-11-07 17:49:26.000000000 +1100
@@ -14,13 +14,6 @@
* This file is licenced under the GPL.
*/
-#ifdef CONFIG_PPC_PMAC
-#include <asm/machdep.h>
-#include <asm/pmac_feature.h>
-#include <asm/pci-bridge.h>
-#include <asm/prom.h>
-#endif
-
#ifndef CONFIG_PCI
#error "This file is PCI bus glue. CONFIG_PCI must be defined."
#endif
@@ -118,6 +111,12 @@
if (time_before (jiffies, ohci->next_statechange))
msleep (100);
+ /* Disable emission of interrupts during suspend */
+ ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
+ mb();
+ clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ synchronize_irq(to_pci_dev(hcd->self.controller)->irq);
+
#ifdef CONFIG_USB_SUSPEND
(void) usb_suspend_device (hcd->self.root_hub, message);
#else
@@ -129,16 +128,6 @@
/* let things settle down a bit */
msleep (100);
-#ifdef CONFIG_PPC_PMAC
- if (_machine == _MACH_Pmac) {
- struct device_node *of_node;
-
- /* Disable USB PAD & cell clock */
- of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
- if (of_node)
- pmac_call_feature(PMAC_FTR_USB_ENABLE, of_node, 0, 0);
- }
-#endif /* CONFIG_PPC_PMAC */
return 0;
}
@@ -148,20 +137,11 @@
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
int retval = 0;
-#ifdef CONFIG_PPC_PMAC
- if (_machine == _MACH_Pmac) {
- struct device_node *of_node;
-
- /* Re-enable USB PAD & cell clock */
- of_node = pci_device_to_OF_node (to_pci_dev(hcd->self.controller));
- if (of_node)
- pmac_call_feature (PMAC_FTR_USB_ENABLE, of_node, 0, 1);
- }
-#endif /* CONFIG_PPC_PMAC */
-
/* resume root hub */
if (time_before (jiffies, ohci->next_statechange))
msleep (100);
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+
#ifdef CONFIG_USB_SUSPEND
/* get extra cleanup even if remote wakeup isn't in use */
retval = usb_resume_device (hcd->self.root_hub);
Index: linux-2.6.14-benh/drivers/usb/host/uhci-hcd.c
===================================================================
--- linux-2.6.14-benh.orig/drivers/usb/host/uhci-hcd.c 2005-11-07 15:11:16.000000000 +1100
+++ linux-2.6.14-benh/drivers/usb/host/uhci-hcd.c 2005-11-07 17:18:55.000000000 +1100
@@ -770,6 +770,12 @@
dev_dbg(uhci_dev(uhci), "%s\n", __FUNCTION__);
+ /* Disable emission of interrupts during suspend */
+ pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP, 0);
+ mb();
+ clear_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
+ synchronize_irq(to_pci_dev(uhci_dev(uhci))->irq);
+
spin_lock_irq(&uhci->lock);
if (uhci->hc_inaccessible) /* Dead or already suspended */
goto done;
@@ -782,12 +788,14 @@
if (uhci->rh_state > UHCI_RH_SUSPENDED) {
dev_warn(uhci_dev(uhci), "Root hub isn't suspended!\n");
hcd->state = HC_STATE_RUNNING;
+ set_bit(HC_FLAG_IRQ_ON, &hcd->bitflags);
rc = -EBUSY;
goto done;
};
/* All PCI host controllers are required to disable IRQ generation
- * at the source, so we must turn off PIRQ.
+ * at the source, so we must turn off PIRQ. Already done earlier
+ * but better be safe than sorry...
*/
pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP, 0);
uhci->hc_inaccessible = 1;
^ permalink raw reply
* Re: MPC5200 I2S driver
From: Eric N. Johnson (ACD) @ 2005-11-07 21:04 UTC (permalink / raw)
To: bennett78, linuxppc-embedded
In-Reply-To: <436D068A.7030905@digis.net>
>I would be interested in getting any driver code
>examples for Bestcomm/PSC6/CODEC for the mpc5200
>as well.
There was an earlier discussion on this list. Have a look at:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-September/020210.html
That message has the code we've used to run an I2S DAC on the
MPC5200. It's been stable, although we've not done extensive
testing. You'll also have to prune out the code that's specific to
our hardware, and it supports output only. We have not tried using I2S inputs.
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* Re: [PATCH] Fix ppc32 smp build.
From: Benjamin Herrenschmidt @ 2005-11-07 21:20 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131356850.27347.17.camel@baythorne.infradead.org>
On Mon, 2005-11-07 at 09:47 +0000, David Woodhouse wrote:
> On Sun, 2005-11-06 at 21:51 +1100, Paul Mackerras wrote:
> > If we really can get unsynchronized timebases still, then I suppose we
> > need to bring back the smp_tb_synchronized variable,
>
> We make no attempt to sync the timebases on quad powersurge, as far as I
> can tell -- and we never set smp_tb_synchronized there.
We don't even use the software sync ? Hrm... actually, I think the
software sync was designed for 2 CPUs only.
Now, go find the one user that had a quad powersurge :)
Ben.
^ permalink raw reply
* Re: Linux 2.6.14 and ALSA
From: Benjamin Herrenschmidt @ 2005-11-07 21:21 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: LinuxPPC-dev
In-Reply-To: <20051107201011.3b1e4db4.pochini@shiny.it>
On Mon, 2005-11-07 at 20:10 +0000, Giuliano Pochini wrote:
>
> I know there is a big ppc32-ppc64 merge in progress. Anyway, with Linux
> 2.6.14 alsa-driver doesn't compile anymore. The configure script cannot
> compile many of its mini test programs because it cannot find the following
> headers. This is not a bug report. This is just a (incomplete?) list of
> files that have still to be moved in order to make alsa compile. I hope it
> helps.
Just include include/asm-powerpc before include/asm-ppc, we do that with
an "asm" symlink link in the arch code
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-07 17:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded, Dan Malek
In-Reply-To: <1131396000.4652.24.camel@gaston>
On Tue, Nov 08, 2005 at 07:39:59AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
>
> >
> > The bug is that the zeroed TLB is not invalidated (the same reason
> > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
>
> I see, so you are in the same situation as ia64 which has valid but
> unmapped TLBs ?
>
> > Dan, I wonder why we just don't go back to v2.4 behaviour. It is not very
> > clear to me that "two exception" speedup offsets the additional code required
> > for "one exception" version. Have you actually done any measurements?
>
> What do you mean by "one exception" version ? You probably get 3 in fact
> since after you have serviced the fault in the common code, you take
> another fault to fill the PTE.
Yep, that would be 3!
> In fact, you could even go back to one exception by pre-filling the TLB
> in update_mmu_cache :)
OK, thats a good idea as we talked on IRC. Working on that.
> > There is chance that the additional code ends up in the same cacheline,
> > which would mean no huge gain by the "two exception" approach. Might be
> > even harmful for performance (you need two exceptions instead of one
> > after all).
> >
> > The "two exception" approach requires a TLB flush (to nuke the zeroed)
> > at each PTE update for correct behaviour (which BTW is another slowdown):
>
> I think the current code, even with your fix, is sub-optimal. But of
> course, the only way to be sure is to do real measurements
Indeed.
Thanks!
^ permalink raw reply
* Re: PPCBoot 2.0.0 Errors
From: Wolfgang Denk @ 2005-11-07 22:09 UTC (permalink / raw)
To: Sette Agostino; +Cc: linuxppc-embedded
In-Reply-To: <69DF49BE936F4441980EC1D59F0ADC2F0108C12C@aqlby02a.siemens.it>
In message <69DF49BE936F4441980EC1D59F0ADC2F0108C12C@aqlby02a.siemens.it> you wrote:
>
> I have the following problem at the PPCBoot startup:
>
> PPCBoot 2.0.0 (Oct 20 2005 - 12:28:22)
PPCBoot is a dead project. It was discontinued more than 3 years ago.
It is definitely a bad idea to use it for current projects. Use
U-Boot instead.
Also, this is completely off topic on this mailing list.
> CPU: unknown MPC859 (0x08010004) at 133 MHz: 16 kB I-Cache 8 kB D-Cache
Use U-Boot instead.
> Board: Siemens CCM
And don't use a board configuration that does not match your hardware.
> ## Booting image at 40180000 ...
> Image Name: Linux-2.4.20-rthal5
Argh... Ancient stuff again. Forget it.
> Anybody experienced the same problem? Any suggestions about how to solve it?
Use current software. Read the documentation. Post on the appropriate
mailing lists.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
My challenge to the goto-less programmer is to recode tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch). - W. R. Stevens
^ permalink raw reply
* [PATCH] ppc32: Update MPC834x platform to work with new phylib
From: galak @ 2005-11-07 22:17 UTC (permalink / raw)
To: Andrew Morton, Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded
MPC834x uses the gianfar network driver which now uses the new phylib.
We need to update the platform code to create a gianfar platform MDIO
bus and pass the right intializations to the gianfar driver to make
things work again.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit bc8310fb525f2174b0a1e3a970da38b664ead6c1
tree 5d692f91fbd625f4413c4f6873292e5f2ecac42c
parent c51e3a417bb0f295e13a5bad86302b5212eafdf3
author Kumar Gala <galak@kernel.crashing.org> Mon, 07 Nov 2005 16:06:56 -0600
committer Kumar Gala <galak@kernel.crashing.org> Mon, 07 Nov 2005 16:06:56 -0600
arch/ppc/configs/mpc834x_sys_defconfig | 431 +++++++++++++++++++++++---------
arch/ppc/platforms/83xx/mpc834x_sys.c | 23 +-
arch/ppc/syslib/mpc83xx_devices.c | 12 +
arch/ppc/syslib/mpc83xx_sys.c | 24 +-
include/asm-ppc/mpc83xx.h | 1
5 files changed, 353 insertions(+), 138 deletions(-)
diff --git a/arch/ppc/configs/mpc834x_sys_defconfig b/arch/ppc/configs/mpc834x_sys_defconfig
index 4a5522c..673dc64 100644
--- a/arch/ppc/configs/mpc834x_sys_defconfig
+++ b/arch/ppc/configs/mpc834x_sys_defconfig
@@ -1,16 +1,17 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.11-rc4
-# Thu Feb 17 16:12:23 2005
+# Linux kernel version: 2.6.14
+# Mon Nov 7 15:38:29 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
-CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
@@ -18,23 +19,28 @@ CONFIG_GENERIC_NVRAM=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# 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_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
+CONFIG_INITRAMFS_SOURCE=""
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
@@ -44,6 +50,7 @@ CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
#
# Loadable module support
@@ -59,34 +66,84 @@ CONFIG_6xx=y
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
+# CONFIG_E200 is not set
# CONFIG_E500 is not set
+CONFIG_PPC_FPU=y
+# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
+# CONFIG_WANT_EARLY_SERIAL is not set
CONFIG_PPC_GEN550=y
-CONFIG_83xx=y
-
-#
-# Freescale 83xx options
-#
-CONFIG_MPC834x_SYS=y
-CONFIG_MPC834x=y
CONFIG_PPC_STD_MMU=y
#
# Platform options
#
+# CONFIG_PPC_MULTIPLATFORM is not set
+# CONFIG_APUS is not set
+# CONFIG_KATANA is not set
+# CONFIG_WILLOW is not set
+# CONFIG_CPCI690 is not set
+# CONFIG_POWERPMC250 is not set
+# CONFIG_CHESTNUT is not set
+# CONFIG_SPRUCE is not set
+# CONFIG_HDPU is not set
+# CONFIG_EV64260 is not set
+# CONFIG_LOPEC is not set
+# CONFIG_MVME5100 is not set
+# CONFIG_PPLUS is not set
+# CONFIG_PRPMC750 is not set
+# CONFIG_PRPMC800 is not set
+# CONFIG_SANDPOINT is not set
+# CONFIG_RADSTONE_PPC7D is not set
+# CONFIG_PAL4 is not set
+# CONFIG_GEMINI is not set
+# CONFIG_EST8260 is not set
+# CONFIG_SBC82xx is not set
+# CONFIG_SBS8260 is not set
+# CONFIG_RPX8260 is not set
+# CONFIG_TQM8260 is not set
+# CONFIG_ADS8272 is not set
+# CONFIG_PQ2FADS is not set
+# CONFIG_LITE5200 is not set
+CONFIG_MPC834x_SYS=y
+# CONFIG_EV64360 is not set
+CONFIG_83xx=y
+CONFIG_MPC834x=y
# CONFIG_SMP is not set
-# CONFIG_PREEMPT is not set
# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+# CONFIG_SOFTWARE_SUSPEND is not set
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_GENERIC_ISA_DMA=y
-# CONFIG_PCI is not set
-# CONFIG_PCI_DOMAINS is not set
+# CONFIG_PPC_I8259 is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+# CONFIG_MPC83xx_PCI2 is not set
+CONFIG_PCI_LEGACY_PROC=y
#
# PCCARD (PCMCIA/CardBus) support
@@ -94,10 +151,6 @@ CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PCCARD is not set
#
-# PC-card bridges
-#
-
-#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
@@ -112,6 +165,75 @@ CONFIG_TASK_SIZE=0x80000000
CONFIG_BOOT_LOAD=0x00800000
#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_BIC=y
+# CONFIG_IPV6 is not set
+# CONFIG_NETFILTER is not set
+
+#
+# DCCP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_DCCP is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_SCHED is not set
+# CONFIG_NET_CLS_ROUTE is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_IEEE80211 is not set
+
+#
# Device Drivers
#
@@ -123,6 +245,11 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
#
+# Connector - unified userspace <-> kernelspace linker
+#
+# CONFIG_CONNECTOR is not set
+
+#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
@@ -140,15 +267,19 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
# 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_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32768
CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
@@ -159,6 +290,11 @@ CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
# CONFIG_ATA_OVER_ETH is not set
#
@@ -169,6 +305,7 @@ CONFIG_IOSCHED_CFQ=y
#
# SCSI device support
#
+# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
#
@@ -179,110 +316,116 @@ CONFIG_IOSCHED_CFQ=y
#
# Fusion MPT device support
#
+# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
+# CONFIG_IEEE1394 is not set
#
# I2O device support
#
+# CONFIG_I2O is not set
#
# Macintosh device drivers
#
#
-# Networking support
+# Network device support
#
-CONFIG_NET=y
-
-#
-# Networking options
-#
-CONFIG_PACKET=y
-# CONFIG_PACKET_MMAP is not set
-# CONFIG_NETLINK_DEV is not set
-CONFIG_UNIX=y
-# CONFIG_NET_KEY is not set
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-# CONFIG_IP_ADVANCED_ROUTER is not set
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-# CONFIG_IP_PNP_RARP is not set
-# CONFIG_NET_IPIP is not set
-# CONFIG_NET_IPGRE is not set
-# CONFIG_IP_MROUTE is not set
-# CONFIG_ARPD is not set
-CONFIG_SYN_COOKIES=y
-# CONFIG_INET_AH is not set
-# CONFIG_INET_ESP is not set
-# CONFIG_INET_IPCOMP is not set
-# CONFIG_INET_TUNNEL is not set
-CONFIG_IP_TCPDIAG=y
-# CONFIG_IP_TCPDIAG_IPV6 is not set
-# CONFIG_IPV6 is not set
-# CONFIG_NETFILTER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
#
-# SCTP Configuration (EXPERIMENTAL)
+# ARCnet devices
#
-# CONFIG_IP_SCTP is not set
-# CONFIG_ATM is not set
-# CONFIG_BRIDGE is not set
-# CONFIG_VLAN_8021Q is not set
-# CONFIG_DECNET is not set
-# CONFIG_LLC2 is not set
-# CONFIG_IPX is not set
-# CONFIG_ATALK is not set
-# CONFIG_X25 is not set
-# CONFIG_LAPB is not set
-# CONFIG_NET_DIVERT is not set
-# CONFIG_ECONET is not set
-# CONFIG_WAN_ROUTER is not set
+# CONFIG_ARCNET is not set
#
-# QoS and/or fair queueing
+# PHY device support
#
-# CONFIG_NET_SCHED is not set
-# CONFIG_NET_CLS_ROUTE is not set
+CONFIG_PHYLIB=y
#
-# Network testing
+# MII PHY device drivers
#
-# CONFIG_NET_PKTGEN is not set
-# CONFIG_NETPOLL is not set
-# CONFIG_NET_POLL_CONTROLLER is not set
-# CONFIG_HAMRADIO is not set
-# CONFIG_IRDA is not set
-# CONFIG_BT is not set
-CONFIG_NETDEVICES=y
-# CONFIG_DUMMY is not set
-# CONFIG_BONDING is not set
-# CONFIG_EQUALIZER is not set
-# CONFIG_TUN is not set
+CONFIG_MARVELL_PHY=y
+# CONFIG_DAVICOM_PHY is not set
+# CONFIG_QSEMI_PHY is not set
+# CONFIG_LXT_PHY is not set
+# CONFIG_CICADA_PHY is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+
+#
+# Tulip family network device support
+#
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_NET_PCI=y
+# CONFIG_PCNET32 is not set
+# CONFIG_AMD8111_ETH is not set
+# CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_B44 is not set
+# CONFIG_FORCEDETH is not set
+# CONFIG_DGRS is not set
+# CONFIG_EEPRO100 is not set
+CONFIG_E100=y
+# CONFIG_FEALNX is not set
+# CONFIG_NATSEMI is not set
+# CONFIG_NE2K_PCI is not set
+# CONFIG_8139CP is not set
+# CONFIG_8139TOO is not set
+# CONFIG_SIS900 is not set
+# CONFIG_EPIC100 is not set
+# CONFIG_SUNDANCE is not set
+# CONFIG_TLAN is not set
+# CONFIG_VIA_RHINE is not set
#
# Ethernet (1000 Mbit)
#
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+CONFIG_E1000=y
+# CONFIG_E1000_NAPI is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SIS190 is not set
+# CONFIG_SKGE is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_VIA_VELOCITY is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
CONFIG_GIANFAR=y
# CONFIG_GFAR_NAPI is not set
#
# Ethernet (10000 Mbit)
#
+# CONFIG_CHELSIO_T1 is not set
+# CONFIG_IXGB is not set
+# CONFIG_S2IO is not set
#
# Token Ring devices
#
+# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
@@ -293,10 +436,14 @@ CONFIG_GIANFAR=y
# Wan interfaces
#
# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
@@ -323,14 +470,6 @@ CONFIG_INPUT=y
# CONFIG_INPUT_EVBUG is not set
#
-# Input I/O drivers
-#
-# CONFIG_GAMEPORT is not set
-CONFIG_SOUND_GAMEPORT=y
-# CONFIG_SERIO is not set
-# CONFIG_SERIO_I8042 is not set
-
-#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
@@ -340,6 +479,12 @@ CONFIG_SOUND_GAMEPORT=y
# CONFIG_INPUT_MISC is not set
#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
# Character devices
#
# CONFIG_VT is not set
@@ -358,6 +503,7 @@ CONFIG_SERIAL_8250_NR_UARTS=4
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
@@ -376,6 +522,7 @@ CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
@@ -385,6 +532,12 @@ CONFIG_GEN_RTC=y
# CONFIG_RAW_DRIVER is not set
#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_TELCLOCK is not set
+
+#
# I2C support
#
CONFIG_I2C=y
@@ -400,23 +553,68 @@ CONFIG_I2C_CHARDEV=y
#
# I2C Hardware Bus support
#
-# CONFIG_I2C_ISA is not set
+# 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_PIIX4 is not set
CONFIG_I2C_MPC=y
+# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT 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_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
+# Miscellaneous I2C Chip support
+#
+# CONFIG_SENSORS_DS1337 is not set
+# CONFIG_SENSORS_DS1374 is not set
+# CONFIG_SENSORS_EEPROM is not set
+# CONFIG_SENSORS_PCF8574 is not set
+# CONFIG_SENSORS_PCA9539 is not set
+# CONFIG_SENSORS_PCF8591 is not set
+# CONFIG_SENSORS_RTC8564 is not set
+# CONFIG_SENSORS_M41T00 is not set
+# CONFIG_SENSORS_MAX6875 is not set
+# CONFIG_RTC_X1205_I2C 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
+
+#
+# Hardware Monitoring support
#
-# CONFIG_I2C_SENSOR is not set
+CONFIG_HWMON=y
+# CONFIG_HWMON_VID 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_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
+# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
+# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
+# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
@@ -427,33 +625,26 @@ CONFIG_I2C_MPC=y
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
+# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
-# CONFIG_SENSORS_SMSC47B397 is not set
+# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
+# CONFIG_SENSORS_SMSC47B397 is not set
+# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
+# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
+# CONFIG_SENSORS_W83627EHF is not set
+# CONFIG_HWMON_DEBUG_CHIP 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
+# Misc devices
#
-# CONFIG_W1 is not set
#
-# Misc devices
+# Multimedia Capabilities Port drivers
#
#
@@ -479,11 +670,12 @@ CONFIG_I2C_MPC=y
#
# USB support
#
-# CONFIG_USB_ARCH_HAS_HCD is not set
-# CONFIG_USB_ARCH_HAS_OHCI is not set
+CONFIG_USB_ARCH_HAS_HCD=y
+CONFIG_USB_ARCH_HAS_OHCI=y
+# CONFIG_USB is not set
#
-# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
@@ -502,10 +694,15 @@ CONFIG_I2C_MPC=y
# CONFIG_INFINIBAND is not set
#
+# SN Devices
+#
+
+#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
@@ -515,17 +712,16 @@ CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
-
-#
-# XFS support
-#
+# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
@@ -546,12 +742,10 @@ CONFIG_DNOTIFY=y
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=y
-# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
+# CONFIG_RELAYFS_FS is not set
#
# Miscellaneous filesystems
@@ -580,6 +774,7 @@ CONFIG_NFS_FS=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
+CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
@@ -588,6 +783,7 @@ CONFIG_SUNRPC=y
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
#
# Partition Types
@@ -614,6 +810,7 @@ CONFIG_PARTITION_ADVANCED=y
# Library routines
#
# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
@@ -625,7 +822,9 @@ CONFIG_CRC32=y
#
# Kernel hacking
#
+# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
+CONFIG_LOG_BUF_SHIFT=14
# CONFIG_SERIAL_TEXT_DEBUG is not set
#
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
index 79b3f53..98edc75 100644
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -51,6 +51,9 @@
#include <syslib/ppc83xx_setup.h>
+static const char *GFAR_PHY_0 = "phy0:0";
+static const char *GFAR_PHY_1 = "phy0:1";
+
#ifndef CONFIG_PCI
unsigned long isa_io_base = 0;
unsigned long isa_mem_base = 0;
@@ -97,6 +100,7 @@ mpc834x_sys_setup_arch(void)
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
struct gianfar_platform_data *pdata;
+ struct gianfar_mdio_data *mdata;
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -111,24 +115,27 @@ mpc834x_sys_setup_arch(void)
#endif
mpc83xx_early_serial_map();
+ /* setup the board related info for the MDIO bus */
+ mdata = (struct gianfar_mdio_data *) ppc_sys_get_pdata(MPC83xx_MDIO);
+
+ mdata->irq[0] = MPC83xx_IRQ_EXT1;
+ mdata->irq[1] = MPC83xx_IRQ_EXT2;
+ mdata->irq[2] = -1;
+ mdata->irq[31] = -1;
+ mdata->paddr += binfo->bi_immr_base;
+
/* setup the board related information for the enet controllers */
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC83xx_TSEC1);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC83xx_IRQ_EXT1;
- pdata->phyid = 0;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_0;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC83xx_TSEC2);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC83xx_IRQ_EXT2;
- pdata->phyid = 1;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_1;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
diff --git a/arch/ppc/syslib/mpc83xx_devices.c b/arch/ppc/syslib/mpc83xx_devices.c
index dbf8aca..f43fbf9 100644
--- a/arch/ppc/syslib/mpc83xx_devices.c
+++ b/arch/ppc/syslib/mpc83xx_devices.c
@@ -27,18 +27,20 @@
* what IMMRBAR is, will get fixed up by mach_mpc83xx_fixup
*/
+struct gianfar_mdio_data mpc83xx_mdio_pdata = {
+ .paddr = 0x24520,
+};
+
static struct gianfar_platform_data mpc83xx_tsec1_pdata = {
.device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
FSL_GIANFAR_DEV_HAS_MULTI_INTR,
- .phy_reg_addr = 0x24000,
};
static struct gianfar_platform_data mpc83xx_tsec2_pdata = {
.device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
FSL_GIANFAR_DEV_HAS_MULTI_INTR,
- .phy_reg_addr = 0x24000,
};
static struct fsl_i2c_platform_data mpc83xx_fsl_i2c1_pdata = {
@@ -220,6 +222,12 @@ struct platform_device ppc_sys_platform_
},
},
},
+ [MPC83xx_MDIO] = {
+ .name = "fsl-gianfar_mdio",
+ .id = 0,
+ .dev.platform_data = &mpc83xx_mdio_pdata,
+ .num_resources = 0,
+ },
};
static int __init mach_mpc83xx_fixup(struct platform_device *pdev)
diff --git a/arch/ppc/syslib/mpc83xx_sys.c b/arch/ppc/syslib/mpc83xx_sys.c
index 29aa633..da74344 100644
--- a/arch/ppc/syslib/mpc83xx_sys.c
+++ b/arch/ppc/syslib/mpc83xx_sys.c
@@ -24,72 +24,72 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "8349E",
.mask = 0xFFFF0000,
.value = 0x80500000,
- .num_devices = 8,
+ .num_devices = 9,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART, MPC83xx_SEC2,
- MPC83xx_USB2_DR, MPC83xx_USB2_MPH
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH, MPC83xx_MDIO
},
},
{
.ppc_sys_name = "8349",
.mask = 0xFFFF0000,
.value = 0x80510000,
- .num_devices = 7,
+ .num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART,
- MPC83xx_USB2_DR, MPC83xx_USB2_MPH
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH, MPC83xx_MDIO
},
},
{
.ppc_sys_name = "8347E",
.mask = 0xFFFF0000,
.value = 0x80520000,
- .num_devices = 8,
+ .num_devices = 9,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART, MPC83xx_SEC2,
- MPC83xx_USB2_DR, MPC83xx_USB2_MPH
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH, MPC83xx_MDIO
},
},
{
.ppc_sys_name = "8347",
.mask = 0xFFFF0000,
.value = 0x80530000,
- .num_devices = 7,
+ .num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART,
- MPC83xx_USB2_DR, MPC83xx_USB2_MPH
+ MPC83xx_USB2_DR, MPC83xx_USB2_MPH, MPC83xx_MDIO
},
},
{
.ppc_sys_name = "8343E",
.mask = 0xFFFF0000,
.value = 0x80540000,
- .num_devices = 7,
+ .num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART, MPC83xx_SEC2,
- MPC83xx_USB2_DR,
+ MPC83xx_USB2_DR, MPC83xx_MDIO
},
},
{
.ppc_sys_name = "8343",
.mask = 0xFFFF0000,
.value = 0x80550000,
- .num_devices = 6,
+ .num_devices = 7,
.device_list = (enum ppc_sys_devices[])
{
MPC83xx_TSEC1, MPC83xx_TSEC2, MPC83xx_IIC1,
MPC83xx_IIC2, MPC83xx_DUART,
- MPC83xx_USB2_DR,
+ MPC83xx_USB2_DR, MPC83xx_MDIO
},
},
{ /* default match */
diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h
index bb1b057..ce21220 100644
--- a/include/asm-ppc/mpc83xx.h
+++ b/include/asm-ppc/mpc83xx.h
@@ -107,6 +107,7 @@ enum ppc_sys_devices {
MPC83xx_SEC2,
MPC83xx_USB2_DR,
MPC83xx_USB2_MPH,
+ MPC83xx_MDIO,
};
#endif /* CONFIG_83xx */
^ permalink raw reply related
* Re: [PATCH] Fix ppc32 smp build.
From: Paul Mackerras @ 2005-11-07 23:29 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131356850.27347.17.camel@baythorne.infradead.org>
David Woodhouse writes:
> We make no attempt to sync the timebases on quad powersurge, as far as I
> can tell -- and we never set smp_tb_synchronized there.
Hmmm. Does anyone still have one of those? I have a dual but not a
quad.
In any case we can use the generic tbsync code (smp-tbsync.c) which
should work on any machine, and doesn't require any hardware support.
Paul.
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Dan Malek @ 2005-11-08 0:44 UTC (permalink / raw)
To: pantelis.antoniou; +Cc: linuxppc-embedded
In-Reply-To: <200511072250.03217.pantelis.antoniou@gmail.com>
On Nov 7, 2005, at 3:50 PM, Pantelis Antoniou wrote:
> Yep. That should be the target. Remember the poor 8xx is not exactly a
> speed demon :).
It really isn't a big speed difference. The context save/restore
is minimal. The original thought was " ...well, I'm already here,
I know we will take another exception, so may as well fake the
error case and call do_page_fault." However, I really do like
a minimal TLB miss case for valid PTEs, and push everything
else to the heavyweight functions.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Dan Malek @ 2005-11-08 0:46 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded, Joakim Tjernlund, gtolstolytkin
In-Reply-To: <20051107182211.GI3839@smtp.west.cox.net>
On Nov 7, 2005, at 1:22 PM, Tom Rini wrote:
> Assuming Dan doesn't come up with a more simple & better fix, maybe we
> should go back to the original patch I made?
I'm working on it. It'll look more like 2.4.
Thanks.
-- Dan
^ 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