* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Anton Vorontsov @ 2007-10-05 12:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <E6B4F79B-254F-4273-8E49-D15BCFF6955A@kernel.crashing.org>
On Fri, Oct 05, 2007 at 12:18:58AM -0500, Kumar Gala wrote:
[...]
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> Looks allright, if it also works, then ship it :-)
>>
>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Now that this has been ack'd by Ben if you can respin the patch set we can
> get these in for 2.6.24
Great, will do.
> (I assume you are using a UCC as ethernet for test some of the QE support
> on 8568?)
Yup, UCC as eth. Plus I've also tested SPI (which is in QE) in
loopback mode.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Fix regression. Make hot unlplug of CPU0 work again.
From: Michael Ellerman @ 2007-10-05 12:20 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071005070519.GQ9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
On Fri, 2007-10-05 at 17:05 +1000, Tony Breeds wrote:
> On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
> > Early in the 2.6.23 cycle we broke the ability to offline cpu0
> > (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> > ensuring that the (xics) default irq server, will not be 0 when taking
> > cpu0 offline.
> >
> > Also catches a use of irq, when virq should be used (I think that the
> > last one).
>
> Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
> back to the drawing board.
Maybe we should revert the original patch and go back to the drawing
board for 2.6.24? Making sure we address the initial problem (which was
exposed by kexec I think) and that we don't break cpu hotplug on the
way.
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: Device tree and external RTC
From: Guennadi Liakhovetski @ 2007-10-05 10:45 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <OFF5EAF9C9.4E27AE67-ON8825736A.0064875E-8825736A.00652EB0@selinc.com>
On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:
> A follow on question though. I've looked at the patch and it seems to be
> just adding 6 lines to an existing array in fsl_soc.c. However, I can't
> seem to find any array in fsl_soc.c that contains lines that the patch
> indicates should already be there (i.e., there's nothing in fsl_soc.c that
> has the word "ricoh" in it which the patch indicates it should). Is my
> fsl_soc.c already out of date? Will the patch apply? I've got 2.6.22.
Ok, we both (Peter and myself) have forgotten, that this change has first
aooeared after 2.6.22. So, best try 2.6.23-rc9, or use one of the
git-trees (from Linux or from Paulus, or from Kumar Gala, or...) _plus_
the patch we both pointed at.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Fix regression. Make hot unlplug of CPU0 work again.
From: Tony Breeds @ 2007-10-05 7:05 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
In-Reply-To: <20071005035241.GO9814@bakeyournoodle.com>
On Fri, Oct 05, 2007 at 01:52:41PM +1000, Tony Breeds wrote:
> Early in the 2.6.23 cycle we broke the ability to offline cpu0
> (7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
> ensuring that the (xics) default irq server, will not be 0 when taking
> cpu0 offline.
>
> Also catches a use of irq, when virq should be used (I think that the
> last one).
Hmm testing, this on a JS21 shows that it doesn't work. I guess I'll go
back to the drawing board.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Kumar Gala @ 2007-10-05 5:18 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: PowerPC dev list
In-Reply-To: <1191535520.28239.2.camel@pasglop>
On Oct 4, 2007, at 5:05 PM, Benjamin Herrenschmidt wrote:
>
>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Subject: [PATCH] [POWERPC] QEIC: Implement pluggable handlers, fix
>> MPIC cascading
>>
>> set_irq_chained_handler overwrites MPIC's handle_irq function
>> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
>> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>>
>> To solve this problem efficiently, QEIC needs pluggable handlers,
>> specific to the underlaying interrupt controller.
>>
>> Patch extends qe_ic_init() function to accept low and high interrupt
>> handlers. To avoid #ifdefs, stack of interrupt handlers specified in
>> the header file and functions are marked 'static inline', thus
>> handlers are compiled-in only if actually used (in the board file).
>> Another option would be to lookup for parent controller and
>> automatically detect handlers, but this will waste text size because
>> of never used handlers.
>>
>> qe_ic_init() also changed in regard to support multiplexed high/low
>> lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
>> handler implemented appropriately.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> Looks allright, if it also works, then ship it :-)
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Now that this has been ack'd by Ben if you can respin the patch set
we can get these in for 2.6.24
(I assume you are using a UCC as ethernet for test some of the QE
support on 8568?)
- k
^ permalink raw reply
* Re: [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Kumar Gala @ 2007-10-05 5:15 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070925143440.GD5323@localhost.localdomain>
On Sep 25, 2007, at 9:34 AM, Anton Vorontsov wrote:
> 8 bytes padding required to match MPC85xx registers layout.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/
> sysdev/qe_lib/qe_io.c
> index e32b45b..d566e89 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe_io.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
> @@ -36,6 +36,9 @@ struct port_regs {
> __be32 cpdir2; /* Direction register */
> __be32 cppar1; /* Pin assignment register */
> __be32 cppar2; /* Pin assignment register */
> +#ifdef CONFIG_MPC85xx
use CONFIG_PPC_85xx
> + u8 pad[8];
> +#endif
> };
- k
^ permalink raw reply
* Fix regression. Make hot unlplug of CPU0 work again.
From: Tony Breeds @ 2007-10-05 3:52 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
Early in the 2.6.23 cycle we broke the ability to offline cpu0
(7ccb4a662462616f6be5053e26b79580e02f1529). This patch fixes that by
ensuring that the (xics) default irq server, will not be 0 when taking
cpu0 offline.
Also catches a use of irq, when virq should be used (I think that the
last one).
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Unless there is a problem with this patch, it'd be nice to get it into
2.6.23 :)
arch/powerpc/platforms/pseries/xics.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index f0b5ff1..2fb8fd0 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -837,6 +837,15 @@ void xics_migrate_irqs_away(void)
/* Allow IPIs again... */
xics_set_cpu_priority(cpu, DEFAULT_PRIORITY);
+ /* It would be bad to migrate any IRQs to the CPU we're taking down */
+ if (default_server == cpu) {
+ unsigned int new_server = first_cpu(cpu_online_map);
+
+ default_server = get_hard_smp_processor_id(new_server);
+ printk(KERN_WARNING "%s: default server was %d, reset to %d\n",
+ __func__, cpu, default_server);
+ }
+
for_each_irq(virq) {
struct irq_desc *desc;
int xics_status[2];
@@ -882,7 +891,7 @@ void xics_migrate_irqs_away(void)
/* Reset affinity to all cpus */
desc->chip->set_affinity(virq, CPU_MASK_ALL);
- irq_desc[irq].affinity = CPU_MASK_ALL;
+ irq_desc[virq].affinity = CPU_MASK_ALL;
unlock:
spin_unlock_irqrestore(&desc->lock, flags);
}
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] [POWERPC] update immap_86xx.h for the 8610
From: Kumar Gala @ 2007-10-05 3:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4705634A.9070800@freescale.com>
On Oct 4, 2007, at 5:03 PM, Timur Tabi wrote:
> Kumar, can you pull this patch into your 2.6.24 tree? It's needed
> for the 8610.
applied.
- k
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 3:08 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005025930.GA24218@mag.az.mvista.com>
On Thu, Oct 04, 2007 at 07:59:30PM -0700, Mark A. Greer wrote:
> On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> > The zImage is already hardware and
> > firmware specific;
>
> And [potentially] firmware version and zImage size specific.
I meant to add, "which is why it'll be difficult to come up with a
heuristic that will work in all situations."
Mark
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 2:59 UTC (permalink / raw)
To: Mark A. Greer, Valentine Barshak, linuxppc-dev
In-Reply-To: <20071005022554.GE25637@localhost.localdomain>
On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> > On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > > > David Gibson wrote:
> > > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> >
> > > > Looking deeper at this I've found that currently u-boot thinks that
> > > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > > > defined as (8 << 20)), although all physical memory is identity mapped.
> > > > That's why it puts command line and board info structure as high as
> > > > possible within the first 8MB. This worked fine with uImage, since
> > > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > > > (we need space at the start of the memory to eventually put vmlinux
> > > > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > > > workaround for that is to always link zImage at >=8MB base or to have
> > > > 4MB granularity like this:
> > > >
> > > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> > > >
> > > > Reserve at least 64K for u-boot cmd_line and bdinfo.
> > >
> > > Ah. Right. That makes things a bit tricky. Even this 4MB
> > > granularity may not be enough (say, if the vmlinux is < 4MB, but the
> > > zImage has a really big initrd and is > 4MB).
> > >
> > > Except... it shouldn't really be the link address that matters. The
> > > zImage is relocatable, so it should only be the load address specified
> > > in the uImage header which matters. I think that's currently derived
> > > from the link address, but it doesn't have to be.
> >
> > Having the link address jump around depending on the size of the kernel
> > or zImage is wrong IMHO. It just screams "weird can't boot issues."
>
> Hrm. Except we already have that - the zImage is linked at a fixed
> location, and will just not work if the sizes are wrong.
Yes, its an issue now (which is why we're having this discussion) but
at least its predictable ATM. Having it jump around on you because
you happened to set/clear a CONFIG option is worse.
My point is that the address needs to be set manually--no fancy heuristics
or whatever to guess.
> > We need a way to specify exactly where we want the zImage linked no
> > matter what the kernel or zImage size.
> >
> > Also, being able to control the link address (that is, the download
> > address with some firmwares) is not a u-boot specific issue and we
> > shouldn't make a u-boot specific solution.
> >
> > The more general problem is that some firmwares examine the ELF header
> > and download the zImage to address it was linked at. Some firmwares let
> > you override this but some don't and those are the problem ones.
> >
> > We talked about this a bit back in February,
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
> >
> > In that thread Geoff Levand suggested a config option and running it
> > thru a preprocessor. David Gibson suggested making a replaceable linker
> > script. I suggested passing the value of a config option to the wrapper
> > script which would use objcopy/whatever to change the section addresses
> > in the image (maybe this is what Geoff had in mind, I'm not sure).
> >
> > I still like my idea best. I haven't coded yet it so I don't have a patch
> > but this is what I mean:
> >
> > 1) add a config option (default 4MB) for the link address
> > 2) add a parameter to the wrapper script thru which we pass the value in
> > the config option
> > 3) the wrapper script changes the VMA/LMA to the address specified
> > (objcopy --change-addresses=<some math to get correct incr> ?).
> >
> > I'll code it up in the next day or two unless someone doesn't like the idea.
>
> A config option just doesn't seem right to me, except as a
> special-circumstances hack.
Acutally, I started to hack up the patch and noticed that its already
there. Its 'CONFIG_BOOT_LOAD' which is an "Advanced setup" option
in arch/powerpc/Kconfig (probably migrated from arch/ppc/Kconfig).
Several defconfig's have it set but its not used AFAICS.
> The zImage is already hardware and
> firmware specific;
And [potentially] firmware version and zImage size specific.
> we should be able to figure out workable link and
> load addresses for a specific zImage
I was going to argue with you here until...
> (which might need to be different
> for different zImages produced by the same config).
Oh yeah, I forgot about multiple zImages from the same config. D*mn.
Hmm, I guess I have to think about this more then. (and stop hacking up
the patch I was talking about).
> Of course, the same objection would apply to CONFIG_DEVICE_TREE which
> we have already.
Yep.
Mark
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: David Gibson @ 2007-10-05 2:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071005015849.GA9862@mag.az.mvista.com>
On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > > David Gibson wrote:
> > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
>
> > > Looking deeper at this I've found that currently u-boot thinks that
> > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > > defined as (8 << 20)), although all physical memory is identity mapped.
> > > That's why it puts command line and board info structure as high as
> > > possible within the first 8MB. This worked fine with uImage, since
> > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > > (we need space at the start of the memory to eventually put vmlinux
> > > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > > workaround for that is to always link zImage at >=8MB base or to have
> > > 4MB granularity like this:
> > >
> > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> > >
> > > Reserve at least 64K for u-boot cmd_line and bdinfo.
> >
> > Ah. Right. That makes things a bit tricky. Even this 4MB
> > granularity may not be enough (say, if the vmlinux is < 4MB, but the
> > zImage has a really big initrd and is > 4MB).
> >
> > Except... it shouldn't really be the link address that matters. The
> > zImage is relocatable, so it should only be the load address specified
> > in the uImage header which matters. I think that's currently derived
> > from the link address, but it doesn't have to be.
>
> Having the link address jump around depending on the size of the kernel
> or zImage is wrong IMHO. It just screams "weird can't boot issues."
Hrm. Except we already have that - the zImage is linked at a fixed
location, and will just not work if the sizes are wrong.
> We need a way to specify exactly where we want the zImage linked no
> matter what the kernel or zImage size.
>
> Also, being able to control the link address (that is, the download
> address with some firmwares) is not a u-boot specific issue and we
> shouldn't make a u-boot specific solution.
>
> The more general problem is that some firmwares examine the ELF header
> and download the zImage to address it was linked at. Some firmwares let
> you override this but some don't and those are the problem ones.
>
> We talked about this a bit back in February,
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
>
> In that thread Geoff Levand suggested a config option and running it
> thru a preprocessor. David Gibson suggested making a replaceable linker
> script. I suggested passing the value of a config option to the wrapper
> script which would use objcopy/whatever to change the section addresses
> in the image (maybe this is what Geoff had in mind, I'm not sure).
>
> I still like my idea best. I haven't coded yet it so I don't have a patch
> but this is what I mean:
>
> 1) add a config option (default 4MB) for the link address
> 2) add a parameter to the wrapper script thru which we pass the value in
> the config option
> 3) the wrapper script changes the VMA/LMA to the address specified
> (objcopy --change-addresses=<some math to get correct incr> ?).
>
> I'll code it up in the next day or two unless someone doesn't like the idea.
A config option just doesn't seem right to me, except as a
special-circumstances hack. The zImage is already hardware and
firmware specific; we should be able to figure out workable link and
load addresses for a specific zImage (which might need to be different
for different zImages produced by the same config).
Of course, the same objection would apply to CONFIG_DEVICE_TREE which
we have already.
--
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: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Mark A. Greer @ 2007-10-05 1:58 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20071003055005.GD18978@localhost.localdomain>
On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> > David Gibson wrote:
> > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> > Looking deeper at this I've found that currently u-boot thinks that
> > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> > defined as (8 << 20)), although all physical memory is identity mapped.
> > That's why it puts command line and board info structure as high as
> > possible within the first 8MB. This worked fine with uImage, since
> > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> > (we need space at the start of the memory to eventually put vmlinux
> > image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> > damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> > workaround for that is to always link zImage at >=8MB base or to have
> > 4MB granularity like this:
> >
> > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
> >
> > Reserve at least 64K for u-boot cmd_line and bdinfo.
>
> Ah. Right. That makes things a bit tricky. Even this 4MB
> granularity may not be enough (say, if the vmlinux is < 4MB, but the
> zImage has a really big initrd and is > 4MB).
>
> Except... it shouldn't really be the link address that matters. The
> zImage is relocatable, so it should only be the load address specified
> in the uImage header which matters. I think that's currently derived
> from the link address, but it doesn't have to be.
Having the link address jump around depending on the size of the kernel
or zImage is wrong IMHO. It just screams "weird can't boot issues."
We need a way to specify exactly where we want the zImage linked no
matter what the kernel or zImage size.
Also, being able to control the link address (that is, the download
address with some firmwares) is not a u-boot specific issue and we
shouldn't make a u-boot specific solution.
The more general problem is that some firmwares examine the ELF header
and download the zImage to address it was linked at. Some firmwares let
you override this but some don't and those are the problem ones.
We talked about this a bit back in February,
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
In that thread Geoff Levand suggested a config option and running it
thru a preprocessor. David Gibson suggested making a replaceable linker
script. I suggested passing the value of a config option to the wrapper
script which would use objcopy/whatever to change the section addresses
in the image (maybe this is what Geoff had in mind, I'm not sure).
I still like my idea best. I haven't coded yet it so I don't have a patch
but this is what I mean:
1) add a config option (default 4MB) for the link address
2) add a parameter to the wrapper script thru which we pass the value in
the config option
3) the wrapper script changes the VMA/LMA to the address specified
(objcopy --change-addresses=<some math to get correct incr> ?).
I'll code it up in the next day or two unless someone doesn't like the idea.
Mark
^ permalink raw reply
* Re: include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
From: Kumar Gala @ 2007-10-05 0:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <4705691A.9020509@freescale.com>
On Oct 4, 2007, at 5:28 PM, Timur Tabi wrote:
> Kumar, this is what I get when I compile your 2.6.24 branch for the
> 8610:
>
> CC arch/powerpc/sysdev/fsl_soc.o
> In file included from arch/powerpc/sysdev/fsl_soc.c:40:
> include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
> make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
> make: *** [arch/powerpc/sysdev] Error 2
>
> Commenting out the "#include <asm/cpm.h>" in cpm2.h makes the
> compilation failure go away, but I don't know if that's the proper
> fix, since the 8610 doesn't have a CPM.
Scott mentioned this and I've fixed it in my tree.
- k
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Nish Aravamudan @ 2007-10-05 0:01 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003011909.GG9814@bakeyournoodle.com>
On 10/2/07, Tony Breeds <tony@bakeyournoodle.com> wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
>
> Clarify when RTAS logging is enabled.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.
Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
Thanks,
Nish
^ permalink raw reply
* include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
From: Timur Tabi @ 2007-10-04 22:28 UTC (permalink / raw)
To: Kumar Gala, PowerPC dev list
Kumar, this is what I get when I compile your 2.6.24 branch for the 8610:
CC arch/powerpc/sysdev/fsl_soc.o
In file included from arch/powerpc/sysdev/fsl_soc.c:40:
include/asm/cpm2.h:14:21: error: asm/cpm.h: No such file or directory
make[1]: *** [arch/powerpc/sysdev/fsl_soc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Commenting out the "#include <asm/cpm.h>" in cpm2.h makes the compilation
failure go away, but I don't know if that's the proper fix, since the 8610
doesn't have a CPM.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Benjamin Herrenschmidt @ 2007-10-04 22:05 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071004130454.GA15448@localhost.localdomain>
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [PATCH] [POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
>
> set_irq_chained_handler overwrites MPIC's handle_irq function
> (handle_fasteoi_irq) thus MPIC never gets eoi event from the
> cascaded IRQ. This situation hangs MPIC on MPC8568E.
>
> To solve this problem efficiently, QEIC needs pluggable handlers,
> specific to the underlaying interrupt controller.
>
> Patch extends qe_ic_init() function to accept low and high interrupt
> handlers. To avoid #ifdefs, stack of interrupt handlers specified in
> the header file and functions are marked 'static inline', thus
> handlers are compiled-in only if actually used (in the board file).
> Another option would be to lookup for parent controller and
> automatically detect handlers, but this will waste text size because
> of never used handlers.
>
> qe_ic_init() also changed in regard to support multiplexed high/low
> lines as found in MPC8568E-MDS, plus qe_ic_cascade_muxed_mpic()
> handler implemented appropriately.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Looks allright, if it also works, then ship it :-)
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 2 +-
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
> arch/powerpc/sysdev/qe_lib/qe_ic.c | 29 +++---------
> include/asm-powerpc/qe_ic.h | 68 ++++++++++++++++++++++++++++-
> 6 files changed, 78 insertions(+), 27 deletions(-)
>
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> index d494bc4..95f32ca 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> @@ -140,7 +140,7 @@ static void __init mpc832x_sys_init_IRQ(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> index 24a790c..f842a1c 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
> @@ -151,7 +151,7 @@ void __init mpc832x_rdb_init_IRQ(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> index db69576..5971fe6 100644
> --- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> @@ -147,7 +147,7 @@ static void __init mpc836x_mds_init_IRQ(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_low_ipic, qe_ic_cascade_high_ipic);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> index c379286..69c177b 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> @@ -174,7 +174,7 @@ static void __init mpc85xx_mds_pic_init(void)
> if (!np)
> return;
>
> - qe_ic_init(np, 0);
> + qe_ic_init(np, 0, qe_ic_cascade_muxed_mpic, NULL);
> of_node_put(np);
> #endif /* CONFIG_QUICC_ENGINE */
> }
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
> index 9a2d1ed..e1c0fd6 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
> @@ -321,25 +321,9 @@ unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic)
> return irq_linear_revmap(qe_ic->irqhost, irq);
> }
>
> -void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
> -{
> - struct qe_ic *qe_ic = desc->handler_data;
> - unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
> -
> - if (cascade_irq != NO_IRQ)
> - generic_handle_irq(cascade_irq);
> -}
> -
> -void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
> -{
> - struct qe_ic *qe_ic = desc->handler_data;
> - unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
> -
> - if (cascade_irq != NO_IRQ)
> - generic_handle_irq(cascade_irq);
> -}
> -
> -void __init qe_ic_init(struct device_node *node, unsigned int flags)
> +void __init qe_ic_init(struct device_node *node, unsigned int flags,
> + void (*low_handler)(unsigned int irq, struct irq_desc *desc),
> + void (*high_handler)(unsigned int irq, struct irq_desc *desc))
> {
> struct qe_ic *qe_ic;
> struct resource res;
> @@ -399,11 +383,12 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags)
> qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
>
> set_irq_data(qe_ic->virq_low, qe_ic);
> - set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
> + set_irq_chained_handler(qe_ic->virq_low, low_handler);
>
> - if (qe_ic->virq_high != NO_IRQ) {
> + if (qe_ic->virq_high != NO_IRQ &&
> + qe_ic->virq_high != qe_ic->virq_low) {
> set_irq_data(qe_ic->virq_high, qe_ic);
> - set_irq_chained_handler(qe_ic->virq_high, qe_ic_cascade_high);
> + set_irq_chained_handler(qe_ic->virq_high, high_handler);
> }
> }
>
> diff --git a/include/asm-powerpc/qe_ic.h b/include/asm-powerpc/qe_ic.h
> index e386fb7..a779b2c 100644
> --- a/include/asm-powerpc/qe_ic.h
> +++ b/include/asm-powerpc/qe_ic.h
> @@ -56,9 +56,75 @@ enum qe_ic_grp_id {
> QE_IC_GRP_RISCB /* QE interrupt controller RISC group B */
> };
>
> -void qe_ic_init(struct device_node *node, unsigned int flags);
> +void qe_ic_init(struct device_node *node, unsigned int flags,
> + void (*low_handler)(unsigned int irq, struct irq_desc *desc),
> + void (*high_handler)(unsigned int irq, struct irq_desc *desc));
> void qe_ic_set_highest_priority(unsigned int virq, int high);
> int qe_ic_set_priority(unsigned int virq, unsigned int priority);
> int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high);
>
> +struct qe_ic;
> +unsigned int qe_ic_get_low_irq(struct qe_ic *qe_ic);
> +unsigned int qe_ic_get_high_irq(struct qe_ic *qe_ic);
> +
> +static inline void qe_ic_cascade_low_ipic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +}
> +
> +static inline void qe_ic_cascade_high_ipic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +}
> +
> +static inline void qe_ic_cascade_low_mpic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +
> + desc->chip->eoi(irq);
> +}
> +
> +static inline void qe_ic_cascade_high_mpic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +
> + desc->chip->eoi(irq);
> +}
> +
> +static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
> + struct irq_desc *desc)
> +{
> + struct qe_ic *qe_ic = desc->handler_data;
> + unsigned int cascade_irq;
> +
> + cascade_irq = qe_ic_get_high_irq(qe_ic);
> + if (cascade_irq == NO_IRQ)
> + cascade_irq = qe_ic_get_low_irq(qe_ic);
> +
> + if (cascade_irq != NO_IRQ)
> + generic_handle_irq(cascade_irq);
> +
> + desc->chip->eoi(irq);
> +}
> +
> #endif /* _ASM_POWERPC_QE_IC_H */
^ permalink raw reply
* Re: [PATCH] [POWERPC] update immap_86xx.h for the 8610
From: Timur Tabi @ 2007-10-04 22:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <11913604331348-git-send-email-timur@freescale.com>
Kumar, can you pull this patch into your 2.6.24 tree? It's needed for the 8610.
Timur Tabi wrote:
> Update the definition of the global utilities structure (ccsr_guts) in
> immap_86xx.h and add some related macros for the Freescale 8610 SOC.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch is for 2.6.24.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Device tree and external RTC
From: Guennadi Liakhovetski @ 2007-10-04 19:52 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OF6E4972CE.0F54E43B-ON8825736A.00637A7C-8825736A.00646F2A@selinc.com>
On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:
> Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/04/2007 02:29:06
> AM:
>
> > > CONFIG_SENSORS_M41T00=y
> >
> > It shall not hurt, but do you really have this one?
>
> I turned this on because my clock is a SMT M41T00. Not sure why it's
> called a sensor in the .config.
It is the deprecated driver for the same rtc chip. But maybe it is this
one that makes your RTC work ATM, see below.
> > First, this might be either a userspace or a kernel problem. Do you have
>
> > the correct device nodes? Are you using udev? Should be something like
>
> Ultimatly it was my own stupididty that did me in. You are absolutly
> correct, I didn't have the right device nodes and because we're limited on
> space we don't want to use udev. Once I created the rtc0 device and
> linked rtc to it, hwclock started working correctly.
It shouldn't. It probably does thanks to the m41t00 driver, but you don't
want it, instead...
> > you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the
> > i2c_devices array. I think, patch at
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you
> > need.
>
> I'll give this a try. I'd really prefer to be using the device tree for
> this, but I guess as long as I have it working using configuration options
> in the kernel it doesn't really matter. Either way I don't have to write
> any special board support code for the kernel.
you need this patch to get ds1307 attach to your rtc chip.
And, besides, linuxppc-embedded is deprecated, linuxppc-dev should be used
instead:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Console handover: tty0 instead of ttyCPM0?
From: Scott Wood @ 2007-10-04 18:50 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710041146y2c74b9dcy3dd413934680ab10@mail.gmail.com>
Alan Bennett wrote:
> Do you know what would cause this?
>
> I've configured a board to console off of SMC1 (ttyCPM0) and on 1
> board it works fine, however a new revision of the board I get the
> following result and lose the console. Both boards have "exact"
> versions of the kernel and u-boot.
>
> BAD: console handover: boot [udbg0] -> real [tty0]
> GOOD: console handover: boot [udbg0] -> real [ttyCPM0]
[snip]
> Linux/PowerPC load: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsroow
You really should turn on line wrap in your serial program...
> console handover: boot [udbg0] -> real [tty0]
[snip]
> Kernel command line: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::2
This one has console=ttyCPM0. The other one doesn't (unless it was
eaten by the lack of line wrap).
-Scott
^ permalink raw reply
* Console handover: tty0 instead of ttyCPM0?
From: Alan Bennett @ 2007-10-04 18:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
Do you know what would cause this?
I've configured a board to console off of SMC1 (ttyCPM0) and on 1
board it works fine, however a new revision of the board I get the
following result and lose the console. Both boards have "exact"
versions of the kernel and u-boot.
BAD: console handover: boot [udbg0] -> real [tty0]
GOOD: console handover: boot [udbg0] -> real [ttyCPM0]
IMMRBASE is e0000000
CONFIG_PPC_EARLY_DEBUG_CPM=y
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xe0000888
doesn't WORK:
==========================================
zImage starting: loaded at 0x00400000 (sp: 0x07bc19a0)
Allocating 0x309670 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x00710448)...done 0x2f0ad4 bytes
Linux/PowerPC load: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsroow
Finalizing device tree... flat tree at 0x71e3a0
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using Embedded Planet EP8248E machine description
Linux version 2.6.23-rc6-VTM-0007-1763 (root@fremont) (gcc version 3.4.5) #5 Th7
console [udbg0] enabled
setup_arch: bootmem
ep8248_setup_arch()
ep8248_setup_arch(), finish
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: root=/dev/nfs ip=192.168.10.45:::255.255.255.0::eth0 nfsrow
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [tty0]
BOARD THAT WORKS:
==========================================
zImage starting: loaded at 0x00400000 (sp: 0x07bc19a0)
Allocating 0x309670 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x00710448)...done 0x2f0ad4 bytes
Linux/PowerPC load: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::25
Finalizing device tree... flat tree at 0x71e3a0
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using Embedded Planet EP8248E machine description
Linux version 2.6.23-rc6-VTM-0007-1763 (root@fremont) (gcc version 3.4.5) #5 Th7
console [udbg0] enabled
setup_arch: bootmem
ep8248_setup_arch()
ep8248_setup_arch(), finish
arch: exit
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists in Zone order. Total pages: 32512
Kernel command line: console=ttyCPM0,38400n8 root=/dev/nfs ip=192.168.10.49:::2
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25Dentry cache hash table entries: 16384 (order)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126660k/131072k available (2852k kernel code, 4264k reserved, 132k data)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Generic PHY: Registered new driver
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-10-04 18:36 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20071002012730.GO12049@parisc-linux.org>
On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote:
>
> The thing to remember is that sym2 is in transition from being a dual
> BSD/Linux driver to being a purely Linux driver.
I was wondering about that; couldn't tell if the split in the code
was historical, or being intentionally maintained.
> > My gut instinct is to say "ack", although prudence dictates that
> > I should test first. Which might take a few days...
>
> Fine by me.
I tested the patch, it worked great. It also seemed to recover
much more quickly -- so quickly, in fact, that I thought something
had gone wrong.
I reviewed it one more time, it really does look good. A formal
submission and acked by's at earliest convenience would be good.
--linas
^ permalink raw reply
* Re: Device tree and external RTC
From: Bruce_Leonard @ 2007-10-04 18:25 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <87ve9nw2ft.fsf@macbook.be.48ers.dk>
Peter,
Peter Korsgaard <jacmet@gmail.com> wrote on 10/04/2007 04:21:10 AM:
> >>>>> "Bruce" == Bruce Leonard <Bruce_Leonard@selinc.com> writes:
>
>
> You need to add #address/size-cells to the I2C node, E.G.:
> + #address-cells = <1>;
> + #size-cells = <0>;
>
>
> You need to set compatible and reg, E.G.
> rtc@54 {
> device_type = "rtc";
> compatible = "stm,m41t00";
> reg = <54>;
> };
>
> And it should get picked up automatically by
> fsl_soc.c:of_find_i2c_driver().
>
> Notice that you will need to use galak's git tree
Thanks for the info. It's this sort of thing that isn't clearly
documented anywhere, and until I'm REALLY familiar with the kernel knowing
where to look is a challenge.
A follow on question though. I've looked at the patch and it seems to be
just adding 6 lines to an existing array in fsl_soc.c. However, I can't
seem to find any array in fsl_soc.c that contains lines that the patch
indicates should already be there (i.e., there's nothing in fsl_soc.c that
has the word "ricoh" in it which the patch indicates it should). Is my
fsl_soc.c already out of date? Will the patch apply? I've got 2.6.22.
Bruce
^ permalink raw reply
* Re: Device tree and external RTC
From: Bruce_Leonard @ 2007-10-04 18:17 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0710041046040.4537@poirot.grange>
Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/04/2007 02:29:06
AM:
> > CONFIG_SENSORS_M41T00=y
>
> It shall not hurt, but do you really have this one?
I turned this on because my clock is a SMT M41T00. Not sure why it's
called a sensor in the .config.
> First, this might be either a userspace or a kernel problem. Do you have
> the correct device nodes? Are you using udev? Should be something like
Ultimatly it was my own stupididty that did me in. You are absolutly
correct, I didn't have the right device nodes and because we're limited on
space we don't want to use udev. Once I created the rtc0 device and
linked rtc to it, hwclock started working correctly.
> > When I dump out ppc_md, all the RTC functions (i.e., get_rtc_time,
> > read_rtc_val, etc.) are all NULL.
>
> Don't think you need those. Those are for powerpc platforms not using
> the generic rtc driver.
Right.
> you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the
> i2c_devices array. I think, patch at
> http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you
> need.
I'll give this a try. I'd really prefer to be using the device tree for
this, but I guess as long as I have it working using configuration options
in the kernel it doesn't really matter. Either way I don't have to write
any special board support code for the kernel.
Thanks for all the information and pointers. It's been a big help!
Bruce
^ permalink raw reply
* Re: Stdout console clogging => 300ms blocked
From: Linas Vepstas @ 2007-10-04 17:21 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <fe0v88$dt5$1@sea.gmane.org>
Hi Bernard,
On Wed, Oct 03, 2007 at 08:49:12PM +0000, Hollis Blanchard wrote:
> On Tue, 02 Oct 2007 09:41:28 +0200, Willaert, Bernard wrote:
>
> > Problem:
> > When we log debug output via the serial console on a multithreaded
> > application, the console throughput may get clogged and then we
> > experience a >300ms deadlock.
> >
> > #define THREAD_DELAY 1000
> > usleep(THREAD_DELAY);
> > fprintf(stdout," <----- thread 1\n");
[...]
> >
> > usleep(THREAD_DELAY);
> > fprintf(stdout," <----- thread 2\n");
> >
> > baudrate=115200
OK, lets do the math. 115200 baud == approx 115200 bits per second
assuming 8N1 for stop & parity bits, I get approx 9 bits per byte
so your serial port is capable of 115.2/9 = 12.8KBytes per second.
Now, every millisecond, you are attempting to print
" <----- thread 1\n"
Lets see, thats 17 bytes. And also " <----- thread 2\n" for
a grand total of 34 bytes per millisecond.
And you are attempting to jam this through a serial line capable
of 12.8 Bytes per millisecond? Well, of course it won't fit!
> > Real output on the console:
> >
> > .... /\ ........
> > <----- thread 1
> > <----- thread 2
> > <----- thread 1
> > <----- thread 2
> > <----- thread 1
> > <----- thread 2
> > !!!!!!!!!!! thread2 interval timeout = 335 ms
Well, thread 1 clearly also had a delay of 335 milliseconds
for a total of 670 milliseconds delay.
Now, theoretically, we should have seen a delay equal to
(34 - 12.8)/34 = 0.623 seconds
I'd say that theory and practice match up pretty damned well;
I see no evidence of any problem at all.
> Could you not post HTML please? Thanks.
Agreed.
--linas
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Grant Likely @ 2007-10-04 16:42 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <13039401.post@talk.nabble.com>
On 10/4/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
> Hi ...
> I did followed you and it worked as well. I really Thank you for it.
>
> At one Place i am doing memcpy() of floating point data to the memory mapped
> registers, what could be the substitute of it like "memcpy_toio() " which is
> suggested in the Book. I am working BE architecture.
>
> I would really appreaciate if you would let me know the defineation of these
> wrapper functions (in_be32,out_be32(),ioread32(),iowrite32(),etc) so that i
> could have the clear idea of the reason for not directly dreferencing the
> Pointer.
You don't want to directly dereference pointers to device registers
because you don't want the processor or compiler to reorder your
register accesses. The in/out_* wrappers keeps the compiler from
reordering things, and the wrappers contain the 'sync' instruction
which prevents the processor from reordering operations at runtime.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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