* [PATCH v3] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-07 19:13 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, miltonm
In-Reply-To: <20070907092143.GB32102@lixom.net>
Some versions of PWRficient 1682M have an interrupt controller in which
the first register in each pair for interrupt sources doesn't always
read with the right polarity/sense values.
To work around this, keep a software copy of the register instead. Since
it's not modified from the mpic itself, it's a feasible solution. Still,
keep it under a config option to avoid wasting memory on other platforms.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 041df77..22a8fa9 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -137,6 +137,16 @@ config MPIC_U3_HT_IRQS
depends on PPC_MAPLE
default y
+config MPIC_BROKEN_REGREAD
+ bool
+ depends on MPIC
+ help
+ This option enables a MPIC driver workaround for some chips
+ that have a bug that causes some interrupt source information
+ to not read back properly. It is safe to use on other chips as
+ well, but enabling it uses about 8KB of memory to keep copies
+ of the register contents in software.
+
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 95cd90f..117d90a 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,6 +5,7 @@ config PPC_PASEMI
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
+ select MPIC_BROKEN_REGREAD
help
This option enables support for PA Semi's PWRficient line
of SoC processors, including PA6T-1682M
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 74c64c0..c0fe063 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -228,8 +228,13 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, unsigne
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- return _mpic_read(mpic->reg_type, &mpic->isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ return mpic->isu_reg0_shadow[idx];
+ else
+#endif
+ return _mpic_read(mpic->reg_type, &mpic->isus[isu],
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -240,6 +245,11 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
_mpic_write(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
+
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ mpic->isu_reg0_shadow[idx] = value;
+#endif
}
#define mpic_read(b,r) _mpic_read(mpic->reg_type,&(b),(r))
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 262db6b..c877fa7 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -309,6 +309,10 @@ struct mpic
unsigned long *hwirq_bitmap;
#endif
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ u32 isu_reg0_shadow[MPIC_MAX_IRQ_SOURCES];
+#endif
+
/* link */
struct mpic *next;
^ permalink raw reply related
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-07 19:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1189173891.28781.162.camel@johannes.berg>
On Fri, Sep 07, 2007 at 04:04:51PM +0200, Johannes Berg wrote:
> On Fri, 2007-09-07 at 00:44 +1000, Paul Mackerras wrote:
> > This creates a clockevent for the PowerPC decrementer and registers it
> > with the generic clock/timer system, and implements the dynamic ticks
> > (no idle HZ) option for PowerPC.
>
> I tried both patches applied and with/without CONFIG_NOHZ but my quad G5
> won't boot. Anybody else have more luck?
Did you try with the two changes I suggested? Patch below.
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 1353d73..c863b07 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -554,6 +554,7 @@ void timer_interrupt(struct pt_regs * regs)
u64 tb_next_jiffy;
struct clock_event_device *evt = &per_cpu(decrementers, cpu);
+ set_dec(DECREMENTER_MAX);
#ifdef CONFIG_PPC32
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
@@ -931,8 +932,6 @@ void __init time_init(void)
/* Register the clocksource */
clocksource_init();
-
- set_dec(DECREMENTER_MAX);
}
^ permalink raw reply related
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Johannes Berg @ 2007-09-07 19:26 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070907191616.GB6765@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Fri, 2007-09-07 at 14:16 -0500, Olof Johansson wrote:
> On Fri, Sep 07, 2007 at 04:04:51PM +0200, Johannes Berg wrote:
> > On Fri, 2007-09-07 at 00:44 +1000, Paul Mackerras wrote:
> > > This creates a clockevent for the PowerPC decrementer and registers it
> > > with the generic clock/timer system, and implements the dynamic ticks
> > > (no idle HZ) option for PowerPC.
> >
> > I tried both patches applied and with/without CONFIG_NOHZ but my quad G5
> > won't boot. Anybody else have more luck?
>
> Did you try with the two changes I suggested? Patch below.
No, I hadn't dug through mail yet. I'm away from the machine, will give
it a try early next week. Thanks!
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-07 20:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1189193188.28781.193.camel@johannes.berg>
On Fri, Sep 07, 2007 at 09:26:28PM +0200, Johannes Berg wrote:
> On Fri, 2007-09-07 at 14:16 -0500, Olof Johansson wrote:
> > On Fri, Sep 07, 2007 at 04:04:51PM +0200, Johannes Berg wrote:
> > > On Fri, 2007-09-07 at 00:44 +1000, Paul Mackerras wrote:
> > > > This creates a clockevent for the PowerPC decrementer and registers it
> > > > with the generic clock/timer system, and implements the dynamic ticks
> > > > (no idle HZ) option for PowerPC.
> > >
> > > I tried both patches applied and with/without CONFIG_NOHZ but my quad G5
> > > won't boot. Anybody else have more luck?
> >
> > Did you try with the two changes I suggested? Patch below.
>
> No, I hadn't dug through mail yet. I'm away from the machine, will give
> it a try early next week. Thanks!
I just verified, and with those fixes I can boot a quad G5 here with:
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
-Olof
^ permalink raw reply
* Re: [PATCH 3/5] Add DMA of-node to mpc8641hpcn board dts
From: Scott Wood @ 2007-09-07 21:10 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11891624391565-git-send-email-wei.zhang@freescale.com>
Zhang Wei wrote:
> This patch adds DMA of-node to MPC8641HPCN board dts.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 40 ++++++++++++++++++++++++++++++++
> 1 files changed, 40 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 5d82709..e0175a4 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -433,5 +433,45 @@
> device_type = "open-pic";
> big-endian;
> };
> +
> + dma@21000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,dma";
> + reg = <21300 4>;
> + ranges = <0 21100 200>;
> + dma-channel@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
The channels aren't buses; only the parent dma node needs #address-cells
and #size-cells.
-Scott
^ permalink raw reply
* RE: random panic and freezes on mpc8349 itx
From: Benedict, Michael @ 2007-09-07 21:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200709071405.06500.nschichan@freebox.fr>
What version of U-boot are you using? Could it be RAM initialization?
There was a RAM initialization bug in the ITX for u-boot git sources
until April 2007.
Good luck,
Michael
linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.org wrote:
> Hi,
>=20
> I am currently working with an MPC8349ITX board and I have
> some trouble with
> the kernel as soon as it reaches userland.
>=20
> If I boot the kernel with all the memory (256MB) available (no
> mem=3D... on the command line), I get random freezes or random kernel
> panics.=20
> Some times it
> won't even run init. Some times it will panic badly if I try
> to put some
> pressure to the system (stress --cpu 256). Some times it will hang
> immediately after logging in, ...
>=20
> If I boot the kernel with mem=3D64M, these freeze and random
> panic disapear and
> I am able to run the stress program without any problems.
>=20
> I have had this strange behaviour on both kernel 2.6.20 and
> 2.6.22 with
> mpc834x_itx_defconfig (both from kernel.org) (ARCH=3Dpowerpc).
>=20
> I am inclined to say that it is not a broken RAM chip problem because
> if I use a 2.6.17 from kernel.org with all the RAM available
> (ARCH=3Dppc) configured with mpc834x_sys_defconfig (there was no
> defconfig for the=20
> itx board on this
> version) everything runs fine and I am able to run the stress program
> without any problems.
>=20
> The panic does not happen very often, 90% of the time, the
> board hangs and
> stops responding to ping. When a panic do happen it is almost always
> in a different place.
>=20
> Does any of you have met this problem before ? If you have
> any clues about
> what is hapenning I'd be glad to hear about it :)
>=20
> Thank you for your attention,
>=20
> Regards,
^ permalink raw reply
* Re: [patch v2] Cell: Wrap master run control bit
From: Arnd Bergmann @ 2007-09-07 22:46 UTC (permalink / raw)
To: Geoff Levand; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras, jk
In-Reply-To: <46E0A8C8.9030505@am.sony.com>
On Friday 07 September 2007, Geoff Levand wrote:
> v2:
> o Added comments about unmapping PS pages when disabled.
What about my comment about making the new functions return void?
Arnd <><
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Arnd Bergmann @ 2007-09-07 23:01 UTC (permalink / raw)
To: Geoff Levand; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <46E0A9E8.3050701@am.sony.com>
On Friday 07 September 2007, Geoff Levand wrote:
> >> @@ -178,6 +179,8 @@ struct spu_management_ops {
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*enumerate_spus)(int (*fn)(void *da=
ta));
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*create_spu)(struct spu *spu, void =
*data);
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*destroy_spu)(struct spu *spu);
> >> +=C2=A0=C2=A0=C2=A0=C2=A0int (*enable_spu)(struct spu_context *ctx);
> >> +=C2=A0=C2=A0=C2=A0=C2=A0int (*disable_spu)(struct spu_context *ctx);
> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*init_affinity)(void);
> >> =C2=A0};
> >=20
> > Also, I think you should make the return type of the callback
> > 'void' since the result is not used anywhere.
>=20
> Noguchi-san was hesitant to do this. =C2=A0I also thought lets leave it
> as is until we consider the unmapping support, as maybe a return
> value might make sense.=20
Sorry for having to reply twice on this. I first only got the
other mail because of a mail server hickup.
In general, I think we should follow the rule of keeping the interfaces
as simple as possible. If nobody is using the return value here,
we probably won't need it in the future either. And if we do, we
can still change it.
Arnd <><
^ permalink raw reply
* Re: [PATCH 01/10] cpm2: Infrastructure code cleanup.
From: Arnd Bergmann @ 2007-09-08 14:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070905192841.GA32441@ld0162-tx32.am.freescale.net>
On Wednesday 05 September 2007, Scott Wood wrote:
>=20
> =A0void *cpm_dpram_addr(unsigned long offset)
> =A0{
> -=A0=A0=A0=A0=A0=A0=A0return (void *)(im_dprambase + offset);
> +=A0=A0=A0=A0=A0=A0=A0return (void __force *)(im_dprambase + offset);
> =A0}
> =A0EXPORT_SYMBOL(cpm_dpram_addr);
This does not look like a legitimate use of __force. I think it's better
to leave the warning in place for cases like this, so that someone else
can clean up the remaining users of this.
In this particular case, it seems that the function should either
be removed or changed to return an __iomem pointer so you get the
warning in the mac-fcc driver using it.
The rest of your patch looks great.
Arnd <><
^ permalink raw reply
* Re: [PATCH 01/10] cpm2: Infrastructure code cleanup.
From: Scott Wood @ 2007-09-08 16:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200709081648.54960.arnd@arndb.de>
On Sat, Sep 08, 2007 at 04:48:53PM +0200, Arnd Bergmann wrote:
> On Wednesday 05 September 2007, Scott Wood wrote:
> >
> > void *cpm_dpram_addr(unsigned long offset)
> > {
> > - return (void *)(im_dprambase + offset);
> > + return (void __force *)(im_dprambase + offset);
> > }
> > EXPORT_SYMBOL(cpm_dpram_addr);
>
> This does not look like a legitimate use of __force. I think it's better
> to leave the warning in place for cases like this, so that someone else
> can clean up the remaining users of this.
>
> In this particular case, it seems that the function should either
> be removed or changed to return an __iomem pointer so you get the
> warning in the mac-fcc driver using it.
Yeah, there's a fair amount of crud in the CPM API...
I wanted to avoid changing it until arch/ppc is gone (or at least until
CPM platforms are officially no longer supported in it) so I don't have
to worry about breaking it. I'm OK with leaving the warning there as a
reminder.
-Scott
^ permalink raw reply
* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Paul Mackerras @ 2007-09-09 9:55 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20070907082143.GA27058@iram.es>
Gabriel Paubert writes:
> The solution now used by i386/x86-64/sparc64 is
> CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
> to use something similar, but the generic code has some
Yes. I'll turn on CONFIG_GENERIC_CMOS_UPDATE. Do you think it needs
to be a config option that can be turned on and off in the kernel
config, or should it just be always on as on x86[-64]?
> problems (it assumes that you have to set the clock
> on a half-second, which is not the case of the RTC on
> my boards to start with).
Let's get the generic code fixed to do what we need then. Care to
send a patch?
Paul.
^ permalink raw reply
* ML403- XUPV2PRO : Change in URL!
From: Ameet Patil @ 2007-09-09 13:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
JYFI, The following URL which provided my Linux patches for the
ML403/404 boards:
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/
has been changed to
http://www.cs.york.ac.uk/rtslab/demos/xupv2pro/
cheers,
-Ameet
^ permalink raw reply
* Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
From: Dan Williams @ 2007-09-09 17:53 UTC (permalink / raw)
To: Zhang Wei; +Cc: shannon.nelson, linux-kernel, linuxppc-dev, paulus
In-Reply-To: <11891624582950-git-send-email-wei.zhang@freescale.com>
On 9/7/07, Zhang Wei <wei.zhang@freescale.com> wrote:
> The driver implements DMA engine API for Freescale MPC85xx DMA
> controller, which could be used for MEM<-->MEM, IO_ADDR<-->MEM
> and IO_ADDR<-->IO_ADDR data transfer.
> The driver supports the Basic mode of Freescale MPC85xx DMA controller.
> The MPC85xx processors supported include MPC8540/60, MPC8555, MPC8548,
> MPC8641 and so on.
> The support for MPC83xx(MPC8349, MPC8360) is experimental.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
> ---
Greetings,
Please copy me on any updates to this driver, drivers/dma, or crypto/async_tx.
Below are a few review comments...
Regards,
Dan
> +/**
> + * fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
> + *
> + * Return - The descriptor allocated. NULL for failed.
> + */
> +static struct fsl_desc_sw *fsl_dma_alloc_descriptor(
> + struct fsl_dma_chan *fsl_chan,
> + gfp_t flags)
> +{
> + dma_addr_t pdesc;
> + struct fsl_desc_sw *desc_sw;
> +
> + desc_sw = dma_pool_alloc(fsl_chan->desc_pool, flags, &pdesc);
> + if (desc_sw) {
> + memset(desc_sw, 0, sizeof(struct fsl_desc_sw));
> + dma_async_tx_descriptor_init(&desc_sw->async_tx,
> + &fsl_chan->common);
> + desc_sw->async_tx.tx_set_src = fsl_dma_set_src;
> + desc_sw->async_tx.tx_set_dest = fsl_dma_set_dest;
> + desc_sw->async_tx.tx_submit = fsl_dma_tx_submit;
> + INIT_LIST_HEAD(&desc_sw->async_tx.tx_list);
> + desc_sw->async_tx.phys = pdesc;
> + }
> +
> + return desc_sw;
> +}
I suggest pre-allocating the descriptors:
1/ It alleviates the need to initialize these async_tx fields which never change
2/ The GFP_ATOMIC allocation can be removed.
iop-adma gets by with one PAGE_SIZE buffer (128 descriptors).
[..]
> +static irqreturn_t fsl_dma_chan_do_interrupt(int irq, void *data)
> +{
> + struct fsl_dma_chan *fsl_chan = (struct fsl_dma_chan *)data;
> + dma_addr_t stat;
> +
> + stat = get_sr(fsl_chan);
> + dev_dbg(fsl_chan->device->dev, "event: channel %d, stat = 0x%x\n",
> + fsl_chan->id, stat);
> + set_sr(fsl_chan, stat); /* Clear the event register */
> +
> + stat &= ~(FSL_DMA_SR_CB | FSL_DMA_SR_CH);
> + if (!stat)
> + return IRQ_NONE;
> +
> + /* If the link descriptor segment transfer finishes,
> + * we will recycle the used descriptor.
> + */
> + if (stat & FSL_DMA_SR_EOSI) {
> + dev_dbg(fsl_chan->device->dev, "event: End-of-segments INT\n");
> + dev_dbg(fsl_chan->device->dev, "event: clndar 0x%016llx, "
> + "nlndar 0x%016llx\n", (u64)get_cdar(fsl_chan),
> + (u64)get_ndar(fsl_chan));
> + stat &= ~FSL_DMA_SR_EOSI;
> + fsl_chan_ld_cleanup(fsl_chan, 1);
> + }
> +
> + /* If it current transfer is the end-of-transfer,
> + * we should clear the Channel Start bit for
> + * prepare next transfer.
> + */
> + if (stat & (FSL_DMA_SR_EOLNI | FSL_DMA_SR_EOCDI)) {
> + dev_dbg(fsl_chan->device->dev, "event: End-of-link INT\n");
> + stat &= ~FSL_DMA_SR_EOLNI;
> + fsl_chan_xfer_ld_queue(fsl_chan);
> + }
> +
> + if (stat)
> + dev_dbg(fsl_chan->device->dev, "event: unhandled sr 0x%02x\n",
> + stat);
> +
> + dev_dbg(fsl_chan->device->dev, "event: Exit\n");
> + tasklet_hi_schedule(&dma_tasklet);
> + return IRQ_HANDLED;
> +}
This driver implements locking and callbacks inconsistently with how
it is done in ioatdma and iop-adma. The big changes are that all
locks have been upgraded from 'spin_lock_bh' to 'spin_lock_irqsave',
and async_tx callbacks can happen in irq context. I would like to
keep everything in bottom-half context to lessen the restrictions on
what async_tx clients can perform in their callback routines. What
are the implications of moving 'fsl_chan_ld_cleanup' to the tasklet
and changing the 'tasklet_hi_schedule' to 'tasklet_schedule'?
[..]
> +static struct dma_chan *of_find_dma_chan_by_phandle(phandle phandle)
> +{
> + struct device_node *np;
> + struct dma_chan *chan;
> + struct fsl_dma_device *fdev;
> +
> + np = of_find_node_by_phandle(phandle);
> + if (!np || !of_device_is_compatible(np->parent, "fsl,dma"))
> + return NULL;
> +
> + fdev = dev_get_drvdata(&of_find_device_by_node(np->parent)->dev);
> +
> + list_for_each_entry(chan, &fdev->common.channels, device_node)
> + if (to_of_device(to_fsl_chan(chan)->chan_dev)->node == np)
> + return chan;
> + return NULL;
> +}
> +EXPORT_SYMBOL(of_find_dma_chan_by_phandle);
This routine implies that there is a piece of code somewhere that
wants to select which channels it can use. A similar effect can be
achieved by registering a dma_client with the dmaengine interface
('dma_async_client_register'). Then when the client code makes a call
to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
for each channel in the system. It will also be asynchronously
notified of channels entering and leaving the system. The goal is to
share a common infrastructure for channel management.
> +
> +static int __devinit of_fsl_dma_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + int err;
> + unsigned int irq;
> + struct fsl_dma_device *fdev;
> +
> + fdev = kzalloc(sizeof(struct fsl_dma_device), GFP_KERNEL);
> + if (!fdev) {
> + dev_err(&dev->dev, "No enough memory for 'priv'\n");
> + err = -ENOMEM;
> + goto err;
> + }
> + fdev->dev = &dev->dev;
> + INIT_LIST_HEAD(&fdev->common.channels);
> +
> + /* get DMA controller register base */
> + err = of_address_to_resource(dev->node, 0, &fdev->reg);
> + if (err) {
> + dev_err(&dev->dev, "Can't get %s property 'reg'\n",
> + dev->node->full_name);
> + goto err;
> + }
> +
> + dev_info(&dev->dev, "Probe the Freescale DMA driver for %s "
> + "controller at 0x%08x...\n",
> + match->compatible, fdev->reg.start);
> + fdev->reg_base = ioremap(fdev->reg.start, fdev->reg.end
> + - fdev->reg.start + 1);
> +
> + dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> + fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
> + fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
> + fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
> + fdev->common.device_is_tx_complete = fsl_dma_is_complete;
> + fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
> + fdev->common.device_dependency_added = fsl_dma_dependency_added;
> + fdev->common.dev = &dev->dev;
> +
If this driver adds:
dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
It will be able to take advantage of interrupt triggered callbacks in
async_tx. Without these changes async_tx will poll for the completion
of each transaction.
[..]
^ permalink raw reply
* [2.6 patch] powerpc: proper defconfig for crosscompiles
From: Adrian Bunk @ 2007-09-09 18:21 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Sam Ravnborg, linux-kernel
The trick for finding the right defconfig is neat, but you forgot to
provide an i686_defconfig. ;-)
More seriously, cross compiling the defconfig is often useful, e.g. for
testing the compilation of patches that touch multiple architectures,
and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is
non-empty.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
0b0e6e0e3a16f48348cb9c40ef1bb55ef42f92eb
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 2065138..a39bac4 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -35,7 +35,11 @@ endif
export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY
+ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
+else
+KBUILD_DEFCONFIG := g5_defconfig
+endif
ifeq ($(CONFIG_PPC64),y)
OLDARCH := ppc64
^ permalink raw reply related
* Re: [2.6 patch] powerpc: proper defconfig for crosscompiles
From: Sam Ravnborg @ 2007-09-09 18:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20070909182117.GJ3563@stusta.de>
On Sun, Sep 09, 2007 at 08:21:17PM +0200, Adrian Bunk wrote:
> The trick for finding the right defconfig is neat, but you forgot to
> provide an i686_defconfig. ;-)
>
> More seriously, cross compiling the defconfig is often useful, e.g. for
> testing the compilation of patches that touch multiple architectures,
> and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is
> non-empty.
Thanks - much appreciated.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
^ permalink raw reply
* Re: [2.6 patch] powerpc: proper defconfig for crosscompiles
From: Olof Johansson @ 2007-09-09 20:40 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, paulus, linux-kernel, Sam Ravnborg
In-Reply-To: <20070909182117.GJ3563@stusta.de>
On Sun, Sep 09, 2007 at 08:21:17PM +0200, Adrian Bunk wrote:
> The trick for finding the right defconfig is neat, but you forgot to
> provide an i686_defconfig. ;-)
>
> More seriously, cross compiling the defconfig is often useful, e.g. for
> testing the compilation of patches that touch multiple architectures,
> and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is
> non-empty.
You should probably use ppc64_defconfig instead, since it's the "superset"
config that will compile a multiplatform kernel.
-Olof
^ permalink raw reply
* Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
From: Timur Tabi @ 2007-09-09 21:48 UTC (permalink / raw)
To: Dan Williams; +Cc: linuxppc-dev, shannon.nelson, paulus, linux-kernel
In-Reply-To: <e9c3a7c20709091053u607e710ay1eb76c53312706ea@mail.gmail.com>
Dan Williams wrote:
> This routine implies that there is a piece of code somewhere that
> wants to select which channels it can use. A similar effect can be
> achieved by registering a dma_client with the dmaengine interface
> ('dma_async_client_register'). Then when the client code makes a call
> to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
> for each channel in the system. It will also be asynchronously
> notified of channels entering and leaving the system. The goal is to
> share a common infrastructure for channel management.
Are you familiar with the "flat device tree" used for PowerPC systems? The
"piece of code somewhere" is the device tree subsystem that parses the device
tree, which is compiled from the .dts files in arch/powerpc/boot/dts.
The FDT is how PowerPC systems specify hardware configuration. In the case of
85xx, the FDT contains entries for each DMA device (typically 2), and the
entries contain sub-entries for each DMA channel as well as the address of the
register sets for each channel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
From: Dan Williams @ 2007-09-09 22:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, shannon.nelson, paulus, linux-kernel
In-Reply-To: <46E46A3F.2050708@freescale.com>
On 9/9/07, Timur Tabi <timur@freescale.com> wrote:
> Dan Williams wrote:
>
> > This routine implies that there is a piece of code somewhere that
> > wants to select which channels it can use. A similar effect can be
> > achieved by registering a dma_client with the dmaengine interface
> > ('dma_async_client_register'). Then when the client code makes a call
> > to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
> > for each channel in the system. It will also be asynchronously
> > notified of channels entering and leaving the system. The goal is to
> > share a common infrastructure for channel management.
>
> Are you familiar with the "flat device tree" used for PowerPC systems? The
> "piece of code somewhere" is the device tree subsystem that parses the device
> tree, which is compiled from the .dts files in arch/powerpc/boot/dts.
>
> The FDT is how PowerPC systems specify hardware configuration. In the case of
> 85xx, the FDT contains entries for each DMA device (typically 2), and the
> entries contain sub-entries for each DMA channel as well as the address of the
> register sets for each channel.
>
Ahh, ok then this code is replacing what would normally be handled by
the PCI bus enumeration code, or the platform device registrations for
iop-adma in arch/arm/mach-iop13xx. Sorry for the noise with this
comment.
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> -
Thanks,
Dan
^ permalink raw reply
* Re: Document and implement an improved flash device binding for powerpc (v5)
From: David Gibson @ 2007-09-10 3:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <2fcd14e175d5a215cd8d602ac74fce21@kernel.crashing.org>
On Fri, Sep 07, 2007 at 04:25:10PM +0200, Segher Boessenkool wrote:
> > This patch replaces the binding for flash chips in
> > booting-without-of.txt with an clarified and improved version. It
> > also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
> > Finally it revises the Ebony device tree source to use the new binding
> > as an example.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> Thanks for doing this work David!
>
>
> > + /* First look for RedBoot table or partitions on the command
> > + * line, these take precedence over device tree information */
>
> Any specific reason you chose this order? Just curious...
Well, RedBoot on the grounds that an on-device partition table, if
present, should take precedence over platform defaults. And that
overriding partition information on the command line should, well,
override...
> > + .data = (void *)"jedec_probe",
>
> Hrm, this cast is only getting rid of the const-ness of the
> string literal -- maybe .data should be declared const, or
> does the majority of users want it writable?
Not sure. But this is defined in the core anyway, and I didn't really
want to bother with delving into that at this time.
--
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: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: David Gibson @ 2007-09-10 3:25 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <3b29878a7d3d1b14f84b5d3b182cdb98@kernel.crashing.org>
On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher Boessenkool wrote:
> > + l) Freescale DMA
>
> > + - compatible : Should be "fsl,dma".
>
> Please choose some more specific name. "fsl,mpc8540-dma" would
> be a reasonable choice perhaps.
More precisely, the compatible property should always have an specific
entry based on the exact chip the DMA engine resides in, as well as a
more general entry for any fsl dma engine of this type.
--
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: [PATCH 2/5] Add Freescale DMA engine driver maintainer.
From: David Gibson @ 2007-09-10 3:27 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11891624382764-git-send-email-wei.zhang@freescale.com>
On Fri, Sep 07, 2007 at 06:53:53PM +0800, Zhang Wei wrote:
> This patch adds Freescale DMA engine driver maintainer.
This is meaningless without the actual driver, so it shouldn't be a
separate patch. Fold it into the patch that actually adds the driver
support.
--
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: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-09-09 23:29 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev, David Gibson
In-Reply-To: <20070907005803.GJ26079@localhost.localdomain>
On Fri Sep 7 10:58:03 EST 2007, David Gibson wrote:
>> On Wed, Sep 05, 2007 at 02:21:16PM -0500, Scott Wood wrote:
>> This target produces a flat binary rather than an ELF file,
>> fixes the entry point at the beginning of the image, and takes
>> a complete device tree with no fixups needed.
>>
>> The device tree must have labels on /#address-cells, the timebase
>> frequency, and the memory size.
>
> Hrm... the actual contents of this patch are less about producing an
> unheadered binary image than they are about introducing the "raw"
> platform. I don't mind the idea of a "raw" platform (although I'm not
> sure I like that name for it), but the patch comment needs work.
Plus, its not quite as generic as you think.
>> Signed-off-by: Scott Wood <scottwood at freescale.com>
>> ---
>> arch/powerpc/Kconfig | 12 +++++++++++
>> arch/powerpc/boot/Makefile | 4 ++-
>> arch/powerpc/boot/fixed-head.S | 4 +++
>> arch/powerpc/boot/io.h | 7 ++++++
>> arch/powerpc/boot/raw-platform.c | 41
>> ++++++++++++++++++++++++++++++++++++++
>> arch/powerpc/boot/wrapper | 21 ++++++++++++++----
>> 6 files changed, 83 insertions(+), 6 deletions(-)
>> create mode 100644 arch/powerpc/boot/fixed-head.S
>> create mode 100644 arch/powerpc/boot/raw-platform.c
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 00099ef..251d0c3 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -358,6 +358,18 @@ config WANT_DEVICE_TREE
>> bool
>> default n
>>
>> +config BUILD_RAW_IMAGE
>> + bool "Build firmware-independent image"
>> + select WANT_DEVICE_TREE
>> + help
>> + If this is enabled, a firmware independent "raw" image will
>> be
>> + built, as zImage.raw. This requires a completely filled-in
>> + device tree, with the following labels:
>> +
>> + mem_size_cells: on /#address-cells
>> + memsize: on the size portion of /memory/reg
>> + timebase: on the boot CPU's timebase property
>>
You need these labels on (in) the data not on the property struct ...
(one can label either today, but only properties in the not to distant
past).
>> +
>> config DEVICE_TREE
>> string "Static device tree source file"
>> depends on WANT_DEVICE_TREE
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index 02f0fe0..2a6a4c6 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -48,7 +48,8 @@ src-wlib := string.S crt0.S stdio.c main.c
>> flatdevtree.c flatdevtree_misc.c \
>> cpm-serial.c stdlib.c planetcore.c
>> src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
>> cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
>> - ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
>> cuboot-8xx.c cuboot-pq2.c
>> + ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c \
>> + cuboot-8xx.c cuboot-pq2.c fixed-head.S raw-platform.c
>> src-boot := $(src-wlib) $(src-plat) empty.c
>>
>> src-boot := $(addprefix $(obj)/, $(src-boot))
>> @@ -146,6 +147,7 @@ image-$(CONFIG_PPC_83xx) +=
>> cuImage.83xx
>> image-$(CONFIG_PPC_85xx) += cuImage.85xx
>> image-$(CONFIG_EBONY) += treeImage.ebony
>> cuImage.ebony
>> image-$(CONFIG_BAMBOO) += treeImage.bamboo
>> +image-$(CONFIG_BUILD_RAW_IMAGE) += zImage.raw
>> endif
>>
>> # For 32-bit powermacs, build the COFF and miboot images
>> diff --git a/arch/powerpc/boot/fixed-head.S
>> b/arch/powerpc/boot/fixed-head.S
>> new file mode 100644
>> index 0000000..8e14cd9
>> --- /dev/null
>> +++ b/arch/powerpc/boot/fixed-head.S
>> @@ -0,0 +1,4 @@
>> + .text
>> + .global _zimage_start
>> +_zimage_start:
>> + b _zimage_start_lib
>> diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
>> index ccaedae..ec57ec9 100644
>> --- a/arch/powerpc/boot/io.h
>> +++ b/arch/powerpc/boot/io.h
>> @@ -99,4 +99,11 @@ static inline void barrier(void)
>> asm volatile("" : : : "memory");
>> }
>>
>> +static inline void disable_irq(void)
>> +{
>> + int dummy;
>> + asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0"
>> :
>> + "=r" (dummy) : : "memory");
>> +}
This will fail (mtmsr illegal instruction) on 64 bit processors that do
not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
>> +
>> #endif /* _IO_H */
>> diff --git a/arch/powerpc/boot/raw-platform.c
>> b/arch/powerpc/boot/raw-platform.c
>> new file mode 100644
>> index 0000000..b9caeee
>> --- /dev/null
>> +++ b/arch/powerpc/boot/raw-platform.c
>> @@ -0,0 +1,41 @@
>> +/*
>> + * The "raw" platform -- for booting from a complete dtb without
>> + * any fixups.
>> + *
>> + * Author: Scott Wood <scottwood at freescale.com>
>> + *
>> + * Copyright (c) 2007 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 version 2 as
>> published
>> + * by the Free Software Foundation.
>> + */
>> +
>> +#include "ops.h"
>> +#include "types.h"
>> +#include "io.h"
>> +
>> +BSS_STACK(4096);
>> +
>> +/* These are labels in the device tree. */
>> +extern u32 memsize[2], timebase, mem_size_cells;
>> +
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long
>> r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> + u64 memsize64 = memsize[0];
>> +
>> + if (mem_size_cells == 2) {
>> + memsize64 <<= 32;
>> + memsize64 |= memsize[1];
>> + }
>> +
>> + if (sizeof(void *) == 4 && memsize64 >= 0x100000000ULL)
>> + memsize64 = 0xffffffff;
>> +
>> + disable_irq();
see above, only works on some processors.
>> + timebase_period_ns = 1000000000 / timebase;
>> + simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32,
>> 64);
>> + ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
>>
only 64 malloc slots?
So the labels are linked against to find the memory size to allocate
all above the load address to malloc ...
We can eliminate the need for the labels by calling simple_alloc_init
twice: the first time on a small bss region, read the properties, then
call it again with the full memory, and then call ft_init again. That
is the trick I used in the kexec series. When dtlib merges, we can
read the tree without malloc and avoid the extra dance.
>> + serial_console_init();
I'm not sure I consider serial_console firemware independent: our
wrapper IO macros simply do normal loads and stores, and rely on
firmware to setup either tlbs, virtural mappings, or other to make the
IO cache inhibited ...
yea, i realize it doesn't have to find a console, and it all works
without it. But this is why I pulled the call from my kexec patches.
>> +}
Just to clarify: this should go in the Kconfig help:
This platform requires
(1) device tree fully filled out, including memory size and timebase
frequency
(2) (currently) labels
(3) firmware that jumps to start of image (this is like old kernels)
(4) after its in ram (we must have writable data/bss)
(5) space below load to decompress vmlinux (no vmlinux_alloc to
fallback to malloc)
(6) all space above load address available to hold malloc region
(7) for console output (or input) from wrapper, on most cpus, some
magic setup
Except for this supplying the dt instead of looking for one passed in
r3, it is very similar to my kexec platform. That platform has a few
more features, however
(1) support for SMP with 64 bit kernel (6xx would require small patch)
(2) support for finding available space above or below, via memregions
(3) support for avoiding memroy blocks (rtas, etc)
I think that code could be tweaked to be used by both.
>> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
>> index 65f6854..a6501e9 100755
>> --- a/arch/powerpc/boot/wrapper
>> +++ b/arch/powerpc/boot/wrapper
>> @@ -30,6 +30,7 @@ dtb=
>> dts=
>> cacheit=
>> gzip=.gz
>> +binary=
>>
>> # cross-compilation prefix
>> CROSS=
>> @@ -107,10 +108,11 @@ while [ "$#" -gt 0 ]; do
>> done
>>
>> if [ -n "$dts" ]; then
>> - if [ -z "$dtb" ]; then
>> - dtb="$platform.dtb"
>> - fi
>> - dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
>> + dtasm="$object/$platform.dtb.S"
>> + dto="$object/$platform.dtb.o"
>> + echo '.section .kernel:dtb,"a"' > "$dtasm"
>> + dtc -O asm -b 0 -V 16 "$dts" >> "$dtasm" || exit 1
>> + ${CROSS}gcc "$dtasm" -c -o "$dto"
>> fi
If we are going to start calling gcc from the wrapper (even if it is on
a .S) ...
and synthesizing the input file from pieces ...
and not checking if you need -m32 or if its disallowed ...
not sanitizing preprocessor include environment ...
and if one passes dts and dtb you changed behavior ...
If we need the asm label, I'd rather add the call to dtc->asm and
asm->.o in the makefile and link it into the platform, maybe using a
raw-* rule like cuboot and treeboot, or just hardcode the output to be
dtb.o (since we only have one dts). If we want it to show up in the
.dtb instead of .text then we can use objcopy to rename the section or
do your cat of echo and dtc in a gen_ rule).
... but I think minimal alloc/peek at tree/full alloc is the way to go
for now.
>>
>> if [ -z "$kernel" ]; then
>> @@ -153,6 +155,10 @@ ps3)
>> ksection=.kernel:vmlinux.bin
>> isection=.kernel:initrd
>> ;;
>> +raw)
>> + platformo="$object/fixed-head.o $object/raw-platform.o"
>> + binary=y
>> + ;;
>> esac
>>
>> vmz="$tmpdir/`basename \"$kernel\"`.$ext"
>> @@ -216,7 +222,7 @@ fi
>>
>> if [ "$platform" != "miboot" ]; then
>> ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
>> - $platformo $tmp $object/wrapper.a
>> + $platformo $tmp $dto $object/wrapper.a
>> rm $tmp
>> fi
>>
>> @@ -295,3 +301,8 @@ ps3)
>> gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
>> ;;
>> esac
>> +
>> +if [ -n "$binary" ]; then
>> + mv "$ofile" "$ofile".elf
>> + ${CROSS}objcopy -O binary "$ofile".elf "$ofile"
>> +fi
I'm not sure how putting a binary flag test here will help other
platforms. Even those that want a .elf left behind, if they need ohter
processing they will done the move already. I'd say just make this
part of the platform case just above, although I could accept it being
moved ahead of that case.
Actually, looking at the current case, treeboot, cuboot, and ps3 all
(could) start with this rename and objcopy, so lets put it above the
final platform fixup case, and update those platforms to use this
feature (adjusting the calls to nm, dd, gzip, etc accordingly).
Bottom line: This looks like a very simple platform, but it has hidden
assumptions in its environment (mtmsr, laod in the middle of memory,
others?) and takes the wrapper script in directions i'd rather it not
go. I'd like you to look at my kexec platform series, and see if
reusing some of that code would give us a more robust "raw" image.
(even if you don't need the detached kernel, initramfs parsing, and
detached initrd; I was thinking more like memranges and the
vmlinuz_alloc. The policy about not using memory to end can be
relaxed, and find_end_of_ram made to search memory). It's on my short
list to rediff and repost those anyways.
milton
^ permalink raw reply
* linux can't read pci bus configure space of a scsi controller (lsi53c1020)
From: yuan tian @ 2007-09-10 7:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
Hi,
I have a board based on ocotea(ppc440gx) as reference.
Without PCI bus,the linux system can run successfully on
the board. when the PCI bus is used,the system hung.
on the pci bus ,there are two pci devices.one is a scsi
controller,the other is a fpga. i found the system hung at
indirect_pci.c.
indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 *val)
{
struct pci_controller *hose = bus->sysdata;
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
if (hose->set_cfg_type)
if (bus->number != hose->first_busno)
cfg_type = 1;
PCI_CFG_OUT(hose->cfg_addr,
(0x80000000 | ((bus->number - hose->bus_offset) << 16)
| (devfn << 8) | ((offset & 0xfc) | cfg_type)));
/*
* Note: the caller has already checked that offset is
* suitably aligned and that len is 1, 2 or 4.
*/
cfg_data = hose->cfg_data + (offset & 3);
switch (len) {
case 1:
*val = in_8(cfg_data);
break;
case 2:
*val = in_le16(cfg_data);
break;
default:
*val = in_le32(cfg_data);
break;
}
return PCIBIOS_SUCCESSFUL;
}
the system run to *val = in_le32(cfg_data) , the board hung.
when i get out scsi controller,the system can run successfully.
the vxworks run successfully on the board with these two pci devices.
so i think the board have no problem on the hardware.
my question is :
why can linux read fpga pci configure space and can't read scsi
controller(lsi 53c1020)?
any help will be appreciated!
Regards,
--
Tom
[-- Attachment #2: Type: text/html, Size: 2224 bytes --]
^ permalink raw reply
* Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-10 9:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
Hello all.
What are the steps to configure an MPC500B-Board to react on an IRQ (2)?
I have written a test-driver with this code-snippets, but the prozessor
hangs when loading the driver.
my __init-function looks like:
static int __init mod_init( void )
{
volatile static struct mpc52xx_intr __iomem *intr;
u32 intr_ctrl;
// ...
printk( "intmod.ko: interrupt init ");
if (request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_SHARED , "intmod",
INTMOD_IRQ_BOARD) == -EBUSY)
printk("KO\n");
else
printk("OK\n");
intr = ioremap(MPC52xx_MBAR+MPC52xx_INTR_OFFSET, MPC52xx_INTR_SIZE);
// read - modify - write
intr_ctrl = in_be32(&intr->ctrl);
intr_ctrl &= 0xfff3ffff;
intr_ctrl |= 0x00080200;
out_be32(&intr->ctrl, intr_ctrl); // ERROR!
if(intr) iounmap(intr);
// ...
}
On the Line, marked with "ERROR!" the prozessor hangs and the kernel drops
out.
TIA: Silvio
Mit freundlichen Gruessen
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: fricke@jabber.org
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Gabriel Paubert @ 2007-09-10 9:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18147.49943.182399.64990@cargo.ozlabs.ibm.com>
On Sun, Sep 09, 2007 at 07:55:35PM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > The solution now used by i386/x86-64/sparc64 is
> > CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
> > to use something similar, but the generic code has some
>
> Yes. I'll turn on CONFIG_GENERIC_CMOS_UPDATE. Do you think it needs
> to be a config option that can be turned on and off in the kernel
> config, or should it just be always on as on x86[-64]?
I believe that it can be turned on systematically. But
I only have 32 bit, non HV machines (basically 603e, 750,
and 74xx processors).
>
> > problems (it assumes that you have to set the clock
> > on a half-second, which is not the case of the RTC on
> > my boards to start with).
>
> Let's get the generic code fixed to do what we need then. Care to
> send a patch?
I'm unsure on how to implement it in a way acceptable
upstream, the problem is that the following lines:
if (abs(xtime.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2)
fail = update_persistent_clock(now);
next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec;
are hardwired to half a second. Can it be transformed into
a per arch static inline function defined in asm-${arch}?
There is also a possible problem in notify_cmos_timer, I believe
that the logic is wrong and the condition is reversed and should
be "if (!no_sync_cmos_clock)".
Otherwise the clock update timer will never be started! This boolean
really should be called disable_persistent_clock_updates or something
similar.
I'm really wondering how much testing all this code has had. The
more I look at the timekeeping code changes in the last months,
the less I understand them.
Gabriel
^ 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