* Re: linux DMA capabilities in MV64460
From: Phil Nitschke @ 2006-03-09 8:02 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-embedded
In-Reply-To: <1141857378.28095.22.camel@localhost.localdomain>
On Wed, 2006-03-08 at 22:36 +0000, Adrian Cox wrote:
> On Mon, 2006-03-06 at 14:39 +1030, Phil Nitschke wrote:
> > How is a DMA controlled (from a device driver writer's perspective) when
> > a third-party (i.e. in the bridge) DMA controller needs to do the work
> > to get the data from a PCI Target into main memory?
> >
> > What kernel API should be provided by the DMA Controller Driver?
>
> There is no current API for this in the kernel, but there are some
> proposals. From Intel, we have I/OAT, which targets network operations:
> http://lkml.org/lkml/2006/3/3/219
>
> There's some overlap with the ADMA feature set, which is intended to
> accelerate RAID operations:
> http://lkml.org/lkml/2006/2/2/442
>
Thanks, Adrian, these are the sorts of APIs I was asking about. At a
quick glance, they look a little "bleeding edge" for my comfort zone.
(And not an exact match for what I'm trying to do...) Nonetheless, I'll
take a closer look at them.
Thanks,
--
Phil Nitschke <Phil.Nitschke@avalon.com.au>
Avalon Systems Pty Ltd
^ permalink raw reply
* Re: Yosemite board ala, PPC405EP
From: Stefan Roese @ 2006-03-09 13:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Jeff.Fellin
In-Reply-To: <440F4DA2.3040706@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
On Wednesday, 8. March 2006 22:33, David Hawkins wrote:
> > Sorry, I was confused. I have a PPC405EP. not a Yosemite board.
>
> Ok, sorry then, I can't help.
>
> Take a look at the Denx web site, they have a bunch of
> BDI2000 configuration files, I'm not sure whether they
> have a 405EP, but take a look.
Yes, we have. Take a look at the attached bubinga config file (AMCC 405EP
evaluation board).
The 405EP is quite different from the 405GP(r) regarding it initialization.
The PLL is setup normally not via strapping pins as on the 405GP(r) but by
reading values from a EEPROM. This can behavior can be configured by one
strapping pin (don't know which one right now). Please take a look at the PLL
setup in the BDI config file.
Best regards,
Stefan
[-- Attachment #2: bubinga.cfg --]
[-- Type: text/plain, Size: 4625 bytes --]
;bdiGDB configuration file for PPChameleonEVB for U-Boot
; ------------------------------------------------------
;
[INIT]
; init core register
WSPR 954 0x00000000 ;DCWR: Disable data cache write-thru
WSPR 1018 0x00000000 ;DCCR: Disable data cache
WSPR 1019 0x00000000 ;ICCR: Disable instruction cache
WSPR 982 0xFFF80000 ;EVPR: Exception Vector Table @0x00000000
;
WDCR 0x0F9 0x08000000
; Setup PLL
; CPU=133MHz
; PLB=133MHz
; OPB=66MHz
; EBC=33MHz
WDCR 0x0F0 0x00001203
WDCR 0x0F4 0x8042223E
; Setup Peripheral Bus
; CS0 (default mode)
WDCR 18 0x00000010 ;Select PB0AP
WDCR 19 0x92015480 ;PB0AP: NOR Flash/SRAM
WDCR 18 0x00000000 ;Select PB0CR
;WDCR 19 0xFFC5A000 ;PB0CR: BAS=0xFFC,BS=4MB,BU=R/W,BW=16bit
WDCR 19 0xFFC58000 ;PB0CR: BAS=0xFFC,BS=4MB,BU=R/W,BW=8bit
WDCR 18 0x00000011 ;Select PB1AP
WDCR 19 0x92015480 ;PB1AP: SRAM/NOR Flash
WDCR 18 0x00000001 ;Select PB1CR
WDCR 19 0xFF85A000 ;PB1CR: BAS=0xFF8,BS=4MB,BU=R/W,BW=16bit
;WDCR 18 0x00000011 ;Select PB1AP
;WDCR 19 0x02815480 ;PB1AP: NVRAM and RTC
;WDCR 18 0x00000001 ;Select PB1CR
;WDCR 19 0xF0018000 ;PB1CR: 1MB at 0xF0000000, r/w, 8bit
;WDCR 18 0x00000012 ;Select PB2AP
;WDCR 19 0x04815A80 ;PB2AP: Keyboard and Mouse
;WDCR 18 0x00000002 ;Select PB2CR
;WDCR 19 0xF0118000 ;PB2CR: 1MB at 0xF0100000, r/w, 8bit
;WDCR 18 0x00000013 ;Select PB3AP
;WDCR 19 0x01815280 ;PB3AP: IRDA
;WDCR 18 0x00000003 ;Select PB3CR
;WDCR 19 0xF0218000 ;PB3CR: 1MB at 0xF0200000, r/w, 8bit
;WDCR 18 0x00000017 ;Select PB7AP
;WDCR 19 0x01815280 ;PB7AP: FPGA
;WDCR 18 0x00000007 ;Select PB7CR
;WDCR 19 0xF0318000 ;PB7CR: 1MB at 0xF0300000, r/w, 8bit
; Setup SDRAM Controller
WDCR 16 0x00000080 ;Select SDTR1
WDCR 17 0x01074015 ;SDTR1: SDRAM Timing Register
WDCR 16 0x00000040 ;Select MB0CF
WDCR 17 0x00084001 ;MB0CF: 16MB @ 0x00000000
WDCR 16 0x00000030 ;Select RTR
WDCR 17 0x07f00000 ;RTR: Refresh Timing Register
WDCR 16 0x00000020 ;Select MCOPT1
WDCR 17 0x80800000 ;MCOPT1: Enable SDRAM Controller
; Setup MMU info - these lines must be uncommented to debug Linux kernel
;WM32 0x000000f4 0x00000000 ;invalidate kernel page table base
;WM32 0x000000f8 0x00000000 ;invalidate process page table base
;WM32 0x000000f0 0xc00000f4 ;invalidate page table base
; Setup OCM
WDCR 0x01A 0xEC000000
WDCR 0x01B 0xC0000000
[TARGET]
JTAGCLOCK 0 ;use 16 MHz JTAG clock
CPUTYPE 405 ;the used target CPU type
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT)
WAKEUP 2000 ;wakeup time after reset
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWPB uses one or two hardware breakpoints
;VECTOR CATCH ;catch unhandled exceptions
;MMU XLAT 0xC0000000 ;enable virtual address mode
;PTBASE 0x000000f0 ;address where kernel/user stores pointer to page table
;SIO 7 9600 ;TCP port for serial IO
;REGLIST SPR ;select register to transfer to GDB
REGLIST ALL ;select register to transfer to GDB
;SCANPRED 2 2 ;JTAG devices connected before PPC400
;SCANSUCC 3 3 ;JTAG devices connected after PPC400
[HOST]
IP 192.168.1.1
FORMAT BIN
FILE /tftpboot/bubinga/u-boot.bin
LOAD MANUAL ;load code MANUAL or AUTO after reset
DEBUGPORT 2001
PROMPT PPC405EP>
[FLASH]
; ###FIXME### - workspace does not work with onchip memory
WORKSPACE 0x100000 ;workspace in on-chip SRAM for fast programming algorithm
; WORKSPACE 0 ;workspace in on-chip SRAM for fast programming algorithm
;CHIPTYPE AM29BX16 ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
;CHIPSIZE 0x400000 ;The size of one flash chip in bytes (e.g. AM29F040 = 0x80000)
;BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32)
CHIPTYPE AM29F ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
CHIPSIZE 0x80000 ;The size of one flash chip in bytes (e.g. AM29F040 = 0x80000)
BUSWIDTH 8 ;The width of the flash memory bus in bits (8 | 16 | 32)
FILE /tftpboot/bubinga/u-boot.bin
FORMAT BIN 0xFFFC0000
; erase whole Flash
;ERASE 0xFFC00000 CHIP
; Erase just the last seven blocks for U-Boot
ERASE 0xFFFC0000
ERASE 0xFFFD0000
ERASE 0xFFFE0000
ERASE 0xFFFF0000
[REGS]
IDCR1 0x010 0x011 ;MEMCFGADR and MEMCFGDATA
IDCR2 0x012 0x013 ;EBCCFGADR and EBCCFGDATA
;IDCR3 0x014 0x015 ;KIAR and KIDR
FILE /tftpboot/BDI2000/reg405ep.def
^ permalink raw reply
* Re: [Patch] Fix compile error for ML300/403
From: Andrei Konovalov @ 2006-03-09 13:33 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, linuxppc-embedded list
In-Reply-To: <528646bc0603081507t24c7e2f5u8e2823931200a857@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> Fix compile error due to changes in ppc_sys.c. This is needed in the
> powerpc.git tree
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ---
> commit 75ec8a6ff8410c30f459e5e1c924ce811f8b1e25
> tree 87f29c44458d2966bf208f9ea25432b26faa2eb5
> parent 126dddf2535520cbeafb7069ce092b80beb8558a
> author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -0700
> committer <grant@weasley-twins.(none)> Wed, 08 Mar 2006 16:03:56 -0700
>
> arch/ppc/platforms/4xx/virtex.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
> index 2a2a65c..4d893ef 100644
> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -27,7 +27,7 @@
> /* Device type enumeration for platform bus definitions */
> #ifndef __ASSEMBLY__
> enum ppc_sys_devices {
> - VIRTEX_UART, VIRTEX_FB,
> + VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
AFAIK there is no VIRTEX_FB in the powerpc.git tree yet.
Otherwise I confirm that adding NUM_PPC_SYS_DEVS is necessary.
Thanks,
Andrei
> };
> #endif
>
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-09 13:51 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1048 bytes --]
Hi,
I'm trying to implement non-coherent DMA for PPC desktop systems (like the
AmigaOne with G3/G4 CPU). For this I want to use the code in
arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
implemented in this file allocates pages with alloc_pages() and maps them to
its own linear address space, but without unmapping the allocated pages from
the kernel linear addressing. Due to this the pages are mapped twice, which
results in a conflict between the different WIMG settings of the pages.
Is there an API that can be used to unmap the allocated pages from the
kernel linear addressing? I thought about using kunmap() and
flush_all_zero_pkmaps(), but I'm not sure if this is the right approach and
HIGHMEM doesn't work on the AmigaOne too (the highmem base is occupied by
the PCI/ISA I/O space!). Wouldn't it be possible to just clear the valid (V)
bit of the PTE and do a TLB cache flush?
Any suggestions?
Thanks!
Regards,
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: [PATCH] Fix platform_notify functions marked __init
From: Mark A. Greer @ 2006-03-09 17:36 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev
In-Reply-To: <1141855821.28095.18.camel@localhost.localdomain>
On Wed, Mar 08, 2006 at 10:10:20PM +0000, Adrian Cox wrote:
> While adding USB support to an MV64360 based board this week, I
> discovered that all MV64x60 boards in the kernel have platform_notify
> functions marked with __init. This causes an oops if a device is added
> after boot.
>
> The patch below removes the __init markers. I do not have all these
> boards to test on, but the change seems very unlikely to break anything
> else.
Arg... I realized this a long time ago and fixed it in my tree.
Somewhere along the line, I dropped it, I guess.
Thanks for the patch Adrian.
Mark
^ permalink raw reply
* System time accuracy
From: Brent Cook @ 2006-03-09 14:57 UTC (permalink / raw)
To: linuxppc-dev
I'm having a puzzling problem. On every 7448-based Linux system that I have
worked on so far, including:
Mac Mini, 1.5 Ghz
Various PMC boards - MV64460 system controller
Freescale HPC II - TSI108 system controller
, the system clock loses approx 1 second every 5 minutes. In fact, I have been
unable to even get NTP to sync these system clocks properly; it just doesn't
adjust fast enough to keep up with the lag, leading to big drifts and adjtimex
just doesn't keep up. Eventually the systems get more than 180 seconds out of
sync and NTP stops trying.
Is this normal behavior, and if so, what have you done to work around it? Is
this a general issue with PPC arch, Linux 2.6 (tried 2.6.11 - 2.6.15), or
specific to the platforms I have tried so far?
Here is the result of running openntpd on a freshly synced system (this
particular one is the HPC II running 2.6.11):
ntpd -sd
192.168.1.1: offset 0.000066 delay 0.000352, next query 5s
reply from 192.168.1.1: offset 0.010422 delay 0.000242, next query 5s
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset 0.020899 delay 0.000256, next query 5s
reply from 192.168.1.1: offset 0.031362 delay 0.000306, next query 5s
reply from 192.168.1.1: offset 0.041838 delay 0.000316, next query 5s
reply from 192.168.1.1: offset 0.052244 delay 0.000226, next query 287s
reply from 192.168.1.1: offset 0.652178 delay 0.000343, next query 30s
adjusting local clock by 0.052244s
reply from 192.168.1.1: offset 0.684853 delay 0.000275, next query 30s
reply from 192.168.1.1: offset 0.725305 delay 0.000257, next query 30s
reply from 192.168.1.1: offset 0.788057 delay 0.000397, next query 30s
reply from 192.168.1.1: offset 0.850732 delay 0.000291, next query 30s
reply from 192.168.1.1: offset 0.913406 delay 0.000233, next query 30s
reply from 192.168.1.1: offset 0.976180 delay 0.000369, next query 30s
reply from 192.168.1.1: offset 1.038846 delay 0.000279, next query 30s
adjusting local clock by 0.913406s
reply from 192.168.1.1: offset 1.071584 delay 0.000309, next query 30s
reply from 192.168.1.1: offset 1.104273 delay 0.000289, next query 30s
reply from 192.168.1.1: offset 1.136919 delay 0.000273, next query 30s
reply from 192.168.1.1: offset 1.169708 delay 0.000342, next query 30s
reply from 192.168.1.1: offset 1.202390 delay 0.000295, next query 30s
reply from 192.168.1.1: offset 1.235082 delay 0.000252, next query 30s
adjusting local clock by 1.235082s
reply from 192.168.1.1: offset 1.267829 delay 0.000320, next query 30s
For comparison, this is an x86 PC doing the same thing:
ntpd -sd
ntp engine ready
reply from 192.168.1.1: offset -0.025448 delay 0.000618, next query 5s
reply from 192.168.1.1: offset -0.025973 delay 0.000285, next query 9s
reply from 192.168.1.1: offset -0.030136 delay 0.000248, next query 5s
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset -0.033057 delay 0.000293, next query 6s
reply from 192.168.1.1: offset -0.036570 delay 0.000321, next query 5s
reply from 192.168.1.1: offset -0.039546 delay 0.000231, next query 5s
reply from 192.168.1.1: offset -0.042481 delay 0.000289, next query 34s
reply from 192.168.1.1: offset -0.062430 delay 0.000264, next query 32s
adjusting local clock by -0.039546s
reply from 192.168.1.1: offset -0.049193 delay 0.000264, next query 307s
reply from 192.168.1.1: offset -0.052205 delay 0.000299, next query 307s
reply from 192.168.1.1: offset -0.078816 delay 0.000284, next query 309s
reply from 192.168.1.1: offset -0.010273 delay 0.000336, next query 326s
reply from 192.168.1.1: offset -0.038518 delay 0.000279, next query 323s
reply from 192.168.1.1: offset -0.066434 delay 0.000314, next query 312s
adjusting local clock by -0.049193s
Now, none of these PPC systems has /dev/rtc (the x86 does), but that should
not matter, since the real-time clock is usually used in Linux a boot or
shutdown.
^ permalink raw reply
* Re: Virtex-4 TEMAC device driver available?
From: Yoshio Kashiwagi @ 2006-03-09 18:10 UTC (permalink / raw)
To: S. Egbert, linuxppc-embedded
In-Reply-To: <JS200602192039433.11799406@co-nss.co.jp>
Hello Steve San,
Although I was performing porting for the reference design of
xapp902 shown in the following URL, I have noticed that the
temac circuit of this xapp902 cannot perform control of PHY.
The temac circuit of this xapp902 does not have control of PHY.
http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
As a result of consulting with our client, our client newly
creates their original temac based on xapp807 design of the
following URL. It is because the function is insufficient
using Linux in this xapp897 design.
http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf
Since I created the temac driver of their design, the release
of the driver to ML became impossible to me.
Best Regaeds,
Yoshio kashiwagi - Nissin Systems
> Hello Steve San,
>
> Strictly, GSRD differs from TEMAC.
> Although both are embedded TEMAC is used in Virtex4, GSRD accesses
> direct memory through MPMC. MPMC is a multi-port memory controller
> for GSRD to access direct memory.
>
> http://www.xilinx.com/esp/wired/optical/xlnx_net/gsrd_download.htm
>
> Download of GSRD is linked out of the above-mentioned URL, and
> becomes a place to be logged in (Registration for downloading the
> reference design short cut).
> http://www.xilinx.com/xlnx/xil_entry2.jsp?sMode=login&group=gsrd
>
> Linux2.4 driver is contained in this GSRD. However, this Linux2.4
> driver (adapter.c) has the fault which does not operate correctly,
> when a 100BASE hub is connected. In order to correct this problem,
> it is necessary to add the interrupt handling routine of PHY.
> Although this GSRD is a reference design more nearly high-speed
> than TEMAC, many FPGA resources are used for it.
>
> I am going to create a TEMAC driver (Linux2.6) by a scratch, I
> cannot make time for it now. Since it is due to make by the end of
> this month, if it is completed, I'll announce it to this mailing
> list.
>
> I'll write the Linux2.6 TEMAC driver corresponding to the following
> reference designs.
> http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
> http://www.xilinx.com/bvdocs/appnotes/xapp902.zip
> (The Linux driver is not contained in this reference design)
>
> Best Regards,
>
> Yoshio Kashiwagi - Nissin Systems
>
> > Dear Kashiwagi-San,
> >
> > I noticed in your posting over at linuxppc-embedded in Jan 2006
about
> a
> > Xilinx demo code for the TEMAC driver.
> >
> > So, I pulled the
> > http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip file and
> > browsed it.
> >
> > Do you know where one can get a patch for Linux 2.4?
> >
> > Thank you,
> >
> > Steve Egbert
> >
> > --
> > -----BEGIN GEEK CODE BLOCK-----
> > Version: 3.12
> > GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
> > O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
> > G++ e* h++ r+++ z
> > ------END GEEK CODE BLOCK------
> > GPG Public Key: http://www.egbert.net/pgp
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
------------------------------------------------------------
柏木良夫
株式会社日新システムズ 基礎技術部
Linuxプロフェショナルグループ
〒600-8482 京都市下京区堀川通四条下ル東側 堀川四条ビル
TEL 075-344-7950 FAX 075-344-7887
E-Mail kashiwagi@co-nss.co.jp HTTP http://www.co-nss.co.jp/
------------------------------------------------------------
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-09 22:11 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <15153.1141912297@www026.gmx.net>
On Thu, 2006-03-09 at 14:51 +0100, Gerhard Pircher wrote:
> Hi,
>
> I'm trying to implement non-coherent DMA for PPC desktop systems (like the
> AmigaOne with G3/G4 CPU). For this I want to use the code in
> arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
> implemented in this file allocates pages with alloc_pages() and maps them to
> its own linear address space, but without unmapping the allocated pages from
> the kernel linear addressing. Due to this the pages are mapped twice, which
> results in a conflict between the different WIMG settings of the pages.
>
> Is there an API that can be used to unmap the allocated pages from the
> kernel linear addressing? I thought about using kunmap() and
> flush_all_zero_pkmaps(), but I'm not sure if this is the right approach and
> HIGHMEM doesn't work on the AmigaOne too (the highmem base is occupied by
> the PCI/ISA I/O space!). Wouldn't it be possible to just clear the valid (V)
> bit of the PTE and do a TLB cache flush?
The main problem is that the mappings may be covered by a BAT and thus
pages may not be unmappable individually...
What I would suggest is that your dig in the low level RAM mapping code
and limit it at boot to RAM minus a pool of the size you want.
Ben.
^ permalink raw reply
* Re: [Patch] Fix compile error for ML300/403
From: Grant Likely @ 2006-03-10 6:36 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Paul Mackerras, linuxppc-embedded list
In-Reply-To: <44102EB3.2000301@ru.mvista.com>
On 3/9/06, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> > diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/v=
irtex.h
> > index 2a2a65c..4d893ef 100644
> > --- a/arch/ppc/platforms/4xx/virtex.h
> > +++ b/arch/ppc/platforms/4xx/virtex.h
> > @@ -27,7 +27,7 @@
> > /* Device type enumeration for platform bus definitions */
> > #ifndef __ASSEMBLY__
> > enum ppc_sys_devices {
> > - VIRTEX_UART, VIRTEX_FB,
> > + VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
>
> AFAIK there is no VIRTEX_FB in the powerpc.git tree yet.
> Otherwise I confirm that adding NUM_PPC_SYS_DEVS is necessary.
heh, oops. yeah, I've got the FB driver in my local tree. Fixed
patch attached...
-----
[patch] Fix compile error for ML300/403.
Due to changes in ppc_sys.c. This is needed in Paul's powerpc.git tree
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
commit 60a9fb927e8f68d307339e6e268452d2c62b717f
tree e62d99cb4fa697d8d59af2a3ab063e050ba6ca99
parent 6749c5507388f3fc3719f57a54b540ee83f6661a
author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -=
0700
committer <grant@weasley-twins.(none)> Thu, 09 Mar 2006 23:30:38 -0700
arch/ppc/platforms/4xx/virtex.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virte=
x.h
index 1a01b81..c14325d 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -27,7 +27,7 @@
/* Device type enumeration for platform bus definitions */
#ifndef __ASSEMBLY__
enum ppc_sys_devices {
- VIRTEX_UART,
+ VIRTEX_UART, NUM_PPC_SYS_DEVS,
};
#endif
^ permalink raw reply related
* Re: Stable Linux kernel 2.6 for MPC8XX
From: David Jander @ 2006-03-10 7:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D02CABEE3@rennsmail02.eu.thmulti.com>
On Wednesday 08 March 2006 15:29, Fillod Stephane wrote:
> >I would want to use a linux kernel 2.6 on a custom MPC8xx board.
> >Which stable kernel release must or can I use ?
>
> http://www.denx.de/wiki/bin/view/Know/Linux24vs26
I believe most of those observations and measurements are not valid anymore.
Kernel 2.6 for 8xx has come a long way since this article was written. It
might have been true back then, but it surely isn't anymore.
Kernel 2.6 is bigger than 2.4, that's a fact, but application performance is
actually slightly higher with 2.6.14 than it is with 2.4.25.
The overall robustness and "niceness" of the code is also a totally different
story now. 2.6 software architecture is definitely better, and many drivers
are much more stable. Implementing board support and drivers in 2.6 is also
much easier and cleaner than in 2.4.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: kernel 2.6.15-rc5-latest doesn't work anymore on mpc8540ads
From: Carlos Mitidieri @ 2006-03-10 7:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0512191437460.4403-100000@gate.crashing.org>
Hi,
Has the knowledge about this issue advanced?
What I have noticed so far is that the same happens in 2.6.14, therefore the
problem rose in the transition from 2.6.13.
Would this be related to the IRQ stuff initialization? Any guess?
On Monday 19 December 2005 21:38, Kumar Gala wrote:
> On Mon, 19 Dec 2005, Clemens Koller wrote:
> > Hello!
> >
> > Here is a little update:
> > > I am just about to update my kernel from 2.6.13-rc7 which is working
> > > fine to linus' 2.6.15-rc5-latest git on my mpc8540ads flavored board.
> > > However, the kernel hangs pretty early after
> > >
> > > openpic: exit
> >
> > openpic_init() is called by mpc85xx_ads_init_IRQ in ppc/platforms/85xx
> >
> > ppc_md.init_IRQ=mpc85xx_ads_init_IRQ in ppc/platforms/85xx
> >
> > ppc_md.init_IRQ() is called from powerpc/kernel/irq.c
> >
> > init_IRQ() is called from init/main.c:start_kernel()
> >
> > and that seems to work fine. So, it crashes silently somewhere
> > after that point. I try to build 2.6.15-rc6-latest with kgbd support,
> > not knowing if it's supposed to work on this platform.
>
> It was a guess :)
>
> > Are there some open issues from the ppc->powerpc migration?
>
> possible, can you use git bisect to find what commit may have caused the
> issue?
>
> - kumar
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Carlos Mitidieri
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-10 9:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1141942301.3603.12.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Unmapping pages from the linear addressing without
> HIGHMEM support
> Datum: Fri, 10 Mar 2006 09:11:41 +1100
>
> On Thu, 2006-03-09 at 14:51 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I'm trying to implement non-coherent DMA for PPC desktop systems (like
> > the AmigaOne with G3/G4 CPU). For this I want to use the code in
> > arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
> > implemented in this file allocates pages with alloc_pages() and maps
> > them to its own linear address space, but without unmapping the
> > allocated pages from the kernel linear addressing. Due to this the
> > pages are mapped twice, which results in a conflict between the
> > different WIMG settings of the pages.
> >
> > Is there an API that can be used to unmap the allocated pages from the
> > kernel linear addressing? I thought about using kunmap() and
> > flush_all_zero_pkmaps(), but I'm not sure if this is the right approach
> > and HIGHMEM doesn't work on the AmigaOne too (the highmem base is
> > occupied by the PCI/ISA I/O space!). Wouldn't it be possible to just
> > clear the valid (V) bit of the PTE and do a TLB cache flush?
>
> The main problem is that the mappings may be covered by a BAT and thus
> pages may not be unmappable individually...
>
> What I would suggest is that your dig in the low level RAM mapping code
> and limit it at boot to RAM minus a pool of the size you want.
That would mean I cannot reuse the code in dma-mapping.c, right? Killing the
BAT mappings or limiting the memory size covered by the BATs seems to be
fairly easy, but I guess I have to setup my own page table for the reserved
DMA memory area and implement my own alloc_pages() function!?
Thanks!
Gerhard
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: kernel 2.6.15-rc5-latest doesn't work anymore on mpc8540ads
From: Carlos Mitidieri @ 2006-03-10 11:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43A6ED1E.20506@anagramm.de>
Hi,
The kernel actually hangs when schedule() is called in rest_init() in main.c
Would someone risk a guess ?
(keeping the walk...) Thanks,
On Monday 19 December 2005 18:25, Clemens Koller wrote:
> Hello!
>
> Here is a little update:
> > I am just about to update my kernel from 2.6.13-rc7 which is working
> > fine to linus' 2.6.15-rc5-latest git on my mpc8540ads flavored board.
> > However, the kernel hangs pretty early after
> >
> > openpic: exit
>
> openpic_init() is called by mpc85xx_ads_init_IRQ in ppc/platforms/85xx
>
> ppc_md.init_IRQ=mpc85xx_ads_init_IRQ in ppc/platforms/85xx
>
> ppc_md.init_IRQ() is called from powerpc/kernel/irq.c
>
> init_IRQ() is called from init/main.c:start_kernel()
>
> and that seems to work fine. So, it crashes silently somewhere
> after that point. I try to build 2.6.15-rc6-latest with kgbd support,
> not knowing if it's supposed to work on this platform.
>
> Are there some open issues from the ppc->powerpc migration?
>
> Thanks,
--
Best regards,
Carlos Mitidieri
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Dan Malek @ 2006-03-10 12:59 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <22544.1141981797@www088.gmx.net>
On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
> That would mean I cannot reuse the code in dma-mapping.c, right?
Sure you can. All you need to do is turn of BAT mapping, which
is as easy as using the 'nobats' command line parameter and
all of this code should just work for you.
> ... but I guess I have to setup my own page table for the reserved
> DMA memory area and implement my own alloc_pages() function!?
No, that's already done for you behind all of these functions.
Thanks.
-- Dan
^ permalink raw reply
* Re: Stable Linux kernel 2.6 for MPC8XX
From: Dan Malek @ 2006-03-10 13:16 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603100822.42764.david.jander@protonic.nl>
On Mar 10, 2006, at 2:22 AM, David Jander wrote:
> I believe most of those observations and measurements are not valid
> anymore.
> Kernel 2.6 for 8xx has come a long way since this article was written.
They are still valid, we just have more knowledge about how to
configure the kernels and have added some features you can
use to mitigate the performance issues. The Linux 2.6 kernel
is simply bigger than 2.4, and on these small, resource challenged
processors, you need to very carefully configure the kernels to
your requirements.
Thanks.
-- Dan
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-10 13:31 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
In-Reply-To: <31042.1141997321@www088.gmx.net>
> --- Ursprüngliche Nachricht ---
> Von: Dan Malek <dan@embeddedalley.com>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> Kopie: debian-powerpc@lists.debian.org, linuxppc-dev@ozlabs.org, Benjamin
> Herrenschmidt <benh@kernel.crashing.org>
> Betreff: Re: Unmapping pages from the linear addressing without
> HIGHMEM support
> Datum: Fri, 10 Mar 2006 07:59:33 -0500
>
> On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
>
> Sure you can. All you need to do is turn of BAT mapping, which
> is as easy as using the 'nobats' command line parameter and
> all of this code should just work for you.
Yes, that was the solution I would have used. The other solution is to
reserve a physical memory area for DMA operations that is not mapped by the
BATs (AFAIU nor by any page tables setup by the kernel). Therefore I doubt
that I can simply reuse the dma-mapping.c code for the latter approach!? Do
I mix something up here?
> > ... but I guess I have to setup my own page table for the reserved
> > DMA memory area and implement my own alloc_pages() function!?
>
> No, that's already done for you behind all of these functions.
But only, if the whole BAT mapping is killed, right?
Thanks!
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: Stable Linux kernel 2.6 for MPC8XX
From: Wolfgang Denk @ 2006-03-10 15:33 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603100822.42764.david.jander@protonic.nl>
In message <200603100822.42764.david.jander@protonic.nl> you wrote:
> >
> > http://www.denx.de/wiki/bin/view/Know/Linux24vs26
>
> I believe most of those observations and measurements are not valid anymore.
> Kernel 2.6 for 8xx has come a long way since this article was written. It
> might have been true back then, but it surely isn't anymore.
So did you actually run any benchmarks? Specilations on what might be
or should be are not really helpful.
> Kernel 2.6 is bigger than 2.4, that's a fact, but application performance is
> actually slightly higher with 2.6.14 than it is with 2.4.25.
What says lmbench on your system? Can you please show actual data?
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
...when fits of creativity run strong, more than one programmer or
writer has been known to abandon the desktop for the more spacious
floor. - Fred Brooks, Jr.
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-10 17:10 UTC (permalink / raw)
To: linuxppc
In-Reply-To: <200603080938.35299.david.jander@protonic.nl>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Wed, 2006-03-08 at 09:38 +0100, David Jander wrote:
>
> Thanks to all for the suggestions.
> Is "cleanmark" an open-source tool?
well, I think so, as it's a minimal modified flash_eraseall.c from mtd
> Would you share it?
sure, a gzipped version is attached. Put it in the mtd/util directory
and add it to the Makefile there (to TARGETS) and:
cleanmark: crc32.o cleanmark.o
$(CC) $(LDFLAGS) -o $@ $^
best regards,
Jaap-Jan
>
> Greetings,
>
> --
> David Jander
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: cleanmark.c.gz --]
[-- Type: application/x-gzip, Size: 2567 bytes --]
^ permalink raw reply
* Re: 440gx dma transfer with no data change at dest
From: Kevin Kleinosowski @ 2006-03-10 22:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0603071505110.21479@mohave.arlut.utexas.edu>
Maybe this is too much. Has anyone successfully done a memory-to-memory
DMA transfer with the 2.4.27 kernel routines in
arch/ppc/kernel/ppc4xx_dma.c on any ppc embedded platform? If you have,
are you willing to share a bit of code example, or look at one?
#define MEM_BUF_SIZE_ORDER 4
#define MEM_BUF_SIZE_BYTES 65536UL
#define EBC0_DMA_CHANNEL 1
#define DMA_SR_CS_SET 0x80000000
unsigned long interruptFlags;
ppc_dma_ch_t channelSetup;
int dmaStatus;
u32 src, dst;
src = __get_dma_pages (GFP_KERNEL, MEM_BUF_SIZE_ORDER);
memset ((char *)src, 0xFF, MEM_BUF_SIZE_BYTES);
dst = __get_dma_pages (GFP_KERNEL, MEM_BUF_SIZE_ORDER);
memset ((char *)dst, 0x00, MEM_BUF_SIZE_BYTES);
memset (&channelSetup, 0, sizeof (ppc_dma_ch_t));
interruptFlags = claim_dma_lock ();
ppc4xx_get_channel_config (EBC0_DMA_CHANNEL, &channelSetup);
channelSetup.buffer_enable = 1;
channelSetup.tce_enable = 1;
channelSetup.etd_output = 1;
channelSetup.pce = 0;
channelSetup.pl = 1;
channelSetup.pwidth = PW_32;
channelSetup.sai = 1;
channelSetup.dai = 1;
channelSetup.psc = 0;
channelSetup.pwc = 0;
channelSetup.phc = 0;
channelSetup.cp = PRIORITY_LOW;
channelSetup.pf = PREFETCH_1;
channelSetup.int_enable = 1;
channelSetup.mode = DMA_MODE_MM;
ppc4xx_init_dma_channel (EBC0_DMA_CHANNEL, &channelSetup);
ppc4xx_enable_dma_interrupt (EBC0_DMA_CHANNEL);
ppc4xx_disable_dma (EBC0_DMA_CHANNEL);
ppc4xx_set_src_addr (EBC0_DMA_CHANNEL, virt_to_bus((u32 *)src));
ppc4xx_set_dst_addr (EBC0_DMA_CHANNEL, virt_to_bus((u32 *)dst));
ppc4xx_set_dma_count (EBC0_DMA_CHANNEL, MEM_BUF_SIZE_BYTES);
ppc4xx_enable_dma (EBC0_DMA_CHANNEL);
release_dma_lock (interruptFlags);
dmaStatus = ppc4xx_get_dma_status ();
while ((dmaStatus & (DMA_SR_CS_SET >> EBC0_DMA_CHANNEL)) !=
(DMA_SR_CS_SET >> EBC0_DMA_CHANNEL)) {
printk ("DMA STATUS: 0x%8.8x\n", dmaStatus);
set_current_state (TASK_INTERRUPTIBLE);
schedule_timeout (HZ/4);
dmaStatus = ppc4xx_get_dma_status ();
}
The result dst was initialed to 0x00 but the transfer should have put
it all to 0xff. However most locations are 0xff, and some locations are
0x00. There seems to be no pattern to it. Sometimes all locations of dst
have 0xff.
Anyone see anything wrong?
Kevin
On Tue, 7 Mar 2006, Kevin Kleinosowski wrote:
>
> I am running a simple test with a software initiated DMA transfer from one
> bigphysarea allocated buffer to another bigphysarea allocated buffer. The
> destination buffer shows no data changes once the transfer is done.
>
> However, I perform the same simple test using __get_dma_pages() rather then
> the bigphysarea_alloc_pages() and the destination does get the data transfer.
>
> Is there a reason this should fail for bigphysarea? I understand the low
> memory addresses needed for the DMA controller on some platforms, but I didnt
> think that limitation existed on the PPC. Besides that, the bigphysarea
> returns low memory address anyway. Anyone have an idea why? An old archive
> email had someone with a similar problem, but there were no follow-ups to the
> message.
>
> I have linux 2.4.27-pre3 patched, ppc-linux-gcc (GCC) 3.3.3 (DENX ELDK 3.1.1
> 3.3.3-9), U-Boot 1.1.2, and GMS 440gx board.
>
> thanks,
> Kevin
>
>
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-10 23:12 UTC (permalink / raw)
To: Dan Malek; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <051c9d8f422b0e5289b7083367cf44ca@embeddedalley.com>
On Fri, 2006-03-10 at 07:59 -0500, Dan Malek wrote:
> On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
>
> Sure you can. All you need to do is turn of BAT mapping, which
> is as easy as using the 'nobats' command line parameter and
> all of this code should just work for you.
And the kernel will blow up in flames under various funny circumstances
and you'll lose a fair amount of performances.
The 6xx kernel requires at least the IBAT mapping the kernel text. Some
of the exception handling code path can't deal with getting a hash fault
at critical locations (they can mostly deal with data hash misses
nowadays, but the code has to be accessible at all times).
> > ... but I guess I have to setup my own page table for the reserved
> > DMA memory area and implement my own alloc_pages() function!?
>
> No, that's already done for you behind all of these functions.
>
> Thanks.
>
> -- Dan
>
>
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-10 23:13 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <22544.1141981797@www088.gmx.net>
> That would mean I cannot reuse the code in dma-mapping.c, right? Killing the
> BAT mappings or limiting the memory size covered by the BATs seems to be
> fairly easy, but I guess I have to setup my own page table for the reserved
> DMA memory area and implement my own alloc_pages() function!?
No, just limit the size of the BAT mapping and mark some of the top
pages of the address space reserved... That should be enough.
Ben.
^ permalink raw reply
* Re: Help: How to search for previous topics
From: wang dengyi @ 2006-03-11 10:29 UTC (permalink / raw)
To: linuxppc-embedded
I have the same question too. I use google to search
it, like this: mpc860 site:ozlabs.org
But I am wondering, is there a better way? I suspect
that google may miss something, especialy when
searching with multiply words.
Best regards,
Dengyi Wang
Krishnan wrote:
>Hello,
>
>Could anyone please tell me how previous topics could
be searched so that I
>don't
>need to trouble anyone for repetitive content?
>
>I only know of one way today, go through each list
and try to do a Ctrl+F
>which is quite
>painful.
>
>Cheers,
>Kris
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-11 13:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1142032411.4057.31.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Unmapping pages from the linear addressing
> without HIGHMEM support
> Datum: Sat, 11 Mar 2006 10:13:30 +1100
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
> > Killing the BAT mappings or limiting the memory size covered by the
> > BATs seems to be fairly easy, but I guess I have to setup my own page
> > table for the reserved DMA memory area and implement my own
> > alloc_pages() function!?
>
> No, just limit the size of the BAT mapping and mark some of the top
> pages of the address space reserved... That should be enough.
>
Okay, I will try that first. Marking some of the pages as reserved sounds
like the code you implemented for the uninorth_agp driver with this
"agp_special_page". I guess I still have to modify the code in dma_mapping.c
to use the reserved address space for the consistent memory allocation
(CONSISTENT_BASE, CONSISTENT_END)?
Thanks again!
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: SCCx UART status on 8xx
From: Marcelo Tosatti @ 2006-03-11 22:17 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho
Cc: fbl, Björn Östby, linuxppc-embedded
In-Reply-To: <20060220141830.GA7228@oops.ghostprotocols.net>
Aris,
Can you please prepare a detailed description of what the
patch is doing and why?
Thanks
On Mon, Feb 20, 2006 at 11:18:35AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
> @@ -139,24 +139,31 @@
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFFFC0;
> pinfo->brg = 1;
> }
>
> void scc2_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC2: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFC0FF;
> + cpmp->cp_sicr |= 0x00000900;
> pinfo->brg = 2;
> }
>
> void scc3_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC3: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFC0FFFF;
> + cpmp->cp_sicr |= 0x00140000;
> pinfo->brg = 3;
> }
>
> void scc4_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC4: insert port configuration here */
> + cpmp->cp_sicr &= 0xC0FFFFFF;
> + cpmp->cp_sicr |= 0x1BFFFFFF;
> pinfo->brg = 4;
> }
>
> Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
> @@ -467,6 +467,7 @@
> /* free interrupt handler */
> free_irq(port->irq, port);
>
> +#if 0
> /* If the port is not the console, disable Rx and Tx. */
> if (!(pinfo->flags & FLAG_CONSOLE)) {
> /* Wait for all the BDs marked sent */
> @@ -492,6 +493,7 @@
> /* Shut them really down */
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> }
> +#endif
> }
>
> static void cpm_uart_set_termios(struct uart_port *port,
> @@ -896,7 +898,7 @@
> pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
> }
>
> - ret = cpm_uart_allocbuf(pinfo, 0);
> + ret = cpm_uart_allocbuf(pinfo, 1);
>
> if (ret)
> return ret;
> @@ -912,10 +914,12 @@
>
> static void cpm_uart_release_port(struct uart_port *port)
> {
> +#if 0
> struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
>
> if (!(pinfo->flags & FLAG_CONSOLE))
> cpm_uart_freebuf(pinfo);
> +#endif
> }
>
> /*
^ permalink raw reply
* [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Olaf Hering @ 2006-03-11 21:58 UTC (permalink / raw)
To: Paul Mackeras, Benjamin Herrenschmidt, linuxppc-dev, linux-kernel
commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
Only enable powersave_nap in one place: probe_motherboard()
ppc32 gets nap if the cpu supports it
ppc32 smp gets no nap
ppc64 gets nap unconditionally
---
arch/powerpc/platforms/powermac/feature.c | 8 +++++++-
arch/powerpc/platforms/powermac/setup.c | 4 ----
arch/powerpc/platforms/powermac/smp.c | 4 ----
3 files changed, 7 insertions(+), 9 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/feature.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
@@ -2513,8 +2513,11 @@ found:
/* Nap mode not supported if flush-on-lock property is present */
if (get_property(np, "flush-on-lock", NULL))
break;
+
+#ifndef CONFIG_SMP
+ /* 32 bits SMP can't NAP */
powersave_nap = 1;
- printk(KERN_INFO "Processor NAP mode on idle enabled.\n");
+#endif
break;
}
@@ -2526,6 +2529,9 @@ found:
#ifdef CONFIG_POWER4
powersave_nap = 1;
#endif
+ if (powersave_nap)
+ printk(KERN_INFO "Using native/NAP idle loop\n");
+
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
|| strncmp(model, "iBook", 5) == 0))
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
@@ -621,10 +621,6 @@ static void __init pmac_init_early(void)
/* Probe motherboard chipset */
pmac_feature_init();
- /* We can NAP */
- powersave_nap = 1;
- printk(KERN_INFO "Using native/NAP idle loop\n");
-
/* Initialize debug stuff */
udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/smp.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
@@ -739,10 +739,6 @@ static void __init smp_core99_setup(int
smp_hw_index[i] = i;
}
#endif
-
- /* 32 bits SMP can't NAP */
- if (!machine_is_compatible("MacRISC4"))
- powersave_nap = 0;
}
static int __init smp_core99_probe(void)
^ 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