* RE: 82xx performance
From: Rune Torgersen @ 2008-07-17 15:52 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <200807171747.28624.arnd@arndb.de>
Arnd Bergmann wrote:
> Seeing more hits in handle_mm_fault suggests that you have
> a higher page fault rate. A trivial reason for this might
> be that the amount of memory was misdetected in the new
> code (maybe broken device tree). What is the content of
> /proc/meminfo after a fresh boot?
I also just realized that the /aprch/ppc was set up without high-mem
support (using all 1G as lowmem), while the arch/powerpc was set up with
hightmem. I'm retrying a compile without highmem support and 1 G lowmem
on arch/powerpc now to see if it makes a difference.
^ permalink raw reply
* Re: 82xx performance
From: Arnd Bergmann @ 2008-07-17 15:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04B34B71@ismail.innsys.innovsys.com>
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > If you can't get it to work, readprofile(1) is a much simpler
> > tool, both in what it can do and what it requires you to do.
>
> One thing that pops out is that handle_mm_fault uses twice as many
> ticks in arch/powerpc.
The other thing I found interesting is that cpu_idle is on the
top of the list in arch/powerpc but does not show up anywhere
in your top arch/ppc samples. This indicates that the system is
waiting for something, e.g. disk I/O for a significant amount
of time.
Seeing more hits in handle_mm_fault suggests that you have
a higher page fault rate. A trivial reason for this might
be that the amount of memory was misdetected in the new
code (maybe broken device tree). What is the content of
/proc/meminfo after a fresh boot?
If it's the same, try running a kernel build with 'time --verbose',
using GNU time instead of the bash builtin time to see how the
page fault rate changed.
Arnd <><
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Kumar Gala @ 2008-07-16 12:46 UTC (permalink / raw)
To: benh; +Cc: Dave Jones, akpm, Linus Torvalds, Linux Kernel list,
linuxppc-dev list
In-Reply-To: <1216184495.7740.158.camel@pasglop>
On Jul 16, 2008, at 12:01 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2008-07-16 at 00:20 -0400, Dave Jones wrote:
>> On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote:
>>> Linus,
>>>
>>> I apologize in advance for the couple of merge commits in there. I
>>> merged your tree yesterday in order to fix a (fairly minor)
>>> conflict,
>>> and waited for our autobuilder to test a whole bunch of configs
>>> overnight before asking you to pull, at which point, sfr informed
>>> me of
>>> a bunch of this time non-trivial conflicts with whatever you
>>> pulled in
>>> the meantime...
>>>
>>> So here it is with 2 merge csets at the top, I'll try to do better
>>> next
>>> time. I don't want to rebase or my sub-maintainers will hate me.
>>>
>>> So please pull from:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>>
>> Boom!
>>
>> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
>> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/
>> platforms/82xx/ep8248e.c:129: undefined reference to
>> `alloc_mdio_bitbang'
>> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/
>> platforms/82xx/ep8248e.c:143: undefined reference to
>> `mdiobus_register'
>>
>> .config is at http://davej.fedorapeople.org/kernel-2.6.27-ppc.config
>
> Kumar, I think that's your realm, what's up there ?
I'll look into this. On the note I'd like to add a ppc6xx_defconfig
and use the defconfig from Dave as the starts of that. Any objections?
- k
^ permalink raw reply
* Re: [PATCH 4/6] crypto: talitos - fix GFP flag usage
From: Kim Phillips @ 2008-07-17 15:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Herbert Xu, linux-crypto
In-Reply-To: <D59ED865-85CF-4C1E-9D79-D9DD0DE49505@kernel.crashing.org>
On Thu, 17 Jul 2008 07:26:14 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> 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 :)
In honouring requests that don't have the CRYPTO_TFM_REQ_MAY_SLEEP set,
afaict, it's the standard non-wait variant GFP that drivers use (see
the ixp4xx driver for e.g.).
Kim
^ permalink raw reply
* Re: Videomode 800x480
From: Detlev Zundel @ 2008-07-17 15:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <18482586.post@talk.nabble.com>
Hi Alex,
> Hello, the physical settings for sync are made by U-Boot and working!
> But in Lunux when I use 800x480, the screen is well, but the Kernel crashes
> at Bootup!
> Using 800x600 works!
> Now I need only "Dummy" settings, that I can tell Linux I would like 800x480
> and the Kernel doesn`t crash!
> I don`t know exactly why the Kernel crashes, I know only that the modedB
> 800x600 and so on work!
> I will try your settings immediately!
Your keymap seems to be broken. Try to include this in your ~/.Xmodmap
file:
keycode 10 = 1 period
Cheers
Detlev
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Booting ML405 (Kernel panic - not syncing: No init found)
From: Neeraj Garg @ 2008-07-17 15:23 UTC (permalink / raw)
To: Ron Sass; +Cc: linuxppc-embedded
In-Reply-To: <200807161447.m6GElde4032109@rsass-homer.uncc.edu>
[-- Attachment #1: Type: text/plain, Size: 8074 bytes --]
Hi,
I changed the owner of the busybox, and used chmod as you told me for
bin/busybox but its permission are -rwsrwxr-x not srwxrwxr-x-r.
--for compiling helloworld I used $powerpc-405-linux-gnu-gcc -static
helloworld.c -o helloworld
--For ramdisk creation I followed the following steps:
mkdir tmp/initrd
dd if=/dev/zero of=images/initrd.img bs=1k count=8192
/sbin/mke2fs -F -v -m0 images/initrd.img
mount -o loop images/initrd.img tmp/initrd
cp -av ramdisk/* tmp/initrd
//here ramdisk holds directory structure.. I copied directory structure
from git, linux support ...but I changed lib and bin contents (bin
contents with busybox-1.10.3 installation, and lib contents with lib of
my cross-compiler setup ,crosstool-0.28-rc35)
umount tmp/initrd
gzip < images/initrd.img > images/ramdisk.image.gz
----For making directory structure of ramdisk I followed following steps
for file in libc libcrypt libdl libm libpthread libresolv libutil
do
cp $file-*.so /home/neeraj/kerneldev/rootfs0.1/lib
cp -d $file.so.[*0-9] /home/neeraj/kerneldev/rootfs0.1/lib
done
cp -d ld*.so* /home/neeraj/kerneldev/rootfs0.1/lib
----And in menuconfig I selected filesystem as ramdisk with following
settings
<*> RAM block device support
(16) Default number of RAM disks
(32768) Default RAM disk size (kbytes)
// I think here can be the issue
-------------------------------------------------------------------
Neeraj Garg
Ron Sass wrote:
> Hmmm... I think you've got a problem with your ramdisk. There are
> a couple of issues but these alone don't explain your helloworld test.
>
> 1. busybox should be set to root not neeraj
> 2. you need to setuid busybox for some apps to run
> (chmod 4775 bin/busybox so that it is srwxrwxr-x-r)
> 3. I would be wary of Yaghmour's text... it is a little dated
> and if I remember correctly, he uses some regular expressions
> to copy "just" the libraries you need to lib; but with
> newer versions of gcc/glibc these regular expressions
> don't catch everything
>
> Two questions:
>
> Can you tell me exactly what your cross-compile command-line looks
> like? How are compiling helloworld?
>
> How are you creating the ramdisk? How do you go from directory
> structure to ramdisk.image.gz?
>
> Ron
>
>
>> Hi,
>>
>> --Ron,Permissions are -rwxrwxr-x for all and owner is neeraj itself. And
>> shared libraries are present in lib/ . Now I have placed helloworld.elf
>> (using printf to print helloworld, and linked with -static option) in
>> bin/ and changed init=/bin/helloworld , again it says cannot execute
>> /bin/helloworld.
>>
>> --John, we are using our custom hardware board, not exactly ML405 but
>> its more or less similar to ML405, so I cannot use bit file provided for
>> ML405. Till now we were using xilkernel, but now onward we are planning
>> to use Linux. For serial console I have no option other than uartlite.
>> This is how I compiled kernel :
>>
>> 1) make ARCH=ppc ml405_defconfig
>> 2) patched kernel src with EDK(10.1) , so as to change xparameter.h, and
>> later made some changed in arch/ppc/boot/simple/embed_config.c and
>> xparameters.h file.
>> 3) make ARCH=ppc menuconfig , and selected uartlite to be console and
>> ramdisk as file system.
>> 4) Created ramdisk (as per Building embedded linux, Karim Yaghmour,
>> however major and minor number for device nodes is similar to ramdisk
>> provided at git.xilinx.com)
>> 5) I have placed this ramdisk in arch/ppc/boot/images
>> 6) And then issued $make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu-
>> zImge.initrd
>>
>>
>> --I have downloaded ELDK4.1 and installed it. And when I compile
>> simple helloworld.c using cross compiler, it says unresolved symbol
>> 'printf' . Is there anything else to install with ELDK ?
>>
>>
>> -------------------------------------------------------------------
>> Neeraj Garg
>>
>>
>>
>> In addition to what John wrote, I would also investigate your ramdisk.
>> I would be sure to check that you have the permissions/owner set correctly
>> on bin/busybox. Also, I would double check that, if you compiled busybox
>> with shared libraries, the shared libraries are in the right place
>> on your ramdisk.
>>
>>
>> Ron
>>
>> >
>> > Hi,
>> >
>> > Yes I am using ARCH=ppc (actual line is $make ARCH=ppc
>> > CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I have
>> > placed ramdisk.image.gz in arch/ppc/boot/images. In case of ARCH=powerpc
>> > I cannot find processor type 405 , in make menuconfig. Thats why i am
>> > using ARCH=ppc.
>> >
>>
>> --------------060307000300070002040802
>> Content-Type: text/html; charset=ISO-8859-1
>> Content-Transfer-Encoding: 7bit
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>> <html>
>> <head>
>> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>> </head>
>> <body bgcolor="#ffffff" text="#000000">
>> Hi,<br>
>> <br>
>> --Ron,Permissions are -rwxrwxr-x for all and owner is neeraj itself.
>> And shared libraries are present in lib/ . Now I have placed
>> helloworld.elf (using printf to print helloworld, and linked with
>> -static option) in bin/ and changed init=/bin/helloworld , again it
>> says cannot execute /bin/helloworld. <br>
>> <br>
>> --John, we are using our custom hardware board, not exactly ML405 but
>> its more or less similar to ML405, so I cannot use bit file provided
>> for ML405. Till now we were using xilkernel, but now onward we are
>> planning to use Linux. For serial console I have no option other than
>> uartlite. This is how I compiled kernel :<br>
>> <br>
>> 1) make ARCH=ppc ml405_defconfig<br>
>> 2) patched kernel src with EDK(10.1) , so as to change xparameter.h,
>> and later made some changed in arch/ppc/boot/simple/embed_config.c and
>> xparameters.h file.<br>
>> 3) make ARCH=ppc menuconfig , and selected uartlite to be console and
>> ramdisk as file system.<br>
>> 4) Created ramdisk (as per Building embedded linux, Karim Yaghmour,
>> however major and minor number for device nodes is similar to ramdisk
>> provided at git.xilinx.com)<br>
>> 5) I have placed this ramdisk in arch/ppc/boot/images<br>
>> 6) And then issued $make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu-
>> zImge.initrd<br>
>> <br>
>> <br>
>> --I have downloaded ELDK4.1 and installed it. And when I compile
>> simple helloworld.c using cross compiler, it says unresolved symbol
>> 'printf' . Is there anything else to install with ELDK ?<br>
>> <br>
>> <br>
>> <div class="moz-signature">
>> <pre>-------------------------------------------------------------------
>> Neeraj Garg
>> </pre>
>> </div>
>> <br>
>> <br>
>> In addition to what John wrote, I would also investigate your ramdisk.
>> <br>
>> I would be sure to check that you have the permissions/owner set
>> correctly
>> <br>
>> on bin/busybox. Also, I would double check that, if you compiled
>> busybox
>> <br>
>> with shared libraries, the shared libraries are in the right place
>> <br>
>> on your ramdisk.<br>
>> <br>
>> <br>
>> Ron
>> <br>
>> <br>
>> > <br>
>> > Hi,
>> <br>
>> > <br>
>> > Yes I am using ARCH=ppc (actual line is $make ARCH=ppc <br>
>> > CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I
>> have <br>
>> > placed ramdisk.image.gz in arch/ppc/boot/images. In case of
>> ARCH=powerpc <br>
>> > I cannot find processor type 405 , in make menuconfig. Thats why i
>> am <br>
>> > using ARCH=ppc.
>> <br>
>> > <br>
>> <font color="navy" face="Arial" size="2"><span
>> style="font-size: 10pt; font-family: Arial; color: navy;"></span></font>
>> </body>
>> </html>
>>
>> --------------060307000300070002040802--
>>
>>
>> --===============0970715627==
>> Content-Type: text/plain; charset="us-ascii"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> --===============0970715627==--
>>
>>
[-- Attachment #2: Type: text/html, Size: 8871 bytes --]
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-17 15:20 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080717150422.GC31932@secretlab.ca>
On Thu, Jul 17, 2008 at 09:04:22AM -0600, Grant Likely wrote:
> On Thu, Jul 17, 2008 at 06:13:35PM +0400, Anton Vorontsov wrote:
> > On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
> > [...]
> > > > I think it would be better to have a module that scans the device tree
> > > > for LED nodes and registers a single leds-gpio platform device for the
> > > > whole lot.
> > > >
> > > > Thoughts?
> > >
> > > I like the idea, thanks.
> >
> > Ugh, no. The idea sounds good, but in practice it isn't, since we'll
> > have to handle suspend/resume ops ourselves. When we stick with the
> > device/driver model we're getting all this for free.
>
> Won't the leds-gpio driver give you suspend/resume support?
Ah. I just wrongly read your message. You're purposing to use gpio
leds platform driver... I think this is doable, yes.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: 82xx performance
From: Rune Torgersen @ 2008-07-17 15:12 UTC (permalink / raw)
To: Arnd Bergmann, Milton Miller, linuxppc-dev
In-Reply-To: <200807170032.36564.arnd@arndb.de>
Arnd Bergmann wrote:
> If you can't get it to work, readprofile(1) is a much simpler
> tool, both in what it can do and what it requires you to do.
One thing that pops out is that handle_mm_fault uses twice as many ticks
in arch/powerpc.
Top 20 calls from readprofile
2.6.25 arch/ppc
305993 total 0.1295
53301 __flush_dcache_icache 832.8281
25746 clear_pages 919.5000
19086 __copy_tofrom_user 33.3671
17198 get_page_from_freelist 13.3525
12741 _tlbia 353.9167
12317 handle_mm_fault 8.9774
9669 handle_page_fault 75.5391
8037 do_page_fault 9.5225
6450 cpu_idle 25.1953
5430 update_mmu_cache 21.8952
4663 copy_page 32.3819
3712 __link_path_walk 0.8452
3302 find_vma 19.6548
3241 __do_fault 2.6741
3235 unmap_vmas 2.1741
3184 lru_cache_add_active 16.5833
3076 __alloc_pages 3.8450
3062 find_lock_page 9.8141
2826 zone_watermark_ok 16.0568
2593 put_page 6.8237
2.6.25 arch/powerpc
60982 cpu_idle 262.8534
54601 __flush_dcache_icache_phys 650.0119
25676 clear_pages 917.0000
24892 handle_mm_fault 8.7772
19478 __copy_tofrom_user 34.0524
18112 get_page_from_freelist 12.3716
13245 _tlbia 367.9167
11976 do_page_fault 10.3241
10028 handle_page_fault 78.3438
6025 update_mmu_cache 23.5352
4650 page_address 15.7095
4097 copy_page 28.4514
4031 __do_fault 1.9838
3952 find_vma 27.4444
3861 __link_path_walk 0.9237
3533 unmap_vmas 2.2590
3400 lru_cache_add_active 19.3182
3317 find_lock_page 11.0567
3238 __alloc_pages 4.5223
2825 zone_watermark_ok 16.8155
2740 __d_lookup 5.8547
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Grant Likely @ 2008-07-17 15:07 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <20080717110730.GA24775@polina.dev.rtsoft.ru>
On Thu, Jul 17, 2008 at 03:07:30PM +0400, Anton Vorontsov wrote:
> On Thu, Jul 17, 2008 at 07:59:03AM +0200, Segher Boessenkool wrote:
> > 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"?
I like this idea (a 'leds' parent node). They aren't really children
of the GPIO node or any other device/bus in the system. Putting them
under a dedicated 'leds' node would make them easy to find and would
have the added advantage of making it easier to have a single driver
instance manage the whole lot.
g.
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Grant Likely @ 2008-07-17 15:04 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080717141335.GA2219@polina.dev.rtsoft.ru>
On Thu, Jul 17, 2008 at 06:13:35PM +0400, Anton Vorontsov wrote:
> On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
> [...]
> > > I think it would be better to have a module that scans the device tree
> > > for LED nodes and registers a single leds-gpio platform device for the
> > > whole lot.
> > >
> > > Thoughts?
> >
> > I like the idea, thanks.
>
> Ugh, no. The idea sounds good, but in practice it isn't, since we'll
> have to handle suspend/resume ops ourselves. When we stick with the
> device/driver model we're getting all this for free.
Won't the leds-gpio driver give you suspend/resume support?
g.
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Sean MacLennan @ 2008-07-17 14:58 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <20080717110730.GA24775@polina.dev.rtsoft.ru>
On Thu, 17 Jul 2008 15:07:30 +0400
"Anton Vorontsov" <avorontsov@ru.mvista.com> wrote:
> 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"?
I also put the leds under the gpio controller for the Warp. It is then
very clear which gpio controller the leds belong to.
Putting them at the top level does not associate the leds with the
correct gpio controller.
Warning: I am *not* using the of gpio led driver, but I hope to move to
it once the dust settles and drop the current Warp specific driver ;)
Cheers,
Sean
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Arnd Bergmann @ 2008-07-17 14:53 UTC (permalink / raw)
To: cbe-oss-dev, benh
Cc: linuxppc-dev, Roland Dreier, Peter Altevogt, Hans Boettiger
In-Reply-To: <1216275643.7740.302.camel@pasglop>
On Thursday 17 July 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-07-16 at 09:54 +0200, Arnd Bergmann wrote:
> > On Wednesday 16 July 2008, Roland Dreier wrote:
> > > > Strong ordering is only active when both the bridge and the IOMMU
> > > > enable it, but for correctly written drivers, this only results in a
> > > > slowdown.
> > >
> > > So when would someone use this dma attribute? As a hack to fix drivers
> > > where the real fix is too complicated?
> >
> > This is used in the Axon PCIe endpoint drivers, e.g. in the Roadrunner
> > machine. The reason was to improve roundtrip latency by doing only
> > mmio stores, not loads, on each side of the PCIe connection, which
> > turn into posted DMA operations on the other end. With relaxed ordering,
> > the posted writes may be observed out of order. Strong ordering makes
> > sure they arrive in-order without having to do a non-posted mmio read
> > or eieio operation on the receiver side.
>
> I don't think it's legal for writes from a given initiator to arrive to
> memory out of order.
>
> Some drivers, notably network drivers, for example, rely on the "OWN"
> bit being written last in memory when writing back ring buffer status.
>
> If the bit arrives before the actual data, then data corruption will
> occur.
Ok, this makes sense. I've followed the bit down in the specification,
and now it seems like we can't just set relaxed ordering in the IOMMU
but should use the value that comes from the PCIe device.
The flow of the order bit in this machine is as follows:
1. The device can select relaxed (weak) or non-relaxed (strong) ordering
for a DMA transfer. PCI-X is always strong, DMAx can be configured globally,
and PCIe is device specific.
2. The PCIe root complex can override the order bit and force it to strong
ordering (which we don't).
3. The PLB5-to-C3PO bridge can override the bit and force it to weak or
strong or leave it alone (we force it to weak).
4. The IOMMU can force the bit to weak on a per-page base (we don't without
the patch, but do with the patch).
Peter and Hans were involved in the discussion that led to the decision
to change step 3 from per-transfer default to always weak ordering.
I think they verified that this is safe for all the peripherals that we
have on the QS21 and QS22 blades (tg3, ehci, mthca, mptsas), but that
doesn't mean that it is safe in general, so I guess you are right that
we should not make it the default in the kernel for Cell systems.
Hans, can you confirm this?
Arnd <><
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-17 14:13 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080717140519.GA32617@polina.dev.rtsoft.ru>
On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote:
[...]
> > I think it would be better to have a module that scans the device tree
> > for LED nodes and registers a single leds-gpio platform device for the
> > whole lot.
> >
> > Thoughts?
>
> I like the idea, thanks.
Ugh, no. The idea sounds good, but in practice it isn't, since we'll
have to handle suspend/resume ops ourselves. When we stick with the
device/driver model we're getting all this for free.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Calling the kernel from a mini-bootloader
From: Guillaume Dargaud @ 2008-07-17 13:22 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I'm in the process of writing a mini-bootloaler for a custom board and would
like some feedback on my boot methodology.
Basically the kernel code (elf file) is copied into memory by a JTAG
debugger. A custom program (yet to be finished) then copies it onto an
onboard flash memory using serial commands. This flash is not part of the
flat memory addressing.
When I want to boot, I have a small bootloader put into an eprom that _is_
part of the flat memory addressing. This (finished but not tested yet)
bootloader basically does two things:
- it copies the content of the first flash into RAM
- it launches it using a custom function call like "0x400000();"
Now, I'd like to know if this is a reasonable approach ? I couldn't think of
a better way, but maybe there are issues I didn't think off.
One additional question, if the above is valid, is that I would like to pass
a particular argument to the kernel to set its MAC address. I can read an
external value (similar to jumpers) from the bootloader via GPIO. Is there a
way to pass this value to the kernel so that a modified
arch/ppc/boot/simple/embed_config.c can use it to set the MAC address ?
Maybe the main() of the kernel can receive argv/argc the usual way, and I
just need to call "0x400000(argc, argv);" but I have no idea if that works.
Thanks for suggestions.
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-17 14:05 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080717041531.GA27243@secretlab.ca>
On Wed, Jul 16, 2008 at 10:15:31PM -0600, Grant Likely wrote:
> On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> > On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> > > Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> > > is not much code can be shared between the two drivers (both are mostly
> > > driver bindings anyway).
> >
> > Why can't this driver use the existing gpio-led driver? Basically, do
> > something like this:
> >
> > of_gpio_leds_probe(...)
> > {
> > gpio = of_get_gpio(np, 0);
> > label = of_get_property(np, "label", NULL);
> >
> > struct gpio_led led = {
> > .name = label,
> > .gpio = gpio,
> > };
> >
> > pdev = platform_device_register_simple("leds-gpio", 0, NULL, 0);
> > platform_device_add_data(pdev, &led, sizeof(led));
> > }
>
> Ugh; that means registering *2* 'struct device' with the kernel instead of
> one. One as a platform device and one as an of_platform device.
> It's bad enough that the LED scheme we're using for OF bindings has a
> separate registration for every single LED.
>
> Now that it comes to it, I worry that this driver takes the wrong
> approach. The number of resources dedicated per LED in this driver
> seems pretty loony to me (one of_platform device per LED). The fact
> that the binding specifies one node per LED makes of_platform not a very
> efficient solution.
>
> I think it would be better to have a module that scans the device tree
> for LED nodes and registers a single leds-gpio platform device for the
> whole lot.
>
> Thoughts?
I like the idea, thanks.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: powerpc: Fix OF parsing of 64 bits PCI addresses
From: Segher Boessenkool @ 2008-07-17 14:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216274011.7740.293.camel@pasglop>
> The OF parsing code for PCI addresses isn't always treating properly
> the address space indication 0b11 (ie. 0x3) as meaning 64 bits
> memory space.
>
> This means that it fails to parse addresses for PCI BARs that have
> this encoding set by the firmware, which happens on some SLOF
> versions and breaks offb palette handling on Powerstation.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Looks good.
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-17 13:55 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807162143460.26314@t2.domain.actdsltmp>
On Wed, Jul 16, 2008 at 10:13:06PM -0700, Trent Piepho wrote:
> on Wed, 16 Jul 2008, Grant Likely wrote:
> > On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
> >> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> >>> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> >>> is not much code can be shared between the two drivers (both are mostly
> >>> driver bindings anyway).
> >>
> >> Why can't this driver use the existing gpio-led driver? Basically, do
> >> something like this:
> >>
> >
> > Ugh; that means registering *2* 'struct device' with the kernel instead of
> > one. One as a platform device and one as an of_platform device.
> > It's bad enough that the LED scheme we're using for OF bindings has a
> > separate registration for every single LED.
>
> Ok, how about adding code the existing leds-gpio driver so that it can creates
> LEDs from of_platform devices too?
Few comments below.
> I've made a patch to do this and it works ok. The code added to leds-gpio is
> about half what was involved in Anton's new driver.
This isn't true.
> What I did was re-factor
> the existing platform device probe function to use a new function that creates
> a single led. Then a new of_platform probe function can use it too. That way
> most of the probe code is shared. remove, suspend and resume aren't shared,
> but they're short. And the existing code to actually drive the led gets
> reused as is.
>
> There is still one of_platform device per led because of how the bindings work
> (but that could be changed with new bindings), but there are zero extra
> platform devices created.
You didn't count extra platform driver. You can't #ifdef it. The only way
you can avoid this is creating leds-gpio-base.c or something, and place the
helper functions there.
> Here's an example patch. It won't apply to the git kernel as is, but should
> make it clear how this works.
>
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index a4a2838..12e681e 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -71,11 +71,45 @@ static int gpio_blink_set(struct led_classdev *led_cdev,
> return led_dat->platform_gpio_blink_set(led_dat->gpio, delay_on, delay_off);
> }
>
> +static int create_gpio_led(struct gpio_led *cur_led,
The create_gpio_led() interface is also quite weird, since it implies that
we have to pass two GPIO LED "handles": struct gpio_led_data (that we
allocated) and temporary struct gpio_led. And this helper function will
just assign things from one struct to another, and then will register the
led.
With OF driver I don't need "struct gpio_led". Only the platform driver
need this so platforms could pass gpio led info through it, while with OF
we're getting all information from the device tree.
I'm not opposed to another struct used in the OF driver though, I'm rather
opposed to the indirectness it introduces. But I also believe that we
can refactor the code so it will look neat. I just don't want to do
all this churn to save mere 30 lines of code.
> + struct gpio_led_data *led_dat, struct device *parent,
> + int (*blink_set)(unsigned, unsigned long *, unsigned long *))
We don't need blink_set. Personally I think that accepting blink
support in leds-gpio driver was... um, not right. In OF driver we'll
never use it. We support just GPIO LEDs, not PWM LEDs.
> +
> +{
> + int ret;
> +
> + ret = gpio_request(cur_led->gpio, cur_led->name);
> + if (ret < 0)
> + return ret;
> +
> + led_dat->cdev.name = cur_led->name;
> + led_dat->cdev.default_trigger = cur_led->default_trigger;
> + led_dat->gpio = cur_led->gpio;
> + led_dat->can_sleep = gpio_cansleep(cur_led->gpio);
> + led_dat->active_low = cur_led->active_low;
> + if (blink_set) {
> + led_dat->platform_gpio_blink_set = blink_set;
> + led_dat->cdev.blink_set = gpio_blink_set;
> + }
> + led_dat->cdev.brightness_set = gpio_led_set;
> + led_dat->cdev.brightness = cur_led->start_on ? LED_FULL : LED_OFF;
> +
> + gpio_direction_output(led_dat->gpio,
> + led_dat->active_low ^ cur_led->start_on);
> +
> + INIT_WORK(&led_dat->work, gpio_led_work);
> +
> + ret = led_classdev_register(parent, &led_dat->cdev);
> + if (ret < 0)
> + gpio_free(led_dat->gpio);
> +
> + return ret;
> +}
> +
> static int gpio_led_probe(struct platform_device *pdev)
> {
> struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
> - struct gpio_led *cur_led;
> - struct gpio_led_data *leds_data, *led_dat;
> + struct gpio_led_data *leds_data;
> int i, ret = 0;
>
> if (!pdata)
> @@ -87,36 +121,10 @@ static int gpio_led_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> for (i = 0; i < pdata->num_leds; i++) {
> - cur_led = &pdata->leds[i];
> - led_dat = &leds_data[i];
> -
> - ret = gpio_request(cur_led->gpio, cur_led->name);
> + ret = create_gpio_led(&pdata->leds[i], &leds_data[i],
> + &pdev->dev, pdata->gpio_blink_set);
> if (ret < 0)
> goto err;
> -
> - led_dat->cdev.name = cur_led->name;
> - led_dat->cdev.default_trigger = cur_led->default_trigger;
> - led_dat->gpio = cur_led->gpio;
> - led_dat->can_sleep = gpio_cansleep(cur_led->gpio);
> - led_dat->active_low = cur_led->active_low;
> - if (pdata->gpio_blink_set) {
> - led_dat->platform_gpio_blink_set = pdata->gpio_blink_set;
> - led_dat->cdev.blink_set = gpio_blink_set;
> - }
> - led_dat->cdev.brightness_set = gpio_led_set;
> - led_dat->cdev.brightness =
> - cur_led->start_on ? LED_FULL : LED_OFF;
> -
> - gpio_direction_output(led_dat->gpio,
> - led_dat->active_low ^ cur_led->start_on);
> -
> - INIT_WORK(&led_dat->work, gpio_led_work);
> -
> - ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
> - if (ret < 0) {
> - gpio_free(led_dat->gpio);
> - goto err;
> - }
> }
>
> platform_set_drvdata(pdev, leds_data);
> @@ -217,3 +225,105 @@ MODULE_AUTHOR("Raphael Assenat <raph@8d.com>");
> MODULE_DESCRIPTION("GPIO LED driver");
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("platform:leds-gpio");
> +
> +
> +/* #ifdef CONFIG_LEDS_GPIO_OF */
Heh.
> +/* OpenFirmware bindings */
> +#include <linux/of_platform.h>
> +
> +/* crap for old kernel, ignore */
> +static inline const char *dev_name(struct device *dev)
> +{ return dev->bus_id; }
> +int of_get_gpio(struct device_node *np, int index)
> +{ const u32 *pp = of_get_property(np, "gpio", NULL); return pp ? *pp : -1; }
> +
> +static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct device_node *np = ofdev->node;
> + struct gpio_led led;
> + struct gpio_led_data *led_dat;
> + int ret;
> +
> + led_dat = kzalloc(sizeof(*led_dat), GFP_KERNEL);
> + if (!led_dat)
> + return -ENOMEM;
> +
> + memset(&led, 0, sizeof(led));
> + led.gpio = of_get_gpio(np, 0);
> + led.name = of_get_property(np, "label", NULL);
> + if (!led.name)
> + led.name = dev_name(&ofdev->dev);
> +
> + ret = create_gpio_led(&led, led_dat, &ofdev->dev, NULL);
> + if (ret < 0) {
> + kfree(led_dat);
> + return ret;
> + }
> +
> + dev_set_drvdata(&ofdev->dev, led_dat);
> +
> + return 0;
> +}
> +
> +static int __devexit of_gpio_leds_remove(struct of_device *ofdev)
> +{
> + struct gpio_led_data *led = dev_get_drvdata(&ofdev->dev);
> +
> + led_classdev_unregister(&led->cdev);
> + cancel_work_sync(&led->work);
> + gpio_free(led->gpio);
> + kfree(led);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int of_gpio_led_suspend(struct of_device *ofdev, pm_message_t state)
> +{
> + struct gpio_led_data *led = dev_get_drvdata(&ofdev->dev);
> +
> + led_classdev_suspend(&led->cdev);
> + return 0;
> +}
> +
> +static int of_gpio_led_resume(struct of_device *ofdev)
> +{
> + struct gpio_led_data *led = dev_get_drvdata(&ofdev->dev);
> +
> + led_classdev_resume(&led->cdev);
> + return 0;
> +}
> +#else
> +#define of_gpio_led_suspend NULL
> +#define of_gpio_led_resume NULL
> +#endif /* CONFIG_PM */
> +
> +static const struct of_device_id of_gpio_leds_match[] = {
> + { .compatible = "gpio-led", },
> + {},
> +};
> +
> +static struct of_platform_driver of_gpio_leds_driver = {
> + .driver = {
> + .name = "of_gpio_leds",
> + .owner = THIS_MODULE,
> + },
> + .match_table = of_gpio_leds_match,
> + .probe = of_gpio_leds_probe,
> + .remove = __devexit_p(of_gpio_leds_remove),
> + .suspend = of_gpio_led_suspend,
> + .resume = of_gpio_led_resume,
> +};
> +
> +static int __init of_gpio_leds_init(void)
> +{
> + return of_register_platform_driver(&of_gpio_leds_driver);
> +}
> +module_init(of_gpio_leds_init);
> +
> +static void __exit of_gpio_leds_exit(void)
> +{
> + of_unregister_platform_driver(&of_gpio_leds_driver);
> +}
> +module_exit(of_gpio_leds_exit);
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] dtc: supply a definition for YYRHSLOC if there isn't one
From: Paul Gortmaker @ 2008-07-17 14:02 UTC (permalink / raw)
To: Paul Gortmaker, linuxppc-dev, jdl
In-Reply-To: <20080717054713.GF21564@yookeroo.seuss>
David Gibson wrote:
> On Wed, Jul 16, 2008 at 01:53:57PM -0400, Paul Gortmaker wrote:
>
>> It seems that some machines, like a default RHEL4 install, will
>> not have a definition for YYRHSLOC, and that prevents building
>> dtc. This supplies what appears to be the standard definition
>> for it in the event that the host system does not have it defined.
>>
>
> I'm pretty uneasy about this, since it relies on knowing the internals
> of how bison manages its tokens. What version of bison is it in RHEL4
> that causes the trouble?
>
Right -- well, I trust your judgment on something like that more than
my own. The version in question is "bison (GNU Bison) 1.875c".
When I was digging around, the definitions all pretty much came back
with the one I'd used, but I do understand your concern.
> In fact I have a feeling that the extra 'file' field in YYLTYPE never
> gets used, which means we could just ditch our custom YYLLOC_DEFAULT
> definition, which would be a better idea, IMO, except that we'll
> probably want the file info back at some point.
>
> Ick.
>
Sorry to be the bearer of bad news :-) If you have an alternate fix that
you'd like me to test, I'd be happy to do so; I've still access to the old
machine on which the problem report was 1st bounced to me from. If I
tried to fix it in any other way than what I did, I'd probably hurt
myself...
Paul.
^ permalink raw reply
* Re: [HOW] binutils-2.17 breaks the 2.6.26 kernel
From: Segher Boessenkool @ 2008-07-17 13:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: ppcdev, Alan Modra, Milton Miller
In-Reply-To: <9e4733910807161738g58da8bd7v78e9d50dc4d846cb@mail.gmail.com>
> Previous threads have mentioned that binutil-2.17 is broken for
> building powerpc kernels. It is fixed in binutils-2.18.
Yes.
> I have encountered this and upgrading to 2.18 fixed my build. The
> symptom is large kernel sizes and a long time in gzip. In my case it
> was gziping a 2GB file.
Are you using a "binary" (non-ELF) image file? This sounds like a
different problem, caused by the kernel linker script not handling
the build-id section correctly -- it places it at 0, and the rest
of the kernel at 3GB, you can imagine the rest. I've seen this
on various embedded targets, but not on PowerPC iirc -- maybe I
don't build any affected defconfig, what's yours?
I have a working (tested! thanks Milton) workaround for the current
problem, will send it later today. This problem funnily is hidden
by the presence of build-id :-)
Segher
^ permalink raw reply
* Re: use xilinx gpio from linux on a ppc405
From: Joachim Meyer @ 2008-07-17 13:40 UTC (permalink / raw)
To: Jens Wirth; +Cc: linuxppc-embedded
Hi Jens
Thanks for your fast answer.
I have some questions befor I try it out:
1. Can I proof, if my gpio is correctly connected with my design or should I try it to proof it?
2. Is the code you send c? If yes, do I need any specific libaries? Then I crosscompile it, put it on my Board and it should work?
3. In edk I saw This at the 4 LEDs:
Base Adress: 0x40000000
High Adress: 0x4000ffff
How would it be for my case? Something like this:
char *mapped_address = ioremap(0x40000000, 0xffff);
writeb(0xffff, mapped_address);
iounmap(mapped_address);
I don't understand why the there are so many steps between the base and the high adress.
Thanks and Greez
Joachim
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Chirag Jog @ 2008-07-17 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-rt-users, Josh Triplett, Steven Rostedt, linuxppc-dev,
Nivedita Singhvi, Timothy R. Chavez, Thomas Gleixner, paulmck,
linux.kernel
In-Reply-To: <1216085521.7740.37.camel@pasglop>
Hi Benjamin,
Thanks for the review
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2008-07-15 11:32:01]:
> On Wed, 2008-07-09 at 21:35 +0530, Chirag Jog wrote:
> > Hi,
> > This patch fixes various paths in the -rt kernel on powerpc64 where per_cpu
> > variables are accessed in a preempt unsafe way.
> > When a power box with -rt kernel is booted, multiple BUG messages are
> > generated "BUG: init:1 task might have lost a preemption check!".
> > After booting a kernel with these patches applied, these messages
> > don't appear.
> >
> > Also I ran the realtime tests from ltp to ensure the stability.
>
> That sounds bad tho...
>
> IE. You are changing the code to lock/unlock on all those TLB batching
> operations, but seem to miss the core reason why it was done that way:
> ie, the code assumes that it will not change CPU -between- those calls,
> since the whole stuff should be already have been within a per-cpu
> locked section at the caller level.
>
All these operations are done assuming that tlb_gather_mmu disables
preemption and tlb_finish_mmu enables preemption again.
This is not true for -rt.
For x86, none of the code paths between tlb_gather_mmu and
tlb_finish_mmu access any per_cpu variables.
But this is not true for powerpc64 as we can see.
One way could be to make tlb_gather_mmu disable preemption as it does
in mainline but only for powerpc.
Although i am not sure, if this is the right step ahead.
I am attaching a patch below for the same.
I have left out the tce bits, as they are fine.
Note: I haven't extensively tested the patch
- Thanks,
Chirag
Index: linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c
===================================================================
--- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/tlb_64.c 2008-07-17 16:51:31.000000000 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c 2008-07-17 16:51:33.000000000 +0530
@@ -37,7 +37,7 @@
/* This is declared as we are using the more or less generic
* include/asm-powerpc/tlb.h file -- tgall
*/
-DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
+DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
@@ -96,7 +96,7 @@
* This is safe since tlb_gather_mmu has disabled preemption.
* tlb->cpu is set by tlb_gather_mmu as well.
*/
- cpumask_t local_cpumask = cpumask_of_cpu(tlb->cpu);
+ cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
Index: linux-2.6.25.8-rt7/arch/powerpc/mm/init_32.c
===================================================================
--- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/init_32.c 2008-07-17 16:51:31.000000000 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/mm/init_32.c 2008-07-17 16:51:33.000000000 +0530
@@ -54,7 +54,7 @@
#endif
#define MAX_LOW_MEM CONFIG_LOWMEM_SIZE
-DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
+DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
unsigned long total_memory;
unsigned long total_lowmem;
Index: linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h
===================================================================
--- linux-2.6.25.8-rt7.orig/include/asm-powerpc/tlb.h 2008-07-17 16:51:31.000000000 +0530
+++ linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h 2008-07-17 16:51:33.000000000 +0530
@@ -46,11 +46,8 @@
* pages are going to be freed and we really don't want to have a CPU
* access a freed page because it has a stale TLB
*/
- if (tlbbatch->index) {
- preempt_disable();
+ if (tlbbatch->index)
__flush_tlb_pending(tlbbatch);
- preempt_enable();
- }
pte_free_finish();
}
Index: linux-2.6.25.8-rt7/include/asm-generic/tlb.h
===================================================================
--- linux-2.6.25.8-rt7.orig/include/asm-generic/tlb.h 2008-07-17 16:51:31.000000000 +0530
+++ linux-2.6.25.8-rt7/include/asm-generic/tlb.h 2008-07-17 17:33:02.000000000 +0530
@@ -41,23 +41,32 @@
unsigned int nr; /* set to ~0U means fast mode */
unsigned int need_flush;/* Really unmapped some ptes? */
unsigned int fullmm; /* non-zero means full mm flush */
+#if !defined(__powerpc64__)
int cpu;
+#endif
struct page * pages[FREE_PTE_NR];
};
/* Users of the generic TLB shootdown code must declare this storage space. */
-DECLARE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
-
+#if !defined(__powerpc64__)
+ DECLARE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
+#else
+ DECLARE_PER_CPU(struct mmu_gather, mmu_gathers);
+#endif
/* tlb_gather_mmu
* Return a pointer to an initialized struct mmu_gather.
*/
static inline struct mmu_gather *
tlb_gather_mmu(struct mm_struct *mm, unsigned int full_mm_flush)
{
- int cpu;
- struct mmu_gather *tlb = &get_cpu_var_locked(mmu_gathers, &cpu);
- tlb->cpu = cpu;
+#if !defined(__powerpc64__)
+ int cpu;
+ struct mmu_gather *tlb = &get_cpu_var_locked(mmu_gathers, &cpu);
+ tlb->cpu = cpu;
+#else
+ struct mmu_gather *tlb = &get_cpu_var(mmu_gathers);
+#endif
tlb->mm = mm;
/* Use fast mode if only one CPU is online */
@@ -93,7 +102,11 @@
/* keep the page table cache within bounds */
check_pgt_cache();
- put_cpu_var_locked(mmu_gathers, tlb->cpu);
+#if !defined(__powerpc64__)
+ put_cpu_var_locked(mmu_gathers, tlb->cpu);
+#else
+ put_cpu_var(mmu_gathers);
+#endif
}
/* tlb_remove_page
^ permalink raw reply
* RE: linux boot sequence
From: Rami WEHBI @ 2008-07-17 12:42 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-embedded
Hello Siva,
I am using the 2.6.23 kernel and the target is the ppc405.=20
Using the booting-without-of.txt, and in searching in the kernel code I =
found that the devices_info are passed as parameters (memory size is the =
parameter I am searching for) by calling the function =
"find_bootinfo(void)" in /arch/ppc/kernel/setup.c
This function initializes send the pointer to linux on the device info =
as following (line 345):
Rec =3D (struct bi_record *) =
_ALIGN((ulong)__bss_start+(1<<20)-1,(1<<20));
What is this address stand for ???=20
Rami,
-----Message d'origine-----
De : linuxppc-embedded-bounces+rami.wehbi=3Dwirecom-tech.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+rami.wehbi=3Dwirecom-tech.com@ozlabs.or=
g] De la part de Siva Prasad
Envoy=E9 : mercredi 16 juillet 2008 20:46
=C0 : Rami WEHBI
Cc : linuxppc-embedded@ozlabs.org
Objet : RE: linux boot sequence
Rami,
Please make sure to copy the list as well.
OF - Open firmware. I am not sure which version of Linux kernel you are =
using, and which boot loader. Lately it is all OF based, however it is =
supported in the form of device tree blob/structure. For more =
information read booting-without-of.txt in Documentation/powerpc.
U-Boot updates the detected memory in the dtb you loaded, so that when =
kernel reads it, correct information is provided.
There is no auto-detect option in kernel. You need to write your own =
code at the exact location it needs to identify the size of memory. =
Typically this is passed to the kernel either through DTB or kernel =
arguments.
Good Luck.
- Siva
-----Original Message-----
From: Rami WEHBI [mailto:rwehbi@wirecom-tech.com]
Sent: Monday, July 14, 2008 11:47 PM
To: Siva Prasad
Subject: RE: linux boot sequence
what is the OF dtb ??? And how does the bootloader update it ???
How can I do to set the autodetect option in the kernel ???
Best Regards,
Rami,
-----Message d'origine-----
De : Siva Prasad [mailto:sprasad@bivio.net]=20
Envoy=E9 : vendredi 11 juillet 2008 23:01
=C0 : Rami WEHBI
Cc : linuxppc-embedded@ozlabs.org
Objet : linux boot sequence
Well!... You can pass the size as part of the OF memory=3D<>.
Typically your boot loader should detect the amount of memory on the =
system and update the OF dtb to reflect the available memory.
You may also tweak the kernel yourself to autodetect, instead of reading =
from the OF. How ever, I would recommend the previous approach.
- Siva
Date: Fri, 11 Jul 2008 08:34:54 +0200
From: "Rami WEHBI" <rwehbi@wirecom-tech.com>
Subject: linux boot sequence
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
=09
<D3C541E264C021479BFB60B3B790C0FB497014@etoilenoire.STARWARS.local>
Content-Type: text/plain; charset=3D"iso-8859-1"
Hi all,
=20
I am using the ppc405 and I would like to know, how does linux on =
this architect detect the available memory size in details !!!
is it a parameter passed to linux at startup by the boot loader =
??
is it an automatic detection ?? what are the steps to accomplish =
this job then ???
=20
Best regards to all,
=20
Rami
=20
Rami WEHBI =09
Recherche & D?veloppement =09
T?l : +33 2 36 56 86 00=09
Fax : +33 2 36 56 86 01=09
www.wirecom-tech.com=09
<http://www.wirecom-tech.com> =09
WIRECOM Technologies
135, Rue Jacques Charles
45166 Olivet
=09
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: Use PPC_LONG and PPC_LONG_ALIGN in lib/string.S
From: Kumar Gala @ 2008-07-17 12:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <36B8084A-B0E4-48D5-97FD-05DD68D4A5D8@kernel.crashing.org>
On Jul 17, 2008, at 7:28 AM, Kumar Gala wrote:
>
> 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?
ignore me.. when I look closer its obvious.
- k
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Use PPC_LONG_ALIGN in uaccess.h
From: Kumar Gala @ 2008-07-17 12:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5F490C95-09E9-4378-B0B9-891FED7B182C@kernel.crashing.org>
On Jul 17, 2008, at 7:28 AM, Kumar Gala wrote:
>
> 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?
ignore me.. when I look closer its obvious.
- k
^ permalink raw reply
* 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
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