* Re: [PATCH] powerpc/pseries failed reconfig notifier chain call cleanup
From: Nathan Fontenot @ 2009-03-11 15:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236750467.7086.42.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2009-03-05 at 13:53 -0600, Nathan Fontenot wrote:
>> The return code from invoking the notifier chain when updating the
>> ibm,dynamic-memory property is not handled properly. In failure
>> cases (rc == NOTIFY_BAD) we should be restoring the original value
>> of the property. In success (rc == NOTIFY_OK) we should be returning
>> zero from the calling routine.
>
> This is actually not clear to me ... if the memory has been added or
> removed, we must make sure the device-tree is up to date... ie, we can't
> tell the firmware that we failed can we ?
>
Once the memory is added or removed the device tree is updated to reflect
the change. The case for systems where the memory in the device tree is
specified in the ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory
property is slightly different. Because it is a property that is being
updated (as opposed to addition or removal of a device tree node for
memory specified as memory@XXXX nodes) The kernel updates the property
in the device tree then invokes the notifier chain. If anyone on the
notifier chain returns a failure we should restore the property to its
previous value. I think that part is understood.
The main user (and probably only user) of this interface is the drmgr
tool that handles DLPAR of memory and other conmponents. The drmgr
tool tries to update the property after acquiring it from firmware. If
the property update fails, drmgr cleans up and returns the memory to
firmware. This update ensures that the device tree property is not left
in a state that implies that the system owns the memory.
Hope that helps.
-Nathan
> Ben.
>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/reconfig.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> Index: linux-2.6/arch/powerpc/platforms/pseries/reconfig.c
>> ===================================================================
>> --- linux-2.6.orig/arch/powerpc/platforms/pseries/reconfig.c 2008-10-23 22:29:24.000000000 -0500
>> +++ linux-2.6/arch/powerpc/platforms/pseries/reconfig.c 2009-03-05 13:20:00.000000000 -0600
>> @@ -468,9 +468,13 @@
>>
>> rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> action, value);
>> + if (rc == NOTIFY_BAD) {
>> + rc = prom_update_property(np, oldprop, newprop);
>> + return -ENOMEM;
>> + }
>> }
>>
>> - return rc;
>> + return 0;
>> }
>>
>> /**
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH v2] powerpc: Add support for CoreInt delivery of interrupts on MPIC
From: Kumar Gala @ 2009-03-11 15:18 UTC (permalink / raw)
Cc: linuxppc-dev
CoreInt provides a mechansim to deliver the IRQ vector directly
into the core on an interrupt (via the SPR EPR) rather than having
to go IACK on the PIC. This is suppose to provide an improvment
in interrupt latency by reducing the time to get the IRQ vector.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* Fixed MPIC_GREG_GCONF_COREINT flag to be 0x60000000 as per spec and pointed about by Dave
arch/powerpc/include/asm/mpic.h | 5 +++++
arch/powerpc/sysdev/mpic.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c2ccca5..475b06e 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
#define MPIC_GREG_FEATURE_1 0x00010
#define MPIC_GREG_GLOBAL_CONF_0 0x00020
#define MPIC_GREG_GCONF_RESET 0x80000000
+#define MPIC_GREG_GCONF_COREINT 0x60000000
#define MPIC_GREG_GCONF_8259_PTHROU_DIS 0x20000000
#define MPIC_GREG_GCONF_NO_BIAS 0x10000000
#define MPIC_GREG_GCONF_BASE_MASK 0x000fffff
@@ -357,6 +358,8 @@ struct mpic
#define MPIC_BROKEN_FRR_NIRQS 0x00000800
/* Destination only supports a single CPU at a time */
#define MPIC_SINGLE_DEST_CPU 0x00001000
+/* Enable CoreInt delivery of interrupts */
+#define MPIC_ENABLE_COREINT 0x00002000
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf0000000
@@ -470,6 +473,8 @@ extern void mpic_end_irq(unsigned int irq);
extern unsigned int mpic_get_one_irq(struct mpic *mpic);
/* This one gets from the primary mpic */
extern unsigned int mpic_get_irq(void);
+/* This one gets from the primary mpic via CoreInt*/
+extern unsigned int mpic_get_coreint_irq(void);
/* Fetch Machine Check interrupt from primary mpic */
extern unsigned int mpic_get_mcirq(void);
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index a35297d..6fca4f1 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1169,6 +1169,12 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mb();
}
+ /* CoreInt */
+ if (flags & MPIC_ENABLE_COREINT)
+ mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
+ mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
+ | MPIC_GREG_GCONF_COREINT);
+
if (flags & MPIC_ENABLE_MCK)
mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
@@ -1524,6 +1530,30 @@ unsigned int mpic_get_irq(void)
return mpic_get_one_irq(mpic);
}
+unsigned int mpic_get_coreint_irq(void)
+{
+ struct mpic *mpic = mpic_primary;
+ u32 src;
+
+ BUG_ON(mpic == NULL);
+
+ src = mfspr(SPRN_EPR);
+
+ if (unlikely(src == mpic->spurious_vec)) {
+ if (mpic->flags & MPIC_SPV_EOI)
+ mpic_eoi(mpic);
+ return NO_IRQ;
+ }
+ if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
+ if (printk_ratelimit())
+ printk(KERN_WARNING "%s: Got protected source %d !\n",
+ mpic->name, (int)src);
+ return NO_IRQ;
+ }
+
+ return irq_linear_revmap(mpic->irqhost, src);
+}
+
unsigned int mpic_get_mcirq(void)
{
struct mpic *mpic = mpic_primary;
--
1.5.6.6
^ permalink raw reply related
* NFS problems on a MPC5200-based board
From: Bartłomiej Sięka @ 2009-03-11 15:08 UTC (permalink / raw)
To: linuxppc-dev
Hi,
This is a follow-up on NFS problems on an MPC5200-based board reported
here a while back:
http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-to21750004.html#a21792612
To recap: while using NFS, especially while mounting the root
filesystem over NFS, the system is really slow and displays a bunch of
"nfs: server 192.168.1.1 not responding, still trying" messages.
Sometimes it is able to get to the login prompt, sometimes not. In
cases where the login is successful, the system is still extremely
sluggish (console hangs for tens of seconds and longer).
git bisect narrows down the troublesome commit as:
commit 4c456a67f501b8b15542c7c21c28812bf88f484b
Author: Gerhard Pircher <gerhard_pircher@gmx.net>
Date: Fri Jan 23 06:51:28 2009 +0000
powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code
_PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL.
Thus it has to be masked out, if the BAT mapping should be non
cacheable or CPU_FTR_NEED_COHERENT is not set.
This will work on normal SMP setups because we force-set
CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP.
Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We have tested recent mainline kernel (past 2.6.29-rc7) with the
4c456a6...
commit reverted and NFS problems went away.
Other people have also reported similar problems (original posters on
Cc):
http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792825.html
http://www.nabble.com/-PATCH--Add-support-for-the-digsy-MTC-board.-tp21750004p21792612.html
The commit in question does not look directly related to NFS/
networking; moreover it is a fix for some other problem, so just
reverting it is not an option, it seems (?). So how do we go about
having NFS operational again? Any comments?
Regards,
Bartlomiej Sieka
^ permalink raw reply
* Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Mark Bishop @ 2009-03-11 15:52 UTC (permalink / raw)
To: linuxppc-dev
Has anyone been able to get a newer Freescale BSP to work with a RevA
(processor version 1.0) RDB?
The boards we received didn't have SPI compiled into the kernel and
when we went to go re-compile the kernel using the 20081222 and
20080711 BSPs. I realize that the interrupts were reversed for eTEC1
and eTEC2 and I've made the changes in the .dtb file and I no longer
hang when I ping, etc. But I still can't get the board on the
network. I've verified it isn't the network settings.
I've pinged Freescale for support (didn't help much) and I am now
looking for someone who has actually done it (if ever).
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2009-03-11 15:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, linuxppc-dev list, Andrew Morton,
Linux Kernel list
In-Reply-To: <1236769025.7086.46.camel@pasglop>
On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
>
> I'd like to have Andrew or Linus opinion on doing this driver swap that
> late in the process.
Quite franklly, no.
If it was a totally _new_ driver, there's no chance of regression, which
is why we allow those drivers.
But switching an old one for a new one does not match that pattern. We can
clearly get regressions. As such, we don't do it late in the -rc series.
Linus
^ permalink raw reply
* Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Kumar Gala @ 2009-03-11 15:42 UTC (permalink / raw)
To: Mark Bishop; +Cc: linuxppc-dev
In-Reply-To: <20090311115234.7hmj4jj79csgk4wo@www.bish.net>
On Mar 11, 2009, at 10:52 AM, Mark Bishop wrote:
> Has anyone been able to get a newer Freescale BSP to work with a
> RevA (processor version 1.0) RDB?
>
> The boards we received didn't have SPI compiled into the kernel and
> when we went to go re-compile the kernel using the 20081222 and
> 20080711 BSPs. I realize that the interrupts were reversed for
> eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no
> longer hang when I ping, etc. But I still can't get the board on
> the network. I've verified it isn't the network settings.
>
> I've pinged Freescale for support (didn't help much) and I am now
> looking for someone who has actually done it (if ever).
Have you tried a kernel.org kernel? The group here would be more than
happy to help with any issues you might find with the kernel.org kernel.
- k
^ permalink raw reply
* Re: [PATCH 0/7] Generic RTC class driver
From: Kyle McMartin @ 2009-03-11 15:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Paul Mundt, Dann Frazier
In-Reply-To: <alpine.LRH.2.00.0903111134270.1040@vixen.sonytel.be>
On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
> Is it OK for you to take it through your PA-RISC tree?
> If yes, I can resend the patch series with the collected acks.
>
That's fine with me, just hit me up with a git tree address and I'll
suck it all into the rtc-parisc tree?
regards, Kyle
^ permalink raw reply
* Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Mark Bishop @ 2009-03-11 16:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <A0ED6D80-FD02-4BED-B50B-7F3028E47888@kernel.crashing.org>
Yes I have actually. I have booted a 2.6.28.6. Same problem.
Also, is it me but at some point from 2.6.23 to 2.6.28 did they =20
started using hex numbers in the .dts file for "interrupts =3D " without =20
the 0x preamble?
I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this =20
board and .28 looked way different in the interrupt section for the =20
eTSEC.
Quoting Kumar Gala <galak@kernel.crashing.org>:
>
> On Mar 11, 2009, at 10:52 AM, Mark Bishop wrote:
>
>> Has anyone been able to get a newer Freescale BSP to work with a =20
>> RevA (processor version 1.0) RDB?
>>
>> The boards we received didn't have SPI compiled into the kernel and =20
>> when we went to go re-compile the kernel using the 20081222 and =20
>> 20080711 BSPs. I realize that the interrupts were reversed for =20
>> eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no =20
>> longer hang when I ping, etc. But I still can't get the board on =20
>> the network. I've verified it isn't the network settings.
>>
>> I've pinged Freescale for support (didn't help much) and I am now =20
>> looking for someone who has actually done it (if ever).
>
> Have you tried a kernel.org kernel? The group here would be more =20
> than happy to help with any issues you might find with the =20
> kernel.org kernel.
>
> - k
>
>
^ permalink raw reply
* [PATCH] powerpc: Remove extra semicolon in fsl_soc.c
From: Johns Daniel @ 2009-03-11 15:50 UTC (permalink / raw)
To: afleming, linuxppc-dev, stable
A semicolon at the end of the macro means that the for loop has an
empty body, and so TSEC/MDIO will not work with older device trees.
This fix only applies to 2.6.28; apparently, this code is gone for
2.6.29, according to Grant Likely!
Signed-off-by: Johns Daniel <johns.daniel@gmail.com>
---
--- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig 2009-02-20
16:41:27.000000000 -0600
+++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c 2009-03-10
15:56:47.000000000 -0500
@@ -257,7 +257,7 @@
gfar_mdio_of_init_one(np);
/* try the deprecated version */
- for_each_compatible_node(np, "mdio", "gianfar");
+ for_each_compatible_node(np, "mdio", "gianfar")
gfar_mdio_of_init_one(np);
return 0;
---
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Update smp support to handle doorbells and non-mpic init
From: Scott Wood @ 2009-03-11 15:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1236771963-28181-1-git-send-email-galak@kernel.crashing.org>
On Wed, Mar 11, 2009 at 06:46:03AM -0500, Kumar Gala wrote:
> +void __init mpc85xx_smp_init(void)
> +{
> + struct device_node *np;
> +
> + smp_85xx_ops.message_pass = NULL;
> +
> + np = of_find_node_by_type(NULL, "open-pic");
We should probably look by compatible rather than device_type. I see
only one device tree that has the latter but not the former (ksi8560),
and it's not SMP (but should still be fixed, of course).
-Scott
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Geert Uytterhoeven @ 2009-03-11 15:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel list, linuxppc-dev list
In-Reply-To: <alpine.LFD.2.00.0903110835020.32478@localhost.localdomain>
Hi Linus,
On Wed, 11 Mar 2009, Linus Torvalds wrote:
> On Wed, 11 Mar 2009, Benjamin Herrenschmidt wrote:
> > I'd like to have Andrew or Linus opinion on doing this driver swap that
> > late in the process.
>
> Quite franklly, no.
>
> If it was a totally _new_ driver, there's no chance of regression, which
> is why we allow those drivers.
>
> But switching an old one for a new one does not match that pattern. We can
> clearly get regressions. As such, we don't do it late in the -rc series.
Are you aware the old one was introduced in 2.6.29-rc1? So there cannot be a
regression from 2.6.28 or older.
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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
* fsldma driver questions
From: Crossley, Malcolm (GE EntSol, Intelligent Platforms) @ 2009-03-11 15:52 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
I've been examining the fsl dma driver (drivers/dma/fsldma.c) to work
out how a typical dma engine driver works so I can port an Intel dma
engine driver to the new dmaengine interface.=20
I have noticed that append_ld_queue() changes the next link descriptor
address field in the last link descriptor of the chain. The
append_ld_queue function is called from the fsl_dma_tx_submit() which
can called at any time by a kernel module using that channel. This could
result in the link descriptor being changed whilst the DMA engine is
running. Could this issue cause unexpected behavior of the DMA engine or
the driver?
A second question I have is to do with the dma_halt() routine setting
the channel abort flag. The dma_halt() routine is called from
fsl_chan_xfer_ld_queue() after the dma engine has been detected as idle.
The dma_halt() routine sets the channel stop flag and the channel abort
flag. Whilst the dma engine could be idle, it may not have completed a
transfer AFAICT. Or if the engine is has no more transactions then a
channel abort does not need to be issued anyway?
I have access to a GE Fanuc SBC310 which has an 8641D containing a dma
engine this driver was written for. So I can test any patches.=20
Thanks for your time. Malcolm
--=20
Malcolm Crossley, Software Engineer,=20
GE Fanuc Intelligent Platforms
GE Fanuc Intelligent Platforms Ltd, registered in England and Wales
(3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB729849476
^ permalink raw reply
* Re: [PATCH] powerpc: Remove extra semicolon in fsl_soc.c
From: Grant Likely @ 2009-03-11 16:03 UTC (permalink / raw)
To: Johns Daniel; +Cc: linuxppc-dev, Greg KH, afleming, stable
In-Reply-To: <ba5d9360903110850gbcb0d2y25f8756a19d46cda@mail.gmail.com>
On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel <johns.daniel@gmail.com> wrot=
e:
> A semicolon at the end of the macro means that the for loop has an
> empty body, and so TSEC/MDIO will not work with older device trees.
>
> This fix only applies to 2.6.28; apparently, this code is gone for
> 2.6.29, according to Grant Likely!
>
> Signed-off-by: Johns Daniel <johns.daniel@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Greg: Andy Flemming should probably confirm this, but I think this
one should be backported to the stable series.
g.
> ---
> --- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig =A0 2009-02-20
> 16:41:27.000000000 -0600
> +++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c =A0 =A0 =A0 =A02009-03-1=
0
> 15:56:47.000000000 -0500
> @@ -257,7 +257,7 @@
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfar_mdio_of_init_one(np);
>
> =A0 =A0 =A0 =A0/* try the deprecated version */
> - =A0 =A0 =A0 for_each_compatible_node(np, "mdio", "gianfar");
> + =A0 =A0 =A0 for_each_compatible_node(np, "mdio", "gianfar")
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfar_mdio_of_init_one(np);
>
> =A0 =A0 =A0 =A0return 0;
> ---
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [stable] [PATCH] powerpc: Remove extra semicolon in fsl_soc.c
From: Greg KH @ 2009-03-11 16:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Greg KH, Johns Daniel, afleming, stable
In-Reply-To: <fa686aa40903110903h1077860dt45c1a5aecd2ef42f@mail.gmail.com>
On Wed, Mar 11, 2009 at 10:03:22AM -0600, Grant Likely wrote:
> On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel <johns.daniel@gmail.com> wrote:
> > A semicolon at the end of the macro means that the for loop has an
> > empty body, and so TSEC/MDIO will not work with older device trees.
> >
> > This fix only applies to 2.6.28; apparently, this code is gone for
> > 2.6.29, according to Grant Likely!
> >
> > Signed-off-by: Johns Daniel <johns.daniel@gmail.com>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> Greg: Andy Flemming should probably confirm this, but I think this
> one should be backported to the stable series.
That's what he is asking for as he sent it to stable@kernel.org and
asked that it go into the 2.6.28 tree only :)
thanks,
greg k-h
^ permalink raw reply
* Please pull mpc52xx-next
From: Grant Likely @ 2009-03-11 16:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Hey Ben, here's another -next pull request. I think this exhausts
everything in my queue. I'm sure someone will tell me if I've missed
anything. I'll update patchwork later today.
One commit is outside of arch/powerpc, but it is a xilinx-only change
to an SPI driver, and David has acked it.
Cheers,
g.
The following changes since commit e7eec2fc27d7dbefd5852c36b3fe6229e6302c99:
roel kluin (1):
powerpc/ps3: Make ps3av_set_video_mode mode ID signed
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx next
Grant Likely (2):
powerpc/5200: remove sysfs debug file from GPT driver
powerpc/bootwrapper: add fixed-head.o to simpleimage wrappers
John Linn (1):
powerpc/virtex/spi: Xilinx SPI driver not releasing memory
Wolfgang Grandegger (1):
powerpc/5200: add function to return external clock frequency
Wolfram Sang (1):
powerpc/5200: add Phytec phyCORE-MPC5200B-IO board (pcm032)
arch/powerpc/boot/dts/pcm032.dts | 392 ++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 4 +-
arch/powerpc/include/asm/mpc52xx.h | 1 +
arch/powerpc/platforms/52xx/Kconfig | 1 +
arch/powerpc/platforms/52xx/mpc5200_simple.c | 3 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 37 +++
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 39 ---
drivers/spi/xilinx_spi.c | 9 +-
8 files changed, 442 insertions(+), 44 deletions(-)
create mode 100644 arch/powerpc/boot/dts/pcm032.dts
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] drivers/base: Add bus_register_notifier_alldev() variant
From: Greg KH @ 2009-03-11 16:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090306160818.404.92700.stgit@localhost.localdomain>
On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> bus_register_notifier_alldev() is a variation on bus_register_notifier()
> which also triggers the notifier callback for devices already on the bus
> and already bound to drivers.
>
> This function is useful for the case where a driver needs to get a
> reference to a struct device other than the one it is bound to and
> it is not known if the device will be bound before or after this
> function is called. For example, an Ethernet device connected to
> a PHY that is probed separately.
Can't you just walk the list of all devices already on the bus to get
"notified" of them, and then register your notifier handler as well (or
register it first, and then walk the list, which is pretty much what
your patch does)?
I see this api addition as just confusing people as to which one they
should register for :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-03-11 16:31 UTC (permalink / raw)
To: Roland Dreier; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <adaiqmgbq6w.fsf@cisco.com>
On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier <rdreier@cisco.com> wrote:
> Are there really cases where spinning for 1 jiffy is too long of a
> timeout?
If the result is a timeout, then I say no. A timeout is an error
condition, and the code will usually terminate.
> It might make sense for the parameter passed in to be in terms
> of microseconds but I have a hard time coming up with a case where
> having the real timeout be 40 msecs or whatever 1 jiffy ends up being is
> a real problem -- after all, this helper is intended for the case where
> we expect the condition to become true much sooner than the worst case.
Well, that's the point. What if the condition takes a long time to
come true. One argument against this code is that it encourages
developers to use busy-waits for long periods of time. The only way
to prevent this is to make the timeout really short. But if we're
using jiffies, then the minimum amount of time needs to be two. It
can't be one, because what if jiffies increments immediately after
starting the loop? So you need to use a value of two as a minimum.
Two jiffies can be a very long time. Besides, if this function is
used when interrupts are disabled, I believe that on some platforms,
jiffies never increments. If so, we can't use the actual 'jiffies'
variable.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC] drivers/base: Add bus_register_notifier_alldev() variant
From: Grant Likely @ 2009-03-11 16:35 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090311162623.GE21831@suse.de>
On Wed, Mar 11, 2009 at 10:26 AM, Greg KH <gregkh@suse.de> wrote:
> On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> bus_register_notifier_alldev() is a variation on bus_register_notifier()
>> which also triggers the notifier callback for devices already on the bus
>> and already bound to drivers.
>>
>> This function is useful for the case where a driver needs to get a
>> reference to a struct device other than the one it is bound to and
>> it is not known if the device will be bound before or after this
>> function is called. =A0For example, an Ethernet device connected to
>> a PHY that is probed separately.
>
> Can't you just walk the list of all devices already on the bus to get
> "notified" of them, and then register your notifier handler as well (or
> register it first, and then walk the list, which is pretty much what
> your patch does)?
Yes, and I originally did, but it looks to me like a useful common
pattern that is less error prone than open coding it.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Scott Wood @ 2009-03-11 16:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Roland Dreier
In-Reply-To: <ed82fe3e0903110931y62e23a02yf2a9719e5a69bd2@mail.gmail.com>
Timur Tabi wrote:
> On Wed, Mar 11, 2009 at 12:09 AM, Roland Dreier <rdreier@cisco.com> wrote:
>
>> Are there really cases where spinning for 1 jiffy is too long of a
>> timeout?
>
> If the result is a timeout, then I say no. A timeout is an error
> condition, and the code will usually terminate.
[snip]
> Two jiffies can be a very long time.
One jiffy is fine, but two is just too long?
Given that it only happens in cases of malfunctioning hardware (or a
buggy driver), it seems reasonable as long as preemption isn't disabled
(I'm assuming anyone that cares about a rare latency of a couple jiffies
is using a preemptible kernel).
> Besides, if this function is
> used when interrupts are disabled, I believe that on some platforms,
> jiffies never increments. If so, we can't use the actual 'jiffies'
> variable.
Disallow that, enforced with a call to might_sleep().
Alternatively, do something with get_cycles(), and have some sort of
#define by which arches can say if get_cycles actually works. In the
absence of a working get_cycles() or equivalent, timeouts with
interrupts disabled aren't going to happen whether we abstract it with a
macro or not.
-Scott
^ permalink raw reply
* Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Scott Wood @ 2009-03-11 16:53 UTC (permalink / raw)
To: Mark Bishop; +Cc: linuxppc-dev
In-Reply-To: <20090311120300.atgtikpneo0gos0w@www.bish.net>
On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote:
> Yes I have actually. I have booted a 2.6.28.6. Same problem.
I've booted many recent kernels on revA 8313ERDB; networking works fine.
I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment
so I have to address that first. :-(
Are you using the stock config and device tree from 2.6.28.6, or have you
made any changes?
> Also, is it me but at some point from 2.6.23 to 2.6.28 did they
> started using hex numbers in the .dts file for "interrupts = " without
> the 0x preamble?
Yes. dts version 0 had hex by default (with OF-like radix prefixes), and version 1 (indicated by
/dts-v1/; at the top of the file) has decimal by default (with C-like
radix prefixes).
> I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this
> board and .28 looked way different in the interrupt section for the
> eTSEC.
>
> Quoting Kumar Gala <galak@kernel.crashing.org>:
Please don't top-post.
> >>The boards we received didn't have SPI compiled into the kernel and
> >>when we went to go re-compile the kernel using the 20081222 and
> >>20080711 BSPs. I realize that the interrupts were reversed for
> >>eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no
> >>longer hang when I ping, etc. But I still can't get the board on
> >>the network. I've verified it isn't the network settings.
You're sure you're not trying to talk to the switch (which will claim
link-up regardless of what's plugged into it)? The non-switch ethernet
port is eTSEC2.
What *does* it do when you ping, if neither hang nor work?
-Scott
^ permalink raw reply
* Re: [RFC] drivers/base: Add bus_register_notifier_alldev() variant
From: Greg KH @ 2009-03-11 17:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fa686aa40903110935g155fbf7m83f4aead71d72488@mail.gmail.com>
On Wed, Mar 11, 2009 at 10:35:29AM -0600, Grant Likely wrote:
> On Wed, Mar 11, 2009 at 10:26 AM, Greg KH <gregkh@suse.de> wrote:
> > On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
> >> From: Grant Likely <grant.likely@secretlab.ca>
> >>
> >> bus_register_notifier_alldev() is a variation on bus_register_notifier()
> >> which also triggers the notifier callback for devices already on the bus
> >> and already bound to drivers.
> >>
> >> This function is useful for the case where a driver needs to get a
> >> reference to a struct device other than the one it is bound to and
> >> it is not known if the device will be bound before or after this
> >> function is called. For example, an Ethernet device connected to
> >> a PHY that is probed separately.
> >
> > Can't you just walk the list of all devices already on the bus to get
> > "notified" of them, and then register your notifier handler as well (or
> > register it first, and then walk the list, which is pretty much what
> > your patch does)?
>
> Yes, and I originally did, but it looks to me like a useful common
> pattern that is less error prone than open coding it.
How about we wait, and if someone else does the same thing, we then add
it to the core like this?
Actually, wouldn't it make more sense to just change the default
"bus_register_notifier" to do this? Is there some reason that the
caller would not want this kind of thing to happen?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5] introduce macro spin_event_timeout()
From: Grant Likely @ 2009-03-11 17:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <1236731097.7086.32.camel@pasglop>
On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
>>
>> Alan did have one valid point though. =A0Determining how long to loop
>> for is architecture-specific. =A0Using jiffies is bad, because even one
>> jiffy is too long. =A0Adding a udelay() inside the loop means that it
>> only checks he condition every microsecond. =A0So the real solution is
>> to use keep looping until a certain amount of time has passed. =A0This
>> means using an architecture-specific timebase register.
>
>> Now we can create a generic version of the function that uses jiffies,
>> and then arch-specific versions where possible. =A0But Alan still needs
>> to be convinced. =A0I already posted a length rebuttal to his email, but
>> I haven't gotten a reply yet.
>>
> There are several aspects here:
>
> =A0- The amount of time to wait should be specified by the caller since
> it's generally going to come from HW specs
>
> =A0- The amount of time between the polls ... that could also be an
> argument to the macro, not sure there
>
> =A0- The precision of the actual wait calls... I vote for microseconds fo=
r
> everything and udelay. The arch will do its best.
No, not udelay. Or any delay for that matter. If spinning on a
condition, then there is no advantage to burning cycles with a
udelay(). Those cycles may as well be used to keep testing the
condition so the loop can be exited faster. a udelay() would only
serve to always make the busywait longer.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/7] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-03-11 17:26 UTC (permalink / raw)
To: Kyle McMartin
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Paul Mundt, Dann Frazier
In-Reply-To: <20090311154505.GB5448@bombadil.infradead.org>
Hi Kyle,
On Wed, 11 Mar 2009, Kyle McMartin wrote:
> On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
> > Is it OK for you to take it through your PA-RISC tree?
> > If yes, I can resend the patch series with the collected acks.
>
> That's fine with me, just hit me up with a git tree address and I'll
> suck it all into the rtc-parisc tree?
I put it up at:
master.kernel.org:/pub/scm/linux/kernel/git/geert/linux-rtc-generic.git
The master branch should be a descendant of your rtc-parisc branch.
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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] powerpc/85xx: Update smp support to handle doorbells and non-mpic init
From: Kumar Gala @ 2009-03-11 17:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090311155242.GA11120@ld0162-tx32.am.freescale.net>
On Mar 11, 2009, at 10:52 AM, Scott Wood wrote:
> On Wed, Mar 11, 2009 at 06:46:03AM -0500, Kumar Gala wrote:
>> +void __init mpc85xx_smp_init(void)
>> +{
>> + struct device_node *np;
>> +
>> + smp_85xx_ops.message_pass = NULL;
>> +
>> + np = of_find_node_by_type(NULL, "open-pic");
>
> We should probably look by compatible rather than device_type. I see
> only one device tree that has the latter but not the former (ksi8560),
> and it's not SMP (but should still be fixed, of course).
Ever other lookup for the mpic node is done by type. I see no reason
to change this right now.
- k
^ permalink raw reply
* Re: Freescale MPC8313ERDB-RevA and newer BSP/kernel
From: Mark Bishop @ 2009-03-11 18:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090311165320.GB11120@ld0162-tx32.am.freescale.net>
Quoting Scott Wood <scottwood@freescale.com>:
> On Wed, Mar 11, 2009 at 12:03:00PM -0400, Mark Bishop wrote:
>> Yes I have actually. I have booted a 2.6.28.6. Same problem.
>
> I've booted many recent kernels on revA 8313ERDB; networking works fine.
> I'll try 2.6.28.6 specifically, though u-boot is acting up at the moment
> so I have to address that first. :-(
>
> Are you using the stock config and device tree from 2.6.28.6, or have you
> made any changes?
>
>> Also, is it me but at some point from 2.6.23 to 2.6.28 did they
>> started using hex numbers in the .dts file for "interrupts =3D " without
>> the 0x preamble?
>
> Yes. dts version 0 had hex by default (with OF-like radix =20
> prefixes), and version 1 (indicated by
> /dts-v1/; at the top of the file) has decimal by default (with C-like
> radix prefixes).
>
>> I've been looking at 2.6.20, 2.6.23, and 2.6.28 .dts files for this
>> board and .28 looked way different in the interrupt section for the
>> eTSEC.
>>
>> Quoting Kumar Gala <galak@kernel.crashing.org>:
>
> Please don't top-post.
>
>> >>The boards we received didn't have SPI compiled into the kernel and
>> >>when we went to go re-compile the kernel using the 20081222 and
>> >>20080711 BSPs. I realize that the interrupts were reversed for
>> >>eTEC1 and eTEC2 and I've made the changes in the .dtb file and I no
>> >>longer hang when I ping, etc. But I still can't get the board on
>> >>the network. I've verified it isn't the network settings.
>
> You're sure you're not trying to talk to the switch (which will claim
> link-up regardless of what's plugged into it)? The non-switch ethernet
> port is eTSEC2.
>
> What *does* it do when you ping, if neither hang nor work?
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
After remapping the IRQs, it is working now.
Any idea on what I need to do to get SPI working? I've compiled it =20
into the kernel but don't see anything in /proc/bus
^ 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