* Re: 5121 cache handling.
From: Kenneth Johansson @ 2009-08-10 20:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090807195600.GB11681@b07421-ec1.am.freescale.net>
On Fri, 2009-08-07 at 14:56 -0500, Scott Wood wrote:
> On Fri, Aug 07, 2009 at 02:53:52PM +0200, Kenneth Johansson wrote:
> > on 5121 there is a e300 core that unfortunately is connected to the rest
> > of the SOC with a bus that do not support coherency.
> >
> > solution for many driver has been to use uncached memory. But for the
> > framebuffer that is not going to work as the performance impact of doing
> > graphics operations on uncached memory is to large.
> >
> > currently the "solution" is to flush the cache in the interrupt
> > handler.
> >
> > #if defined(CONFIG_NOT_COHERENT_CACHE)
> > int i;
> > unsigned int *ptr;
> > ptr = coherence_data;
> > for (i = 0; i < 1024*8; i++)
> > *ptr++ = 0;
> > #endif
> >
> > Now this apparently is not enough on a e300 core that has a PLRU cache
> > replacement algorithm. but what is the optimal solution?
>
> Which driver (in which kernel) are you looking at?
The one included in ltib 2009-06-02 for ads5121. Thought that was
including the latest drivers.
> drivers/video/fsl-diu-fb.c in current mainline has properly sized
> coherence data. It also does a dcbz (on unused data) instead of loads,
> as it's apparently faster (though I'd think you'd get more traffic
> flushing those zeroes out later on, compared to a clean line that can
> just be discarded).
It's hard to know exactly how things behave when cache is involved.
But the code allocate the 52KB buffer with vmalloc that cant be right as
cache is stored with physical address the 52KB data need to be 52KB
continuous in physical address and vmalloc do not guarantee that.
> > should not the framebuffer be marked as cache write through. that is the
> > W bit should be set in the tlb mapping. Why is this not done ? is that
> > feature also not working on 5121 ??
>
> It probably would have been too slow.
how much slower would write through be ? I thought it was not that big
of a difference from copy back.
^ permalink raw reply
* Linux MAINTAINERS section FREESCALE HIGHSPEED USB DEVICE DRIVER
From: Joe Perches @ 2009-08-10 19:08 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Guennadi Liakhovetski, linux-usb
Hi.
This entry, copied below, is no longer correct.
The "F:" entry got renamed by commit
54e4026b64a970303349b952866641a7804ef594
New file: drivers/usb/gadget/fsl_udc_core.c
Are you still maintaining this file?
You did not sign-off on the rename.
What should be done here?
cheers, Joe
FREESCALE HIGHSPEED USB DEVICE DRIVER
M: Li Yang <leoli@freescale.com>
L: linux-usb@vger.kernel.org
L: linuxppc-dev@ozlabs.org
S: Maintained
F: drivers/usb/gadget/fsl_usb2_udc.c
^ permalink raw reply
* Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
From: Artem Bityutskiy @ 2009-08-10 16:25 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Vitaly Wool, Albrecht Dreß, linuxppc-dev,
linux-mtd, Ken MacLeod, David Woodhouse
In-Reply-To: <20090810161942.GA27833@pengutronix.de>
On Mon, 2009-08-10 at 18:19 +0200, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> > On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > > > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > > > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > > > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > > > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> > > >
> > > > Tested with a phyCORE-MPC5121e.
> > > >
> > > > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> > >
> > > Looks good to me.
> > >
> > > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > This patch is sitting in my l2-mtd-2.6.git tree.
>
> Great, thanks a lot (and for your l2-tree in general!). One question: Are the
> additional Acked-bys added later? I could think they might be useful for
> David's review...
Well, I do not bother maintaining nice history there, so rebase it
freely, which means I can add your ack. Will do tomorrow.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
From: Wolfram Sang @ 2009-08-10 16:19 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: devicetree-discuss, Vitaly Wool, Albrecht Dreß, linuxppc-dev,
linux-mtd, Ken MacLeod, David Woodhouse
In-Reply-To: <1249795043.9157.37.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> > >
> > > Tested with a phyCORE-MPC5121e.
> > >
> > > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> >
> > Looks good to me.
> >
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> This patch is sitting in my l2-mtd-2.6.git tree.
Great, thanks a lot (and for your l2-tree in general!). One question: Are the
additional Acked-bys added later? I could think they might be useful for
David's review...
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: need help getting SPI controller working on 405EX
From: Nathan French @ 2009-08-10 16:07 UTC (permalink / raw)
To: Lorenz Kolb; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <h5mjg0$rqs$1@ger.gmane.org>
Lorenz, thanks for the reply.
> For getting spidev devices you have to add entries for an spidev device
> to your newly created spi-"bus". So what you are currently missing are
> the spidev child-nodes in the device tree.
> As I'm currently cut off from some device to test, no guaranty that it
> will work, but your dts entry should look something like:
>
> SPI0: spi@ef600600 {
> cell-index = <0>;
> compatible = "ibm,spi-405ex", "ibm,spi";
> reg = <ef600600 6>;
> interrupts = <8 4>;
> interrupt-parent = <&UIC0>;
> mode = "cpu";
>
> yourdevice@0 {
> compatible = "spidev";
> spi-max-frequency = <1000000>; /* what ever your
> max-freq. is */
> reg = <0>; /* Chipselect-address */
> };
> };
This did not appear to have any effect.
> At least something similar worked for me some months ago (before we
> switched to a "real" driver for some custom peripheral).
Did this work on a 4xx PowerPC platform? Or something else? I've been
told that there is no SPI driver for 4xx. If you have done this on 4xx
then I'm very interested.
Thanks,
Nathan
^ permalink raw reply
* [PATCH 2/2] Support R_PPC64_REL32 relocation type
From: M. Mohan Kumar @ 2009-08-10 14:14 UTC (permalink / raw)
To: horms, kexec; +Cc: linuxppc-dev, nhorman, miltonm
[PATCH 2/2] Support R_PPC64_REL32 relocation type
gcc-4.4 compiler creates R_PPC64_REL32 relocation type in the ppc64
purgatory code. Add support to handle R_PPC64_REL32 relocation type.
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
---
kexec/arch/ppc64/kexec-elf-rel-ppc64.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kexec/arch/ppc64/kexec-elf-rel-ppc64.c b/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
index 80543af..97aa34c 100644
--- a/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
+++ b/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
@@ -62,6 +62,10 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, unsigned long r_type,
*(uint64_t *)location = value;
break;
+ case R_PPC64_REL32:
+ *(uint32_t *)location = value - (uint32_t)location;
+ break;
+
case R_PPC64_TOC:
*(uint64_t *)location = my_r2(ehdr);
break;
--
1.6.2.5
^ permalink raw reply related
* [PATCH 1/2] Make dtstruct variable to be 8 byte aligned
From: M. Mohan Kumar @ 2009-08-10 14:13 UTC (permalink / raw)
To: horms, kexec; +Cc: linuxppc-dev, nhorman, miltonm
[PATCH 1/2] Make dtstruct variable to be 8 byte aligned
kexec is creating a version 3 device tree to be backwards compatible. This
version of the struct has 8-byte alignment for properties whose value is 8 or
more bytes. As the code directly checks the pointer when deciding to add the
alignment word, the struct memory must start on an 8 byte boundary. Force the
dtstruct variable to be always 8 bytes aligned.
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
---
kexec/arch/ppc64/fs2dt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..b01ff86 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -41,7 +41,7 @@
static char pathname[MAXPATH], *pathstart;
static char propnames[NAMESPACE] = { 0 };
-static unsigned dtstruct[TREEWORDS], *dt;
+static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
static unsigned long long mem_rsrv[2*MEMRESERVE] = { 0, 0 };
static int crash_param = 0;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 03/14] powerpc: use printk_once
From: Gary Thomas @ 2009-08-10 11:56 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras, LKML, Marcin Slusarz
In-Reply-To: <1249904809.4958.4.camel@concordia>
Michael Ellerman wrote:
> On Mon, 2009-08-10 at 10:00 +0200, Wolfram Sang wrote:
>> On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
>>> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: linuxppc-dev@ozlabs.org
>>> ---
>>> arch/powerpc/kernel/iommu.c | 6 +-----
>>> arch/powerpc/kernel/irq.c | 5 ++---
>>> arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
>>> 3 files changed, 5 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>>> index fd51578..c7fa258 100644
>>> --- a/arch/powerpc/kernel/iommu.c
>>> +++ b/arch/powerpc/kernel/iommu.c
>>> @@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
>>> struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>>> {
>>> unsigned long sz;
>>> - static int welcomed = 0;
>>> struct page *page;
>>>
>>> /* Set aside 1/4 of the table for large allocations. */
>>> @@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>>>
>>> iommu_table_clear(tbl);
>>>
>>> - if (!welcomed) {
>>> - printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
>>> + printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
>>> novmerge ? "disabled" : "enabled");
>>> - welcomed = 1;
>>> - }
>>>
>>> return tbl;
>>> }
>>> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
>>> index f7f376e..05ebd21 100644
>>> --- a/arch/powerpc/kernel/irq.c
>>> +++ b/arch/powerpc/kernel/irq.c
>>> @@ -231,7 +231,6 @@ skip:
>>> void fixup_irqs(cpumask_t map)
>>> {
>>> unsigned int irq;
>>> - static int warned;
>>>
>>> for_each_irq(irq) {
>>> cpumask_t mask;
>>> @@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
>>> }
>>> if (irq_desc[irq].chip->set_affinity)
>>> irq_desc[irq].chip->set_affinity(irq, &mask);
>>> - else if (irq_desc[irq].action && !(warned++))
>>> - printk("Cannot set affinity for irq %i\n", irq);
>>> + else if (irq_desc[irq].action)
>>> + printk_once("Cannot set affinity for irq %i\n", irq);
>> Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
>> while we are here?
>
> I think you should drop it, it's stupid. If we actually care about irqs
> that don't have a set affinity we should keep a count and report that at
> the end of the loop.
In addition, this change would prevent reporting missing
affinity on more than one IRQ if there were such.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 03/14] powerpc: use printk_once
From: Michael Ellerman @ 2009-08-10 11:46 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Paul Mackerras, Marcin Slusarz, LKML
In-Reply-To: <20090810080049.GA3132@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]
On Mon, 2009-08-10 at 10:00 +0200, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
> > Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: linuxppc-dev@ozlabs.org
> > ---
> > arch/powerpc/kernel/iommu.c | 6 +-----
> > arch/powerpc/kernel/irq.c | 5 ++---
> > arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
> > 3 files changed, 5 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> > index fd51578..c7fa258 100644
> > --- a/arch/powerpc/kernel/iommu.c
> > +++ b/arch/powerpc/kernel/iommu.c
> > @@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
> > struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> > {
> > unsigned long sz;
> > - static int welcomed = 0;
> > struct page *page;
> >
> > /* Set aside 1/4 of the table for large allocations. */
> > @@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> >
> > iommu_table_clear(tbl);
> >
> > - if (!welcomed) {
> > - printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> > + printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> > novmerge ? "disabled" : "enabled");
> > - welcomed = 1;
> > - }
> >
> > return tbl;
> > }
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index f7f376e..05ebd21 100644
> > --- a/arch/powerpc/kernel/irq.c
> > +++ b/arch/powerpc/kernel/irq.c
> > @@ -231,7 +231,6 @@ skip:
> > void fixup_irqs(cpumask_t map)
> > {
> > unsigned int irq;
> > - static int warned;
> >
> > for_each_irq(irq) {
> > cpumask_t mask;
> > @@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
> > }
> > if (irq_desc[irq].chip->set_affinity)
> > irq_desc[irq].chip->set_affinity(irq, &mask);
> > - else if (irq_desc[irq].action && !(warned++))
> > - printk("Cannot set affinity for irq %i\n", irq);
> > + else if (irq_desc[irq].action)
> > + printk_once("Cannot set affinity for irq %i\n", irq);
>
> Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
> while we are here?
I think you should drop it, it's stupid. If we actually care about irqs
that don't have a set affinity we should keep a count and report that at
the end of the loop.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Pavel Machek @ 2009-08-10 8:19 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Pallipadi, Venkatesh, Shaohua Li,
Ingo Molnar, linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <200908091522.02898.rjw@sisk.pl>
On Sun 2009-08-09 15:22:02, Rafael J. Wysocki wrote:
> On Sunday 09 August 2009, Pavel Machek wrote:
> > Hi!
> >
> > > > Also, approaches such as [1] can make use of this
> > > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > > when it is offlined, thereby providing the system administrator a rope to hang
> > > > himself with should he feel the need to do so.
> > > I didn't see the reason why administrator needs to know which state offline cpu
> > > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > > C-state is already preferred.
> > >
> >
> > Agreed, deepest c-state is always best, there's no need to make it configurable.
>
> Unless it doesn't work.
If it does not work, machine will not boot. We already have
max_cstate= kernel command line option to work around that...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Milton Miller @ 2009-08-10 7:37 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: kexec, Simon Horman, linuxppc-dev
In-Reply-To: <20090805164938.GA2970@in.ibm.com>
On Thu Aug 6 at about 02:49:38 EST in 2009, M. Mohan Kumar wrote:
>
> When I align the dtstruct variable to 8 bytes, I am able to invoke kdump.
>
> When the line
> static unsigned dtstruct[TREEWORDS], *dt;
> changed to
> static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
>
> kexec-tool works.
Doh. that is the correct fix.
kexec is creating a version 3 device tree, to be backwards compatible
as far as possible. (Well, that and it was written before version 3
existed). This version of the struct has 8-byte alignment for properties
whose value is 8 or more bytes. As the code directly checks the pointer
when deciding to add the alignment word, the struct memory must start on
an 8 byte boundary.
Mohan, please prepare a patch with the above text in the changelog
and send it to Simon.
thanks.
milton
^ permalink raw reply
* Re: [PATCH 03/14] powerpc: use printk_once
From: Wolfram Sang @ 2009-08-10 8:00 UTC (permalink / raw)
To: Marcin Slusarz; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1249847649-11631-4-git-send-email-marcin.slusarz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/kernel/iommu.c | 6 +-----
> arch/powerpc/kernel/irq.c | 5 ++---
> arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
> 3 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index fd51578..c7fa258 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
> struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> {
> unsigned long sz;
> - static int welcomed = 0;
> struct page *page;
>
> /* Set aside 1/4 of the table for large allocations. */
> @@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>
> iommu_table_clear(tbl);
>
> - if (!welcomed) {
> - printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> + printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> novmerge ? "disabled" : "enabled");
> - welcomed = 1;
> - }
>
> return tbl;
> }
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index f7f376e..05ebd21 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -231,7 +231,6 @@ skip:
> void fixup_irqs(cpumask_t map)
> {
> unsigned int irq;
> - static int warned;
>
> for_each_irq(irq) {
> cpumask_t mask;
> @@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
> }
> if (irq_desc[irq].chip->set_affinity)
> irq_desc[irq].chip->set_affinity(irq, &mask);
> - else if (irq_desc[irq].action && !(warned++))
> - printk("Cannot set affinity for irq %i\n", irq);
> + else if (irq_desc[irq].action)
> + printk_once("Cannot set affinity for irq %i\n", irq);
Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
while we are here?
Other than that:
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: sequoia: The final kernel image would overwrite the device tree
From: Geert Uytterhoeven @ 2009-08-10 7:49 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Stefan Roese, Linux/PPC Development
In-Reply-To: <20090808073807.18C4B832E416@gemini.denx.de>
On Sat, 8 Aug 2009, Wolfgang Denk wrote:
> In message <1249678991.10143.1.camel@pasglop> you wrote:
> > My experience, however, with a Canyonlands board, is that uBoot has
> > a bug that makes it always allocate the device-tree below 8M and clash
> > with the kernel when it gets too big.
> >
> > I think Stefan fixed that recently, you may need to rebuild your uboot,
> > I'll let him tell you the details about the fix.
>
> Right. These are the relevant commits; they went into mainline some
> time ago:
>
> commit 27dd5f8e1062684f1ba685760409d9b2ab6691bf
> Author: Stefan Roese <sr@denx.de>
> Date: Tue Jul 28 10:56:03 2009 +0200
>
> ppc4xx: amcc: Move "kernel_addr_r" etc to higher locations (> 16MB)
>
> This patch moves the load addresses for kernel, fdt and ramdisk to higher
> addresses (>= 16MB). This enables booting of bigger kernel images (e.g.
> lockdep enabled).
Ah, thanks, that explains it.
I'll make sure my kernel images get smaller again ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH v2 0/6] Device table matching for SPI subsystem
From: Artem Bityutskiy @ 2009-08-10 7:35 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, Andrew Morton, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
On Fri, 2009-07-31 at 04:39 +0400, Anton Vorontsov wrote:
> Andrew,
>
> This new patch set overwrites following patches:
>
> hwmon-lm70-convert-to-device-table-matching.patch
> hwmon-adxx-convert-to-device-table-matching.patch
> spi-merge-probe-and-probe_id-callbacks.patch
> spi-prefix-modalias-with-spi.patch
> of-remove-stmm25p40-alias.patch
> mtd-m25p80-convert-to-device-table-matching.patch
> spi-add-support-for-device-table-matching.patch
Are you going to send v3 and address David's comments?
Do you want some of these patches to go via the MTD tree or
they better go as a series via some other tree?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-08-10 6:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
This is a simple enough fix that I decided was worth having now, it
basically allow "direct" DMA (non-iommu) to work for devices that have a
< 32-bit DMA mask (such as some infamous broadcom wireless chips) when
the machine simply has not enough memory to go over the chip addressing
limit. This fixes various smallish G5 (like old iMac G5) wireless.
The following changes since commit f4b9a988685da6386d7f9a72df3098bcc3270526:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.infradead.org/ubi-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc/dma: pci_set_dma_mask() shouldn't fail if mask fits in RAM
arch/powerpc/kernel/dma.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-08-10 6:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249069310.20192.220.camel@macbook.infradead.org>
On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> On an iMac G5, the b43 driver is failing to initialise because trying to
> set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> in the machine anyway:
> https://bugzilla.redhat.com/show_bug.cgi?id=514787
>
> We should probably let it succeed if the available RAM in the system
> doesn't exceed the requested limit.
I've slightly modified the patch to use lmb_end_of_DRAM() instead
of highest_memmap_pfn because the later is an mm internal.h thing,
it looked too fishy to rely on it form arch code with a local
"extern" in the C code :-) It's not going to cause much more overhead
and it's not a hot path anyway afaik.
Below is a copy of what I've commited to my merge branch and will
ask Linus to pull in a few minutes.
>From 10ba96df690618632a8786494b2359f5ee350048 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw2@infradead.org>
Date: Fri, 31 Jul 2009 09:41:50 +0000
Subject: [PATCH] powerpc/dma: pci_set_dma_mask() shouldn't fail if mask fits in RAM
On an iMac G5, the b43 driver is failing to initialise because trying to
set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
in the machine anyway:
https://bugzilla.redhat.com/show_bug.cgi?id=514787
We should probably let it succeed if the available RAM in the system
doesn't exceed the requested limit.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/dma.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 20a60d6..ccf129d 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -7,6 +7,7 @@
#include <linux/device.h>
#include <linux/dma-mapping.h>
+#include <linux/lmb.h>
#include <asm/bug.h>
#include <asm/abs_addr.h>
@@ -90,11 +91,10 @@ static void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sg,
static int dma_direct_dma_supported(struct device *dev, u64 mask)
{
#ifdef CONFIG_PPC64
- /* Could be improved to check for memory though it better be
- * done via some global so platforms can set the limit in case
+ /* Could be improved so platforms can set the limit in case
* they have limited DMA windows
*/
- return mask >= DMA_BIT_MASK(32);
+ return mask >= (lmb_end_of_DRAM() - 1);
#else
return 1;
#endif
--
1.6.1.2.14.gf26b5
^ permalink raw reply related
* [PATCH 2/2] kmemleak: Allow kmemleak to be built on powerpc
From: Michael Ellerman @ 2009-08-10 5:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: catalin.marinas
In-Reply-To: <ab02e115992881a734e8e90b7d3f2d8617db4bf2.1249880775.git.michael@ellerman.id.au>
Lightly tested, doesn't crash the kernel, leak reports appear
to be mostly sane.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
lib/Kconfig.debug | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 12327b2..d5ca9a5 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -338,7 +338,7 @@ config SLUB_STATS
config DEBUG_KMEMLEAK
bool "Kernel memory leak detector"
- depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM) && \
+ depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM || PPC) && \
!MEMORY_HOTPLUG
select DEBUG_FS if SYSFS
select STACKTRACE if STACKTRACE_SUPPORT
--
1.6.2.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/vmlinux.lds: Move _edata down
From: Michael Ellerman @ 2009-08-10 5:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: catalin.marinas
Currently _edata does not include several data sections, this causes
the kernel's report of memory usage at boot to not match reality, and
also prevents kmemleak from working - because it scan between _sdata
and _edata for pointers to allocated memory.
This mirrors a similar change made recently to the x86 linker script.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 8ef8a14..3bb0997 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -245,10 +245,6 @@ SECTIONS
}
#endif
- . = ALIGN(PAGE_SIZE);
- _edata = .;
- PROVIDE32 (edata = .);
-
/* The initial task and kernel stack */
#ifdef CONFIG_PPC32
. = ALIGN(8192);
@@ -282,6 +278,10 @@ SECTIONS
__nosave_end = .;
}
+ . = ALIGN(PAGE_SIZE);
+ _edata = .;
+ PROVIDE32 (edata = .);
+
/*
* And finally the bss
*/
--
1.6.2.1
^ permalink raw reply related
* [PATCH] Add kmemleak annotations to lmb.c
From: Michael Ellerman @ 2009-08-10 5:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: catalin.marinas, David S. Miller, linux-kernel
We don't actually want kmemleak to track the lmb allocations, so we
pass min_count as 0. However telling kmemleak about lmb allocations
allows it to scan that memory for pointers to other memory that is
tracked by kmemleak, ie. slab allocations etc.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
lib/lmb.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index e4a6482..dc10bc5 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -352,8 +352,10 @@ u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
u64 ret = lmb_alloc_nid_region(&mem->region[i],
nid_range,
size, align, nid);
- if (ret != ~(u64)0)
+ if (ret != ~(u64)0) {
+ kmemleak_alloc(__va(ret), size, 0, 0);
return ret;
+ }
}
return lmb_alloc(size, align);
@@ -412,6 +414,8 @@ u64 __init __lmb_alloc_base(u64 size, u64 align, u64 max_addr)
/* this area isn't reserved, take it */
if (lmb_add_region(&lmb.reserved, base, size) < 0)
return 0;
+
+ kmemleak_alloc(__va(base), size, 0, 0);
return base;
}
res_base = lmb.reserved.region[j].base;
--
1.6.2.1
^ permalink raw reply related
* [PATCH] powerpc: Enable GCOV
From: Michael Ellerman @ 2009-08-10 5:02 UTC (permalink / raw)
To: linuxppc-dev
Make it possible to enable GCOV code coverage measurement on powerpc.
Lightly tested on 64-bit, seems to work as expected.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 7 +++++++
arch/powerpc/kernel/vdso32/Makefile | 1 +
arch/powerpc/kernel/vdso64/Makefile | 2 ++
arch/powerpc/xmon/Makefile | 2 ++
kernel/gcov/Kconfig | 2 +-
5 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 035946f..720e8c3 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -115,6 +115,13 @@ ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),)
obj-y += ppc_save_regs.o
endif
+# Disable GCOV in odd or sensitive code
+GCOV_PROFILE_prom_init.o := n
+GCOV_PROFILE_ftrace.o := n
+GCOV_PROFILE_machine_kexec_64.o := n
+GCOV_PROFILE_machine_kexec_32.o := n
+GCOV_PROFILE_kprobes.o := n
+
extra-$(CONFIG_PPC_FPU) += fpu.o
extra-$(CONFIG_ALTIVEC) += vector.o
extra-$(CONFIG_PPC64) += entry_64.o
diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile
index c3d57bd..b54b816 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -12,6 +12,7 @@ endif
targets := $(obj-vdso32) vdso32.so vdso32.so.dbg
obj-vdso32 := $(addprefix $(obj)/, $(obj-vdso32))
+GCOV_PROFILE := n
EXTRA_CFLAGS := -shared -fno-common -fno-builtin
EXTRA_CFLAGS += -nostdlib -Wl,-soname=linux-vdso32.so.1 \
diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
index fa7f1b8..dd0c8e9 100644
--- a/arch/powerpc/kernel/vdso64/Makefile
+++ b/arch/powerpc/kernel/vdso64/Makefile
@@ -7,6 +7,8 @@ obj-vdso64 = sigtramp.o gettimeofday.o datapage.o cacheflush.o note.o
targets := $(obj-vdso64) vdso64.so vdso64.so.dbg
obj-vdso64 := $(addprefix $(obj)/, $(obj-vdso64))
+GCOV_PROFILE := n
+
EXTRA_CFLAGS := -shared -fno-common -fno-builtin
EXTRA_CFLAGS += -nostdlib -Wl,-soname=linux-vdso64.so.1 \
$(call ld-option, -Wl$(comma)--hash-style=sysv)
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index 85ab97a..faa81b6 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -2,6 +2,8 @@
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
+GCOV_PROFILE := n
+
ifdef CONFIG_PPC64
EXTRA_CFLAGS += -mno-minimal-toc
endif
diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
index 22e9dcf..654efd0 100644
--- a/kernel/gcov/Kconfig
+++ b/kernel/gcov/Kconfig
@@ -34,7 +34,7 @@ config GCOV_KERNEL
config GCOV_PROFILE_ALL
bool "Profile entire Kernel"
depends on GCOV_KERNEL
- depends on S390 || X86
+ depends on S390 || X86 || (PPC && EXPERIMENTAL)
default n
---help---
This options activates profiling for the entire kernel.
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Vaidyanathan Srinivasan @ 2009-08-10 2:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Pavel Machek, Pallipadi, Venkatesh,
Shaohua Li, Ingo Molnar, linuxppc-dev@lists.ozlabs.org,
Darrick J. Wong
In-Reply-To: <200908091522.02898.rjw@sisk.pl>
* Rafael J. Wysocki <rjw@sisk.pl> [2009-08-09 15:22:02]:
> On Sunday 09 August 2009, Pavel Machek wrote:
> > Hi!
> >
> > > > Also, approaches such as [1] can make use of this
> > > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > > when it is offlined, thereby providing the system administrator a rope to hang
> > > > himself with should he feel the need to do so.
> > > I didn't see the reason why administrator needs to know which state offline cpu
> > > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > > C-state is already preferred.
> > >
> >
> > Agreed, deepest c-state is always best, there's no need to make it configurable.
>
> Unless it doesn't work.
Yes, this is one of the reason. Kernel will know about the deepest
sleep state and any restrictions and should set that as default in the
preferred_offline state. End-users and sys-admins need not change it,
default will be the deepest sleep state supported and allowed by the
system which may be different than the one supported by the processor.
This framework could allow the default to be set easily by other
userspace tools. These restrictions apply to cpuidle governor as
well, hence at some level both these subsystems should be in sync.
As described in this patch series, the meaning of offline cpu is
different in a virtualized system and this framework provides
flexibility of choice there. Platforms today do have a choice on what
state an offline cpu should reside, this framework is one of the
possible methods to exploit that choice and not restrict it due to
lack of OS flexibility.
--Vaidy
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Michael Ellerman @ 2009-08-10 1:51 UTC (permalink / raw)
To: mohan; +Cc: linuxppc-dev, Neil Horman, Simon Horman, kexec, miltonm
In-Reply-To: <20090807145405.GB3110@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
On Fri, 2009-08-07 at 20:24 +0530, M. Mohan Kumar wrote:
> On Fri, Aug 07, 2009 at 08:05:49PM +0530, M. Mohan Kumar wrote:
> > Hi,
> >
> > After enabling EARLY_DEBUG (and DEBUG in some of the files in
> > arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
> > byte alignment:
> >
> > # ./kexec -e
> > Starting new kernel
> > console [udbg0] enabled
> > -> early_setup(), dt_ptr: 0x7723000
> > -> early_init_devtree(c000000007723000)
> > Invalid tag 5 scanning flattened device tree !
> > search "chosen", depth: 0, uname:
> > Invalid tag 5 scanning flattened device tree !
> > dt_root_size_cells = 2
> > dt_root_addr_cells = 2
> > Invalid tag 5 scanning flattened device tree !
> > reserving: 128c000 -> 5ec1f7
> > reserving: 7734000 -> 8cc000
> > reserving: 7723000 -> f698
> > Phys. mem: 0
> > -> move_device_tree
> > <- move_device_tree
> > Scanning CPUs ...
> > Invalid tag 5 scanning flattened device tree !
> > <- early_init_devtree()
> > Probing machine type ...
> > pSeries ...
> > No suitable machine found !
> >
> >
> > So device-tree is getting corrupted when dtstruct variable is not aligned to
> > 8 byte variable. This problem is not seen with gcc-3.4. Is it compiler
> > issue? or bug in the code.
> >
>
> I tried writing the device tree to a binary file with and without dt_len and
> compared the files after hexdump:
That sounds like a good idea.
> 0000 0001 2f00 0000 0000 0003 0000 0004 0000 0001 2f00 0000 0000 0003 0000 0004
> 0000 0000 0000 0002 0000 0003 0000 0004 0000 0000 0000 0002 0000 0003 0000 0004
> 0000 000f 0000 0002 0000 0003 0000 0004 0000 000f 0000 0002 0000 0003 0000 0004
> 0000 001b 3ef1 4800 0000 0003 0000 000d 0000 001b 3ef1 4800 0000 0003 0000 000d
> 0000 002b 0000 0000 4942 4d2c 3931 3135 | 0000 002b 4942 4d2c 3931 3135 2d35 3035
> 2d35 3035 0000 0000 0000 0003 0000 0005 | 0000 0000 0000 0003 0000 0005 0000 0036
So the one on the left (which is ?) - has extra padding after 0x2b,
which is the property data length, before the property value
"IBM,9115-505". There shouldn't be any padding there.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 03/14] powerpc: use printk_once
From: Marcin Slusarz @ 2009-08-09 19:53 UTC (permalink / raw)
To: LKML; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1249847649-11631-1-git-send-email-marcin.slusarz@gmail.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
---
arch/powerpc/kernel/iommu.c | 6 +-----
arch/powerpc/kernel/irq.c | 5 ++---
arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index fd51578..c7fa258 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
{
unsigned long sz;
- static int welcomed = 0;
struct page *page;
/* Set aside 1/4 of the table for large allocations. */
@@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
iommu_table_clear(tbl);
- if (!welcomed) {
- printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
+ printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
novmerge ? "disabled" : "enabled");
- welcomed = 1;
- }
return tbl;
}
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index f7f376e..05ebd21 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -231,7 +231,6 @@ skip:
void fixup_irqs(cpumask_t map)
{
unsigned int irq;
- static int warned;
for_each_irq(irq) {
cpumask_t mask;
@@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
}
if (irq_desc[irq].chip->set_affinity)
irq_desc[irq].chip->set_affinity(irq, &mask);
- else if (irq_desc[irq].action && !(warned++))
- printk("Cannot set affinity for irq %i\n", irq);
+ else if (irq_desc[irq].action)
+ printk_once("Cannot set affinity for irq %i\n", irq);
}
local_irq_enable();
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 6ff9d71..4282dff 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1243,19 +1243,14 @@ static int ppc4xx_pciex_validate_bdf(struct ppc4xx_pciex_port *port,
struct pci_bus *bus,
unsigned int devfn)
{
- static int message;
-
/* Endpoint can not generate upstream(remote) config cycles */
if (port->endpoint && bus->number != port->hose->first_busno)
return PCIBIOS_DEVICE_NOT_FOUND;
/* Check we are within the mapped range */
if (bus->number > port->hose->last_busno) {
- if (!message) {
- printk(KERN_WARNING "Warning! Probing bus %u"
- " out of range !\n", bus->number);
- message++;
- }
+ printk_once(KERN_WARNING
+ "Warning! Probing bus %u out of range!\n", bus->number);
return PCIBIOS_DEVICE_NOT_FOUND;
}
--
1.6.3.3
^ permalink raw reply related
* Re: need help getting SPI controller working on 405EX
From: Lorenz Kolb @ 2009-08-09 13:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1249574886.3747.2650.camel__48649.694157257$1249575290$gmane$org@localhost.localdomain>
Nathan French wrote:
> Hi, I am trying to add support for the 405EX's SPI controller on a Kilauea board. I've added the below to the device tree (under plb/opb/):
>
> [nfrench@nfrench-laptop linux-2.6-denx]$ diff -C2 arch/powerpc/boot/dts/kilauea.dts spi.dts
> *** arch/powerpc/boot/dts/kilauea.dts 2009-05-05 15:56:16.000000000 -0700
> --- spi.dts 2009-08-06 08:42:19.000000000 -0700
> ***************
> *** 207,210 ****
> --- 207,221 ----
> #size-cells = <0>;
> };
> +
> + SPI0: spi@ef600600 {
> + cell-index = <0>;
> + compatible = "ibm,spi-405ex", "ibm,spi";
> + reg = <ef600600 6>;
> + interrupts = <8 4>;
> + interrupt-parent = <&UIC0>;
> + mode = "cpu";
> + };
>
> RGMII0: emac-rgmii@ef600b00 {
>
That entry within the device tree will generally make the spi-"bus"
known to Linux, that's ok so far.
> I've also compiled my kernel with the following enabled:
>
> CONFIG_SPI=y
> CONFIG_SPI_MASTER=y
> CONFIG_SPI_SPIDEV=y
>
> I see this make it into the device tree after boot:
>
> [root@10.2.3.28 /]$ find /proc/device-tree/ | grep spi
> /proc/device-tree/plb/opb/spi@ef600600
> /proc/device-tree/plb/opb/spi@ef600600/name
> /proc/device-tree/plb/opb/spi@ef600600/mode
> /proc/device-tree/plb/opb/spi@ef600600/interrupt-parent
> /proc/device-tree/plb/opb/spi@ef600600/interrupts
> /proc/device-tree/plb/opb/spi@ef600600/reg
> /proc/device-tree/plb/opb/spi@ef600600/compatible
> /proc/device-tree/plb/opb/spi@ef600600/cell-index
>
> But I don't see any /dev/spidev* devices created or any mention of SPI
> at boot time. I'm starting to suspect that I don't have the kernel
> configured right, otherwise I would see at least the SPI driver
> complaining about something, right?
For getting spidev devices you have to add entries for an spidev device
to your newly created spi-"bus". So what you are currently missing are
the spidev child-nodes in the device tree.
As I'm currently cut off from some device to test, no guaranty that it
will work, but your dts entry should look something like:
SPI0: spi@ef600600 {
cell-index = <0>;
compatible = "ibm,spi-405ex", "ibm,spi";
reg = <ef600600 6>;
interrupts = <8 4>;
interrupt-parent = <&UIC0>;
mode = "cpu";
yourdevice@0 {
compatible = "spidev";
spi-max-frequency = <1000000>; /* what ever your
max-freq. is */
reg = <0>; /* Chipselect-address */
};
};
>
> Thanks,
>
> Nathan French
At least something similar worked for me some months ago (before we
switched to a "real" driver for some custom peripheral).
Regards,
Lorenz
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Rafael J. Wysocki @ 2009-08-09 13:22 UTC (permalink / raw)
To: Pavel Machek
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Pallipadi, Venkatesh, Shaohua Li,
Ingo Molnar, linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <20090809120818.GA1338@ucw.cz>
On Sunday 09 August 2009, Pavel Machek wrote:
> Hi!
>
> > > Also, approaches such as [1] can make use of this
> > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > when it is offlined, thereby providing the system administrator a rope to hang
> > > himself with should he feel the need to do so.
> > I didn't see the reason why administrator needs to know which state offline cpu
> > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > C-state is already preferred.
> >
>
> Agreed, deepest c-state is always best, there's no need to make it configurable.
Unless it doesn't work.
Rafael
^ 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