* 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
* Re: [PATCH] Don't build arch/powerpc/sysdev/dcr.c for ARCH=ppc kernels
From: Josh Boyer @ 2007-10-04 14:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1191508485.7014.7.camel@concordia>
On Fri, 05 Oct 2007 00:34:45 +1000
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Thu, 2007-10-04 at 05:56 -0500, Josh Boyer wrote:
> > On Wed, 2007-10-03 at 22:50 -0600, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > dcr.c is an arch/powerpc only thing.
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > ---
> > >
> > > Ben/Paulus,
> > >
> > > As far as I can tell this is correct. Having sysdev/dcr.c in the arch/ppc
> > > build spits out warnings. Grep doesn't show anything in arch/ppc that
> > > is using it.
> >
> > Sorry, no. The ibm_emac driver uses it, which is arch/ppc. (Yes, the
> > old one.)
> >
> > If there are warnings, let's fix those up. Perhaps Michael's recent
> > patches in that area introduced something.
>
> Hmm, I picked a good time to be away :)
>
> I think it's OK. ibm_emac uses dcr_write() but it should always be using
> the native one from dcr-native.h. So I think this patch is good.
Agreed.
> Just another reason to get rid of arch/ppc :D
Agreed.
josh
^ permalink raw reply
* Re: [PATCH] Don't build arch/powerpc/sysdev/dcr.c for ARCH=ppc kernels
From: Michael Ellerman @ 2007-10-04 14:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1191495405.3647.3.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Thu, 2007-10-04 at 05:56 -0500, Josh Boyer wrote:
> On Wed, 2007-10-03 at 22:50 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > dcr.c is an arch/powerpc only thing.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > Ben/Paulus,
> >
> > As far as I can tell this is correct. Having sysdev/dcr.c in the arch/ppc
> > build spits out warnings. Grep doesn't show anything in arch/ppc that
> > is using it.
>
> Sorry, no. The ibm_emac driver uses it, which is arch/ppc. (Yes, the
> old one.)
>
> If there are warnings, let's fix those up. Perhaps Michael's recent
> patches in that area introduced something.
Hmm, I picked a good time to be away :)
I think it's OK. ibm_emac uses dcr_write() but it should always be using
the native one from dcr-native.h. So I think this patch is good.
Just another reason to get rid of arch/ppc :D
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
* [PATCH] [POWERPC] 85xx: Killed <asm/mpc85xx.h>
From: Kumar Gala @ 2007-10-04 13:54 UTC (permalink / raw)
To: linuxppc-dev
asm-powerpc/mpc85xx.h was really a hold over from arch/ppc. Now that
more decoupling has occurred we can remove <asm/mpc85xx.h> and some of
its legacy.
As part of this we moved the definition of CPM_MAP_ADDR into cpm2_common
for 85xx platforms. This is a stop gap until we switch them over to the
new device-tree based config.
---
arch/powerpc/platforms/85xx/mpc8540_ads.h | 35 -----------------
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 1 -
arch/powerpc/platforms/85xx/mpc85xx_ads.h | 60 -----------------------------
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 10 ++++-
arch/powerpc/platforms/85xx/mpc85xx_cds.h | 43 --------------------
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 1 -
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 -
arch/powerpc/sysdev/cpm2_common.c | 4 ++
include/asm-powerpc/cpm2.h | 20 ----------
include/asm-powerpc/fs_pd.h | 2 -
include/asm-powerpc/mpc85xx.h | 45 ---------------------
11 files changed, 13 insertions(+), 209 deletions(-)
delete mode 100644 arch/powerpc/platforms/85xx/mpc8540_ads.h
delete mode 100644 arch/powerpc/platforms/85xx/mpc85xx_ads.h
delete mode 100644 arch/powerpc/platforms/85xx/mpc85xx_cds.h
delete mode 100644 include/asm-powerpc/mpc85xx.h
Removing code is far more fun than adding it :)
diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/powerpc/platforms/85xx/mpc8540_ads.h
deleted file mode 100644
index da82f4c..0000000
--- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * arch/powerpc/platforms/85xx/mpc8540_ads.h
- *
- * MPC8540ADS board definitions
- *
- * Maintainer: Kumar Gala <kumar.gala@freescale.com>
- *
- * Copyright 2004 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
-
-#ifndef __MACH_MPC8540ADS_H__
-#define __MACH_MPC8540ADS_H__
-
-#include <linux/initrd.h>
-
-#define BOARD_CCSRBAR ((uint)0xe0000000)
-#define BCSR_ADDR ((uint)0xf8000000)
-#define BCSR_SIZE ((uint)(32 * 1024))
-
-/* PCI interrupt controller */
-#define PIRQA MPC85xx_IRQ_EXT1
-#define PIRQB MPC85xx_IRQ_EXT2
-#define PIRQC MPC85xx_IRQ_EXT3
-#define PIRQD MPC85xx_IRQ_EXT4
-
-/* Offset of CPM register space */
-#define CPM_MAP_ADDR (CCSRBAR + MPC85xx_CPM_OFFSET)
-
-#endif /* __MACH_MPC8540ADS_H__ */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index 378a244..5bc9319 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -22,7 +22,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc85xx.h>
#include <asm/prom.h>
#include <asm/mpic.h>
#include <mm/mmu_decl.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.h b/arch/powerpc/platforms/85xx/mpc85xx_ads.h
deleted file mode 100644
index 46c3532..0000000
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.h
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * MPC85xx ADS board definitions
- *
- * Maintainer: Kumar Gala <galak@kernel.crashing.org>
- *
- * Copyright 2004 Freescale Semiconductor Inc.
- *
- * 2006 (c) MontaVista Software, Inc.
- * Vitaly Bordug <vbordug@ru.mvista.com>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
-
-#ifndef __MACH_MPC85XXADS_H
-#define __MACH_MPC85XXADS_H
-
-#include <linux/initrd.h>
-#include <sysdev/fsl_soc.h>
-
-#define BCSR_ADDR ((uint)0xf8000000)
-#define BCSR_SIZE ((uint)(32 * 1024))
-
-#ifdef CONFIG_CPM2
-
-#define MPC85xx_CPM_OFFSET (0x80000)
-
-#define CPM_MAP_ADDR (get_immrbase() + MPC85xx_CPM_OFFSET)
-#define CPM_IRQ_OFFSET 60
-
-#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
-#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC1 ((uint)0x28+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC2 ((uint)0x29+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC3 ((uint)0x2a+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
-
-/* FCC1 Clock Source Configuration. These can be
- * redefined in the board specific file.
- * Can only choose from CLK9-12 */
-#define F1_RXCLK 12
-#define F1_TXCLK 11
-
-/* FCC2 Clock Source Configuration. These can be
- * redefined in the board specific file.
- * Can only choose from CLK13-16 */
-#define F2_RXCLK 13
-#define F2_TXCLK 14
-
-/* FCC3 Clock Source Configuration. These can be
- * redefined in the board specific file.
- * Can only choose from CLK13-16 */
-#define F3_RXCLK 15
-#define F3_TXCLK 16
-
-#endif /* CONFIG_CPM2 */
-#endif /* __MACH_MPC85XXADS_H */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index afe5868..4d063ee 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -36,7 +36,6 @@
#include <asm/machdep.h>
#include <asm/ipic.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <mm/mmu_decl.h>
#include <asm/prom.h>
@@ -47,6 +46,15 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
+/* CADMUS info */
+/* xxx - galak, move into device tree */
+#define CADMUS_BASE (0xf8004000)
+#define CADMUS_SIZE (256)
+#define CM_VER (0)
+#define CM_CSR (1)
+#define CM_RST (2)
+
+
static int cds_pci_slot = 2;
static volatile u8 *cadmus;
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.h b/arch/powerpc/platforms/85xx/mpc85xx_cds.h
deleted file mode 100644
index b251c9f..0000000
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * arch/powerpc/platforms/85xx/mpc85xx_cds.h
- *
- * MPC85xx CDS board definitions
- *
- * Maintainer: Kumar Gala <galak@kernel.crashing.org>
- *
- * Copyright 2004 Freescale Semiconductor, Inc
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
-
-#ifndef __MACH_MPC85XX_CDS_H__
-#define __MACH_MPC85XX_CDS_H__
-
-/* CADMUS info */
-#define CADMUS_BASE (0xf8004000)
-#define CADMUS_SIZE (256)
-#define CM_VER (0)
-#define CM_CSR (1)
-#define CM_RST (2)
-
-/* CDS NVRAM/RTC */
-#define CDS_RTC_ADDR (0xf8000000)
-#define CDS_RTC_SIZE (8 * 1024)
-
-/* PCI interrupt controller */
-#define PIRQ0A MPC85xx_IRQ_EXT0
-#define PIRQ0B MPC85xx_IRQ_EXT1
-#define PIRQ0C MPC85xx_IRQ_EXT2
-#define PIRQ0D MPC85xx_IRQ_EXT3
-#define PIRQ1A MPC85xx_IRQ_EXT11
-
-#define NR_8259_INTS 16
-#define CPM_IRQ_OFFSET NR_8259_INTS
-
-#define MPC85xx_OPENPIC_IRQ_OFFSET 80
-
-#endif /* __MACH_MPC85XX_CDS_H__ */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 772e8de..59c121a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -24,7 +24,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc85xx.h>
#include <mm/mmu_decl.h>
#include <asm/prom.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 00f4c3a..2269d2e 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -39,7 +39,6 @@
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <mm/mmu_decl.h>
#include <asm/prom.h>
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index 453f8a5..ea2ba84 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -330,6 +330,10 @@ static rh_block_t cpm_boot_dpmem_rh_block[16];
static rh_info_t cpm_dpmem_info;
static u8 __iomem *im_dprambase;
+#ifdef CONFIG_PPC_85xx
+#define CPM_MAP_ADDR (get_immrbase() + 0x80000)
+#endif
+
static void cpm2_dpinit(void)
{
spin_lock_init(&cpm_dpmem_lock);
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index e698b1d..111f45d 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -1120,26 +1120,6 @@ typedef struct im_idma {
#define CMXFCR_RF3CS(x) ((uint)((x-9)<<11)) /* FCC3 Receive Clock Source */
#define CMXFCR_TF3CS(x) ((uint)((x-9)<<8)) /* FCC3 Transmit Clock Source */
-#define PC_F1RXCLK PC_CLK(F1_RXCLK)
-#define PC_F1TXCLK PC_CLK(F1_TXCLK)
-#define CMX1_CLK_ROUTE (CMXFCR_RF1CS(F1_RXCLK) | CMXFCR_TF1CS(F1_TXCLK))
-#define CMX1_CLK_MASK ((uint)0xff000000)
-
-#define PC_F2RXCLK PC_CLK(F2_RXCLK)
-#define PC_F2TXCLK PC_CLK(F2_TXCLK)
-#define CMX2_CLK_ROUTE (CMXFCR_RF2CS(F2_RXCLK) | CMXFCR_TF2CS(F2_TXCLK))
-#define CMX2_CLK_MASK ((uint)0x00ff0000)
-
-#define PC_F3RXCLK PC_CLK(F3_RXCLK)
-#define PC_F3TXCLK PC_CLK(F3_TXCLK)
-#define CMX3_CLK_ROUTE (CMXFCR_RF3CS(F3_RXCLK) | CMXFCR_TF3CS(F3_TXCLK))
-#define CMX3_CLK_MASK ((uint)0x0000ff00)
-
-#define CPMUX_CLK_MASK (CMX3_CLK_MASK | CMX2_CLK_MASK)
-#define CPMUX_CLK_ROUTE (CMX3_CLK_ROUTE | CMX2_CLK_ROUTE)
-
-#define CLK_TRX (PC_F3TXCLK | PC_F3RXCLK | PC_F2TXCLK | PC_F2RXCLK)
-
/* I/O Pin assignment for FCC1. I don't yet know the best way to do this,
* but there is little variation among the choices.
*/
diff --git a/include/asm-powerpc/fs_pd.h b/include/asm-powerpc/fs_pd.h
index 64706a0..9361cd5 100644
--- a/include/asm-powerpc/fs_pd.h
+++ b/include/asm-powerpc/fs_pd.h
@@ -19,8 +19,6 @@
#if defined(CONFIG_8260)
#include <asm/mpc8260.h>
-#elif defined(CONFIG_85xx)
-#include <asm/mpc85xx.h>
#endif
#define cpm2_map(member) (&cpm2_immr->member)
diff --git a/include/asm-powerpc/mpc85xx.h b/include/asm-powerpc/mpc85xx.h
deleted file mode 100644
index 5414299..0000000
--- a/include/asm-powerpc/mpc85xx.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * include/asm-powerpc/mpc85xx.h
- *
- * MPC85xx definitions
- *
- * Maintainer: Kumar Gala <galak@kernel.crashing.org>
- *
- * Copyright 2004 Freescale Semiconductor, Inc
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#ifdef __KERNEL__
-#ifndef __ASM_MPC85xx_H__
-#define __ASM_MPC85xx_H__
-
-#include <asm/mmu.h>
-
-#ifdef CONFIG_85xx
-
-#if defined(CONFIG_MPC8540_ADS) || defined(CONFIG_MPC8560_ADS)
-#include <platforms/85xx/mpc85xx_ads.h>
-#endif
-#if defined(CONFIG_MPC8555_CDS) || defined(CONFIG_MPC8548_CDS)
-#include <platforms/85xx/mpc8555_cds.h>
-#endif
-#ifdef CONFIG_MPC85xx_CDS
-#include <platforms/85xx/mpc85xx_cds.h>
-#endif
-
-/* Let modules/drivers get at CCSRBAR */
-extern phys_addr_t get_ccsrbar(void);
-
-#ifdef MODULE
-#define CCSRBAR get_ccsrbar()
-#else
-#define CCSRBAR BOARD_CCSRBAR
-#endif
-
-#endif /* CONFIG_85xx */
-#endif /* __ASM_MPC85xx_H__ */
-#endif /* __KERNEL__ */
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 2/5] Add initial MPC8610 HPCD Platform files.
From: Kumar Gala @ 2007-10-04 13:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Stephen Rothwell, Xianghua Xiao, linuxppc-dev@ozlabs.org
In-Reply-To: <E1IdQ7s-0006DC-8I@jdl.com>
On Oct 4, 2007, at 7:48 AM, Jon Loeliger wrote:
> So, like, the other day Kumar Gala mumbled:
>>
>> On Oct 3, 2007, at 10:41 PM, Stephen Rothwell wrote:
>>
>>> On Wed, 03 Oct 2007 15:09:33 -0500 Jon Loeliger <jdl@freescale.com>
>>> wrote:
>>>>
>>>> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
>>>> +#include <linux/stddef.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/pci.h>
>>>> +#include <linux/kdev_t.h>
>>>> +#include <linux/delay.h>
>>>> +#include <linux/seq_file.h>
>>>> +
>>>> +#include <asm/system.h>
>>>> +#include <asm/time.h>
>>>> +#include <asm/machdep.h>
>>>> +#include <asm/pci-bridge.h>
>>>> +#include <asm/mpc86xx.h>
>>>> +#include <asm/prom.h>
>>>
>>> You should include linux/of.h as well to use the of_ accessor
>>> functions.
>>
>> added.
>>
>> - k
>
> Thanks, Kumar.
np. I made a few other changes (like killing the cpuinfo code in the
platform).
this is on my for-2.6.24 branch now.
- k
^ permalink raw reply
* [RFC][PATCH][POWERPC] QEIC: Implement pluggable handlers, fix MPIC cascading
From: Anton Vorontsov @ 2007-10-04 13:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1191362562.22572.24.camel@pasglop>
On Wed, Oct 03, 2007 at 08:02:42AM +1000, Benjamin Herrenschmidt wrote:
>
> >
> > Exactly, this is what that patch is trying to do. QEIC cascade handler is
> > calling mpic's eoi() (end() actually, as it's flow level, but end == eoi.
> > Is it main objection? Ok, I can get rid of it, and use chip level eoi()
> > directly).
>
> Yes, use eoi() directly, don't add end()
Ok.
> > Yup, exactly. Actually, QEIC's cascade handlers do not really know
> > what needs to be done, but they're good at guessing (if (chip->eoi)).
> >
> > Sure, I can place board-specific QEIC handlers in the board file, but
> > that will be quite big code duplication for all machines using QEIC.
>
> Maybe you can provide a set of common ones, and then just pick the one
> you want from the board file ?
>
> Or have some board code call into a QEIC init routine specifying the
> type of cascade handler to use ... or whatevre you like here.
Ok, thanks. How about this patch?
- - - -
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>
---
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 */
--
1.5.0.6
^ permalink raw reply related
* 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: Misbah khan @ 2007-10-04 13:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20071001135516.GA8572@lixom.net>
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.
Misbah
Olof Johansson-2 wrote:
>
> On Sun, Sep 30, 2007 at 10:38:32PM -0700, Misbah khan wrote:
>
>> Olof Johansson-2 wrote:
>> >
>> > First, PLEASE stop quoting your own text. Do not append > in front of
>> > the lines you write yourself in the reply. It makes it impossible to
>> > tell what parts are new and what are old.
>
> Please read the above again, since you didn't fix your mailer.
>
> Also, make sure it doesn't prepend spaces in front of the lines you are
> writing.
>
>> > I am confused that some people tells me to map the memory noncacheble
>> and
>> > some tells me not. could you tell me which is the best approach and
>> please
>> > elaborate the reason as well. The part of the code is mentioned above
>> is a
>> > reference and my concern are as follows:-
>
> It depends on your application and how the FPGA is attached. Buf if it is
> attached outside of the coherence domain (for example on PCI), then you
> should map it uncacheable. Otherwise you will have to do manual flushing
> of caches to make sure writes make it out to the device, and also flush
> any copy in cache before you read any register. In other words, it makes
> things considerably more complicated and error-prone.
>
>> > 1. I am mapping 32 KB of memory for which i am using _nocasheble. Is it
>> > absolutely fine????
>
> Just use ioremap().
>
>> > 2. I am directly dereferencing the pointer to the mapped region insted
>> of
>> > using a wrapper function due to (1) Aready used in the past and have
>> faith
>> > in it .
>
> I don't care if you have faith in it or not, it's still not the correct
> way to do it. It might work right some of the time by pure luck but it
> is the incorrect way of accessing device memory.
>
>> > (2) I had used functions like ioread32() iowrite32() in the past
>> which
>> > is suggested by rubini in his book on Linux device Driver but the
>> output i
>> > got was bitswapped .
>
> I assume you mean byte swapped and not bit swapped.
>
> Are your registers on the device big- or little endian?
>
> If they are big endian, use in_be32/out_be32. If they're little endian,
> use
> in_le32/out_le32. That will take care of any swapping for you.
>
>> > 3. test_bit()/clear_bit() are the functions which i am using in my
>> driver
>> > and in the way i described above , please let me know that is looks
>> fine
>> > in the Implimention
>
> No it is not fine. You cannot use set_bit/clear_bit against noncacheable
> memory. EVER.
>
>> > or shall i read the value and mask the bits rather
>> > than beliving in these functions for eg :-
>> >
>> > dfr_data_ret=*(volatile UINT32 *)((volatile UINT32
>> > *)mmap_reg_ptr+DATA_STATUS_REG);
>> >
>> > dfr_data_ret&=STATUS_MASK;
>> >
>> > Please reply to clear my doubts.
>
> Just do what I told you earlier:
>
> To read the status register, mask out the STATUS_MASK and write it
> back, do:
>
> val = in_be32(mmap_reg_ptr + DATA_STATUS_REG);
> val &= STATUS_MASK;
> out_be32(MMAP_REG_PTR + DATA_STATUS_REG, val);
>
>
> -Olof
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a13039401
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/5] Add initial MPC8610 HPCD Platform files.
From: Jon Loeliger @ 2007-10-04 12:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, Xianghua Xiao, linuxppc-dev@ozlabs.org
In-Reply-To: <44FE7AFC-1883-49A1-A781-6D966653EDF4@kernel.crashing.org>
So, like, the other day Kumar Gala mumbled:
>
> On Oct 3, 2007, at 10:41 PM, Stephen Rothwell wrote:
>
> > On Wed, 03 Oct 2007 15:09:33 -0500 Jon Loeliger <jdl@freescale.com>
> > wrote:
> >>
> >> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> >> +#include <linux/stddef.h>
> >> +#include <linux/kernel.h>
> >> +#include <linux/pci.h>
> >> +#include <linux/kdev_t.h>
> >> +#include <linux/delay.h>
> >> +#include <linux/seq_file.h>
> >> +
> >> +#include <asm/system.h>
> >> +#include <asm/time.h>
> >> +#include <asm/machdep.h>
> >> +#include <asm/pci-bridge.h>
> >> +#include <asm/mpc86xx.h>
> >> +#include <asm/prom.h>
> >
> > You should include linux/of.h as well to use the of_ accessor
> > functions.
>
> added.
>
> - k
Thanks, Kumar.
jdl
^ permalink raw reply
* Re: [PATCH] Don't build arch/powerpc/sysdev/dcr.c for ARCH=ppc kernels
From: Josh Boyer @ 2007-10-04 12:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1191496084.6245.0.camel@pasglop>
On Thu, 04 Oct 2007 21:08:04 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2007-10-04 at 05:56 -0500, Josh Boyer wrote:
> > On Wed, 2007-10-03 at 22:50 -0600, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > dcr.c is an arch/powerpc only thing.
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > ---
> > >
> > > Ben/Paulus,
> > >
> > > As far as I can tell this is correct. Having sysdev/dcr.c in the arch/ppc
> > > build spits out warnings. Grep doesn't show anything in arch/ppc that
> > > is using it.
> >
> > Sorry, no. The ibm_emac driver uses it, which is arch/ppc. (Yes, the
> > old one.)
> >
> > If there are warnings, let's fix those up. Perhaps Michael's recent
> > patches in that area introduced something.
>
> What does it use of dcr.c ? Initially, the 4xx bits where totally
> inline, but maybe Michael's patches is changing that ?
Gah. Sorry, I was thinking of dcr-low.S, not dcr.c. And poor Michael
has nothing to do with it.
Drink coffee. Then think.
josh
^ permalink raw reply
* Re: linux ethernet problem
From: Valentine Barshak @ 2007-10-04 11:45 UTC (permalink / raw)
To: jxnuxdy; +Cc: linuxppc-embedded
In-Reply-To: <4418074.198781191459542009.JavaMail.coremail@bj163app58.163.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=x-gbk; format=flowed, Size: 976 bytes --]
jxnuxdy wrote:
> Hi,
>
> I use the 440epx CPU and bcm5241 PHY in my system, the ehternet works
> fine in u-boot, however I can't use the ethernet in linux if I didn't
> active the ehernet in u-boot(such as 'ping'... or 'tftp'...).
>
> Is there anyone even encounter such problem? is the issue due to my
> u-boot or linux?
What kernel version do you use?
Please, make sure that phy is initialized by linux and the phy mode is
correct.
IIRC, bcm5241 is connected to the ZMII bridge and works in SMII mode.
Thanks,
Valentine.
>
>
> ,Regards
> - Denny
>
>
> Íø Ò× Yeah.net Ãâ ·Ñ ÓÊ Ïä È« Р¸Ä °æ£¬Õä ²Ø ÕÊ ºÅ ¿ª ·Å£¬¿ì À´ ÇÀ ×¢
> >> < http://event.mail.163.com/chanel/click.htm?from=NO_16&domain=163>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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