* Re: powerpc port for sbc8260-based board problem
From: Sergej Stepanov @ 2008-05-07 19:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <48220428.6020207@freescale.com>
Am Mittwoch, den 07.05.2008, 14:34 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > Am Mittwoch, den 07.05.2008, 13:57 -0500 schrieb Scott Wood:
> >> I'm not sure how it would make a difference -- the BRG should have
> >> already been set through the set_termios callback, which is called from
> >> uart_set_options.
> >>
> >> -Scott
> > Yes, i thought it also, but i traced it for us for the uart console.
> > The cpm_uart_set_termios(..) was not called.
> > At which place should it be called?
> > Is it uart_set_options(..)?
>
> Yes, uart_set_options() calls port->ops->set_termios().
>
> -Scott
Hm... it looks like the default uart_set_termios from
static const struct tty_operations uart_ops in serial_core.c
and not cpm_uart_set_termios(..)?..
Is not it? but why?...
Ok, i have to look at my code again...
Regards.
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Scott Wood @ 2008-05-07 19:42 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1210189239.6362.3.camel@p60365-ste>
Sergej Stepanov wrote:
> Hm... it looks like the default uart_set_termios from
>
> static const struct tty_operations uart_ops in serial_core.c
>
> and not cpm_uart_set_termios(..)?..
>
> Is not it? but why?...
tty_operations != uart_ops
-Scott
^ permalink raw reply
* Re: powerpc port for sbc8260-based board problem
From: Scott Wood @ 2008-05-07 19:44 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <4822063D.5080402@freescale.com>
Scott Wood wrote:
> Sergej Stepanov wrote:
>> Hm... it looks like the default uart_set_termios from
>>
>> static const struct tty_operations uart_ops in serial_core.c
>>
>> and not cpm_uart_set_termios(..)?..
>>
>> Is not it? but why?...
>
> tty_operations != uart_ops
Despite the unfortunate name of the instance of the former.
-Scott
^ permalink raw reply
* Re: jffs2 and unaligned access
From: Segher Boessenkool @ 2008-05-07 20:42 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <1210157630.25560.884.camel@pmac.infradead.org>
>> memcpy_from/to_io() use word aligned accesses on the io side of
>> memory.
>> The MPC5200 local plus bus where our flashes are connected does not
>> allow unaligned accesses, so we have to use the io versions of memcpy.
>
> But this region of flash is marked as suitable for execute-in-place,
> otherwise the point() function wouldn't be working to give a direct
> pointer to it. It sounds like we shouldn't be allowing that.
>
> Which in turn means that perhaps we should have a property in the
> corresponding node in the device-tree which indicates that it's not
> suitable for direct access?
This isn't usually a property of the flash device, but of the various
buses/controllers above the flash device. The device tree should mimic
reality (and it does, it just seems the kernel doesn't use this
information
yet?)
Segher
^ permalink raw reply
* [PATCH] [POWERPC] Xilinx: add compatibility for IBM coreconnect busses.
From: Stephen Neuendorffer @ 2008-05-07 20:47 UTC (permalink / raw)
To: grant.likely, linuxppc-dev
The IBM coreconnect names are pretty well defined, it appears. In
addition, the Xilinx versions of these IPs seem to be proliferating.
Hence, in the future let's prefer to use the standard names. I've
left the old names in for some backward compatibility for existing
device trees.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
arch/powerpc/platforms/40x/virtex.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index 6c72994..7e1c0e3 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -16,11 +16,15 @@
#include <asm/xilinx_intc.h>
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = "ibm,plb3", },
+ { .compatible = "ibm,plb4", },
{ .compatible = "xlnx,plb-v46-1.00.a", },
{ .compatible = "xlnx,plb-v46-1.02.a", },
{ .compatible = "xlnx,plb-v34-1.01.a", },
{ .compatible = "xlnx,plb-v34-1.02.a", },
+ { .compatible = "ibm,opb", },
{ .compatible = "xlnx,opb-v20-1.10.c", },
+ { .compatible = "ibm,dcr", },
{ .compatible = "xlnx,dcr-v29-1.00.a", },
{ .compatible = "xlnx,compound", },
{}
--
1.5.3.4
^ permalink raw reply related
* error building 2.6.25 for G5
From: Chris Friesen @ 2008-05-07 21:08 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm getting the following error when building 2.6.25. Has anyone else
seen anything like this? This is using gcc 3.4.3.
CALL
/home/cfriesen/kernels/2.6.25/linux-2.6.25/scripts/checksyscalls.sh
CHK include/linux/compile.h
CALL
/home/cfriesen/kernels/2.6.25/linux-2.6.25/arch/powerpc/kernel/systbl_chk.sh
AS arch/powerpc/kernel/systbl.o
OBJCOPY arch/powerpc/kernel/vdso64/vdso64.so
BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
PT_DYNAMIC segment is not the .dynamic section
/home/cfriesen/bin/ppc64-R9a/bin/ppc64-R9a-objcopy:
arch/powerpc/kernel/vdso64/vdso64.so: Bad value
BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
PT_DYNAMIC segment is not the .dynamic section
/home/cfriesen/bin/ppc64-R9a/bin/ppc64-R9a-objcopy:
arch/powerpc/kernel/vdso64/vdso64.so: Bad value
make[3]: *** [arch/powerpc/kernel/vdso64/vdso64.so] Error 1
make[2]: *** [arch/powerpc/kernel/vdso64] Error 2
make[1]: *** [arch/powerpc/kernel] Error 2
make: *** [sub-make] Error 2
Chris
^ permalink raw reply
* Re: ALSA vs. non coherent DMA
From: Benjamin Herrenschmidt @ 2008-05-07 21:53 UTC (permalink / raw)
To: Timur Tabi; +Cc: Takashi Iwai, linuxppc-dev list, alsa-devel, Linux Kernel list
In-Reply-To: <4821BB0E.80000@freescale.com>
On Wed, 2008-05-07 at 09:22 -0500, Timur Tabi wrote:
> Takashi Iwai wrote:
>
> > This is a mmap of the data record to be shared in realtime with apps.
> > The app updates its data pointer (appl_ptr) on the mmapped buffer
> > while the driver updates the data (e.g. DMA position, called hwptr) on
> > the fly on the mmapped record. Due to its real-time nature, it has to
> > be coherent -- at least, it was a problem on ARM.
>
> This doesn't sound like a coherency problem to me, and least not one you'd find
> on PowerPC. Both the driver and the application run on the host CPU, so there
> shouldn't be any coherency problem. My understanding is that a "non coherent"
> platform is one where the host CPU isn't aware when a *hardware device* writes
> directly to memory, e.g. via DMA.
Yes, precisely. I was about to make a reply here. There is some
confusion at least in terminology, in Alsa. This is not DMA coherency,
though it is a problem with virtually tagged data caches that some archs
such as ARM have.
So this is ok for all PowerPC since they all have a physically tagged
data cache.
The real problem -is- still the DMA coherency issue and as I see it, is
two fold:
- mmap'ing of the result of dma_alloc_coherent() doesn't work. There
are two issues at play here, one is the pgprot that -must- be set to
uncached for such a mapping on non coherent architectures (and non
coherent architectures only), and the other is our virt_to_page() that
will puke on virtual addresses coming from dma_alloc_coherent().
- mmap'ing of SG lists for non coherent DMA. There the problem is a
mixture of how Alsa allocate the SG buffers mixes with the previous
problem.
I think it's never valid to create an SG list with the output of
dma_alloc_coherent though. We would need a dma_alloc_sg() for that...
sglists are made of pages, thus allocated with GFP, and later DMA mapped
with dma_map_*, however this brings a whole other set of issues/constra
ints such as bouce bufferring on some MMU less platforms if the memory
happens to come out of the wrong place. Also, such mapped buffers are
-not- coherent as they must not be modified via their virtual address
while mapped, -unless- they are also mapped in kernel and/or user space
(vmap & mmap) using some kind of "coherent" attributes such as
pgprot_noncached. (and provided that is possible at all in kernel place
for archs like MIPS).
I don't have an easy answer there, it seems the bogosity roots deep in
alsa, at least for the SG bits. For the non-SG bits, we can probably
work around with an accessor to get the right pgprot and maybe some
variant of virt_to_page() (dma_virt_to_page() ?) that would walk the
kernel page tables to obtain the pfn.
Ben.
^ permalink raw reply
* Re: error building 2.6.25 for G5 -- current git head affected as well
From: Chris Friesen @ 2008-05-07 22:01 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <48221A5F.6020306@nortel.com>
Chris Friesen wrote:
> Hi,
>
> I'm getting the following error when building 2.6.25. Has anyone else
> seen anything like this? This is using gcc 3.4.3.
> BFD: arch/powerpc/kernel/vdso64/vdso64.so: The first section in the
> PT_DYNAMIC segment is not the .dynamic section
> /home/cfriesen/bin/ppc64-R9a/bin/ppc64-R9a-objcopy:
> arch/powerpc/kernel/vdso64/vdso64.so: Bad value
I just verified that current git head shows the same problem. Binutils
version is 2.15.92.0.2, is this too old?
Chris
^ permalink raw reply
* Re: All your drivers are belong to us [was WARNING: mutexes are preferredfor single holder semaphores]
From: Sean MacLennan @ 2008-05-07 21:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <m23aouuqoh.fsf_-_@ohwell.denx.de>
On Wed, 07 May 2008 16:36:30 +0200
"Detlev Zundel" <dzu@denx.de> wrote:
> It also happened that a driver once posted for what the customer
> thought was a completely specific device of his own today supports
> lots of different boards from at least four different manufacturers."
>
> The wording is of course not exact but I hope I caught the spirit of
> what Greg wanted to say. So yes, please post the driver - maybe Greg
> KH will tunnel it into mainline...
I agree with the sentiment. However, it is hard enough to get
legitimate drivers into the kernel. The drivers I mentioned do not
come close to following the Linux kernel coding spec.
Just to start, they use 2 character spaces for indentation :( They are
full of ifdefs since we need to support the whole gamut of 2.6 kernels
plus windows. We also must support multiple board versions in the same
files.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: add compatibility for IBM coreconnect busses.
From: Grant Likely @ 2008-05-07 22:33 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080507204734.574B6185804E@mail138-sin.bigfish.com>
On Wed, May 7, 2008 at 2:47 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> The IBM coreconnect names are pretty well defined, it appears. In
> addition, the Xilinx versions of these IPs seem to be proliferating.
> Hence, in the future let's prefer to use the standard names. I've
> left the old names in for some backward compatibility for existing
> device trees.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likey@secretlab.ca>
I think we can probably give it a release or two and then drop the
older stuff in the list. Virtex support is still very new, so it is
unlikely that there are many (any?) users out there that won't be
keeping up to date with the xilinx device tree changes.
Cheers,
g.
> ---
> arch/powerpc/platforms/40x/virtex.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
> index 6c72994..7e1c0e3 100644
> --- a/arch/powerpc/platforms/40x/virtex.c
> +++ b/arch/powerpc/platforms/40x/virtex.c
> @@ -16,11 +16,15 @@
> #include <asm/xilinx_intc.h>
>
> static struct of_device_id xilinx_of_bus_ids[] __initdata = {
> + { .compatible = "ibm,plb3", },
> + { .compatible = "ibm,plb4", },
> { .compatible = "xlnx,plb-v46-1.00.a", },
> { .compatible = "xlnx,plb-v46-1.02.a", },
> { .compatible = "xlnx,plb-v34-1.01.a", },
> { .compatible = "xlnx,plb-v34-1.02.a", },
> + { .compatible = "ibm,opb", },
> { .compatible = "xlnx,opb-v20-1.10.c", },
> + { .compatible = "ibm,dcr", },
> { .compatible = "xlnx,dcr-v29-1.00.a", },
> { .compatible = "xlnx,compound", },
> {}
> --
> 1.5.3.4
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH] [POWERPC] Xilinx: add compatibility for IBM coreconnect busses.
From: Stephen Neuendorffer @ 2008-05-07 22:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40805071533m546b4954u1c6e88e7224f035c@mail.gmail.com>
Agreed... I intend the backward compatibility to be a temporary thing.
I'd rip it out now, but since we pull out all the information from the
device tree, this will result in 'it doesn't do anything', and I don't
want to be that mean. :)
Steve
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Wednesday, May 07, 2008 3:33 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for IBM
coreconnect busses.
>=20
> On Wed, May 7, 2008 at 2:47 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> > The IBM coreconnect names are pretty well defined, it appears. In
> > addition, the Xilinx versions of these IPs seem to be
proliferating.
> > Hence, in the future let's prefer to use the standard names. I've
> > left the old names in for some backward compatibility for existing
> > device trees.
> >
> > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
>=20
> Acked-by: Grant Likely <grant.likey@secretlab.ca>
>=20
> I think we can probably give it a release or two and then drop the
> older stuff in the list. Virtex support is still very new, so it is
> unlikely that there are many (any?) users out there that won't be
> keeping up to date with the xilinx device tree changes.
>=20
> Cheers,
> g.
>=20
> > ---
> > arch/powerpc/platforms/40x/virtex.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
> > index 6c72994..7e1c0e3 100644
> > --- a/arch/powerpc/platforms/40x/virtex.c
> > +++ b/arch/powerpc/platforms/40x/virtex.c
> > @@ -16,11 +16,15 @@
> > #include <asm/xilinx_intc.h>
> >
> > static struct of_device_id xilinx_of_bus_ids[] __initdata =3D {
> > + { .compatible =3D "ibm,plb3", },
> > + { .compatible =3D "ibm,plb4", },
> > { .compatible =3D "xlnx,plb-v46-1.00.a", },
> > { .compatible =3D "xlnx,plb-v46-1.02.a", },
> > { .compatible =3D "xlnx,plb-v34-1.01.a", },
> > { .compatible =3D "xlnx,plb-v34-1.02.a", },
> > + { .compatible =3D "ibm,opb", },
> > { .compatible =3D "xlnx,opb-v20-1.10.c", },
> > + { .compatible =3D "ibm,dcr", },
> > { .compatible =3D "xlnx,dcr-v29-1.00.a", },
> > { .compatible =3D "xlnx,compound", },
> > {}
> > --
> > 1.5.3.4
> >
> >
> >
> >
>=20
>=20
>=20
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] spi_mpc83xx: test below 0 on unsigned irq in mpc83xx_spi_probe()
From: Andrew Morton @ 2008-05-07 22:46 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, spi-devel-general, dbrownell, linux-kernel
In-Reply-To: <480FA234.1000601@tiscali.nl>
On Wed, 23 Apr 2008 22:55:16 +0200
Roel Kluin <12o3l@tiscali.nl> wrote:
> mpc83xx_spi->irq is unsigned, so the test fails
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
> ---
> diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
> index be15a62..033fd51 100644
> --- a/drivers/spi/spi_mpc83xx.c
> +++ b/drivers/spi/spi_mpc83xx.c
> @@ -454,12 +454,12 @@ static int __init mpc83xx_spi_probe(struct platform_device *dev)
> goto put_master;
> }
>
> - mpc83xx_spi->irq = platform_get_irq(dev, 0);
> -
> - if (mpc83xx_spi->irq < 0) {
> - ret = -ENXIO;
> + ret = platform_get_irq(dev, 0);
> + if (ret < 0)
> goto unmap_io;
> - }
> +
> + mpc83xx_spi->irq = ret;
> + ret = 0;
>
> /* Register for SPI Interrupt */
> ret = request_irq(mpc83xx_spi->irq, mpc83xx_spi_irq,
>
In the recently-merged spi_mpc83xx-much-improved-driver.patch, mpc83xx_spi.irq
has type `int' so I don't think we need this fix any more.
^ permalink raw reply
* Re: [PATCH] Add null pointer check to of_find_property
From: Michael Ellerman @ 2008-05-07 23:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, paulus
In-Reply-To: <1210187999-20274-1-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
On Wed, 2008-05-07 at 14:19 -0500, Timur Tabi wrote:
> Update function of_find_property() to return NULL if the device_node passed
> to it is also NULL. Otherwise, passing NULL will cause a null pointer
> dereference.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch allows callers to do this:
np = of_find_compatible_node(...);
prop = of_get_property(np);
if (!prop)
goto error;
...
error:
of_node_put(np)
:)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: add compatibility for IBM coreconnect busses.
From: David Gibson @ 2008-05-08 0:18 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080507204734.574B6185804E@mail138-sin.bigfish.com>
On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
> The IBM coreconnect names are pretty well defined, it appears. In
> addition, the Xilinx versions of these IPs seem to be proliferating.
> Hence, in the future let's prefer to use the standard names. I've
> left the old names in for some backward compatibility for existing
> device trees.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
If you're talking about future trees, can't you just slap "simple-bus"
on them avoid this monster id table?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: All your drivers are belong to us [was WARNING: mutexes are preferredfor single holder semaphores]
From: Josh Boyer @ 2008-05-08 0:49 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080507174251.2af863d6@wally.pikatech.com>
On Wed, 7 May 2008 17:42:51 -0400
Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Wed, 07 May 2008 16:36:30 +0200
> "Detlev Zundel" <dzu@denx.de> wrote:
>
> > It also happened that a driver once posted for what the customer
> > thought was a completely specific device of his own today supports
> > lots of different boards from at least four different manufacturers."
> >
> > The wording is of course not exact but I hope I caught the spirit of
> > what Greg wanted to say. So yes, please post the driver - maybe Greg
> > KH will tunnel it into mainline...
>
> I agree with the sentiment. However, it is hard enough to get
> legitimate drivers into the kernel. The drivers I mentioned do not
> come close to following the Linux kernel coding spec.
Here's the cool part. There's this Linux driver project:
http://www.linuxdriverproject.org/twiki/bin/view
where they can take drivers like that and clean them up. At least to a
reasonable degree. The benefit for you is that once it's cleaned up,
it can go into the mainline kernel and it will just be there in future
releases. Helpful when you update.
Now, I can't say I've personally ever used that project but its mission
does seem pretty targeted towards groups that want to do the right
thing with respect to drivers. Maybe you could give it a shot and tell
others about the experience.
josh
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcr infrastructure.
From: David Gibson @ 2008-05-08 1:57 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <4777b221c199009151e8f5b7b5f16de3@kernel.crashing.org>
On Tue, May 06, 2008 at 12:56:44PM +0200, Segher Boessenkool wrote:
>> Current standard practice is not to represent the DCR bus as node with
>> subnodes for the DCR-controlled devices. That's because the DCR bus
>> tends to run in addition to other on-chip busses, and some things have
>> to go on another on-chip bus to make sense, but still have DCR control
>> registers (for example the internal bus bridges on 4xx).
>
> Yeah.
>
>> Arguably for DCR-only devices we should instead have a node
>> representing the DCR bus and just put the devices under it with the
>> DCR number encoded in reg in the normal way.
>
> Right.
>
>> But then its
>> inconsistent with the devices that need the other DCR representation.
>
> OTOH, it _is_ consistent with all other (non-DCR) devices that way.
>
> What you could do right now is to give such DCR-only devices both
> normal "reg" etc., and the "dcr-reg" etc. properties, containing
> both the same info. If you do that, your device tree will be
> correct (because you got all the standard stuff right), and the
> kernel will like it as well (because it looks for the "dcr-reg"
> stuff).
> Then maybe later, if/when the kernel supports the standard addressing
> for DCR as well, you could drop the "dcr-reg" things from your DTS.
> Or you could just keep it.
>
> David, will this work, do you think?
Um.. yeah, I guess that should work. Don't forget to slap on
"simple-bus" as appropriate.
>> Segher and I did toss around some ideas for generalizing the DCR
>> representation to a way of representing that any node has some
>> presence on a bus other than its "primary" parent (e.g. other-bus-reg
>> = <&dcr-bus 0x0d0 0x010 &strange-i2c-control-bus 0xabc>). Then
>> DCR-only devices would use normal "reg", devices that sit on another
>> bus would sit on that bus and use this representation to show their
>> DCR control registers. Maybe one day.
>
> One day perhaps, yes :-)
>
> It sounds cleaner to split such a prop into separate props per bus.
> Maybe I said the opposite before, heh :-)
No I think you said that before, too, but I'm not sure I agree.
Seperate props per bus (well, per bus type, really) is probably more
human-readable, but a single prop has the advantage that we can have a
common parser that will interpret future variations on this theme
correctly without having to add things to some list of properties to
look for.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use dcrinfrastructure.
From: David Gibson @ 2008-05-08 1:59 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080506174352.52C857D805C@mail62-va3.bigfish.com>
On Tue, May 06, 2008 at 10:43:50AM -0700, Stephen Neuendorffer wrote:
[snip]
> > > Hmmm, something doesn't quite feel right about this. The node
> > > describing the tft device is a child of the dcr@0 node which is the
> > > dcr bus. However, dcr bindings use dcr-bus and dcr-reg instead of
> > > parent-child relationship to specify how to access the dcr
> registers.
> > > So, in this example; if the device is described by tft@80, and the
> dcr
> > > bus is described by opb2dcr-bridge@40700000, then what does dcr@0
> > > describe? (I do understand what they really describe in EDK terms;
> > > but I'm looking at it through device tree glasses).
> > >
> > > I don't think the presence of a dcr@0 node is a problem, but in this
> > > case #size/address-cells doesn't have any meaning (the child doesn't
> > > have a reg property) and it looks like it should be a child of the
> > > opb2dcr-bridge node (otherwise, what is it attached to?).
> >
> > Yes, indeed. If dcr@0 is representing the DCR bus / interface it
> > should really have the dcr-access-method property and have all the
> > dcr-parent handles point at it.
>
> Hmm, I tend to agree. Certainly the address-cells and size-cells can
> go. Part of the nastiness is that I'm trying to maintain a modicum of
> backward compatibility at the moment in the device tree generator. This
> structure allow the dcr@0 node to have ranges; and the tft node to have
> a properly translated reg = <> property for the existing driver which
> only understands mmio. I don't think it really works for the opb2dcr
> bridge to be a bridge and a dcr-controller at the same time. :) This
> structure is also very similar to what is generated if the
> dcr-controller is native from the processor (there's just no bridge).
I don't really understand what you're getting at here, sorry. Perhaps
you could describe what you're doing with the tft device in more
detail?
> > Current standard practice is not to represent the DCR bus as node with
> > subnodes for the DCR-controlled devices. That's because the DCR bus
> > tends to run in addition to other on-chip busses, and some things have
> > to go on another on-chip bus to make sense, but still have DCR control
> > registers (for example the internal bus bridges on 4xx).
> >
> > Arguably for DCR-only devices we should instead have a node
> > representing the DCR bus and just put the devices under it with the
> > DCR number encoded in reg in the normal way. But then its
> > inconsistent with the devices that need the other DCR representation.
>
> Yup, it's exactly this problem I'm trying to fix in the case of the tft
> driver.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add support for ULI RTC
From: Jin Zhengxiong @ 2008-05-08 2:08 UTC (permalink / raw)
To: Kumar Gala, Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <EFF7334F-3526-4E2B-8D5C-B97A02BDA71A@kernel.crashing.org>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+jinzhengxiong=3Dgmail.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+jinzhengxiong=3Dgmail.com@ozlabs.or
> g] On Behalf Of Kumar Gala
> Sent: Tuesday, May 06, 2008 3:12 AM
> To: Anton Vorontsov
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add=20
> support for ULI RTC
>=20
>=20
> On May 5, 2008, at 1:56 PM, Anton Vorontsov wrote:
>=20
> > The ULI "Super South Bridge" contains ISA bridge to the legacy=20
> > devices, such as Super IO mouse/keyboard/floppy disk controllers,=20
> > parallel port, i8259 interrupt controller and so on.
> >
> > On the MPC8610HPCD, i8259 seems to be disabled (mpc8610_hpcd.c=20
> > confirms this), and other peripherals are not traced out.
> > So we use only RTC.
> >
> > This patch also adds ULI quirk to make RTC actually work=20
> (this quirk=20
> > differs a bit from the one in the fsl_uli1575.c).
>=20
> Can we just one quick for both?
mpc8610HPCD board did not use the quirks in fsl_uli1575.c=20
Jason
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: add compatibility for IBM coreconnect busses.
From: Josh Boyer @ 2008-05-08 2:46 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080508001850.GB5156@yookeroo.seuss>
On Thu, 8 May 2008 10:18:50 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
> > The IBM coreconnect names are pretty well defined, it appears. In
> > addition, the Xilinx versions of these IPs seem to be proliferating.
> > Hence, in the future let's prefer to use the standard names. I've
> > left the old names in for some backward compatibility for existing
> > device trees.
> >
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> If you're talking about future trees, can't you just slap "simple-bus"
> on them avoid this monster id table?
What is that and how does it work?
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: add compatibility for IBM coreconnect busses.
From: David Gibson @ 2008-05-08 3:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080507214630.2f13fd22@zod.rchland.ibm.com>
On Wed, May 07, 2008 at 09:46:30PM -0500, Josh Boyer wrote:
> On Thu, 8 May 2008 10:18:50 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
> > > The IBM coreconnect names are pretty well defined, it appears. In
> > > addition, the Xilinx versions of these IPs seem to be proliferating.
> > > Hence, in the future let's prefer to use the standard names. I've
> > > left the old names in for some backward compatibility for existing
> > > device trees.
> > >
> > > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> >
> > If you're talking about future trees, can't you just slap "simple-bus"
> > on them avoid this monster id table?
>
> What is that and how does it work?
ePAPR states that busses which cannot be probed as such (i.e. the
device tree is the only way to figure out what's on the bus) should
have "simple-bus" in their compatible property. You can then just add
simple-bus to the of_bus_ids list and avoid adding umpteen other things.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
From: Kamalesh Babulal @ 2008-05-08 3:59 UTC (permalink / raw)
To: Adrian Bunk
Cc: kernel list, linuxppc-dev, Pierre Peiffer, Nadia Derbey,
Balbir Singh
In-Reply-To: <20080507134057.GA30637@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> On Wed, May 07, 2008 at 06:52:53PM +0530, Kamalesh Babulal wrote:
>> While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
>> task get blocked for more 120 seconds and does not proceeds future.
>>
>> The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2)
>> syscalls.
>
> Thanks for your report.
>
> I assume this is reproducible?
>
> If yes, what was the last kernel that worked for you?
This is reproducible on 2.6.26-rc1 and 2.6.26-rc1-git(s). 2.6.25 is the last know kernel
to work.
>
> I've also added Pierre Peiffer and Nadia Derbey to the Cc since their
> recent ipc commits are my first suspects.
>
>> Machine is stuck in the task, printing the following call trace
>> more than 5000 times. The oom-killer invoked once in-between.
>>
>> INFO: task msgctl08:16248 blocked for more than 120 seconds.
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Call Trace:
>> [c0000000762435a0] [0000000000000001] 0x1 (unreliable)
>> [c000000076243770] [c000000000010acc] .__switch_to+0x128/0x16c
>> [c000000076243800] [c0000000004b07a4] .schedule+0x7ac/0x890
>> [c0000000762438f0] [c0000000004b2ba4] .rwsem_down_failed_common+0x260/0x2b0
>> [c0000000762439b0] [c0000000004b2c60] .rwsem_down_read_failed+0x2c/0x44
>> [c000000076243a60] [c0000000004b1b84] .down_read+0x44/0x5c
>> [c000000076243af0] [c000000000295e10] .ipc_lock+0x34/0xe0
>> [c000000076243b90] [c00000000029690c] .ipc_lock_check+0x24/0x78
>> [c000000076243c20] [c0000000002972c0] .do_msgsnd+0xb0/0x3f8
>> [c000000076243d10] [c000000000293ce8] .compat_sys_msgsnd+0x94/0xc0
>> [c000000076243db0] [c000000000014418] .compat_sys_ipc+0x130/0x1f4
>> [c000000076243e30] [c000000000008734] syscall_exit+0x0/0x40
>> msgctl08 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0
>> Call Trace:
>> [c00000001e1c7640] [c0000000000101bc] .show_stack+0x70/0x1bc (unreliable)
>> [c00000001e1c76f0] [c0000000000c2c78] .oom_kill_process+0x78/0x230
>> [c00000001e1c77a0] [c0000000000c3390] .out_of_memory+0x28c/0x320
>> [c00000001e1c7870] [c0000000000c70ac] .__alloc_pages_internal+0x364/0x468
>> [c00000001e1c7980] [c0000000000e83cc] .alloc_page_vma+0x120/0x14c
>> [c00000001e1c7a20] [c0000000000e0224] .read_swap_cache_async+0x7c/0x160
>> [c00000001e1c7ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
>> [c00000001e1c7ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
>> [c00000001e1c7c80] [c0000000004b5054] .do_page_fault+0x440/0x624
>> [c00000001e1c7e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
>> Mem-info:
>> Node 0 DMA per-cpu:
>> CPU 0: hi: 6, btch: 1 usd: 1
>> CPU 1: hi: 6, btch: 1 usd: 1
>> Node 1 DMA per-cpu:
>> CPU 0: hi: 6, btch: 1 usd: 5
>> CPU 1: hi: 6, btch: 1 usd: 5
>> Active:31 inactive:2628 dirty:1 writeback:6 unstable:0
>> free:156 slab:13071 mapped:548 pagetables:41109 bounce:0
>> Node 0 DMA free:5312kB min:5760kB low:7168kB high:8640kB active:1024kB inactive:768kB present:3928832kB pages_scanned:3912 all_unreclaimable? no
>> lowmem_reserve[]: 0 0 0
>> Node 1 DMA free:4672kB min:4992kB low:6208kB high:7488kB active:960kB inactive:169792kB present:3404992kB pages_scanned:140140 all_unreclaimable? no
>> lowmem_reserve[]: 0 0 0
>> Node 0 DMA: 5*64kB 15*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 5312kB
>> Node 1 DMA: 8*64kB 5*128kB 6*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 4736kB
>> 8185 total pagecache pages
>> Swap cache: add 29545, delete 21888, find 5602/10373
>> Free swap = 803712kB
>> Total swap = 2048128kB
>> 114688 pages of RAM
>> 766 reserved pages
>> 231218 pages shared
>> 7657 pages swap cached
>> Out of memory: kill process 15371 (msgctl08) score 39223 or a child
>> Killed process 15373 (msgctl08)
>> INFO: task msgctl08:15385 blocked for more than 120 seconds.
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Call Trace:
>> [c0000000e9a43290] [0000000000000001] 0x1 (unreliable)
>> [c0000000e9a43460] [c000000000010acc] .__switch_to+0x128/0x16c
>> [c0000000e9a434f0] [c0000000004b07a4] .schedule+0x7ac/0x890
>> [c0000000e9a435e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
>> [c0000000e9a43670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
>> [c0000000e9a43750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
>> [c0000000e9a43800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
>> [c0000000e9a438e0] [c0000000002d81b0] .submit_bio+0x118/0x140
>> [c0000000e9a439a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
>> [c0000000e9a43a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
>> [c0000000e9a43ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
>> [c0000000e9a43ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
>> [c0000000e9a43c80] [c0000000004b5054] .do_page_fault+0x440/0x624
>> [c0000000e9a43e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
>> INFO: task msgctl08:15405 blocked for more than 120 seconds.
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Call Trace:
>> [c0000000b1757290] [0000000000000001] 0x1 (unreliable)
>> [c0000000b1757460] [c000000000010acc] .__switch_to+0x128/0x16c
>> [c0000000b17574f0] [c0000000004b07a4] .schedule+0x7ac/0x890
>> [c0000000b17575e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
>> [c0000000b1757670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
>> [c0000000b1757750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
>> [c0000000b1757800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
>> [c0000000b17578e0] [c0000000002d81b0] .submit_bio+0x118/0x140
>> [c0000000b17579a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
>> [c0000000b1757a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
>> [c0000000b1757ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
>> [c0000000b1757ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
>> [c0000000b1757c80] [c0000000004b5054] .do_page_fault+0x440/0x624
>> [c0000000b1757e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
>> INFO: task msgctl08:15406 blocked for more than 120 seconds.
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Call Trace:
>> [c0000000eec53290] [0000000000000001] 0x1 (unreliable)
>> [c0000000eec53460] [c000000000010acc] .__switch_to+0x128/0x16c
>> [c0000000eec534f0] [c0000000004b07a4] .schedule+0x7ac/0x890
>> [c0000000eec535e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
>> [c0000000eec53670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
>> [c0000000eec53750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
>> [c0000000eec53800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
>> [c0000000eec538e0] [c0000000002d81b0] .submit_bio+0x118/0x140
>> [c0000000eec539a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
>> [c0000000eec53a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
>> [c0000000eec53ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
>> [c0000000eec53ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
>> [c0000000eec53c80] [c0000000004b5054] .do_page_fault+0x440/0x624
>> [c0000000eec53e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
>> --
>> Thanks & Regards,
>> Kamalesh Babulal,
>> Linux Technology Center,
>> IBM, ISTL.
>
> cu
> Adrian
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH 1/2] Add irq_free_host() to free an irq_host
From: Michael Ellerman @ 2008-05-08 4:23 UTC (permalink / raw)
To: linuxppc-dev
Currently there is no irq_free_host() routine, and that's
more or less OK - because all you need to do is free it.
However the next patch needs to introduce additional
tear down so we'll need a proper free routine.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 15 ++++++++-------
include/asm-powerpc/irq.h | 8 ++++++++
2 files changed, 16 insertions(+), 7 deletions(-)
ps. This is 27 material.
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2f73f70..8ba8fbf 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -442,6 +442,13 @@ static int default_irq_host_match(struct irq_host *h, struct device_node *np)
return h->of_node != NULL && h->of_node == np;
}
+void irq_free_host(struct irq_host *host)
+{
+ /* If it's still very early in boot we can't free, oh well. */
+ if (mem_init_done)
+ kfree(host);
+}
+
struct irq_host *irq_alloc_host(struct device_node *of_node,
unsigned int revmap_type,
unsigned int revmap_arg,
@@ -478,13 +485,7 @@ struct irq_host *irq_alloc_host(struct device_node *of_node,
if (revmap_type == IRQ_HOST_MAP_LEGACY) {
if (irq_map[0].host != NULL) {
spin_unlock_irqrestore(&irq_big_lock, flags);
- /* If we are early boot, we can't free the structure,
- * too bad...
- * this will be fixed once slab is made available early
- * instead of the current cruft
- */
- if (mem_init_done)
- kfree(host);
+ irq_free_host(host);
return NULL;
}
irq_map[0].host = host;
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index 5089deb..7d9974a 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -165,6 +165,14 @@ extern struct irq_host *irq_alloc_host(struct device_node *of_node,
struct irq_host_ops *ops,
irq_hw_number_t inval_irq);
+/**
+ * irq_free_host - Free an irq_host data structure
+ * @host: The irq_host to free.
+ *
+ * Does any required cleanup and then frees the irq_host.
+ */
+extern void irq_free_host(struct irq_host *host);
+
/**
* irq_find_host - Locates a host for a given device node
--
1.5.5
^ permalink raw reply related
* [PATCH 2/2] Fix irq_alloc_host() reference counting and callers
From: Michael Ellerman @ 2008-05-08 4:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3c91644d7ab701f99ec7f621fc5c16d23e75c71a.1210220561.git.michael@ellerman.id.au>
When I changed irq_alloc_host() to take an of_node
(52964f87c64e6c6ea671b5bf3030fb1494090a48: "Add an
optional device_node pointer to the irq_host"),
I botched the reference counting semantics.
Stephen pointed out that it's irq_alloc_host()'s
business if it needs to take an additional reference
to the device_node, the caller shouldn't need to care.
To make that clean we also need a free routine, so
the caller doesn't have to deal with dropping the
reference.
Luckily we now have an irq_free_host() where we can
drop the reference - so we can make the reference
counting internal to irq_alloc_host()/irq_free_host().
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 4 +++-
arch/powerpc/platforms/cell/axon_msi.c | 4 ++--
arch/powerpc/platforms/cell/spider-pic.c | 2 +-
arch/powerpc/sysdev/cpm1.c | 2 +-
arch/powerpc/sysdev/cpm2_pic.c | 2 +-
arch/powerpc/sysdev/i8259.c | 2 +-
arch/powerpc/sysdev/ipic.c | 8 +++-----
arch/powerpc/sysdev/mpic.c | 6 ++----
arch/powerpc/sysdev/qe_lib/qe_ic.c | 6 ++----
arch/powerpc/sysdev/tsi108_pci.c | 3 +--
arch/powerpc/sysdev/uic.c | 6 ++----
11 files changed, 19 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 8ba8fbf..0cb2cf3 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -444,6 +444,8 @@ static int default_irq_host_match(struct irq_host *h, struct device_node *np)
void irq_free_host(struct irq_host *host)
{
+ of_node_put(host->of_node);
+
/* If it's still very early in boot we can't free, oh well. */
if (mem_init_done)
kfree(host);
@@ -472,7 +474,7 @@ struct irq_host *irq_alloc_host(struct device_node *of_node,
host->revmap_type = revmap_type;
host->inval_irq = inval_irq;
host->ops = ops;
- host->of_node = of_node;
+ host->of_node = of_node_get(of_node);
if (host->ops->match == NULL)
host->ops->match = default_irq_host_match;
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 8b055bc..45bddbc 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -358,7 +358,7 @@ static int axon_msi_probe(struct of_device *device,
goto out_free_msic;
}
- msic->irq_host = irq_alloc_host(of_node_get(dn), IRQ_HOST_MAP_NOMAP,
+ msic->irq_host = irq_alloc_host(dn, IRQ_HOST_MAP_NOMAP,
NR_IRQS, &msic_host_ops, 0);
if (!msic->irq_host) {
printk(KERN_ERR "axon_msi: couldn't allocate irq_host for %s\n",
@@ -400,7 +400,7 @@ static int axon_msi_probe(struct of_device *device,
return 0;
out_free_host:
- kfree(msic->irq_host);
+ irq_free_host(msic->irq_host);
out_free_fifo:
dma_free_coherent(&device->dev, MSIC_FIFO_SIZE_BYTES, msic->fifo_virt,
msic->fifo_phys);
diff --git a/arch/powerpc/platforms/cell/spider-pic.c b/arch/powerpc/platforms/cell/spider-pic.c
index 3f4b4ae..4e56556 100644
--- a/arch/powerpc/platforms/cell/spider-pic.c
+++ b/arch/powerpc/platforms/cell/spider-pic.c
@@ -300,7 +300,7 @@ static void __init spider_init_one(struct device_node *of_node, int chip,
panic("spider_pic: can't map registers !");
/* Allocate a host */
- pic->host = irq_alloc_host(of_node_get(of_node), IRQ_HOST_MAP_LINEAR,
+ pic->host = irq_alloc_host(of_node, IRQ_HOST_MAP_LINEAR,
SPIDER_SRC_COUNT, &spider_host_ops,
SPIDER_IRQ_INVALID);
if (pic->host == NULL)
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 58292a0..661df42 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -159,7 +159,7 @@ unsigned int cpm_pic_init(void)
out_be32(&cpic_reg->cpic_cimr, 0);
- cpm_pic_host = irq_alloc_host(of_node_get(np), IRQ_HOST_MAP_LINEAR,
+ cpm_pic_host = irq_alloc_host(np, IRQ_HOST_MAP_LINEAR,
64, &cpm_pic_host_ops, 64);
if (cpm_pic_host == NULL) {
printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
index 5fe65b2..b16ca3e 100644
--- a/arch/powerpc/sysdev/cpm2_pic.c
+++ b/arch/powerpc/sysdev/cpm2_pic.c
@@ -266,7 +266,7 @@ void cpm2_pic_init(struct device_node *node)
out_be32(&cpm2_intctl->ic_scprrl, 0x05309770);
/* create a legacy host */
- cpm2_pic_host = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LINEAR,
+ cpm2_pic_host = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
64, &cpm2_pic_host_ops, 64);
if (cpm2_pic_host == NULL) {
printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
diff --git a/arch/powerpc/sysdev/i8259.c b/arch/powerpc/sysdev/i8259.c
index 216c0f5..a96584a 100644
--- a/arch/powerpc/sysdev/i8259.c
+++ b/arch/powerpc/sysdev/i8259.c
@@ -276,7 +276,7 @@ void i8259_init(struct device_node *node, unsigned long intack_addr)
spin_unlock_irqrestore(&i8259_lock, flags);
/* create a legacy host */
- i8259_host = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LEGACY,
+ i8259_host = irq_alloc_host(node, IRQ_HOST_MAP_LEGACY,
0, &i8259_host_ops, 0);
if (i8259_host == NULL) {
printk(KERN_ERR "i8259: failed to allocate irq host !\n");
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 0f2dfb0..80ebba3 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -731,17 +731,15 @@ struct ipic * __init ipic_init(struct device_node *node, unsigned int flags)
memset(ipic, 0, sizeof(struct ipic));
- ipic->irqhost = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LINEAR,
+ ipic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_IPIC_INTS,
&ipic_host_ops, 0);
- if (ipic->irqhost == NULL) {
- of_node_put(node);
+ if (ipic->irqhost == NULL)
return NULL;
- }
ret = of_address_to_resource(node, 0, &res);
if (ret) {
- of_node_put(node);
+ irq_free_host(ipic->irqhost);
return NULL;
}
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..7df0252 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1016,13 +1016,11 @@ struct mpic * __init mpic_alloc(struct device_node *node,
memset(mpic, 0, sizeof(struct mpic));
mpic->name = name;
- mpic->irqhost = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LINEAR,
+ mpic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
isu_size, &mpic_host_ops,
flags & MPIC_LARGE_VECTORS ? 2048 : 256);
- if (mpic->irqhost == NULL) {
- of_node_put(node);
+ if (mpic->irqhost == NULL)
return NULL;
- }
mpic->irqhost->host_data = mpic;
mpic->hc_irq = mpic_irq_chip;
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index f59444d..b6f3d1c 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -335,12 +335,10 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags,
memset(qe_ic, 0, sizeof(struct qe_ic));
- qe_ic->irqhost = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LINEAR,
+ qe_ic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_QE_IC_INTS, &qe_ic_host_ops, 0);
- if (qe_ic->irqhost == NULL) {
- of_node_put(node);
+ if (qe_ic->irqhost == NULL)
return;
- }
ret = of_address_to_resource(node, 0, &res);
if (ret)
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index ac1a72d..24e1f5a 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -426,11 +426,10 @@ void __init tsi108_pci_int_init(struct device_node *node)
{
DBG("Tsi108_pci_int_init: initializing PCI interrupts\n");
- pci_irq_host = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LEGACY,
+ pci_irq_host = irq_alloc_host(node, IRQ_HOST_MAP_LEGACY,
0, &pci_irq_host_ops, 0);
if (pci_irq_host == NULL) {
printk(KERN_ERR "pci_irq_host: failed to allocate irq host !\n");
- of_node_put(node);
return;
}
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 625b275..d35405c 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -280,12 +280,10 @@ static struct uic * __init uic_init_one(struct device_node *node)
}
uic->dcrbase = *dcrreg;
- uic->irqhost = irq_alloc_host(of_node_get(node), IRQ_HOST_MAP_LINEAR,
+ uic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_UIC_INTS, &uic_host_ops, -1);
- if (! uic->irqhost) {
- of_node_put(node);
+ if (! uic->irqhost)
return NULL; /* FIXME: panic? */
- }
uic->irqhost->host_data = uic;
--
1.5.5
^ permalink raw reply related
* [PATCH 01/12] Move declaration of init_bootmem_done into system.h
From: Michael Ellerman @ 2008-05-08 4:27 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/init_32.c | 3 +--
include/asm-powerpc/system.h | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 1952b4d..4541859 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -43,6 +43,7 @@
#include <asm/btext.h>
#include <asm/tlb.h>
#include <asm/sections.h>
+#include <asm/system.h>
#include "mmu_decl.h"
@@ -76,8 +77,6 @@ void MMU_init(void);
/* XXX should be in current.h -- paulus */
extern struct task_struct *current_set[NR_CPUS];
-extern int init_bootmem_done;
-
/*
* this tells the system to map all of ram with the segregs
* (i.e. page tables) instead of the bats.
diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index 2b6559a..df781ad 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -190,6 +190,7 @@ extern struct task_struct *_switch(struct thread_struct *prev,
extern unsigned int rtas_data;
extern int mem_init_done; /* set on boot once kmalloc can be called */
+extern int init_bootmem_done; /* set on !NUMA once bootmem is available */
extern unsigned long memory_limit;
extern unsigned long klimit;
--
1.5.5
^ permalink raw reply related
* [PATCH 02/12] Fix sparse warnings in arch/powerpc/mm
From: Michael Ellerman @ 2008-05-08 4:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5d2ed2a7e92250bdc6d9959dbeaeb3784a7109b4.1210220828.git.michael@ellerman.id.au>
Make two vmemmap helpers static in init_64.c.
Make stab variables static in stab.c
Make psize defs static in hash_utils_64.c
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/hash_utils_64.c | 4 ++--
arch/powerpc/mm/init_64.c | 4 ++--
arch/powerpc/mm/stab.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2b5a399..1a4b4b3 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -117,7 +117,7 @@ static DEFINE_SPINLOCK(linear_map_hash_lock);
/* Pre-POWER4 CPUs (4k pages only)
*/
-struct mmu_psize_def mmu_psize_defaults_old[] = {
+static struct mmu_psize_def mmu_psize_defaults_old[] = {
[MMU_PAGE_4K] = {
.shift = 12,
.sllp = 0,
@@ -131,7 +131,7 @@ struct mmu_psize_def mmu_psize_defaults_old[] = {
*
* Support for 16Mb large pages
*/
-struct mmu_psize_def mmu_psize_defaults_gp[] = {
+static struct mmu_psize_def mmu_psize_defaults_gp[] = {
[MMU_PAGE_4K] = {
.shift = 12,
.sllp = 0,
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index c5ac532..1e52e97 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -183,7 +183,7 @@ void pgtable_cache_init(void)
* do this by hand as the proffered address may not be correctly aligned.
* Subtraction of non-aligned pointers produces undefined results.
*/
-unsigned long __meminit vmemmap_section_start(unsigned long page)
+static unsigned long __meminit vmemmap_section_start(unsigned long page)
{
unsigned long offset = page - ((unsigned long)(vmemmap));
@@ -196,7 +196,7 @@ unsigned long __meminit vmemmap_section_start(unsigned long page)
* which overlaps this vmemmap page is initialised then this page is
* initialised already.
*/
-int __meminit vmemmap_populated(unsigned long start, int page_size)
+static int __meminit vmemmap_populated(unsigned long start, int page_size)
{
unsigned long end = start + page_size;
diff --git a/arch/powerpc/mm/stab.c b/arch/powerpc/mm/stab.c
index efbbd13..60e6032 100644
--- a/arch/powerpc/mm/stab.c
+++ b/arch/powerpc/mm/stab.c
@@ -30,8 +30,8 @@ struct stab_entry {
};
#define NR_STAB_CACHE_ENTRIES 8
-DEFINE_PER_CPU(long, stab_cache_ptr);
-DEFINE_PER_CPU(long, stab_cache[NR_STAB_CACHE_ENTRIES]);
+static DEFINE_PER_CPU(long, stab_cache_ptr);
+static DEFINE_PER_CPU(long, stab_cache[NR_STAB_CACHE_ENTRIES]);
/*
* Create a segment table entry for the given esid/vsid pair.
--
1.5.5
^ permalink raw reply related
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