Re: [PATCH] [POWERPC KVM] Kconfig fixes
Hollis Blanchard wrote: 1 file changed, 5 insertions(+), 6 deletions(-) arch/powerpc/kvm/Kconfig | 11 +-- Don't allow building as a module (asm-offsets dependencies). Also, automatically select KVM_BOOKE_HOST until we better separate the guest and host layers. Applied, thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git master branch
Linus, Please do: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master to get a powerpc update. Thanks, Paul. Documentation/kernel-parameters.txt |2 Documentation/powerpc/booting-without-of.txt | 622 +- Documentation/powerpc/phyp-assisted-dump.txt | 127 +++ arch/powerpc/Kconfig | 82 +- arch/powerpc/Kconfig.debug|2 arch/powerpc/Makefile | 12 arch/powerpc/boot/Makefile| 40 + arch/powerpc/boot/bamboo.c|3 arch/powerpc/boot/cpm-serial.c| 117 ++- arch/powerpc/boot/cuboot-pq2.c| 27 - arch/powerpc/boot/cuboot-rainier.c|3 arch/powerpc/boot/cuboot-sequoia.c|3 arch/powerpc/boot/cuboot-taishan.c|3 arch/powerpc/boot/cuboot-warp.c |2 arch/powerpc/boot/cuboot-yosemite.c | 44 + arch/powerpc/boot/devtree.c | 20 arch/powerpc/boot/dts/bamboo.dts |2 arch/powerpc/boot/dts/canyonlands.dts | 402 + arch/powerpc/boot/dts/ebony.dts |2 arch/powerpc/boot/dts/ep8248e.dts |5 arch/powerpc/boot/dts/ep88xc.dts | 73 +- arch/powerpc/boot/dts/glacier.dts | 467 ++ arch/powerpc/boot/dts/haleakala.dts |4 arch/powerpc/boot/dts/katmai.dts |2 arch/powerpc/boot/dts/kilauea.dts |4 arch/powerpc/boot/dts/ksi8560.dts | 267 ++ arch/powerpc/boot/dts/kuroboxHD.dts | 83 +- arch/powerpc/boot/dts/kuroboxHG.dts | 83 +- arch/powerpc/boot/dts/makalu.dts |4 arch/powerpc/boot/dts/mpc7448hpc2.dts | 97 +- arch/powerpc/boot/dts/mpc8272ads.dts | 132 ++- arch/powerpc/boot/dts/mpc832x_mds.dts |7 arch/powerpc/boot/dts/mpc832x_rdb.dts |4 arch/powerpc/boot/dts/mpc836x_mds.dts |4 arch/powerpc/boot/dts/mpc8540ads.dts | 173 ++-- arch/powerpc/boot/dts/mpc8541cds.dts | 161 ++-- arch/powerpc/boot/dts/mpc8544ds.dts | 299 --- arch/powerpc/boot/dts/mpc8548cds.dts | 289 +++--- arch/powerpc/boot/dts/mpc8555cds.dts | 161 ++-- arch/powerpc/boot/dts/mpc8560ads.dts | 209 ++--- arch/powerpc/boot/dts/mpc8568mds.dts | 291 +++ arch/powerpc/boot/dts/mpc8572ds.dts | 383 - arch/powerpc/boot/dts/mpc8641_hpcn.dts|2 arch/powerpc/boot/dts/mpc866ads.dts | 58 + arch/powerpc/boot/dts/mpc885ads.dts | 77 +- arch/powerpc/boot/dts/pq2fads.dts | 126 +-- arch/powerpc/boot/dts/prpmc2800.dts | 336 arch/powerpc/boot/dts/rainier.dts |6 arch/powerpc/boot/dts/sbc8641d.dts| 352 arch/powerpc/boot/dts/sequoia.dts |6 arch/powerpc/boot/dts/taishan.dts | 31 + arch/powerpc/boot/dts/walnut.dts |1 arch/powerpc/boot/dts/warp.dts|1 arch/powerpc/boot/dts/yosemite.dts| 304 +++ arch/powerpc/boot/ebony.c |3 arch/powerpc/boot/libfdt-wrapper.c|2 arch/powerpc/boot/mpc52xx-psc.c |9 arch/powerpc/boot/mpsc.c |2 arch/powerpc/boot/mv64x60.c |4 arch/powerpc/boot/mv64x60_i2c.c |2 arch/powerpc/boot/ns16550.c | 10 arch/powerpc/boot/ops.h |1 arch/powerpc/boot/prpmc2800.c | 23 - arch/powerpc/boot/ps3-head.S | 25 - arch/powerpc/boot/ps3.c | 23 - arch/powerpc/boot/serial.c|2 arch/powerpc/boot/simpleboot.c| 84 ++ arch/powerpc/boot/treeboot-walnut.c |2 arch/powerpc/boot/virtex405-head.S| 30 + arch/powerpc/boot/wrapper | 32 - arch/powerpc/configs/40x/ep405_defconfig |0 arch/powerpc/configs/40x/kilauea_defconfig|0 arch/powerpc/configs/40x/makalu_defconfig |0 arch/powerpc/configs/40x/walnut_defconfig |0 arch/powerpc/configs/44x/bamboo_defconfig |0 arch/powerpc/configs/44x/canyonlands_defconfig| 138 --- arch/powerpc/configs/44x/ebony_defconfig |0 arch/powerpc/configs/44x/katmai_defconfig |0 arch/powerpc/configs/44x/rainier_defconfig|0 arch/powerpc/configs/44x/sequoia_defconfig
Re: removal of arch/ppc in 2.6.27?
Hi, On Saturday 19 April 2008 17:30:10 Kumar Gala wrote: > This is intended as a reminder that we plan on getting rid of arch/ppc > this summer. I'm guessing based on kernel release times that will be > 2.6.27. That would mean 2.6.26 will be the last kernel to support > arch/ppc. > > If people have boards that like ported over please let us know and > work with us to port this over to arch/powerpc. > > Here is a list based on arch/ppc/platforms. Its not intended to be > complete but a general idea of what's left in arch/ppc. > > PPC_PREPe6xx will this be the end of life for all the PReP's ? I remember a patch posted some month ago, but didn't heard anything since then. Any news? Or just let it die quietly? Marvin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
Marvin writes: > will this be the end of life for all the PReP's ? I remember a patch posted > some month ago, but didn't heard anything since then. Any news? Or just let > it die quietly? No, I'm still planning on getting PReP support over to arch/powerpc, but getting time to work on it has been the difficulty. What sort of PReP do you have? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
On Sun, Apr 20, 2008 at 10:27:27PM +1000, Paul Mackerras wrote: > Marvin writes: > > > will this be the end of life for all the PReP's ? I remember a patch posted > > some month ago, but didn't heard anything since then. Any news? Or just let > > it die quietly? > > No, I'm still planning on getting PReP support over to arch/powerpc, > but getting time to work on it has been the difficulty. > > What sort of PReP do you have? On my side, I have MVME2[467]xx boards. But these are actually PPLUS board but the residual data and boot methods are so similar to PreP that they could be merged. The host bridge is flexible (the MVME5100 has the same PHB but a completely different layout set up by the firmware IIRC). I have local patches in the tree I use (still 2.2) that make the memory map more CHRP like (to have more PCI memory space and less I/O space). The main problem is that I'm short on cycles to work on porting them to 2.6 (the other is that I'm not sure that it's worth putting 2.6 on machines with 16MB of RAM, current kernels with extremely stripped down configs are still much larger than the ones I run on these boards). Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
Hi Paul, On Sunday 20 April 2008 14:27:27 Paul Mackerras wrote: > Marvin writes: > > will this be the end of life for all the PReP's ? I remember a patch > > posted some month ago, but didn't heard anything since then. Any news? Or > > just let it die quietly? > > No, I'm still planning on getting PReP support over to arch/powerpc, > but getting time to work on it has been the difficulty. > > What sort of PReP do you have? IBM 7248 (aka Carolina) and Motorola Powerstack II (aka Utah) - currently running Debian with 2.6.18 kernel. Marvin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ptrace: compat_ptrace_request siginfo
I posted this before, but I hope it can go in now.
It's a prerequisite for some x86 ptrace cleanups I'd like to submit.
For powerpc, it requires this patch that's in Paul's queue:
commit 9c0c44dbd9bc380bee53e2f768c4ad5410b8aae2
Author: Roland McGrath <[EMAIL PROTECTED]>
Date: Sun Apr 20 08:19:24 2008 +1000
[POWERPC] Define copy_siginfo_from_user32
Note: that change plus the patch below obviates the need for this one:
commit e4cc58944c1e2ce41e3079d4eb60c95e7ce04b2b
Author: Andreas Schwab <[EMAIL PROTECTED]>
Date: Sun Apr 20 02:25:13 2008 +1000
[POWERPC] Add compat handler for PTRACE_GETSIGINFO
Thanks,
Roland
---
[PATCH] ptrace: compat_ptrace_request siginfo
This adds support for PTRACE_GETSIGINFO and PTRACE_SETSIGINFO in
compat_ptrace_request. It relies on existing arch definitions for
copy_siginfo_to_user32 and copy_siginfo_from_user32.
On powerpc, this fixes a longstanding regression of 32-bit ptrace
calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
to examine e.g. siginfo_t.si_addr from a signal that sets it.
(This was broken as of 2.6.24 and, I presume, many or all prior versions.)
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
kernel/ptrace.c | 48 +++-
1 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index fdb34e8..67e392e 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -323,9 +323,8 @@ static int ptrace_setoptions(struct task_struct *child,
long data)
return (data & ~PTRACE_O_MASK) ? -EINVAL : 0;
}
-static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user *
data)
+static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
{
- siginfo_t lastinfo;
int error = -ESRCH;
read_lock(&tasklist_lock);
@@ -333,31 +332,25 @@ static int ptrace_getsiginfo(struct task_struct *child,
siginfo_t __user * data)
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- lastinfo = *child->last_siginfo;
+ *info = *child->last_siginfo;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
}
read_unlock(&tasklist_lock);
- if (!error)
- return copy_siginfo_to_user(data, &lastinfo);
return error;
}
-static int ptrace_setsiginfo(struct task_struct *child, siginfo_t __user *
data)
+static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
{
- siginfo_t newinfo;
int error = -ESRCH;
- if (copy_from_user(&newinfo, data, sizeof (siginfo_t)))
- return -EFAULT;
-
read_lock(&tasklist_lock);
if (likely(child->sighand != NULL)) {
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- *child->last_siginfo = newinfo;
+ *child->last_siginfo = *info;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
@@ -424,6 +417,7 @@ int ptrace_request(struct task_struct *child, long request,
long addr, long data)
{
int ret = -EIO;
+ siginfo_t siginfo;
switch (request) {
case PTRACE_PEEKTEXT:
@@ -442,12 +436,22 @@ int ptrace_request(struct task_struct *child, long
request,
case PTRACE_GETEVENTMSG:
ret = put_user(child->ptrace_message, (unsigned long __user *)
data);
break;
+
case PTRACE_GETSIGINFO:
- ret = ptrace_getsiginfo(child, (siginfo_t __user *) data);
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user((siginfo_t __user *) data,
+ &siginfo);
break;
+
case PTRACE_SETSIGINFO:
- ret = ptrace_setsiginfo(child, (siginfo_t __user *) data);
+ if (copy_from_user(&siginfo, (siginfo_t __user *) data,
+ sizeof siginfo))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
break;
+
case PTRACE_DETACH: /* detach a process that was attached. */
ret = ptrace_detach(child, data);
break;
@@ -616,6 +620,7 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
+ siginfo_t siginfo;
int ret;
switch (request) {
@@ -638,6 +6
Re: pci issue - wrong detection of pci ressources
Johan Borkhuis wrote: Hello Christian, Christian Ehrhardt wrote: Hi, I tried to use a radeon r200 based graphic card on a sequoia ppc (440epx) board. I wondered about the initialization of radeonfb that failed with __ioremap(): phys addr 0x0 is RAM lr c029cf80 radeonfb (:00:0a.0): cannot map MMIO radeonfb: probe of :00:0a.0 failed with error -5 [...] I came across a similar problem, which (ultimately) was caused by a lack of memory reserved for PCI. I moved from 2.6.14(ppc) to 2.6.20(powerpc), and suddenly some cards stopped working: the BAR registers were not initialized, so it was not possible to access the cards. Have a look at the boot-time messages, especially the early messages, as the PCI subsystem is started very early in the boot process. You could also try switching on PCI-debugging, and have a look at the debug messages, or add some extra debugging info to the pci-initialization code. Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources. And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem. Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ? With DEBUG in pci-common.c enabled (bad kernel) and a extension showing which functions alloc fails (put a %s for __func__): PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x00018000..0x00018fff -> 0x8000 IO 0x0001e800..0x0001e80f -> 0x 4xx PCI DMA offset set to 0x PCI: Probing PCI hardware PCI: Hiding 4xx host bridge resources :00:00.0 Try to map irq for :00:00.0... -> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2 -> mapped to linux irq 16 Try to map irq for :00:0a.0... -> got one, spec 2 cells (0x0003 0x0008...) on /interrupt-controller2 -> mapped to linux irq 16 Try to map irq for :00:0a.1... PCI: PHB (bus 0) bridge rsrc 0: -000f [0x100], parent c0363060 (PCI IO) PCI: PHB (bus 0) bridge rsrc 1: 00018000-00018fff [0x200], parent c0363038 (PCI mem) PCI: Assigning unassigned resouces... PCI: pci_assign_resource - Failed to allocate mem resource #6:[EMAIL PROTECTED] for :00:0a.0 PCI: pci_assign_resource - Failed to allocate mem resource #2:[EMAIL PROTECTED] for :00:0a.0 PCI: pci_assign_resource - Failed to allocate mem resource #1:[EMAIL PROTECTED] for :00:0a.1 -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization To be complete for the case we might need it I answer all the other questions: Benjamin Herrenschmidt wrote: On Fri, 2008-04-18 at 14:07 +0200, Christian Ehrhardt wrote: => Region 2 is not detected with our kernel, this later break things like radeonfb initialization. I'll need some information here: - Your device-tree (is that the base sequoia one ?) DTS File is the normal sequoia.dts file in arch/powerpc/boot/dts with the latest change being: user:Stefan Roese <[EMAIL PROTECTED]> date:Fri Feb 15 21:35:30 2008 -0600 summary: [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts - Enable DEBUG in arch/powerpc/kernel/pci-common.c and pci_32.c - Send me the resulting dmesg log done - full dmesg attached - Also include the output of /proc/iomem /proc/iomem - bad kernel [EMAIL PROTECTED]:~# cat /proc/iomem e300-e38f : ehci_hcd 18000-18fff : /plb/[EMAIL PROTECTED] 18000-187ff : :00:0a.0 18800-18fff : :00:0a.1 1ef600300-1ef600307 : serial 1ef600400-1ef600407 : serial 1ef600500-1ef600507 : serial 1ef600600-1ef600607 : serial 1fc00-1 : 1fc00.nor_flash /proc/iomem - good kernel [EMAIL PROTECTED]:~# cat /proc/iomem 8000-8fff : PCI host bridge 8000-8000 : :00:0a.1 8002-8003 : :00:0a.0 87ff-87ff : :00:0a.0 87ff-87ff : radeonfb mmio 8800-8fff : :00:0a.0 8800-8fff : radeonfb framebuffer d000-d0001fff : ndfc-nand.0 e100-e17f : musbhsfc_udc.0 e100-e17f : musbhsfc_udc e300-e3ff : ppc-soc-ehci.0 e400-e4ff : ppc-soc-ohci.0 fc00- : physmap-flash.0 fc00- : physmap-flash.0 Actually, there's a bug in radeonfb: In radeonfb.h, try changing unsigned long mmio_base_phys; unsigned long fb_base_phys; To resource_size_t mmio_base_phys; resource_size_t fb_base_phys; This did not fix the issue, as we have seen that it is caused earlier in pci initialization. But that fix corrects the code if it is useful in my case or not ;-) Sergei Shtylyov wrote: Christian Ehrhardt wrote: [...] Bad kernel: 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (re
Re: pci issue - wrong detection of pci ressources
> Yes you're right. Early at the pci initialization are errors of the > allocation for pi ressources. > And that are exactly the ressources failing later, so that pci initialization > seem to be the reason for my problem. > Was there any simple solution (e.g. just somehow increase memory reserved for > pci) when you came across that issue Johan ? Hrm... I was expecting to see a lot more output here, make sure you have "debug" on your command line (or enable early debug output, same effect). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
On Wed, Apr 16, 2008 at 8:40 AM, Laurent Pinchart
<[EMAIL PROTECTED]> wrote:
> This patch converts the MII bitband driver to use GPIO lib for GPIO access.
> The driver can now handle MDC and MDIO on different GPIO banks.
>
> The patch depends on Anton Vorontsov GPIO lib support scheduled for 2.6.26.
> It is by no means complete, I just would like to get some feedback on the
> approach. I'll resubmit it when the CPM2 GPIO support patches will be
> available in the powerpc git tree.
I agree with Anton; nice rework. This would be useful on other
platforms too. Comment below.
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2030,21 +2030,19 @@ platforms are moved over to use the
> flattened-device-tree model.
> fsl,cpm2-mdio-bitbang (reg is port C registers)
>
> Properties for fsl,cpm2-mdio-bitbang:
> - fsl,mdio-pin : pin of port C controlling mdio data
> - fsl,mdc-pin : pin of port C controlling mdio clock
> + gpios : GPIOs controlling mdio clock and mdio data (in that order).
>
> Example:
>
> - [EMAIL PROTECTED] {
> + mdio {
> device_type = "mdio";
> compatible = "fsl,mpc8272ads-mdio-bitbang",
> "fsl,mpc8272-mdio-bitbang",
> "fsl,cpm2-mdio-bitbang";
I think it would be better for the defined binding to use something
like "virtual,mdio-bitbang" or "gpio-mdio". (I like the first better,
but there is already some precedence with the "gpio-led" driver. I
think there is less chance of namespace conflicts with the first)
Of course; the *driver* could also accept these additional compatible
values for backwards compatibility.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: UartLite
BTW, you should really be asking these questions on the linuxppc mailing list On Sun, Apr 20, 2008 at 2:23 PM, David H. Lynch Jr. <[EMAIL PROTECTED]> wrote: > I have been looking more and more at the kernel uartlite driver. > Somewhere along the line while I was not watching PK's driver has > developed alot stronger resemblance to most normal serial drivers. I am > seriously thinking of putting some effort into getting it working for > me, and then pushing my polling patch for interrupt free implimentations. > > But I have tripped over several things that trouble me. Though I am not > a serial driver expert. > > The first is that all the Uartlite related definitions tend to create a > BaseAddress+3 definition. > This really bothers me, it presumes that the registers are all 4 bytes > apart - I know that is the norm > and I have never actually seen a different implimentation, but I do not > think it is set in stone. > It also is basically a cleaver trick to get readb/writeb to work without > adjustment. > Endian issues tend to give me headaches, but somehow I think there is an > endian issue in this. > All the port offsets are defined with the presumption the registers are > 4 bytes apart. > Despite the fact that all the offsets masks and bits are needed in > several files, they are not in a header. Yes, I'm not a big fan of the +3 either; but it is expedient. I think the best solution is to encode it into the device tree by adding optional "reg-stride" and "reg-offset" properties (at least for memory mapped implementations). We can define another binding for the DCR version. > If I can manage to get the thing to work for me, > Am I going to be stepping on any toes if I make changes to adress my > concerns above ? I've got no problem reworking the register accessor functions. > I really want to migrate all the direct IO to a ulite_in() and > ulite_out() routine. > Letting those two routines deal with all the issues of BaseAddress, > register size, endianness, register shift, > and even whether access is via DCR - I have seen atleast one > implimentation that was DCR. > > I would like to remove the +3 from all the macro's etc. as it seems to > me to confuse what is actually going on. > > I did a diff merge against my own driver a few days ago and aside from > these issues, order of functions, some naming issues, the absence of OF > support in my driver, and the presence of polling in mine, the code now > very very strongly parallels my code now. So it should not be alot of > work to merge my code into the standard driver now. > > I will be happy to do this - presuming I am not going to be stepping on > any toes. > I would be happy to not have to support a separate driver, but the stock > driver has to work with my hardware. > It still does not, but I think the code is now close enough for me to > track down and kill the problem. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.26?] Raise the upper limit of NR_CPUS.
On Fri, Apr 18, 2008 at 08:33:44PM +1000, Michael Ellerman wrote: > What happens on non prom-init platforms? Um yeah they wont work. I'll try a slightly different approach. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.26?] Raise the upper limit of NR_CPUS.
On Fri, 2008-04-18 at 15:33 +1000, Tony Breeds wrote: > As the pacas are statically initialised increasing NR_CPUS beyond 128, > means that any additional pacas will be empty ... which is bad. > > This patch adds the required functionality to fill in any excess pacas > at runtime. > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> > --- > I know it's late, but can this be considered for 2.6.26? NAK. You must NEVER manipulate kernel globals from prom_init.c. The fact that prom_init is linked with the kernel is an "accident" which may change. Your scheme would break among others with kexec or non-OF bootloaders Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] [v3][POWERPC] refactor dcr code
> > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > +{
> > + if (host.type == NATIVE)
> > + dcr_unmap_native(host.host.native, dcr_c);
> > + else
> > + dcr_unmap_mmio(host.host.mmio, dcr_c);
>
> What happens if host.type == INVALID? Same question for the other
> accessors in dcr_*_generic.
I guess looking back on it, I assumed that MAP_OK would return 0, meaning that
behavior was undefined,
but I agree it's probably safer to have some error reporting there... There
starts to become a speed tradeoff
at some point, which would make function pointers more attractive. If the
ioremap does fail, or the
dcr-access-method can't be determined, then dcr_unmap_mmio would probably SEGV
anyway, although that's
not something I'd really want to rely on. I'll put an error case in there.
> > +enum host_type_t {MMIO, NATIVE, INVALID};
>
> Should these be DCR_HOST_MMIO, DCR_HOST_NATIVE, DCR_HOST_INVALID?
>
> I worry about the generic nature of the names.
Also seems reasonable,
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
> This MSI driver can be used on 83xx/85xx/86xx board.
> In this driver, virtual interrupt host and chip were
> setup. There are 256 MSI interrupts in this host, Every 32
> MSI interrupts cascaded to one IPIC/MPIC interrupt.
> The chip was treated as edge sensitive and some necessary
> functions were setup for this chip.
>
> Before using the MSI interrupt, PCI/PCIE device need to
> ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
> bitmap show which MSI interrupt was used, reserve bit in
> the bitmap can be used to force the device use some designate
> MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
> for testing the all the MSI interrupts. The msi-available-ranges
> property in the dts file was used for this purpose.
Hi Jason, some comments inline ...
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 6d386d0..bfd3fe4 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -4,6 +4,7 @@ endif
>
> mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o
> mpic_pasemi_msi.o
> obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
> +obj-$(CONFIG_PCI_MSI)+= fsl_msi.o
Do we really always want to build this if we have MSI? Might it depend
on something else as well? CONFIG_FSL_PCI maybe?
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> new file mode 100644
> index 000..e8132cf
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -0,0 +1,457 @@
> +/*
> + * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * Author: Tony Li <[EMAIL PROTECTED]>
> + * Jason Jin <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include "fsl_msi.h"
People consider it good style to have the linux includes before the
asm includes.
> +#ifdef DEBUG
> +#define pr_debug(fmt...) printk(fmt)
> +#else
> +#define pr_debug(fmt...)
> +#endif
Please don't do this, just use pr_debug(). In fact I don't see where you
do use it :)
> +/* A bit ugly, can we get this from the pci_dev somehow? */
> +static struct fsl_msi *fsl_msi;
I recognise that comment :) The answer is "no" we can't (easily) get
this from the pci_dev.
> +static inline u32 fsl_msi_read(u32 __iomem *base,
> + unsigned int reg)
This would fit in 80 chars wouldn't it?
> +{
> + return in_be32(base + (reg >> 2));
> +}
> +
> +static inline void fsl_msi_write(u32 __iomem *base,
> + unsigned int reg, u32 value)
> +{
> + out_be32(base + (reg >> 2), value);
> +}
> +
> +#define fsl_msi_irq_to_hw(virq) ((unsigned int)irq_map[virq].hwirq)
I can't see where this is used, you probably don't need it.
> +/*
> + * We do not need this actually. The MSIR register has been read once
> + * in the cascade interrupt. So, this MSI interrupt has been acked
> +*/
> +static void fsl_msi_end_irq(unsigned int virq)
> +{
> +}
I guess the generic code assumes you have an ack, bummer.
> +static struct irq_chip fsl_msi_chip = {
> + .mask = mask_msi_irq,
> + .unmask = unmask_msi_irq,
> + .ack= fsl_msi_end_irq,
> + .typename = " FSL-MSI ",
I'd rather you didn't try and pad the name by hand, if we want /proc/interrupts
to look pretty we should do that in show_interrupts().
> +static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
> +{
> + struct fsl_msi *msi = h->host_data;
> +
> + /* Exact match, unless node is NULL */
> + return msi->of_node == NULL || msi->of_node == node;
> +}
Do you really want the MSI to be the default irq host?
> +static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
> + irq_hw_number_t hw)
> +{
> + struct fsl_msi *msi = h->host_data;
> + struct irq_chip *chip = msi->hc_irq;
> +
> + set_irq_chip_data(virq, msi);
You don't seem to use chip_data anywhere?
> + get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
> +
> + set_irq_chip_and_handler(virq, chip, handle_edge_irq);
> +
> + return 0;
> +}
> +
> +static struct irq_host_ops fsl_msi_host_ops = {
> + .match = fsl_msi_host_match,
> + .map = fsl_msi_host_map,
> +};
> +
> +irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
> +{
> + unsigned long flags;
> + int offset, order = get_count_order(num);
> +
> + spin_lock_irqsave(&msi->bitmap_lock, flags);
> +
> + offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
> + NR_MSI_IRQS, order);
> +
> + spin_unlock_irqrestore(&msi->bitmap_lock, flag
