* 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
* Re: Device tree and external RTC
From: Peter Korsgaard @ 2007-10-04 11:21 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OFFFD4BE8F.17F6E427-ON88257369.006D8651-88257369.00736D96@selinc.com>
>>>>> "Bruce" == Bruce Leonard <Bruce_Leonard@selinc.com> writes:
Hi,
Bruce> I'm seriously confused by how things are supposed to work now
Bruce> with device trees on the PowerPC arch. I'm bringing up our
Bruce> custom HW which is bassed on the mpc8347e, with an m41t00 RTC
Bruce> hanging off the i2c bus, U-boot is 1.2.0, kernel is 2.6.22.
Bruce> My problem is I can't get the kernel to access the RTC. It
Bruce> works fine in U-boot, but nothing in the kernel.
Bruce> I've searched through all the device tree files that come with
Bruce> the kernel
Bruce> and I can't find any that explicitly show an external device
Bruce> as a child node to a SoC I2C controller but it sure seems to
Bruce> me that the purpose of the device tree is to describe to the
Bruce> kernel all the hardware in the system. Therefore it seems to
Bruce> me that there should be something like the following in the
Bruce> device tree:
Bruce> <snip>
Bruce> i2c@3000 {
Bruce> device_type = "i2c";
Bruce> compatible = "fsl-i2c";
Bruce> reg = <3000 100>;
Bruce> interrupts = <e 8>;
Bruce> interrupt-parent = < &ipic >;
Bruce> dfsrr;
You need to add #address/size-cells to the I2C node, E.G.:
+ #address-cells = <1>;
+ #size-cells = <0>;
Bruce> rtc@54 {
Bruce> device_type = "rtc";
Bruce> something;
Bruce> something;
Bruce> something;
Bruce> }
Bruce> }
Bruce> <snip>
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
(git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git) or
apply the following patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042896.html
As it isn't in mainline yet.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] Don't build arch/powerpc/sysdev/dcr.c for ARCH=ppc kernels
From: Benjamin Herrenschmidt @ 2007-10-04 11:08 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1191495405.3647.3.camel@localhost.localdomain>
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 ?
Ben.
^ permalink raw reply
* Re: [PATCH] Don't build arch/powerpc/sysdev/dcr.c for ARCH=ppc kernels
From: Josh Boyer @ 2007-10-04 10:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071004044911.30154.23109.stgit@trillian.cg.shawcable.net>
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.
josh
^ permalink raw reply
* Re: Device tree and external RTC
From: Guennadi Liakhovetski @ 2007-10-04 9:29 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OF5A3A8901.AAC62E29-ON88257369.007F3E0B-88257369.007FC5D0@selinc.com>
On Wed, 3 Oct 2007 Bruce_Leonard@selinc.com wrote:
> I'm seriously confused by how things are supposed to work now with device
> trees on the PowerPC arch. I'm bringing up our custom HW which is bassed
> on the mpc8347e, with an m41t00 RTC hanging off the i2c bus, U-boot is
> 1.2.0, kernel is 2.6.22. My problem is I can't get the kernel to access
> the RTC. It works fine in U-boot, but nothing in the kernel.
>
> Where I get confused is I'm not sure if this is something that the device
> tree is supposed to be telling the kernel about or if it's something that
> the kernel should probe for.
i2c probing is not perfectly reliable, so, yes, you have to tell the i2c
subsystem what i2c devices you have. There are several possibilities to do
this currently in the kernel, one of which is using the device-tree, which
is also the way I personally prefer:-)
> I've turned on everything in Kconfig I can
> find for I2C and RTC. Here's what I think are the relavant parts of
> .config:
Let's see
...
> CONFIG_I2C_BOARDINFO=y
This is good.
> #
> # I2C Algorithms
> #
> CONFIG_I2C_ALGOBIT=y
> CONFIG_I2C_ALGOPCF=y
> CONFIG_I2C_ALGOPCA=y
You don't need any of these.
> #
> # I2C Hardware Bus support
> #
> CONFIG_I2C_ALI1535=y
> # CONFIG_I2C_ALI1563 is not set
> CONFIG_I2C_ALI15X3=y
> CONFIG_I2C_AMD756=y
> # CONFIG_I2C_AMD756_S4882 is not set
> CONFIG_I2C_AMD8111=y
> CONFIG_I2C_I801=y
> CONFIG_I2C_I810=y
> CONFIG_I2C_PIIX4=y
> CONFIG_I2C_MPC=y
You only have one i2c bus, I guess, and it is the one above: "I2C_MPC".
> CONFIG_I2C_NFORCE2=y
> # CONFIG_I2C_OCORES is not set
> CONFIG_I2C_PARPORT_LIGHT=y
> CONFIG_I2C_PROSAVAGE=y
> # CONFIG_I2C_SAVAGE4 is not set
> CONFIG_I2C_SIMTEC=y
> CONFIG_I2C_SIS5595=y
> CONFIG_I2C_SIS630=y
> CONFIG_I2C_SIS96X=y
> # CONFIG_I2C_STUB is not set
> # CONFIG_I2C_VIA is not set
> CONFIG_I2C_VIAPRO=y
> CONFIG_I2C_VOODOO3=y
>
> #
> # Miscellaneous I2C Chip support
> #
> # CONFIG_SENSORS_DS1337 is not set
> # CONFIG_SENSORS_DS1374 is not set
> # CONFIG_SENSORS_EEPROM is not set
> # CONFIG_SENSORS_PCF8574 is not set
> # CONFIG_SENSORS_PCA9539 is not set
> # CONFIG_SENSORS_PCF8591 is not set
> CONFIG_SENSORS_M41T00=y
It shall not hurt, but do you really have this one?
> # CONFIG_SENSORS_MAX6875 is not set
> CONFIG_I2C_DEBUG_CORE=y
> CONFIG_I2C_DEBUG_ALGO=y
> CONFIG_I2C_DEBUG_BUS=y
> CONFIG_I2C_DEBUG_CHIP=y
>
> <snip>
>
> #
> # Real Time Clock
> #
> CONFIG_RTC_LIB=y
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_HCTOSYS=y
> CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
> CONFIG_RTC_DEBUG=y
>
> #
> # RTC interfaces
> #
> CONFIG_RTC_INTF_SYSFS=y
> CONFIG_RTC_INTF_PROC=y
> CONFIG_RTC_INTF_DEV=y
> # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
> # CONFIG_RTC_DRV_TEST is not set
>
> #
> # I2C RTC drivers
> #
> CONFIG_RTC_DRV_DS1307=y
Ok, so, this is your rtc.
> However, I get the following error when I run hwclock --debug:
> hwclock from util-linux-2.12r
> hwclock: Open of /dev/rtc failed, errno=19: No such device. (note that
> the device is present with a major of 10 and a minor of 135)
> No usable clock interface found.
> Cannot access the Hardware Clock via any known method.
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
$ ls -l /dev/rtc*
lrwxrwxrwx 1 root root 4 Oct 4 10:44 /dev/rtc -> rtc0
crw-rw---- 1 root root 254, 0 Oct 4 10:44 /dev/rtc0
> 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.
> I've searched through all the device tree files that come with the kernel
> and I can't find any that explicitly show an external device as a child
> node to a SoC I2C controller but it sure seems to me that the purpose of
> the device tree is to describe to the kernel all the hardware in the
> system. Therefore it seems to me that there should be something like the
> following in the device tree:
>
> <snip>
> i2c@3000 {
> device_type = "i2c";
> compatible = "fsl-i2c";
> reg = <3000 100>;
> interrupts = <e 8>;
> interrupt-parent = < &ipic >;
> dfsrr;
>
> rtc@54 {
> device_type = "rtc";
> something;
> something;
> something;
> }
> }
> <snip>
Yes, this is exactly what you need, if you don't want to hard code your
rtc in the kernel board-specific code. I'm gessing, examples you were
looking at are in arch/powerpc/boot/dts/kuroboxH[DG].dts. For this to work
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.
Having applied the above patch and booted with the new kernel and
device-tree, after "cd /proc/device-tree" and calling lsprop you should
see something like
soc10x/i2c@80003000:
name "i2c"
interrupt-parent 00000001
interrupts 00000005 00000002
reg 80003000 00001000
compatible "fsl-i2c"
device_type "i2c"
#size-cells 00000000
#address-cells 00000001
soc10x/i2c@80003000/rtc@32:
name "rtc"
reg 00000032 (50)
compatible "ricoh,rs5c372a"
device_type "rtc"
Then you should have a directory like
/sys/devices/platform/fsl-i2c.0/i2c-adapter/i2c-0/0-0032
with a link in it like
lrwxrwxrwx 1 root root 0 Oct 4 11:00 driver -> ../../../../../../bus/i2c/drivers/rtc-rs5c372
dmesg should report something like
rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0
and
rtc-rs5c372 0-0032: setting the system clock to 2007-10-04 08:44:26 (1191487466)
Don't know what other messages ds1307 prints out.
> Okay, I figured out that I was indeed reading the clock (should have been
> using date command rather than hwclock command), so sorry for the noise.
> So what is is that hwclock is trying to do that it's unhappy about?
No, date is just giving you the system time, set either from rtc, or from
an ntp server, or to 1.1.1970 on startup.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH 4/4] edac: Add Cell memory controller
From: Benjamin Herrenschmidt @ 2007-10-04 7:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, bluesmoke-devel,
cbe-oss-dev
In-Reply-To: <20071004170047.30883e02.sfr@canb.auug.org.au>
On Thu, 2007-10-04 at 17:00 +1000, Stephen Rothwell wrote:
> On Thu, 04 Oct 2007 15:40:44 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > +++ linux-work/drivers/edac/cell-edac.c 2007-10-04 15:34:46.000000000 +1000
> > @@ -0,0 +1,258 @@
> > +#include <linux/module.h>
> > +#include <linux/init.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/stop_machine.h>
> > +#include <asm/io.h>
> > +#include <asm/machdep.h>
> > +#include <asm/cell-regs.h>
>
> Since you use the of_ accessors, you should include linux/of.h
Looks like it gets pulled in by somebody on my behalf, I suppose I can
respin the patch though or just send a corrective add-on (I prefer the
later as I have to go home now :-)
Ben.
^ 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