* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Martin Schwidefsky @ 2009-07-20 7:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Nick Piggin, Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <1248073873.13067.31.camel@pasglop>
On Mon, 20 Jul 2009 17:11:13 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > > I would like to merge the new support that depends on this in 2.6.32,
> > > so unless there's major objections, I'd like this to go in early during
> > > the merge window. We can sort out separately how to carry the patch
> > > around in -next until then since the powerpc tree will have a dependency
> > > on it.
> >
> > Can't see any problem with that.
>
> CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
> far nobody objected to the patch itself)
>
> IE. The patch affects all archs, though it's a trivial change every
> time, but I'll have stuff in powerpc-next that depends on it, and so I'm
> not sure what the right approach is here. Should I put it in the powerpc
> tree ?
>
> I also didn't have any formal Ack from anybody, neither mm folks nor
> arch maintainers :-)
Well the change is trivial, it just adds another unused argument to the
macros. For the records: it still compiles on s390.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te,ud,md}_free_tlb()
From: Benjamin Herrenschmidt @ 2009-07-20 7:11 UTC (permalink / raw)
To: Nick Piggin
Cc: Linux-Arch, linuxppc-dev, Hugh Dickins, linux-kernel,
Linux Memory Management, Linus Torvalds
In-Reply-To: <20090715135620.GD7298@wotan.suse.de>
On Wed, 2009-07-15 at 15:56 +0200, Nick Piggin wrote:
> > I would like to merge the new support that depends on this in 2.6.32,
> > so unless there's major objections, I'd like this to go in early during
> > the merge window. We can sort out separately how to carry the patch
> > around in -next until then since the powerpc tree will have a dependency
> > on it.
>
> Can't see any problem with that.
CC'ing Linus here. How do you want to proceed with that merge ? (IE. so
far nobody objected to the patch itself)
IE. The patch affects all archs, though it's a trivial change every
time, but I'll have stuff in powerpc-next that depends on it, and so I'm
not sure what the right approach is here. Should I put it in the powerpc
tree ?
I also didn't have any formal Ack from anybody, neither mm folks nor
arch maintainers :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Mounting a USB flash stick based root FS directly.
From: Cristian Axenie @ 2009-07-20 5:14 UTC (permalink / raw)
To: Dushara Jayasinghe; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C20DE6983@mailsvr>
Hello !
If you properly set the root fs on your USB flash you should try to
set it up using some uBoot bootargs :
e.g. :
setenv usbstick_args setenv bootargs root=/dev/sdXX ro
rootdelay=$HOW_MANY_SECONDS_TO_WAIT rootfstype=$YOUR_FS_TYPE
init=/sbin/init console=$consoledev,$baudrate;
setenv usbstick 'run usbstick_args;bootm fe500000 - fe700000'
setenv bootcmd run usbstick
Best !
On 7/20/09, Dushara Jayasinghe <DusharaJ@optiscan.com> wrote:
> Hi all,
>
> I'm attempting to mount the root file system directly from a USB flash stick
> (thus avoiding a ram-disk). The init thread is delayed until the USB device
> is enumerated. However, I find the call to sys_mount() in line 218 @
> http://git.denx.de/?p=linux-2.6-denx.git;a=blob;f=init/do_mounts.c;h=8d4ff5afc1d80b56963cbf119b162a3ebce61124;hb=ad2a8c8d0593bf2d1ef163f1ca7574f02b2e770e
> fails. The problem is I can't work out where sys_mount() is implemented.
>
> I'm working off the 2.6.29-DENX kernel (commit id
> ad2a8c8d0593bf2d1ef163f1ca7574f02b2e770e). and My target CPU is an
> mpc8349.
>
>
> Thanks in advance.
>
>
> Dushara Jayasinghe
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Mounting a USB flash stick based root FS directly.
From: Dushara Jayasinghe @ 2009-07-20 2:04 UTC (permalink / raw)
To: 'linuxppc-dev@lists.ozlabs.org'
Hi all,
I'm attempting to mount the root file system directly from a USB flash stic=
k (thus avoiding a ram-disk). The init thread is delayed until the USB devi=
ce is enumerated. However, I find the call to sys_mount() in line 218 @ htt=
p://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dblob;f=3Dinit/do_mounts.c;h=3D8=
d4ff5afc1d80b56963cbf119b162a3ebce61124;hb=3Dad2a8c8d0593bf2d1ef163f1ca7574=
f02b2e770e fails. The problem is I can't work out where sys_mount() is impl=
emented.
I'm working off the 2.6.29-DENX kernel (commit id ad2a8c8d0593bf2d1ef163f1c=
a7574f02b2e770e). and My target CPU is an
mpc8349.
Thanks in advance.
Dushara Jayasinghe
^ permalink raw reply
* Re: proper way to reserve a chunk of memory at the top of the kernel?
From: Benjamin Herrenschmidt @ 2009-07-20 1:54 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev, Linux kernel
In-Reply-To: <4A5CF62F.6020102@nortel.com>
On Tue, 2009-07-14 at 15:18 -0600, Chris Friesen wrote:
> I have a powerpc board with 512BM of memory. The BIOS has a chunk of
> memory at the top end of physical memory which it does not zero out over
> a reboot.
>
> What's the proper way to tell linux that this chunk of physical memory
> should be ignored (so that we can access it later without worrying that
> Linux will try to allocate it)? Should I be calling
>
> lmb_reserve(lmb_end_of_DRAM() - size, size);
>
> in early_reserve_mem() or is there a better mechanism?
The device-tree blob contains a special "reserve map" in the header,
which automatically turns into calls to lmb_reserve() early during boot,
so putting your special region in that map should be the right way to do
what you want without special code.
> For comparison, in an older kernel this was done in set_phys_avail(), by
> calling mem_pieces_remove(&phys_avail, total_lowmem - size, size, 1);
Cheers,
Ben.
> Thanks,
>
> Chris
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* PPCboot and latest kernel
From: vijay sharma @ 2009-07-19 18:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <e571380d0907191132u3985423aiacc7ec8c75c0534b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
Hi ALL,
I have been woking on upgrading an embedded system based on MPC8241 from
2.4.17 linux to 2.6.30 kernel.
I am currently struck one point.
Here is the console output where I am struck:
=================================
cpboot> bootm
## Booting image at 08000000 ...
Image Name: Linux-2.6.30
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 21729342 Bytes = 21220 kB = 20 MB
Load Address: 01900000
Entry Point: 01900570
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory <- <0x0 0x10000000> (256MB)
CPU clock-frequency <- 0xbebc1fe (200MHz)
CPU timebase-frequency <- 0x17d783f (25MHz)
CPU bus-frequency <- 0x5f5e0ff (100MHz)
zImage starting: loaded at 0x01900000 (sp: 0x0fdc3a08)
Allocating 0x165ca04 bytes for kernel ...
gunzipping (0x00000000 <- 0x0190c000:0x02f58efc)...done 0x1637b54 bytes
Linux/PowerPC load:
Finalizing device tree... flat tree at 0x2f65300 <== Beyond this point no
output is available.
(The size of image is 20MB because ramfs embedded inside the image)
==================================
Here are the steps I have taken till now.
1) Defined platform.dts file for my platform. Since I am using MPC8241, I
have taken cuboot-824x.c. Is this file correct.
Do I need to define my own cuboot-*.c file ?
2)Built cuImage and loaded it into memory. I am not seeing any output once
control passes from wrapper to kernel. As you can see from logs mentioned
above.
While going through mail achieves I found two possible reasons for this
1) Wrong entries inside dts file
I am sure serial attributes are correctly defined inside the file. Also it
works for wrapper. It should work for linux also.
2) PPCboot not providing information.
I have built cuImage . Shouldn't kernel be getting its attributes from dtb
file rather then depending on bd_info structure.
I cannot upgrade to uboot. Is there some way I can make my board come up?
Thanks in advance,
Vijay
[-- Attachment #2: Type: text/html, Size: 2603 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: Fix MPIC_BROKEN_REGREAD on non broken MPICs
From: Olof Johansson @ 2009-07-19 15:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <6c9c0889feaceeea55bd2b6fef0c19e408425ef5.1246846125.git.michael@ellerman.id.au>
On Mon, Jul 06, 2009 at 12:08:52PM +1000, Michael Ellerman wrote:
> The workaround enabled by CONFIG_MPIC_BROKEN_REGREAD does not work
> on non-broken MPICs. The symptom is no interrupts being received.
>
> The fix is twofold. Firstly the code was broken for multiple isus,
> we need to index into the shadow array with the src_no, not the idx.
> Secondly, we always do the read, but only use the VECPRI_MASK and
> VECPRI_ACTIVITY bits from the hardware, the rest of "val" comes
> from the shadow.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Olof Johansson <olof@lixom.net>
Tested OK here on an electra. Thanks for fixing this!
-Olof
^ permalink raw reply
* ethtool support in ethernet driver
From: Mohd Arif @ 2009-07-19 11:42 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Dear All,
Happy to be a part of this mailing list!!!!!
The issue is that i want to give support of ethtool in ethernet
driver.
Where do i need to make changes in the driver?
I have never been into driver stuff.
So kindly suggest me accordingly.
Best Regards,
Mohd. Arif
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
-----------------------------------------------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 2329 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: Grant Likely @ 2009-07-18 18:37 UTC (permalink / raw)
To: avorontsov; +Cc: leoli, netdev, linuxppc-dev, afleming, davem
In-Reply-To: <20090718180448.GA3252@oksana.dev.rtsoft.ru>
On Sat, Jul 18, 2009 at 12:04 PM, Anton
Vorontsov<avorontsov@ru.mvista.com> wrote:
> On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote:
> [...]
>> Part of the problem I think is that the phylib code merges two separate
>> constructs; the construct of an MDIO bus (on which many device may
>> reside, not all of them PHYs), and the construct of an MII link whose
>> speed and configuration need to be manipulated. =A0I've run into problem=
s
>> myself on how best to handle things like Ethernet switches which
>> definitely do not behave like PHYs and the phylib state machine cannot
>> be used on them. =A0It seems to me that the whole 'dummy phy' approach
>> is just an artifact of the phylib model not being quite right yet.
>
> Yep. With a bit of phylib rework we can remove all the MDIO emulation
> stuff from phy/fixed.c driver, and leave there just speed/duplex/pause
> assignments.
>
> Though, I still believe that we should avoid two code paths in the
> drivers. One of the code paths will be constantly broken if we do so.
Yes, I agree. Splitting the concepts also has the added advantage
that non-phy devices will have an interface to manipulate the link
speed without modifying drivers.
>> Anton, once again I don't have hardware to test this, so I rely on you
>> to tell be if I screwed it up. =A0It has been compile tested.
>
> Works fine here, thanks!
Awesome. Dave, can you please pick up this series?
Thanks,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 0/4] net: Revive fixed link support
From: Anton Vorontsov @ 2009-07-18 18:04 UTC (permalink / raw)
To: Grant Likely; +Cc: leoli, netdev, linuxppc-dev, afleming, davem
In-Reply-To: <20090717065220.15652.93331.stgit@localhost.localdomain>
On Fri, Jul 17, 2009 at 01:31:25AM -0600, Grant Likely wrote:
[...]
> Part of the problem I think is that the phylib code merges two separate
> constructs; the construct of an MDIO bus (on which many device may
> reside, not all of them PHYs), and the construct of an MII link whose
> speed and configuration need to be manipulated. I've run into problems
> myself on how best to handle things like Ethernet switches which
> definitely do not behave like PHYs and the phylib state machine cannot
> be used on them. It seems to me that the whole 'dummy phy' approach
> is just an artifact of the phylib model not being quite right yet.
Yep. With a bit of phylib rework we can remove all the MDIO emulation
stuff from phy/fixed.c driver, and leave there just speed/duplex/pause
assignments.
Though, I still believe that we should avoid two code paths in the
drivers. One of the code paths will be constantly broken if we do so.
> I
> want to investigate the possibility of separating the two concepts, but
> that will require a fair bit of thought and experimentation.
That would be great indeed.
[...]
> Anton, once again I don't have hardware to test this, so I rely on you
> to tell be if I screwed it up. It has been compile tested.
Works fine here, thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Simple question about powerpc asm.
From: Valentine @ 2009-07-18 13:55 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: HongWoo Lee, linuxppc-dev
In-Reply-To: <20090718125452.3760D832E416@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Valentine,
>
> In message <4A61A48D.8060601@ru.mvista.com> you wrote:
>> PowerPC instructions are 32-bit long. So, there are only 16 bits
>> available within the instruction for constant values. Since address can
>> be up to 64 bits, we have to load it a piece at a time. The "@" within
>> the assembler instruct it to give a specially-processed form of a symbol
>> value:
>>
>> @highest -- refers to bits 48-63 of a constant
>> @higher -- refers to bits 32-47 of a constant
>> @h -- refers to bits 16-31 of a constant
>> @l -- refers to bits 0-15 of a constant
>
> Actually these bit numbers are wrong, as bit 0 is the MSB for PowerPC
> ;-)
All right, you got me ;)
Even copy-pasting from the IBM docs, one has to double-check :)
Regards,
Val.
>
> Best regards,
>
> Wolfgang Denk
>
^ permalink raw reply
* [PATCH] viotape: Fix memory and semaphore leak
From: Michael Buesch @ 2009-07-18 13:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dave Boutcher, Ryan Arnold, Colin Devilbiss
This patch fixes a memory and semaphore leak in the viotape driver's
char device write op. It leaks the DMA memory and the semaphore lock
in case the device was opened with O_NONBLOCK.
This patch is only compile tested, because I do not have the hardware.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
drivers/char/viotape.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
--- linux-2.6.orig/drivers/char/viotape.c
+++ linux-2.6/drivers/char/viotape.c
@@ -401,30 +401,31 @@ static ssize_t viotap_write(struct file
viopath_targetinst(viopath_hostLp),
(u64)(unsigned long)op, VIOVERSION << 16,
((u64)devi.devno << 48) | op->dmaaddr, count, 0, 0);
if (hvrc != HvLpEvent_Rc_Good) {
printk(VIOTAPE_KERN_WARN "hv error on op %d\n",
(int)hvrc);
ret = -EIO;
goto free_dma;
}
- if (noblock)
- return count;
-
- wait_for_completion(&op->com);
+ if (noblock) {
+ ret = count;
+ } else {
+ wait_for_completion(&op->com);
- if (op->rc)
- ret = tape_rc_to_errno(op->rc, "write", devi.devno);
- else {
- chg_state(devi.devno, VIOT_WRITING, file);
- ret = op->count;
+ if (op->rc)
+ ret = tape_rc_to_errno(op->rc, "write", devi.devno);
+ else {
+ chg_state(devi.devno, VIOT_WRITING, file);
+ ret = op->count;
+ }
}
free_dma:
dma_free_coherent(op->dev, count, op->buffer, op->dmaaddr);
up_sem:
up(&reqSem);
free_op:
free_op_struct(op);
return ret;
}
--
Greetings, Michael.
^ permalink raw reply
* how do linux active the ppc405 cache?
From: Li Jun (Aaron) @ 2009-07-18 12:55 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi all,
I have a question about cache activation on the Xilinx Virtex4 ML403 board.
I know that PowerPC instruction and data caches have to be activated
manually with the command
XCache_EnableICache();
XCache_EnableDCache();
It works well with the standalone application, but how about it in Linux
system?
When porting a linux 2.6 on the board, how the cache can be activated by
the OS?
Thanks
[-- Attachment #2: Type: text/html, Size: 2542 bytes --]
^ permalink raw reply
* Re: Simple question about powerpc asm.
From: Wolfgang Denk @ 2009-07-18 12:54 UTC (permalink / raw)
To: Valentine; +Cc: HongWoo Lee, linuxppc-dev
In-Reply-To: <4A61A48D.8060601@ru.mvista.com>
Dear Valentine,
In message <4A61A48D.8060601@ru.mvista.com> you wrote:
>
> PowerPC instructions are 32-bit long. So, there are only 16 bits
> available within the instruction for constant values. Since address can
> be up to 64 bits, we have to load it a piece at a time. The "@" within
> the assembler instruct it to give a specially-processed form of a symbol
> value:
>
> @highest -- refers to bits 48-63 of a constant
> @higher -- refers to bits 32-47 of a constant
> @h -- refers to bits 16-31 of a constant
> @l -- refers to bits 0-15 of a constant
Actually these bit numbers are wrong, as bit 0 is the MSB for PowerPC
;-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Emotions are alien to me. I'm a scientist.
-- Spock, "This Side of Paradise", stardate 3417.3
^ permalink raw reply
* Re: [PATCH RFC 1/2] Makefile: Never use -fno-omit-frame-pointer
From: Ingo Molnar @ 2009-07-18 12:01 UTC (permalink / raw)
To: Anton Vorontsov, Sam Ravnborg
Cc: linuxppc-dev, Steven Rostedt, Sam Ravnborg, linux-kernel
In-Reply-To: <20090714133716.GC28970@oksana.dev.rtsoft.ru>
* Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Wed, Jun 17, 2009 at 12:16:30AM +0400, Anton Vorontsov wrote:
> > According to Segher Boessenkool and GCC manual, -fomit-frame-pointer
> > is only the default when optimising on archs/ABIs where it doesn't
> > hinder debugging and -pg. So, we do not get it by default on x86,
> > not at any optimisation level.
> >
> > On the other hand, *using* -fno-omit-frame-pointer causes gcc to
> > produce buggy code on PowerPC targets.
> >
> > If Segher and GCC manual are right, this patch should be a no-op
> > for all arches except PowerPC, where the patch fixes gcc issues.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> >
> > See this thread for more discussion:
> > http://osdir.com/ml/linux-kernel/2009-05/msg01754.html
> >
> > p.s.
> > Obviously, I didn't test this patch on anything else but PPC32. ;-)
> >
> > Segher, do you know if all GCC versions that we support for
> > building Linux are behaving the way that GCC manual describe?
>
> No news is good news... Ingo, can we merge this into -tip for
> testing?
Changes to the top level Makefile should really go via Sam's kbuild
tree.
Ingo
^ permalink raw reply
* Re: Simple question about powerpc asm.
From: Valentine @ 2009-07-18 10:31 UTC (permalink / raw)
To: HongWoo Lee; +Cc: linuxppc-dev
In-Reply-To: <4A6194D8.9090602@gmail.com>
HongWoo Lee wrote:
> Hi all,
>
> I was reading kernel level source and found this macro.
>
> #define SET_REG_TO_LABEL(reg, label) \
> lis reg,(label)@highest; \
> ori reg,reg,(label)@higher; \
> rldicr reg,reg,32,31; \
> oris reg,reg,(label)@h; \
> ori reg,reg,(label)@l;
>
> But, I couldn't find any clue related with @highest, @higher, @h, @l.
>
> If anybody know about this directives(?), please explain it.
> Or just let me know the keyword, so I can search with those keyword.
>
PowerPC instructions are 32-bit long. So, there are only 16 bits
available within the instruction for constant values. Since address can
be up to 64 bits, we have to load it a piece at a time. The "@" within
the assembler instruct it to give a specially-processed form of a symbol
value:
@highest -- refers to bits 48-63 of a constant
@higher -- refers to bits 32-47 of a constant
@h -- refers to bits 16-31 of a constant
@l -- refers to bits 0-15 of a constant
> Thanks in advance.
>
> HongWoo.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ingo Molnar @ 2009-07-18 10:41 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, Ian.Campbell,
linuxppc-dev, joerg.roedel
In-Reply-To: <20090713181558B.fujita.tomonori@lab.ntt.co.jp>
* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> On Mon, 13 Jul 2009 13:20:22 +0900
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>
> > On Fri, 10 Jul 2009 16:12:48 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > > functionality and reimplemented the surrounding infrastructure in
> > > > terms of that (and incorporating our additional requirements). I
> > > > prototyped this (it is currently unworking, in fact it seems to
> > > > have developed rather a taste for filesystems :-() but the
> > > > diffstat of my WIP patch is:
> > > >
> > > > arch/x86/kernel/pci-swiotlb.c | 6
> > > > arch/x86/xen/pci-swiotlb.c | 2
> > > > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > > > include/linux/swiotlb.h | 12 +
> > > > lib/swiotlb.c | 10 -
> > > > 5 files changed, 385 insertions(+), 30 deletions(-)
> > > >
> > > > where a fair number of the lines in xen-iommu.c are copies of
> > > > functions from swiotlb.c with minor modifications. As I say it
> > > > doesn't work yet but I think it's roughly indicative of what such
> > > > an approach would look like. I don't like it much but am happy to
> > > > run with it if it looks to be the most acceptable approach. [...]
> > >
> > > +400 lines of code to avoid much fewer lines of generic code impact
> > > on the lib/swiotlb.c side sounds like a bad technical choice to me.
> >
> > The amount of code is not the point. The way to impact on the
> > lib/swiotlb.c is totally wrong from the perspective of the kernel
> > design; it uses architecture code in the very original (xen) way.
>
> btw, '+400 lines of code to avoid much fewer lines of generic code
> impact on the lib/swiotlb.c' doesn't sound true to me.
>
> Here is a patch in the way that Xen people want to do:
>
> http://patchwork.kernel.org/patch/26343/
>
> ---
> arch/x86/Kconfig | 4 +
> arch/x86/include/asm/io.h | 2 +
> arch/x86/include/asm/pci_x86.h | 1 +
> arch/x86/include/asm/xen/iommu.h | 12 ++
> arch/x86/kernel/pci-dma.c | 3 +
> arch/x86/pci/Makefile | 1 +
> arch/x86/pci/init.c | 6 +
> arch/x86/pci/xen.c | 51 +++++++
> drivers/pci/Makefile | 2 +
> drivers/pci/xen-iommu.c | 271 ++++++++++++++++++++++++++++++++++++++
>
> Even with the way that Xen people want to do,
> drivers/pci/xen-iommu.c is about 300 lines. And my patchset
> removes the nice amount of lines for dom0 support. I don't see
> much difference wrt lines.
ok, that kind of impact looks reasonable. If we are wrong and the
Xen model becomes duplicated anywhere else it can still be
generalized into core swiotlb code.
Ingo
^ permalink raw reply
* Simple question about powerpc asm.
From: HongWoo Lee @ 2009-07-18 9:24 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I was reading kernel level source and found this macro.
#define SET_REG_TO_LABEL(reg, label) \
lis reg,(label)@highest; \
ori reg,reg,(label)@higher; \
rldicr reg,reg,32,31; \
oris reg,reg,(label)@h; \
ori reg,reg,(label)@l;
But, I couldn't find any clue related with @highest, @higher, @h, @l.
If anybody know about this directives(?), please explain it.
Or just let me know the keyword, so I can search with those keyword.
Thanks in advance.
HongWoo.
^ permalink raw reply
* [PATCH] prom_init: evaluate mem kernel parameter for early allocation
From: Benjamin Krill @ 2009-07-17 20:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman; +Cc: linuxppc-dev
Evaluate mem kernel parameter for early memory allocations. If mem is set
no allocation in the region above the given boundary is allowed. The current
code doesn't take care about this and allocate memory above the given mem
boundary.
Signed-off-by: Benjamin Krill <ben@codiert.org>
---
arch/powerpc/kernel/prom_init.c | 100 +++++++++++++++++++++++++++++++++++++++
1 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index a538824..7c5b618 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -190,6 +190,8 @@ static int __initdata of_platform;
static char __initdata prom_cmd_line[COMMAND_LINE_SIZE];
+static unsigned long __initdata prom_memory_limit;
+
static unsigned long __initdata alloc_top;
static unsigned long __initdata alloc_top_high;
static unsigned long __initdata alloc_bottom;
@@ -484,6 +486,67 @@ static int __init prom_setprop(phandle node, const char *nodename,
return call_prom("interpret", 1, 1, (u32)(unsigned long) cmd);
}
+/* We can't use the standard versions because of RELOC headaches. */
+#define isxdigit(c) (('0' <= (c) && (c) <= '9') \
+ || ('a' <= (c) && (c) <= 'f') \
+ || ('A' <= (c) && (c) <= 'F'))
+
+#define isdigit(c) ('0' <= (c) && (c) <= '9')
+#define islower(c) ('a' <= (c) && (c) <= 'z')
+#define toupper(c) (islower(c) ? ((c) - 'a' + 'A') : (c))
+
+unsigned long prom_strtoul(const char *cp, const char **endp)
+{
+ unsigned long result = 0, base = 10, value;
+
+ if (*cp == '0') {
+ base = 8;
+ cp++;
+ if (toupper(*cp) == 'X') {
+ cp++;
+ base = 16;
+ }
+ }
+
+ while (isxdigit(*cp) &&
+ (value = isdigit(*cp) ? *cp - '0' : toupper(*cp) - 'A' + 10) < base) {
+ result = result * base + value;
+ cp++;
+ }
+
+ if (endp)
+ *endp = cp;
+
+ return result;
+}
+
+unsigned long prom_memparse(const char *ptr, const char **retptr)
+{
+ unsigned long ret = prom_strtoul(ptr, retptr);
+ int shift = 0;
+
+ /*
+ * We can't use a switch here because GCC *may* generate a
+ * jump table which won't work, because we're not running at
+ * the address we're linked at.
+ */
+ if ('G' == **retptr || 'g' == **retptr)
+ shift = 30;
+
+ if ('M' == **retptr || 'm' == **retptr)
+ shift = 20;
+
+ if ('K' == **retptr || 'k' == **retptr)
+ shift = 10;
+
+ if (shift) {
+ ret <<= shift;
+ (*retptr)++;
+ }
+
+ return ret;
+}
+
/*
* Early parsing of the command line passed to the kernel, used for
* "mem=x" and the options that affect the iommu
@@ -521,6 +584,15 @@ static void __init early_cmdline_parse(void)
RELOC(prom_iommu_force_on) = 1;
}
#endif
+ opt = strstr(RELOC(prom_cmd_line), RELOC("mem="));
+ if (opt) {
+ opt += 4;
+ RELOC(prom_memory_limit) = prom_memparse(opt, (const char **)&opt);
+#ifdef CONFIG_PPC64
+ /* Align to 16 MB == size of ppc64 large page */
+ RELOC(prom_memory_limit) = ALIGN(RELOC(prom_memory_limit), 0x1000000);
+#endif
+ }
}
#ifdef CONFIG_PPC_PSERIES
@@ -1027,6 +1099,29 @@ static void __init prom_init_mem(void)
}
/*
+ * If prom_memory_limit is set we reduce the upper limits *except* for
+ * alloc_top_high. This must be the real top of RAM so we can put
+ * TCE's up there.
+ */
+
+ RELOC(alloc_top_high) = RELOC(ram_top);
+
+ if (RELOC(prom_memory_limit)) {
+ if (RELOC(prom_memory_limit) <= RELOC(alloc_bottom)) {
+ prom_printf("Ignoring mem=%x <= alloc_bottom.\n",
+ RELOC(prom_memory_limit));
+ RELOC(prom_memory_limit) = 0;
+ } else if (RELOC(prom_memory_limit) >= RELOC(ram_top)) {
+ prom_printf("Ignoring mem=%x >= ram_top.\n",
+ RELOC(prom_memory_limit));
+ RELOC(prom_memory_limit) = 0;
+ } else {
+ RELOC(ram_top) = RELOC(prom_memory_limit);
+ RELOC(rmo_top) = min(RELOC(rmo_top), RELOC(prom_memory_limit));
+ }
+ }
+
+ /*
* Setup our top alloc point, that is top of RMO or top of
* segment 0 when running non-LPAR.
* Some RS64 machines have buggy firmware where claims up at
@@ -1041,6 +1136,7 @@ static void __init prom_init_mem(void)
RELOC(alloc_top_high) = RELOC(ram_top);
prom_printf("memory layout at init:\n");
+ prom_printf(" memory_limit : %x (16 MB aligned)\n", RELOC(prom_memory_limit));
prom_printf(" alloc_bottom : %x\n", RELOC(alloc_bottom));
prom_printf(" alloc_top : %x\n", RELOC(alloc_top));
prom_printf(" alloc_top_hi : %x\n", RELOC(alloc_top_high));
@@ -2399,6 +2495,10 @@ unsigned long __init prom_init(unsigned long r3, unsigned long r4,
/*
* Fill in some infos for use by the kernel later on
*/
+ if (RELOC(prom_memory_limit))
+ prom_setprop(_prom->chosen, "/chosen", "linux,memory-limit",
+ &RELOC(prom_memory_limit),
+ sizeof(prom_memory_limit));
#ifdef CONFIG_PPC64
if (RELOC(prom_iommu_off))
prom_setprop(_prom->chosen, "/chosen", "linux,iommu-off",
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH 2/2 v4] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Grant Likely @ 2009-07-17 18:31 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, netdev
In-Reply-To: <20090717175138.97CB2832E416@gemini.denx.de>
On Fri, Jul 17, 2009 at 11:51 AM, Wolfgang Denk<wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa40907170745h6c5fae6bia0cff0926c93393c@mail.gmail.com> =
you wrote:
>>
>> > =A0drivers/net/fec_mpc52xx.c =A0 =A0 | =A0 25 ++++++++++++++++++++++--=
-
>> > =A0drivers/net/fec_mpc52xx_phy.c | =A0 23 ++++++++++++++++++++---
>>
>> Blech. =A0now this block of duplicated code I don't like. =A0This is all
>> one device, so surely the mdio speed can be calculated once and used
>> for both drivers.... let me think about this for a bit. =A0'course this
>> problem is all rolled up in the nastiness of having two drivers
>> working on the same device. =A0I suspect is was a mistake to split up
>> all the powerpc ethernet drivers into separate of_platform drivers.
>
> If you like, I can re-introduce the mpc5xxx_get_mii_speed() I unrolled
> upon your request (with or without re-using it for the MPC512x case).
No, there's a deeper issues here. I'm bothered that the mac driver is
impacting the mdio driver. I'd like to find a way for this whole
thing to be handled cleaner, and not have two different drivers
calculate it.
g.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> What is mind? =A0No matter. =A0What is matter? =A0Never mind.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0-- Thomas Hewitt Key, 1799-1875
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: kernel2.6.30 can not boot on my mpc8260 board using u-boot2009.06
From: Scott Wood @ 2009-07-17 18:15 UTC (permalink / raw)
To: jerry_dw; +Cc: linuxppc-dev
In-Reply-To: <6174944.80871247795632146.JavaMail.coremail@bj126app32.126.com>
On Fri, Jul 17, 2009 at 09:53:52AM +0800, jerry_dw wrote:
> Updating property 'current-speed' = 00 00 25 80
> Updating property 'clock-frequency' = 01 79 a7 b0
> Updating property 'bus-frequency' = 03 ef 14 80
> Updating property 'timebase-frequency' = 00 00 00 00
That timebase-frequency doesn't look right...
> BDI2000 console:
> MPC8260|:=>halt
> Target CPU : MPC82xx (G2H4)
> Target state : debug mode
> Debug entry cause : COP halt
> Current PC : 0xc000c5f0
> Current CR : 0x42022088
> Current MSR : 0x00001032
> Current LR : 0xc001cfa8
>
> 0xc000c5f0: in hardwareinterrupt vector table.
Which vector (that address looks a little high to be in the exception
vectors)? Is there anything in the log buffer?
-Scott
^ permalink raw reply
* Re: [PATCH 2/2 v4] MPC52xx FEC: be more conservative when setting MII_SPEED register
From: Wolfgang Denk @ 2009-07-17 17:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, netdev
In-Reply-To: <fa686aa40907170745h6c5fae6bia0cff0926c93393c@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa40907170745h6c5fae6bia0cff0926c93393c@mail.gmail.com> you wrote:
>
> > drivers/net/fec_mpc52xx.c | 25 ++++++++++++++++++++++---
> > drivers/net/fec_mpc52xx_phy.c | 23 ++++++++++++++++++++---
>
> Blech. now this block of duplicated code I don't like. This is all
> one device, so surely the mdio speed can be calculated once and used
> for both drivers.... let me think about this for a bit. 'course this
> problem is all rolled up in the nastiness of having two drivers
> working on the same device. I suspect is was a mistake to split up
> all the powerpc ethernet drivers into separate of_platform drivers.
If you like, I can re-introduce the mpc5xxx_get_mii_speed() I unrolled
upon your request (with or without re-using it for the MPC512x case).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
^ permalink raw reply
* Re: [PATCH 1/2 v5] fs_enet/mii-fec.c: fix MII speed calculation
From: David Miller @ 2009-07-17 16:48 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, netdev, wd
In-Reply-To: <fa686aa40907170741n121d3e4cqdfddaf4d23d4d1fc@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Fri, 17 Jul 2009 08:41:08 -0600
> On Fri, Jul 17, 2009 at 6:27 AM, Wolfgang Denk<wd@denx.de> wrote:
>> The MII speed calculation was based on the CPU clock (ppc_proc_freq),
>> but for MPC512x we must use the bus clock instead.
>>
>> This patch makes it use the correct clock and makes sure we don't
>> clobber reserved bits in the MII_SPEED register.
>>
>> Signed-off-by: Wolfgang Denk <wd@denx.de>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Cc: <netdev@vger.kernel.org>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2 v5] fs_enet/mii-fec.c: fix MII speed calculation
From: David Miller @ 2009-07-17 16:21 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, netdev, wd
In-Reply-To: <fa686aa40907170741n121d3e4cqdfddaf4d23d4d1fc@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Fri, 17 Jul 2009 08:41:08 -0600
> David, this isn't a critical bug fix or a regression, so I think it
> should be merged for -next.
Ok.
^ permalink raw reply
* Re: [PATCH] powerpc/cell: strncpy does not null terminate string
From: Arnd Bergmann @ 2009-07-17 15:56 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev
In-Reply-To: <4A608A69.4060204@gmail.com>
On Friday 17 July 2009, Roel Kluin wrote:
>
> static int __init celleb_machine_type_hack(char *ptr)
> {
> - strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> + strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> return 0;
This still is pointless as long as you keep the explicit null-termination
in the next line, the patch still doesn't change anything significant.
The file is maintained by Ishizaki Kou, if he would prefer to take a
patch replacing the two lines with one, that's fine with me, otherwise
I just wouldn't bother. You still only gain a few bytes of inittext, but
that is discarded at boot time.
Arnd <><
^ 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