* Re: [PATCH 3/3] powerpc: Use PPC_LONG and PPC_LONG_ALIGN in lib/string.S
From: Kumar Gala @ 2008-07-17 12:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <27c8ac7aceccaf7856c65f2ef1305321f94d564e.1216279070.git.michael@ellerman.id.au>
On Jul 17, 2008, at 2:17 AM, Michael Ellerman wrote:
> No change to the generated code.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/lib/string.S | 18 ++++++------------
> 1 files changed, 6 insertions(+), 12 deletions(-)
What's the reason for the change?
- k
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Use PPC_LONG_ALIGN in uaccess.h
From: Kumar Gala @ 2008-07-17 12:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <2e3c13ddbf80969f086c92f40b1ca6cf891a738f.1216279070.git.michael@ellerman.id.au>
On Jul 17, 2008, at 2:17 AM, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> include/asm-powerpc/uaccess.h | 21 +++++++++------------
> 1 files changed, 9 insertions(+), 12 deletions(-)
What's the reason for the change?
- k
^ permalink raw reply
* Re: [PATCH 4/6] crypto: talitos - fix GFP flag usage
From: Kumar Gala @ 2008-07-17 12:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: linuxppc-dev, linux-crypto
In-Reply-To: <20080717121758.GA25267@gondor.apana.org.au>
On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
> On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
>>
>> On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
>>
>>> use GFP_ATOMIC when necessary; use atomic_t when allocating
>>> submit_count.
>>
>> why?
>
> You mean why are atomics required? Yes that is a good question.
Yep. the commit message isn't explaining why, just what :)
> Kim?
- k
^ permalink raw reply
* Re: [PATCH 4/6] crypto: talitos - fix GFP flag usage
From: Herbert Xu @ 2008-07-17 12:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-crypto
In-Reply-To: <BDCB5191-EEDE-4046-A741-80E6EF1333CF@kernel.crashing.org>
On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
>
> On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
>
> >use GFP_ATOMIC when necessary; use atomic_t when allocating
> >submit_count.
>
> why?
You mean why are atomics required? Yes that is a good question.
Kim?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/6] crypto: talitos - remove calls to of_node_put
From: Herbert Xu @ 2008-07-17 12:17 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, linux-crypto
In-Reply-To: <20080716182146.0b095f5d.kim.phillips@freescale.com>
On Wed, Jul 16, 2008 at 06:21:46PM -0500, Kim Phillips wrote:
> From: Lee Nipper <lee.nipper@freescale.com>
>
> Remove of_node_put calls since there is no corresponding of_node_get.
> This patch prevents an exception when talitos is loaded a 2nd time.
> This sequence: modprobe talitos; rmmod talitos; modprobe talitos
> causes this message: "WARNING: Bad of_node_put() on /soc8349@e0000000/crypto@30000".
>
> Signed-off-by: Lee Nipper <lee.nipper@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
All applied to crpyto-2.6. Thanks!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Videomode 800x480
From: Alex_SYS @ 2008-07-17 12:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <487F307C.50706@denx.de>
Hello, I`m doing video=3D0x0... to letFB_find_mode use my default video!
Yes I give you my vfb.c and .config! Thanks very much!
I found that only changing the linelength, the visible resolution changes
too.
=20
Anatolij Gustschin wrote:
>=20
> Alex_SYS wrote:
>>=20
>> Alex_SYS wrote:
>>> <Here is the Kernel Bootup message that it gives when it crashes!
>>>
>>> U-Boot 1.2.0-mpc5200b-tiny-3 (Dec 11 2007 - 11:25:01)
>>>
>>> CPU: MPC5200 v2.2, Core v1.4 at 399.999 MHz
>>> Bus 133 MHz, IPB 133 MHz, PCI 33 MHz
>>> Board: phyCORE-MPC5200B-tiny
>>> I2C: ready
>>> DRAM: 64 MB
>>> SP: 0x03f73768
>>> FLASH: 16 MB
>>> Using pcm030 machine description
>>> Linux version 2.6.23.1-rt5-pcm030-1trunk (aschmid@LINUX) (gcc version
>>> 4.1.2) #39
>>> 4 PREEMPT RT Tue Dec 11 17:58:48 CET 2007
>>> Zone PFN ranges:
>>> DMA 0 -> 16384
>>> Normal 16384 -> 16384
>>> Movable zone start PFN for each node
>>> early_node_map[1] active PFN ranges
>>> 0: 0 -> 16384
>>> Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
>>> Built 1 zonelists in Zone order. Total pages: 16256
>>> Kernel command line: video=3D0x0-16@60 , console=3DttyPSC0,115200
> ----------------------------->^^^^^^^^^
> is this intentional?
>=20
>>> mtdparts=3Dphysmap-f
>>> lash.0:256k(ubootl),1792k(kernel),13312k(jffs2),256k(uboot)ro,256k(oftr=
ee),-(spa
>>> ce) rw root=3D/dev/mtdblock2 rootfstype=3Djffs2
>>> WARNING: experimental RCU implementation.
>>> MPC52xx PIC is up and running!
>>> PID hash table entries: 256 (order: 8, 1024 bytes)
>>> Console: colour dummy device 80x25
>>> console [ttyPSC0] enabled
>>> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>>> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
>>> Memory: 61960k/65536k available (2624k kernel code, 3508k reserved, 144=
k
>>> data, 1
>>> 06k bss, 124k init)
>>> Mount-cache hash table entries: 512
>>> NET: Registered protocol family 16
>>> PCI: Probing PCI hardware
>>> DMA: MPC52xx BestComm driver
>>> DMA: MPC52xx BestComm engine @f0001200 ok !
>>> Generic PHY: Registered new driver
>>> usbcore: registered new interface driver usbfs
>>> usbcore: registered new interface driver hub
>>> usbcore: registered new device driver usb
>>> NET: Registered protocol family 2
>>> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>>> TCP established hash table entries: 2048 (order: 4, 73728 bytes)
>>> TCP bind hash table entries: 2048 (order: 3, 57344 bytes)
>>> TCP: Hash tables configured (established 2048 bind 2048)
>>> TCP reno registered
>>> JFFS2 version 2.2. (NAND) =C3=82=C2=A9 2001-2006 Red Hat, Inc.
>>> io scheduler noop registered (default)
>>> No Options from U-Boot
>>> Lime Driver PROBE
>>> No Mode
>>> Name des Strings 0x0-16@60 with L=C3=83=C2=A4nge 9
>>> Schleife mode Options
>>> Schleife @
>>> Schleife -
>>> Schleife x
>>> DONE vor CVT xres=3D 0 , yres=3D0 , cvt=3D
>>> 0******************************************
>>> ************CVT Mode: Trying specified video mode 0x0
>>> Trying mode 800x480-16@60 800x600-16@20
>>> Error=3D
>>> 0********************************************************************Tr=
yi
>>> ng mode noname 640x400-16@70
>>> Error=3D
>>> 0********************************************************************Tr=
yi
>>> ng mode noname 640x480-16@60
>>> Error=3D
>>> 0********************************************************************Tr=
yi
>>> ng mode noname 800x600-16@56
>=20
> What arguments do you pass to fb_find_mode() in the driver? Probing all o=
f
> these modes is not necessary.
> =20
> <snip>
>>> Error=3D
>>> 0********************************************************************Tr=
yi
>>> ng default video mode
>>> Trying mode noname 800x480-16@60
>>> Error=3D
>>> 0********************************************************************Tr=
yi
>>> ng default mode
>>> Console: switching to colour frame buffer device 114x34
>>> stopped custom tracer.
>>> Oops: Exception in kernel mode, sig: 4 [#1]
>>> PREEMPT pcm030
>>> Modules linked in:
>>> NIP: 00000900 LR: c011d94c CTR: c011daf4
>>> REGS: c3fe7a30 TRAP: 0700 Not tainted (2.6.23.1-rt5-pcm030-1trunk)
>>> MSR: 00081000 <ME> CR: 42042022 XER: 00000000
>>> TASK =3D c3fe5c00[1] 'swapper' THREAD: c3fe6000
>>> GPR00: ffffffff c3fe7ae0 c3fe5c00 c5128bfc 00000000 00010001 00000020
>>> 00000020
>>> GPR08: 00000000 00010001 ffffffff 00000020 c3f5f800 fffffffb 03fcb000
>>> ffffffff
>>> GPR16: 00000001 00000000 c3fe7f78 c024a748 00000000 00000000 00000002
>>> 000001e0
>>> GPR24: 00010001 c011daf4 00000020 c3f5f800 c5128bfc 00000000 00000005
>>> 000001b0
>>> NIP [00000900] 0x900
>=20
> Could you post your current vfb.c and .config file?
>=20
> Best Regards,
> Anatolij
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
http://www.nabble.com/file/p18506984/vfb.c vfb.c=20
http://www.nabble.com/file/p18506984/.config .config=20
--=20
View this message in context: http://www.nabble.com/Videomode-800x480-tp184=
70632p18506984.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* use xilinx gpio from linux on a ppc405
From: Joachim Meyer @ 2008-07-17 12:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I installed (with some help of this mailinglist) a Linux (Kernel 2.6.23 from xilinx) on a ppc405 of a Virtex 2 PRO on a XUPV2P. Then I installed Xenomai. Now I want to control some devices from the Board, so I thought first I try to turn the LEDs on and of. I enabled the LEDs in my Design without interrupt and also compiled the Kernel with Xilinx OPG GPIO support. But I don't know realy how to go on. I found only 2 pages in the internet which gave me a bit of information, but nothing helped me.
Can Anyone explain me what I have to do, or send me a link to a page where it is explained?
The 2 pages I found:
--------------------------
http://osdir.com/ml/linux.uclinux.microblaze/2005-08/msg00120.html
http://www.tango-controls.org/Members/jbutanowicz/tango-on-ml403
The output of the kernel while booting:
-------------------------------------------------
Linux version 2.6.23xlnx (meyer@tiv007) (gcc version 3.4.5) #1 Thu Jul 17 12:10:27 CEST 2008
Xilinx Generic PowerPC board support package (Xilinx XUPV2P) (Virtex-II Pro)
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order. Total pages: 65024
Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25
Console: Xilinx UART Lite
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257664k available (1580k kernel code, 500k data, 96k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Registering device uartlite:0
Registering device xsysace:0
Registering device xilinx_emac:0
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
uartlite.0: ttyUL0 at MMIO 0x40600003 (irq = 3) is a uartlite
console [ttyUL0] enabled
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
System ACE at 0x41800000 mapped to 0xD1020000, irq=1, 500472KB
xsa: xsa1 xsa2
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0: 0: 0: 0
XEmac: using fifo mode.
XEmac: Detected PHY at address 0, ManufID 0x0013, Rev. 0x78e2.
eth0: Dropping NETIF_F_SG since no checksum feature.
eth0: Xilinx 10/100 EMAC at 0x80400000 mapped to 0xD1040000, irq=2
eth0: XEmac id 1.1a, block id 32, type 1
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on xsa2, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing unused kernel memory: 96k init
INIT: version 2.85 booting
Welcome to DENX Embedded Linux Environment
Press 'I' to enter interactive startup.
Building the cache [ OK ]
storage network audio done[ OK ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock : Thu Jan 1 00:00:20 UTC 1970 [ OK ]
Setting hostname localhost: [ OK ]
Checking filesystems
Checking all file systems.
[ OK ]
Mounting local filesystems: [ OK ]
Enabling swap space: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Bringing up loopback interface: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
XSysAce: Queue is plugged
Starting portmap: [ OK ]
Mounting NFS filesystems: XSysAce: Queue is plugged
[ OK ]
XSysAce: Queue is plugged
Mounting other filesystems: [ OK ]
DENX ELDK version 4.1 build 2007-01-19
Linux 2.6.23xlnx on a ppc
localhost login:
Thanks and Greez
Joachim
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: Jon Smirl @ 2008-07-17 12:05 UTC (permalink / raw)
To: Nobin Mathew; +Cc: dinesh, alsa-devel, liam.girdwood, linuxppc-dev
In-Reply-To: <8d6898730807170426wac4719cv7cd925cfcd91aa68@mail.gmail.com>
On 7/17/08, Nobin Mathew <nobin.mathew@gmail.com> wrote:
> Hi Dinesh,
>
> If that is your requirement then go and see the actual code
> sound/arm/aaci.c. They are not using DMA. It is programmed IO.
Search around the list archives, the first version of the
Efika/mpc5200 ac97 driver was programmed IO. The next version updated
it to DMA.
>
>
> Thanks
> Nobin Mathew
>
>
> On 7/17/08, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Thu, Jul 17, 2008 at 11:33:31AM +0530, dinesh wrote:
> >
> > > What i want is that i have a buffer in driver code which is also handled
> > > by some other application i want that this buffer data is to be used for
> > > capture and playback stream fills data to another buffer which i can
> > > passover to my other application.
> >
> > Depending on what exactly you're doing here you may find that this is
> > best implemented in user space with an ALSA plugin rather than doing it
> > as part of a driver. If you do want to do this in kernel space then the
> > parts of an ASoC driver which transfer audio data are just the same as
> > those for any other ALSA driver so things like sound/arm/aaci.c may
> > provide useful examples.
> >
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Marco Stornelli @ 2008-07-17 12:05 UTC (permalink / raw)
To: Ruksen INANIR; +Cc: linuxppc-embedded
In-Reply-To: <487F3248.9080405@gmail.com>
Ruksen INANIR ha scritto:
>
> Thanks for your comments.
> I tried the highmem option but one of the device drivers does not
> support highmem, so it did not work.
Strange....you can try to look at it, it could be only some GFP flag.
> the only choice for me is to increase the lowmem to 1520 MB. the maximum
> lowmem value i reached succesfully is 1503 MB. but any value more than
> 1503 results kernel not able to load kernel modules.
Mmmm....have you tried a stress test? It sounds like a bit strange that
the kernel works well with this mapping but without other modification.
> Upgrading to a 2.6.x kernel may solve the problem, but it needs a lot of
> effort. Does 2.6.x kernel support 2G physical memory?
>
It's the same. Some architecture have 36-bit addressing, but I don't
know if the latest kernel has the support for this feature for powerpc.
>
>
>
> Marco Stornelli wrote:
>> Ruksen INANIR ha scritto:
>>>
>>> Is there any side effects of changing the address splitting?
>>
>> Yes, in this way the application address space is smaller than normal.
>> Some big applications (for example same dbms) might not work. Usually
>> with 2G/2G most of the applications work well.
>>
>>> What should i change for 2G/2G splitting? should i shift the kernel
>>> start?
>>> Thanks
>>>
>> Yes in advanced options of the kernel menu, but sometimes it's not
>> easy. Sometimes ago I had to do the same thing but I have to change
>> the kernel code because some operations were hard-coded. Be careful
>> because it's not an easy operation. However I'd suggest you to use the
>> highmem, the memory performance are worse than direct memory mapping,
>> but usually it's not a problem because the overhead is low.
>>
>>>
>>> Marco Stornelli wrote:
>>>> Marco Stornelli ha scritto:
>>>>> Ruksen INANIR ha scritto:
>>>>>>
>>>>>> Is there a way to increase the lowmem value for ppc. The
>>>>>> MAX_LOW_MEM is defined as max 768 MB. But a value around 1.5 G
>>>>>> works with no problem. But when i try to increase this value to
>>>>>> 1520 or more, kernel complaints about no space for memory
>>>>>> allocation when loading kernel modules.
>>>>>> I do not want to use HIGHMEM config. What is the max lowmem value
>>>>>> for a ppc system? What other setting are needed to use 1520 MB (or
>>>>>> more) as lowmem .
>>>>>> The ppc card has 2G on board memory. 2.4.22 kernel is used.
>>>>>>
>>>>>> Thanks
>>>>>> _______________________________________________
>>>>>> Linuxppc-embedded mailing list
>>>>>> Linuxppc-embedded@ozlabs.org
>>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>>
>>>>> With 32-bit arch you may not use more than 1GB to map the memory
>>>>> (minus some space for some kernel operation). The value of 768MB
>>>>> was not there by chance.
>>>>>
>>>> Only an additional comment: I meant with the address splitting
>>>> 3G/1G. To map more than 1GB, you have to change the splitting 2G/2G
>>>> for example.
>>>>
>>>
>>> _______________________________________________
>>> 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
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* RE: [PATCH 1/4] powerpc: fsl_msi doesn't need it's own of_node
From: Michael Ellerman @ 2008-07-17 11:53 UTC (permalink / raw)
To: Jin Zhengxiong; +Cc: Olof Johannsson, Gala Kumar, linuxppc-dev
In-Reply-To: <CC27DED0F8F39E48A7E75FD768688B7AAC731A@zch01exm27.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
On Thu, 2008-07-17 at 18:48 +0800, Jin Zhengxiong wrote:
> Ack, Tested the patch set on Freescale board and working good.
> Thanks
Thanks for testing.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Ruksen INANIR @ 2008-07-17 11:51 UTC (permalink / raw)
To: Marco Stornelli, linuxppc-embedded
In-Reply-To: <487F2E79.1030102@coritel.it>
Thanks for your comments.
I tried the highmem option but one of the device drivers does not
support highmem, so it did not work.
the only choice for me is to increase the lowmem to 1520 MB. the maximum
lowmem value i reached succesfully is 1503 MB. but any value more than
1503 results kernel not able to load kernel modules.
Upgrading to a 2.6.x kernel may solve the problem, but it needs a lot of
effort. Does 2.6.x kernel support 2G physical memory?
Marco Stornelli wrote:
> Ruksen INANIR ha scritto:
>>
>> Is there any side effects of changing the address splitting?
>
> Yes, in this way the application address space is smaller than normal.
> Some big applications (for example same dbms) might not work. Usually
> with 2G/2G most of the applications work well.
>
>> What should i change for 2G/2G splitting? should i shift the kernel
>> start?
>> Thanks
>>
> Yes in advanced options of the kernel menu, but sometimes it's not
> easy. Sometimes ago I had to do the same thing but I have to change
> the kernel code because some operations were hard-coded. Be careful
> because it's not an easy operation. However I'd suggest you to use the
> highmem, the memory performance are worse than direct memory mapping,
> but usually it's not a problem because the overhead is low.
>
>>
>> Marco Stornelli wrote:
>>> Marco Stornelli ha scritto:
>>>> Ruksen INANIR ha scritto:
>>>>>
>>>>> Is there a way to increase the lowmem value for ppc. The
>>>>> MAX_LOW_MEM is defined as max 768 MB. But a value around 1.5 G
>>>>> works with no problem. But when i try to increase this value to
>>>>> 1520 or more, kernel complaints about no space for memory
>>>>> allocation when loading kernel modules.
>>>>> I do not want to use HIGHMEM config. What is the max lowmem value
>>>>> for a ppc system? What other setting are needed to use 1520 MB (or
>>>>> more) as lowmem .
>>>>> The ppc card has 2G on board memory. 2.4.22 kernel is used.
>>>>>
>>>>> Thanks
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>> With 32-bit arch you may not use more than 1GB to map the memory
>>>> (minus some space for some kernel operation). The value of 768MB
>>>> was not there by chance.
>>>>
>>> Only an additional comment: I meant with the address splitting
>>> 3G/1G. To map more than 1GB, you have to change the splitting 2G/2G
>>> for example.
>>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
>
^ permalink raw reply
* Re: Videomode 800x480
From: Anatolij Gustschin @ 2008-07-17 11:43 UTC (permalink / raw)
To: Alex_SYS; +Cc: linuxppc-embedded
In-Reply-To: <18502863.post@talk.nabble.com>
Alex_SYS wrote:
>
> Alex_SYS wrote:
>> <Here is the Kernel Bootup message that it gives when it crashes!
>>
>> U-Boot 1.2.0-mpc5200b-tiny-3 (Dec 11 2007 - 11:25:01)
>>
>> CPU: MPC5200 v2.2, Core v1.4 at 399.999 MHz
>> Bus 133 MHz, IPB 133 MHz, PCI 33 MHz
>> Board: phyCORE-MPC5200B-tiny
>> I2C: ready
>> DRAM: 64 MB
>> SP: 0x03f73768
>> FLASH: 16 MB
>> Using pcm030 machine description
>> Linux version 2.6.23.1-rt5-pcm030-1trunk (aschmid@LINUX) (gcc version
>> 4.1.2) #39
>> 4 PREEMPT RT Tue Dec 11 17:58:48 CET 2007
>> Zone PFN ranges:
>> DMA 0 -> 16384
>> Normal 16384 -> 16384
>> Movable zone start PFN for each node
>> early_node_map[1] active PFN ranges
>> 0: 0 -> 16384
>> Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
>> Built 1 zonelists in Zone order. Total pages: 16256
>> Kernel command line: video=0x0-16@60 , console=ttyPSC0,115200
----------------------------->^^^^^^^^^
is this intentional?
>> mtdparts=physmap-f
>> lash.0:256k(ubootl),1792k(kernel),13312k(jffs2),256k(uboot)ro,256k(oftree),-(spa
>> ce) rw root=/dev/mtdblock2 rootfstype=jffs2
>> WARNING: experimental RCU implementation.
>> MPC52xx PIC is up and running!
>> PID hash table entries: 256 (order: 8, 1024 bytes)
>> Console: colour dummy device 80x25
>> console [ttyPSC0] enabled
>> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
>> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
>> Memory: 61960k/65536k available (2624k kernel code, 3508k reserved, 144k
>> data, 1
>> 06k bss, 124k init)
>> Mount-cache hash table entries: 512
>> NET: Registered protocol family 16
>> PCI: Probing PCI hardware
>> DMA: MPC52xx BestComm driver
>> DMA: MPC52xx BestComm engine @f0001200 ok !
>> Generic PHY: Registered new driver
>> usbcore: registered new interface driver usbfs
>> usbcore: registered new interface driver hub
>> usbcore: registered new device driver usb
>> NET: Registered protocol family 2
>> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
>> TCP established hash table entries: 2048 (order: 4, 73728 bytes)
>> TCP bind hash table entries: 2048 (order: 3, 57344 bytes)
>> TCP: Hash tables configured (established 2048 bind 2048)
>> TCP reno registered
>> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
>> io scheduler noop registered (default)
>> No Options from U-Boot
>> Lime Driver PROBE
>> No Mode
>> Name des Strings 0x0-16@60 with Länge 9
>> Schleife mode Options
>> Schleife @
>> Schleife -
>> Schleife x
>> DONE vor CVT xres= 0 , yres=0 , cvt=
>> 0******************************************
>> ************CVT Mode: Trying specified video mode 0x0
>> Trying mode 800x480-16@60 800x600-16@20
>> Error=
>> 0********************************************************************Tryi
>> ng mode noname 640x400-16@70
>> Error=
>> 0********************************************************************Tryi
>> ng mode noname 640x480-16@60
>> Error=
>> 0********************************************************************Tryi
>> ng mode noname 800x600-16@56
What arguments do you pass to fb_find_mode() in the driver? Probing all of
these modes is not necessary.
<snip>
>> Error=
>> 0********************************************************************Tryi
>> ng default video mode
>> Trying mode noname 800x480-16@60
>> Error=
>> 0********************************************************************Tryi
>> ng default mode
>> Console: switching to colour frame buffer device 114x34
>> stopped custom tracer.
>> Oops: Exception in kernel mode, sig: 4 [#1]
>> PREEMPT pcm030
>> Modules linked in:
>> NIP: 00000900 LR: c011d94c CTR: c011daf4
>> REGS: c3fe7a30 TRAP: 0700 Not tainted (2.6.23.1-rt5-pcm030-1trunk)
>> MSR: 00081000 <ME> CR: 42042022 XER: 00000000
>> TASK = c3fe5c00[1] 'swapper' THREAD: c3fe6000
>> GPR00: ffffffff c3fe7ae0 c3fe5c00 c5128bfc 00000000 00010001 00000020
>> 00000020
>> GPR08: 00000000 00010001 ffffffff 00000020 c3f5f800 fffffffb 03fcb000
>> ffffffff
>> GPR16: 00000001 00000000 c3fe7f78 c024a748 00000000 00000000 00000002
>> 000001e0
>> GPR24: 00010001 c011daf4 00000020 c3f5f800 c5128bfc 00000000 00000005
>> 000001b0
>> NIP [00000900] 0x900
Could you post your current vfb.c and .config file?
Best Regards,
Anatolij
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Marco Stornelli @ 2008-07-17 11:35 UTC (permalink / raw)
To: Ruksen INANIR; +Cc: linuxppc-embedded
In-Reply-To: <487F2B7D.6080109@gmail.com>
Ruksen INANIR ha scritto:
>
> Is there any side effects of changing the address splitting?
Yes, in this way the application address space is smaller than normal.
Some big applications (for example same dbms) might not work. Usually
with 2G/2G most of the applications work well.
> What should i change for 2G/2G splitting? should i shift the kernel start?
> Thanks
>
Yes in advanced options of the kernel menu, but sometimes it's not easy.
Sometimes ago I had to do the same thing but I have to change the
kernel code because some operations were hard-coded. Be careful because
it's not an easy operation. However I'd suggest you to use the highmem,
the memory performance are worse than direct memory mapping, but usually
it's not a problem because the overhead is low.
>
> Marco Stornelli wrote:
>> Marco Stornelli ha scritto:
>>> Ruksen INANIR ha scritto:
>>>>
>>>> Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM
>>>> is defined as max 768 MB. But a value around 1.5 G works with no
>>>> problem. But when i try to increase this value to 1520 or more,
>>>> kernel complaints about no space for memory allocation when loading
>>>> kernel modules.
>>>> I do not want to use HIGHMEM config. What is the max lowmem value
>>>> for a ppc system? What other setting are needed to use 1520 MB (or
>>>> more) as lowmem .
>>>> The ppc card has 2G on board memory. 2.4.22 kernel is used.
>>>>
>>>> Thanks
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>> With 32-bit arch you may not use more than 1GB to map the memory
>>> (minus some space for some kernel operation). The value of 768MB was
>>> not there by chance.
>>>
>> Only an additional comment: I meant with the address splitting 3G/1G.
>> To map more than 1GB, you have to change the splitting 2G/2G for example.
>>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: Nobin Mathew @ 2008-07-17 11:26 UTC (permalink / raw)
To: dinesh, Nobin Mathew, Grant Likely, linuxppc-dev, alsa-devel,
liam.girdwood
In-Reply-To: <20080717105614.GC15333@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
Hi Dinesh,
If that is your requirement then go and see the actual code
sound/arm/aaci.c. They are not using DMA. It is programmed IO.
Thanks
Nobin Mathew
On 7/17/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Thu, Jul 17, 2008 at 11:33:31AM +0530, dinesh wrote:
>
> > What i want is that i have a buffer in driver code which is also handled
> > by some other application i want that this buffer data is to be used for
> > capture and playback stream fills data to another buffer which i can
> > passover to my other application.
>
> Depending on what exactly you're doing here you may find that this is
> best implemented in user space with an ALSA plugin rather than doing it
> as part of a driver. If you do want to do this in kernel space then the
> parts of an ASoC driver which transfer audio data are just the same as
> those for any other ALSA driver so things like sound/arm/aaci.c may
> provide useful examples.
>
[-- Attachment #2: Type: text/html, Size: 1374 bytes --]
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Ruksen INANIR @ 2008-07-17 11:22 UTC (permalink / raw)
To: Marco Stornelli, linuxppc-embedded
In-Reply-To: <487F2B4C.7070409@coritel.it>
Is there any side effects of changing the address splitting? What should
i change for 2G/2G splitting? should i shift the kernel start?
Thanks
Marco Stornelli wrote:
> Marco Stornelli ha scritto:
>> Ruksen INANIR ha scritto:
>>>
>>> Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM
>>> is defined as max 768 MB. But a value around 1.5 G works with no
>>> problem. But when i try to increase this value to 1520 or more,
>>> kernel complaints about no space for memory allocation when loading
>>> kernel modules.
>>> I do not want to use HIGHMEM config. What is the max lowmem value
>>> for a ppc system? What other setting are needed to use 1520 MB (or
>>> more) as lowmem .
>>> The ppc card has 2G on board memory. 2.4.22 kernel is used.
>>>
>>> Thanks
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>> With 32-bit arch you may not use more than 1GB to map the memory
>> (minus some space for some kernel operation). The value of 768MB was
>> not there by chance.
>>
> Only an additional comment: I meant with the address splitting 3G/1G.
> To map more than 1GB, you have to change the splitting 2G/2G for example.
>
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Marco Stornelli @ 2008-07-17 11:21 UTC (permalink / raw)
To: Ruksen INANIR; +Cc: linuxppc-embedded
In-Reply-To: <487F297B.4070806@coritel.it>
Marco Stornelli ha scritto:
> Ruksen INANIR ha scritto:
>>
>> Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM
>> is defined as max 768 MB. But a value around 1.5 G works with no
>> problem. But when i try to increase this value to 1520 or more, kernel
>> complaints about no space for memory allocation when loading kernel
>> modules.
>> I do not want to use HIGHMEM config. What is the max lowmem value for
>> a ppc system? What other setting are needed to use 1520 MB (or more)
>> as lowmem .
>> The ppc card has 2G on board memory. 2.4.22 kernel is used.
>>
>> Thanks
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
> With 32-bit arch you may not use more than 1GB to map the memory (minus
> some space for some kernel operation). The value of 768MB was not there
> by chance.
>
Only an additional comment: I meant with the address splitting 3G/1G. To
map more than 1GB, you have to change the splitting 2G/2G for example.
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Marco Stornelli @ 2008-07-17 11:14 UTC (permalink / raw)
To: Ruksen INANIR; +Cc: linuxppc-embedded
In-Reply-To: <487F1FD2.7090909@gmail.com>
Ruksen INANIR ha scritto:
>
> Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM is
> defined as max 768 MB. But a value around 1.5 G works with no problem.
> But when i try to increase this value to 1520 or more, kernel complaints
> about no space for memory allocation when loading kernel modules.
> I do not want to use HIGHMEM config. What is the max lowmem value for a
> ppc system? What other setting are needed to use 1520 MB (or more) as
> lowmem .
> The ppc card has 2G on board memory. 2.4.22 kernel is used.
>
> Thanks
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
With 32-bit arch you may not use more than 1GB to map the memory (minus
some space for some kernel operation). The value of 768MB was not there
by chance.
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-17 11:07 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <dc452eaab83710e7d6f86dcc5d77bdda@kernel.crashing.org>
On Thu, Jul 17, 2008 at 07:59:03AM +0200, Segher Boessenkool wrote:
>> diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
>> b/Documentation/powerpc/dts-bindings/gpio/led.txt
>> new file mode 100644
>> index 0000000..7e9ce81
>> --- /dev/null
>> +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
>> @@ -0,0 +1,15 @@
>> +LED connected to GPIO
>> +
>> +Required properties:
>> +- compatible : should be "gpio-led".
>
> This "compatible" name is a bit too generic. No, I don't know a
> better name :-(
>
>> +- label : (optional) the label for this LED. If omitted, the label is
>> + taken from the node name (excluding the unit address).
>
> What is a label?
The label that is written on the board for this particular LED, or
the label that hardware documentation refers to.
> It should be described here. Also, its encoding
> should be described ("a string" I guess).
Yes.
>> +- gpios : should specify LED GPIO.
>> +
>> +Example:
>> +
>> +led@0 {
>> + compatible = "gpio-led";
>> + label = "hdd";
>> + gpios = <&mcu_pio 0 0>;
>> +};
>
> You show a unit address but have no "reg" value. This is
> incorrect.
Hm.. how could I enumerate them then? Or should I just give them the
full names, i.e. "led-hdd" or something?
> What would be the parent node of this, btw?
This is tricky question. Personally I place them inside the gpio
controller node that is responsible for the LED. But I think placing the
led nodes at top level would be also fine (maybe with "leds { }" node as
a parent for all board's LEDs. What would you suggest for a "best
practice"?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: Mark Brown @ 2008-07-17 10:56 UTC (permalink / raw)
To: dinesh; +Cc: linuxppc-dev, alsa-devel, Nobin Mathew, liam.girdwood
In-Reply-To: <1216274611.18207.6.camel@dinesh.dua>
On Thu, Jul 17, 2008 at 11:33:31AM +0530, dinesh wrote:
> What i want is that i have a buffer in driver code which is also handled
> by some other application i want that this buffer data is to be used for
> capture and playback stream fills data to another buffer which i can
> passover to my other application.
Depending on what exactly you're doing here you may find that this is
best implemented in user space with an ALSA plugin rather than doing it
as part of a driver. If you do want to do this in kernel space then the
parts of an ASoC driver which transfer audio data are just the same as
those for any other ALSA driver so things like sound/arm/aaci.c may
provide useful examples.
^ permalink raw reply
* [patch] powerpc: lockless get_user_pages
From: Nick Piggin @ 2008-07-17 10:53 UTC (permalink / raw)
To: Andrew Morton, Dave Kleikamp, Benjamin Herrenschmidt,
linuxppc-dev
In-Reply-To: <20080717104426.GA25083@wotan.suse.de>
Together with the previous patch, I've tested this on mmotm, including
with 64K base pages. However I only have a machine with a single possible
hugepage size, so testing a real multi size system would be nice.
Thanks to Dave for reworking for multiple hugepage sizes (Dave, I had to
make a small change to the slice shift calculation here).
--
powerpc: lockless get_user_pages_fast
Implement lockless get_user_pages_fast for powerpc. Page table existence is
guaranteed with RCU, and speculative page references are used to take a
reference to the pages without having a prior existence guarantee on them.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 3
arch/powerpc/mm/Makefile | 2
arch/powerpc/mm/gup.c | 245 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/pgtable-ppc64.h | 2
include/linux/pagemap.h | 23 +++
6 files changed, 275 insertions(+), 2 deletions(-)
Index: linux-2.6/include/asm-powerpc/pgtable-ppc64.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/pgtable-ppc64.h 2008-07-17 20:30:06.000000000 +1000
+++ linux-2.6/include/asm-powerpc/pgtable-ppc64.h 2008-07-17 20:30:09.000000000 +1000
@@ -461,6 +461,8 @@
return pt;
}
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long address);
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
Index: linux-2.6/include/linux/pagemap.h
===================================================================
--- linux-2.6.orig/include/linux/pagemap.h 2008-07-17 20:30:06.000000000 +1000
+++ linux-2.6/include/linux/pagemap.h 2008-07-17 20:30:09.000000000 +1000
@@ -171,6 +171,29 @@
return 1;
}
+/*
+ * Same as above, but add instead of inc (could just be merged)
+ */
+static inline int page_cache_add_speculative(struct page *page, int count)
+{
+ VM_BUG_ON(in_interrupt());
+
+#if !defined(CONFIG_SMP) && defined(CONFIG_CLASSIC_RCU)
+# ifdef CONFIG_PREEMPT
+ VM_BUG_ON(!in_atomic());
+# endif
+ VM_BUG_ON(page_count(page) == 0);
+ atomic_add(count, &page->_count);
+
+#else
+ if (unlikely(!atomic_add_unless(&page->_count, count, 0)))
+ return 0;
+#endif
+ VM_BUG_ON(PageCompound(page) && page != compound_head(page));
+
+ return 1;
+}
+
static inline int page_freeze_refs(struct page *page, int count)
{
return likely(atomic_cmpxchg(&page->_count, count, 0) == count);
Index: linux-2.6/arch/powerpc/mm/Makefile
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/Makefile 2008-07-17 20:30:06.000000000 +1000
+++ linux-2.6/arch/powerpc/mm/Makefile 2008-07-17 20:30:09.000000000 +1000
@@ -6,7 +6,7 @@
EXTRA_CFLAGS += -mno-minimal-toc
endif
-obj-y := fault.o mem.o \
+obj-y := fault.o mem.o gup.o \
init_$(CONFIG_WORD_SIZE).o \
pgtable_$(CONFIG_WORD_SIZE).o \
mmu_context_$(CONFIG_WORD_SIZE).o
Index: linux-2.6/arch/powerpc/mm/gup.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/arch/powerpc/mm/gup.c 2008-07-17 20:30:09.000000000 +1000
@@ -0,0 +1,258 @@
+/*
+ * Lockless get_user_pages_fast for powerpc
+ *
+ * Copyright (C) 2008 Nick Piggin
+ * Copyright (C) 2008 Novell Inc.
+ */
+#include <linux/sched.h>
+#include <linux/mm.h>
+#include <linux/hugetlb.h>
+#include <linux/vmstat.h>
+#include <linux/pagemap.h>
+#include <linux/rwsem.h>
+#include <asm/pgtable.h>
+
+/*
+ * The performance critical leaf functions are made noinline otherwise gcc
+ * inlines everything into a single function which results in too much
+ * register pressure.
+ */
+static noinline int gup_pte_range(pmd_t pmd, unsigned long addr,
+ unsigned long end, int write, struct page **pages, int *nr)
+{
+ unsigned long mask, result;
+ pte_t *ptep;
+
+ result = _PAGE_PRESENT|_PAGE_USER;
+ if (write)
+ result |= _PAGE_RW;
+ mask = result | _PAGE_SPECIAL;
+
+ ptep = pte_offset_kernel(&pmd, addr);
+ do {
+ pte_t pte = *ptep;
+ struct page *page;
+
+ if ((pte_val(pte) & mask) != result)
+ return 0;
+ VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
+ page = pte_page(pte);
+ if (!page_cache_get_speculative(page))
+ return 0;
+ if (unlikely(pte != *ptep)) {
+ put_page(page);
+ return 0;
+ }
+ pages[*nr] = page;
+ (*nr)++;
+
+ } while (ptep++, addr += PAGE_SIZE, addr != end);
+
+ return 1;
+}
+
+static noinline int gup_huge_pte(pte_t *ptep, struct hstate *hstate,
+ unsigned long *addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long mask;
+ unsigned long pte_end;
+ struct page *head, *page;
+ pte_t pte;
+ int refs;
+
+ pte_end = (*addr + huge_page_size(hstate)) & huge_page_mask(hstate);
+ if (pte_end < end)
+ end = pte_end;
+
+ pte = *ptep;
+ mask = _PAGE_PRESENT|_PAGE_USER;
+ if (write)
+ mask |= _PAGE_RW;
+ if ((pte_val(pte) & mask) != mask)
+ return 0;
+ /* hugepages are never "special" */
+ VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
+
+ refs = 0;
+ head = pte_page(pte);
+ page = head + ((*addr & ~huge_page_mask(hstate)) >> PAGE_SHIFT);
+ do {
+ VM_BUG_ON(compound_head(page) != head);
+ pages[*nr] = page;
+ (*nr)++;
+ page++;
+ refs++;
+ } while (*addr += PAGE_SIZE, *addr != end);
+
+ if (!page_cache_add_speculative(head, refs)) {
+ *nr -= refs;
+ return 0;
+ }
+ if (unlikely(pte != *ptep)) {
+ /* Could be optimized better */
+ while (*nr) {
+ put_page(page);
+ (*nr)--;
+ }
+ }
+
+ return 1;
+}
+
+static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long next;
+ pmd_t *pmdp;
+
+ pmdp = pmd_offset(&pud, addr);
+ do {
+ pmd_t pmd = *pmdp;
+
+ next = pmd_addr_end(addr, end);
+ if (pmd_none(pmd))
+ return 0;
+ if (!gup_pte_range(pmd, addr, next, write, pages, nr))
+ return 0;
+ } while (pmdp++, addr = next, addr != end);
+
+ return 1;
+}
+
+static int gup_pud_range(pgd_t pgd, unsigned long addr, unsigned long end,
+ int write, struct page **pages, int *nr)
+{
+ unsigned long next;
+ pud_t *pudp;
+
+ pudp = pud_offset(&pgd, addr);
+ do {
+ pud_t pud = *pudp;
+
+ next = pud_addr_end(addr, end);
+ if (pud_none(pud))
+ return 0;
+ if (!gup_pmd_range(pud, addr, next, write, pages, nr))
+ return 0;
+ } while (pudp++, addr = next, addr != end);
+
+ return 1;
+}
+
+int get_user_pages_fast(unsigned long start, int nr_pages, int write,
+ struct page **pages)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned long end = start + (nr_pages << PAGE_SHIFT);
+ unsigned long addr = start;
+ unsigned long next;
+ pgd_t *pgdp;
+ int nr = 0;
+ unsigned int shift;
+
+
+ if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
+ start, nr_pages*PAGE_SIZE)))
+ goto slow_irqon;
+
+ /* Cross a slice boundary? */
+ if (addr < SLICE_LOW_TOP) {
+ if (end > SLICE_LOW_TOP)
+ goto slow_irqon;
+
+ if (unlikely(GET_LOW_SLICE_INDEX(addr) !=
+ GET_LOW_SLICE_INDEX(end - 1)))
+ goto slow_irqon;
+ } else {
+ if (unlikely(GET_HIGH_SLICE_INDEX(addr) !=
+ GET_HIGH_SLICE_INDEX(end - 1)))
+ goto slow_irqon;
+ }
+
+ /*
+ * XXX: batch / limit 'nr', to avoid large irq off latency
+ * needs some instrumenting to determine the common sizes used by
+ * important workloads (eg. DB2), and whether limiting the batch size
+ * will decrease performance.
+ *
+ * It seems like we're in the clear for the moment. Direct-IO is
+ * the main guy that batches up lots of get_user_pages, and even
+ * they are limited to 64-at-a-time which is not so many.
+ */
+ /*
+ * This doesn't prevent pagetable teardown, but does prevent
+ * the pagetables from being freed on powerpc.
+ *
+ * So long as we atomically load page table pointers versus teardown,
+ * we can follow the address down to the the page and take a ref on it.
+ */
+ local_irq_disable();
+
+ shift = mmu_psize_defs[get_slice_psize(mm, addr)].shift;
+
+ if (shift > PAGE_SHIFT) {
+ pte_t *ptep;
+ unsigned long a = addr;
+ unsigned long sz = ((1UL) << shift);
+ struct hstate *hstate = size_to_hstate(sz);
+
+ BUG_ON(!hstate);
+ /*
+ * XXX: could be optimized to avoid hstate
+ * lookup entirely (just use shift)
+ */
+
+ ptep = huge_pte_offset(mm, a);
+ do {
+ VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm, a)].shift);
+ if (!gup_huge_pte(ptep, hstate, &a, end, write, pages,
+ &nr))
+ goto slow;
+ ptep++;
+ } while (a != end);
+ } else {
+ pgdp = pgd_offset(mm, addr);
+ do {
+ pgd_t pgd = *pgdp;
+
+ VM_BUG_ON(shift != mmu_psize_defs[get_slice_psize(mm, addr)].shift);
+
+ next = pgd_addr_end(addr, end);
+ if (pgd_none(pgd))
+ goto slow;
+ if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
+ goto slow;
+ } while (pgdp++, addr = next, addr != end);
+ }
+ local_irq_enable();
+
+ VM_BUG_ON(nr != (end - start) >> PAGE_SHIFT);
+ return nr;
+
+ {
+ int ret;
+
+slow:
+ local_irq_enable();
+slow_irqon:
+ /* Try to get the remaining pages with get_user_pages */
+ start += nr << PAGE_SHIFT;
+ pages += nr;
+
+ down_read(&mm->mmap_sem);
+ ret = get_user_pages(current, mm, start,
+ (end - start) >> PAGE_SHIFT, write, 0, pages, NULL);
+ up_read(&mm->mmap_sem);
+
+ /* Have to be a bit careful with return values */
+ if (nr > 0) {
+ if (ret < 0)
+ ret = nr;
+ else
+ ret += nr;
+ }
+
+ return ret;
+ }
+}
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig 2008-07-17 20:30:06.000000000 +1000
+++ linux-2.6/arch/powerpc/Kconfig 2008-07-17 20:30:09.000000000 +1000
@@ -42,6 +42,9 @@
bool
default y
+config HAVE_GET_USER_PAGES_FAST
+ def_bool PPC64
+
config HAVE_SETUP_PER_CPU_AREA
def_bool PPC64
^ permalink raw reply
* RE: [PATCH 1/4] powerpc: fsl_msi doesn't need it's own of_node
From: Jin Zhengxiong @ 2008-07-17 10:48 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt
Cc: Olof Johannsson, linuxppc-dev, Gala Kumar
In-Reply-To: <378edcf6ad114d35166364c5df03a8c422f757a1.1216133084.git.michael@ellerman.id.au>
Ack, Tested the patch set on Freescale board and working good.
Thanks
Jason Jin=20
> -----Original Message-----
> From: Michael Ellerman [mailto:michael@ellerman.id.au]=20
> Sent: Tuesday, July 15, 2008 10:46 PM
> To: Benjamin Herrenschmidt
> Cc: linuxppc-dev@ozlabs.org; Olof Johannsson; Gala Kumar; Jin=20
> Zhengxiong
> Subject: [PATCH 1/4] powerpc: fsl_msi doesn't need it's own of_node
>=20
> The FSL MSI code keeps a pointer to the of_node from the=20
> device it represents. However it also has an irq_host, which=20
> contains a pointer to the of_node, so use that one instead.
>=20
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 12 +++++-------
> arch/powerpc/sysdev/fsl_msi.h | 3 ---
> 2 files changed, 5 insertions(+), 10 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_msi.c=20
> b/arch/powerpc/sysdev/fsl_msi.c index 2c5187c..d49fa99 100644
> --- a/arch/powerpc/sysdev/fsl_msi.c
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -108,7 +108,8 @@ static int fsl_msi_free_dt_hwirqs(struct=20
> fsl_msi *msi)
> bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
> get_count_order(NR_MSI_IRQS));
> =20
> - p =3D of_get_property(msi->of_node, "msi-available-ranges", &len);
> + p =3D of_get_property(msi->irqhost->of_node,=20
> "msi-available-ranges",
> + &len);
> =20
> if (!p) {
> /* No msi-available-ranges property,
> @@ -120,7 +121,7 @@ static int fsl_msi_free_dt_hwirqs(struct=20
> fsl_msi *msi)
> =20
> if ((len % (2 * sizeof(u32))) !=3D 0) {
> printk(KERN_WARNING "fsl_msi: Malformed=20
> msi-available-ranges "
> - "property on %s\n", msi->of_node->full_name);
> + "property on %s\n",=20
> msi->irqhost->of_node->full_name);
> return -EINVAL;
> }
> =20
> @@ -317,14 +318,11 @@ static int __devinit=20
> fsl_of_msi_probe(struct of_device *dev,
> goto error_out;
> }
> =20
> - msi->of_node =3D of_node_get(dev->node);
> + msi->irqhost =3D irq_alloc_host(dev->node, IRQ_HOST_MAP_LINEAR,
> + NR_MSI_IRQS,=20
> &fsl_msi_host_ops, 0);
> =20
> - msi->irqhost =3D irq_alloc_host(of_node_get(dev->node),
> - IRQ_HOST_MAP_LINEAR,
> - NR_MSI_IRQS, &fsl_msi_host_ops, 0);
> if (msi->irqhost =3D=3D NULL) {
> dev_err(&dev->dev, "No memory for MSI irqhost\n");
> - of_node_put(dev->node);
> err =3D -ENOMEM;
> goto error_out;
> }
> diff --git a/arch/powerpc/sysdev/fsl_msi.h=20
> b/arch/powerpc/sysdev/fsl_msi.h index a653468..6574550 100644
> --- a/arch/powerpc/sysdev/fsl_msi.h
> +++ b/arch/powerpc/sysdev/fsl_msi.h
> @@ -22,9 +22,6 @@
> #define FSL_PIC_IP_IPIC 0x00000002
> =20
> struct fsl_msi {
> - /* Device node of the MSI interrupt*/
> - struct device_node *of_node;
> -
> struct irq_host *irqhost;
> =20
> unsigned long cascade_irq;
> --
> 1.5.5
>=20
>=20
^ permalink raw reply
* [patch] powerpc: implement pte_special for 64K pages
From: Nick Piggin @ 2008-07-17 10:44 UTC (permalink / raw)
To: Andrew Morton, Dave Kleikamp, Benjamin Herrenschmidt,
linuxppc-dev
This can be folded into powerpc-implement-pte_special.patch
--
Ben has now freed up a pte bit on 64k pages. Use it for special pte bit.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/include/asm-powerpc/pgtable-64k.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/pgtable-64k.h 2008-07-17 18:53:03.000000000 +1000
+++ linux-2.6/include/asm-powerpc/pgtable-64k.h 2008-07-17 20:30:06.000000000 +1000
@@ -70,11 +70,12 @@
#define PGDIR_MASK (~(PGDIR_SIZE-1))
/* Additional PTE bits (don't change without checking asm in hash_low.S) */
+#define __HAVE_ARCH_PTE_SPECIAL
+#define _PAGE_SPECIAL 0x00000400 /* software: special page */
#define _PAGE_HPTE_SUB 0x0ffff000 /* combo only: sub pages HPTE bits */
#define _PAGE_HPTE_SUB0 0x08000000 /* combo only: first sub page */
#define _PAGE_COMBO 0x10000000 /* this is a combo 4k page */
#define _PAGE_4K_PFN 0x20000000 /* PFN is for a single 4k page */
-#define _PAGE_SPECIAL 0x0 /* don't have enough room for this yet */
/* For 64K page, we don't have a separate _PAGE_HASHPTE bit. Instead,
* we set that to be the whole sub-bits mask. The C code will only
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-17 10:39 UTC (permalink / raw)
To: Grant Likely
Cc: Jean Delvare, Linuxppc-dev, Alan Clucas, Detlev Zundel,
lm-sensors
In-Reply-To: <20080717073312.GB30474@secretlab.ca>
Grant Likely wrote:
> On Thu, Jul 17, 2008 at 09:31:24AM +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
>>>> I've found this thread now. Why can't we totally remove probing from
>>>> i2c-mpc? These are embedded systems, not open boxes like a PC. If a
>>>> i2c client hasn't been converted to the new model yet, convert it
>>>> before deploying with the new i2c-mpc driver. It's not very hard to
>>>> convert the client drivers.
>>> I tend to agree. And the number of unconverted drivers is getting very
>>> low these days. Only 2 RTC drivers are left, and by the end of the day,
>>> almost all hwmon drivers will be converted as well.
>> Thinking more about it I also prefer removing the I2C_CLASS_HWMON flag
>> completely. It just affects HWMON devices anyhow and if there is still
>> an old style driver around, it should be converted.
>
> I'm cool with that.
Good, just sent a new patch.
Wolfgang.
^ permalink raw reply
* [PATCH] i2c-mpc: suppress I2C device probing
From: Wolfgang Grandegger @ 2008-07-17 10:37 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: Jean Delvare
This patch suppresses I2C device probing by clearing the class field
of the "struct i2c_adapter" for the MPC I2C bus adapters. Some board
configurations which rely on probing must be fixed up by adding a
proper I2C device node to the DTS file, like the TQM85xx modules.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/i2c/busses/i2c-mpc.c | 1 -
1 file changed, 1 deletion(-)
Index: powerpc/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- powerpc.orig/drivers/i2c/busses/i2c-mpc.c
+++ powerpc/drivers/i2c/busses/i2c-mpc.c
@@ -312,7 +312,6 @@ static struct i2c_adapter mpc_ops = {
.name = "MPC adapter",
.id = I2C_HW_MPC107,
.algo = &mpc_algo,
- .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
.timeout = 1,
};
^ permalink raw reply
* increase lowmem value for ppc
From: Ruksen INANIR @ 2008-07-17 10:32 UTC (permalink / raw)
To: linuxppc-embedded
Is there a way to increase the lowmem value for ppc. The MAX_LOW_MEM is
defined as max 768 MB. But a value around 1.5 G works with no problem.
But when i try to increase this value to 1520 or more, kernel complaints
about no space for memory allocation when loading kernel modules.
I do not want to use HIGHMEM config. What is the max lowmem value for a
ppc system? What other setting are needed to use 1520 MB (or more) as
lowmem .
The ppc card has 2G on board memory. 2.4.22 kernel is used.
Thanks
^ 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