* Re: [PATCH V3 2/4] AC97 driver for mpc5200
From: Grant Likely @ 2009-05-25 15:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <9e4733910905250815r4a6fa205s26531f08fe99131a@mail.gmail.com>
On Mon, May 25, 2009 at 9:15 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, May 25, 2009 at 2:16 AM, Grant Likely <grant.likely@secretlab.ca>=
wrote:
>> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> +static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned sh=
ort reg)
>>> +{
>>> + =A0 =A0 =A0 int timeout;
>>> + =A0 =A0 =A0 unsigned int val;
>>> +
>>> + =A0 =A0 =A0 spin_lock(&psc_dma->lock);
>>> +
>>> + =A0 =A0 =A0 /* Wait for it to be ready */
>>> + =A0 =A0 =A0 timeout =3D 1000;
>>> + =A0 =A0 =A0 while ((--timeout) && (in_be16(&psc_dma->psc_regs->sr_csr=
.status) &
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_SR_CMDSEND))
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>>
>> Holy unbounded latency Batman! =A0This code waits up to 10ms for a regis=
ter read!
>>
>> I hate spinning, but if it must be done; I'd like to see it small.
>> What is the worst case latency? 125us for 8000Hz bus speed? =A0If you
>> must spin; can a cpu_relax() be used instead of the udelay() while
>> watch the timebase? =A0Timur recently posted a patch which makes this
>> easier.
>>
>> http://patchwork.ozlabs.org/patch/27414/
>>
>> They *should* be appearing in Ben's -next branch soon.
>
>
> The link always runs at 12.288Mhz. Each frame is 256 bits. Worst case
> you wait for two frames, 42us. If it doesn't respond in 42us the codec
> clock is not ticking ( a recurring problem I am running into). These
> codecs may be going into a sleep mode I don't understand, but this is
> not the right place to try and wake them up. I'll lower the retry
> counts to 10 instead of 1000.
That still leaves the problem of unecessarily burning time. udelay
shouldn't be passed any value larger than 1. In fact, I think udelay
itself is too coarse grained. Plus, I'd rather see the timebase used
as the exit condition (as mentioned in previous email).
> I played around with implementing this on a kernel thread with
> interrupts. It can be done but the code is a lot more complex.
A kernel thread is definitely the wrong approach. However, if this is
non-atomic context and IRQs are available, then a wait queue can be
used. 42us is about 16k processor clocks. I'm not sure what the IRQ
and scheduling overhead is so I don't know whether it would be a net
gain or loss in performance. However, it would be a net gain in worst
case latency.
> BTW, 8000Hz is implemented by slot stuffing. The link always runs at
> 12.288Mhz. The DACs are double buffered. When a sample is transfered
> between buffers it sets a bit on the link back to the host, and the
> host sends the next sample in the appropriate slot.
ok.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V3 2/4] AC97 driver for mpc5200
From: Mark Brown @ 2009-05-25 15:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910905250815r4a6fa205s26531f08fe99131a@mail.gmail.com>
On Mon, May 25, 2009 at 11:15:34AM -0400, Jon Smirl wrote:
> The link always runs at 12.288Mhz. Each frame is 256 bits. Worst case
> you wait for two frames, 42us. If it doesn't respond in 42us the codec
Note that some embedded systems will choose to vary the AC97 link clock.
The most common case is where there's a PLL on the CODEC - the CODEC
will start up misclocked at whatever the input frequency it's got is and
then be reclocked using register writes to configure the PLL.
^ permalink raw reply
* Re: [PATCH V3 2/4] AC97 driver for mpc5200
From: Jon Smirl @ 2009-05-25 15:21 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, alsa-devel, Mark Brown
In-Reply-To: <20090525102647.GD18290@sirena.org.uk>
On Mon, May 25, 2009 at 6:26 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>> + =A0 =A0 =A0 =A0 =A0 =A0 spin_lock(&psc_dma->lock);
>> + =A0 =A0 =A0 =A0 =A0 =A0 out_be32(&psc_dma->psc_regs->ac97_slots, psc_d=
ma->slots);
>> + =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock(&psc_dma->lock);
>> + =A0 =A0 =A0 =A0 =A0 =A0 break;
>
> This locking looks wrong - I'd expect it to also cover the modification
> of psc_dma->slots? =A0Otherwise it's hard to see what it buys you.
Grant, why are you spin locking around register access?
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH V3 2/4] AC97 driver for mpc5200
From: Jon Smirl @ 2009-05-25 15:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <fa686aa40905242316j3e8b46e7mcc71dc34df209003@mail.gmail.com>
On Mon, May 25, 2009 at 2:16 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> +static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned sho=
rt reg)
>> +{
>> + =A0 =A0 =A0 int timeout;
>> + =A0 =A0 =A0 unsigned int val;
>> +
>> + =A0 =A0 =A0 spin_lock(&psc_dma->lock);
>> +
>> + =A0 =A0 =A0 /* Wait for it to be ready */
>> + =A0 =A0 =A0 timeout =3D 1000;
>> + =A0 =A0 =A0 while ((--timeout) && (in_be16(&psc_dma->psc_regs->sr_csr.=
status) &
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_SR_CMDSEND))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>
> Holy unbounded latency Batman! =A0This code waits up to 10ms for a regist=
er read!
>
> I hate spinning, but if it must be done; I'd like to see it small.
> What is the worst case latency? 125us for 8000Hz bus speed? =A0If you
> must spin; can a cpu_relax() be used instead of the udelay() while
> watch the timebase? =A0Timur recently posted a patch which makes this
> easier.
>
> http://patchwork.ozlabs.org/patch/27414/
>
> They *should* be appearing in Ben's -next branch soon.
The link always runs at 12.288Mhz. Each frame is 256 bits. Worst case
you wait for two frames, 42us. If it doesn't respond in 42us the codec
clock is not ticking ( a recurring problem I am running into). These
codecs may be going into a sleep mode I don't understand, but this is
not the right place to try and wake them up. I'll lower the retry
counts to 10 instead of 1000.
I played around with implementing this on a kernel thread with
interrupts. It can be done but the code is a lot more complex.
BTW, 8000Hz is implemented by slot stuffing. The link always runs at
12.288Mhz. The DACs are double buffered. When a sample is transfered
between buffers it sets a bit on the link back to the host, and the
host sends the next sample in the appropriate slot.
>
>> +
>> + =A0 =A0 =A0 if (!timeout) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("timeout on ac97 bus (rdy)\n");
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0xffff;
>> + =A0 =A0 =A0 }
>> +
>> + =A0 =A0 =A0 /* Do the read */
>> + =A0 =A0 =A0 out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0=
x7f) << 24));
>> +
>> + =A0 =A0 =A0 /* Wait for the answer */
>> + =A0 =A0 =A0 timeout =3D 1000;
>> + =A0 =A0 =A0 while ((--timeout) && !(in_be16(&psc_dma->psc_regs->sr_csr=
.status) &
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 MPC52xx_PSC_SR_DATA_VAL))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>
> ditto.
>
>> +static int psc_ac97_cold_reset_check(struct snd_ac97 *ac97)
>> +{
>> + =A0 =A0 =A0 int max_reset, timeout;
>> + =A0 =A0 =A0 struct mpc52xx_psc __iomem *regs =3D psc_dma->psc_regs;
>> +
>> + =A0 =A0 =A0 /* AC97 clock is generated by the codec.
>> + =A0 =A0 =A0 =A0* Ensure that it starts ticking after codec reset.
>> + =A0 =A0 =A0 =A0*/
>> + =A0 =A0 =A0 for (max_reset =3D 0; max_reset < 5; max_reset++) {
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Do a cold reset */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_8(®s->op1, MPC52xx_PSC_OP_RES);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_8(®s->op0, MPC52xx_PSC_OP_RES);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(50);
>
> :-/ =A0Don't like, but don't know if there is an alternative.
>
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* PSC recover from cold reset
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* (cfr user manual, not sure if useful)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(®s->sicr, in_be32(®s->sicr)=
);
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 psc_ac97_warm_reset(ac97);
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* first make sure AC97 clock is low */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (timeout =3D 0; ((in_8(®s->ipcr_acr=
.ipcr) & 0x80) !=3D 0) &&
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (timeout <=
100); timeout++)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (timeout =3D=3D 100)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>> +
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* then wait for the transition to high */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (timeout =3D 0; ((in_8(®s->ipcr_acr=
.ipcr) & 0x80) =3D=3D 0) &&
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (timeout <=
100); timeout++)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(10);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (timeout =3D=3D 100)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue;
>
> Using udelay makes this less accurate. =A0Only possible reason to use a
> udelay is if the register cannot be polled at full speed (which is
> possibly the case if it adds bus contention; but I don't think it is
> an issue here).
>
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH v5 2/4] powerpc/virtex: refactor intc driver and add support for i8259 cascading
From: Grant Likely @ 2009-05-25 14:41 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090525144023.13016.23071.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
This patch refactors some of the xilinx_intc interrupt controller driver
and adds support for cascading an i8259 off one of the irq lines.
This patch was based on the ML510 support work done by Roderick
Colenbrander.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/sysdev/xilinx_intc.c | 76 ++++++++++++++++++++++++++++---------
1 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index c658b41..90b5772 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -25,6 +25,7 @@
#include <linux/of.h>
#include <asm/io.h>
#include <asm/processor.h>
+#include <asm/i8259.h>
#include <asm/irq.h>
/*
@@ -191,20 +192,14 @@ struct irq_host * __init
xilinx_intc_init(struct device_node *np)
{
struct irq_host * irq;
- struct resource res;
void * regs;
- int rc;
/* Find and map the intc registers */
- rc = of_address_to_resource(np, 0, &res);
- if (rc) {
- printk(KERN_ERR __FILE__ ": of_address_to_resource() failed\n");
+ regs = of_iomap(np, 0);
+ if (!regs) {
+ pr_err("xilinx_intc: could not map registers\n");
return NULL;
}
- regs = ioremap(res.start, 32);
-
- printk(KERN_INFO "Xilinx intc at 0x%08llx mapped to 0x%p\n",
- (unsigned long long) res.start, regs);
/* Setup interrupt controller */
out_be32(regs + XINTC_IER, 0); /* disable all irqs */
@@ -217,6 +212,7 @@ xilinx_intc_init(struct device_node *np)
if (!irq)
panic(__FILE__ ": Cannot allocate IRQ host\n");
irq->host_data = regs;
+
return irq;
}
@@ -227,23 +223,65 @@ int xilinx_intc_get_irq(void)
return irq_linear_revmap(master_irqhost, in_be32(regs + XINTC_IVR));
}
+#if defined(CONFIG_PPC_I8259)
+/*
+ * Support code for cascading to 8259 interrupt controllers
+ */
+static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+ if (cascade_irq)
+ generic_handle_irq(cascade_irq);
+
+ /* Let xilinx_intc end the interrupt */
+ desc->chip->ack(irq);
+ desc->chip->unmask(irq);
+}
+
+static void __init xilinx_i8259_setup_cascade(void)
+{
+ struct device_node *cascade_node;
+ int cascade_irq;
+
+ /* Initialize i8259 controller */
+ cascade_node = of_find_compatible_node(NULL, NULL, "chrp,iic");
+ if (!cascade_node)
+ return;
+
+ cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+ if (!cascade_irq) {
+ pr_err("virtex_ml510: Failed to map cascade interrupt\n");
+ goto out;
+ }
+
+ i8259_init(cascade_node, 0);
+ set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+
+ out:
+ of_node_put(cascade_node);
+}
+#else
+static inline void xilinx_i8259_setup_cascade(void) { return; }
+#endif /* defined(CONFIG_PPC_I8259) */
+
+static struct of_device_id xilinx_intc_match[] __initconst = {
+ { .compatible = "xlnx,opb-intc-1.00.c", },
+ { .compatible = "xlnx,xps-intc-1.00.a", },
+ {}
+};
+
+/*
+ * Initialize master Xilinx interrupt controller
+ */
void __init xilinx_intc_init_tree(void)
{
struct device_node *np;
/* find top level interrupt controller */
- for_each_compatible_node(np, NULL, "xlnx,opb-intc-1.00.c") {
+ for_each_matching_node(np, xilinx_intc_match) {
if (!of_get_property(np, "interrupts", NULL))
break;
}
- if (!np) {
- for_each_compatible_node(np, NULL, "xlnx,xps-intc-1.00.a") {
- if (!of_get_property(np, "interrupts", NULL))
- break;
- }
- }
-
- /* xilinx interrupt controller needs to be top level */
BUG_ON(!np);
master_irqhost = xilinx_intc_init(np);
@@ -251,4 +289,6 @@ void __init xilinx_intc_init_tree(void)
irq_set_default_host(master_irqhost);
of_node_put(np);
+
+ xilinx_i8259_setup_cascade();
}
^ permalink raw reply related
* [PATCH v5 1/4] powerpc/virtex: Add support for Xilinx PCI host bridge
From: Grant Likely @ 2009-05-25 14:41 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090525144023.13016.23071.stgit@localhost.localdomain>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
This patch adds support for the Xilinx plbv46-pci-1.03.a PCI host
bridge IPcore.
Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/xilinx_pci.h | 21 +++++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/xilinx_pci.c | 132 +++++++++++++++++++++++++++++++++
6 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
diff --git a/arch/powerpc/include/asm/xilinx_pci.h b/arch/powerpc/include/asm/xilinx_pci.h
new file mode 100644
index 0000000..7a8275c
--- /dev/null
+++ b/arch/powerpc/include/asm/xilinx_pci.h
@@ -0,0 +1,21 @@
+/*
+ * Xilinx pci external definitions
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef INCLUDE_XILINX_PCI
+#define INCLUDE_XILINX_PCI
+
+#ifdef CONFIG_XILINX_PCI
+extern void __init xilinx_pci_init(void);
+#else
+static inline void __init xilinx_pci_init(void) { return; }
+#endif
+
+#endif /* INCLUDE_XILINX_PCI */
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index fc7fb00..d0fc686 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -14,6 +14,7 @@
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/xilinx_intc.h>
+#include <asm/xilinx_pci.h>
#include <asm/ppc4xx.h>
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
@@ -47,6 +48,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = "Xilinx Virtex",
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
.restart = ppc4xx_reset_system,
diff --git a/arch/powerpc/platforms/44x/virtex.c b/arch/powerpc/platforms/44x/virtex.c
index 68637fa..cf96cca 100644
--- a/arch/powerpc/platforms/44x/virtex.c
+++ b/arch/powerpc/platforms/44x/virtex.c
@@ -16,6 +16,7 @@
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/xilinx_intc.h>
+#include <asm/xilinx_pci.h>
#include <asm/reg.h>
#include <asm/ppc4xx.h>
#include "44x.h"
@@ -53,6 +54,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = "Xilinx Virtex440",
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index e3e8707..04a8061 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -329,4 +329,8 @@ config MCU_MPC8349EMITX
also register MCU GPIOs with the generic GPIO API, so you'll able
to use MCU pins as GPIOs.
+config XILINX_PCI
+ bool "Xilinx PCI host bridge support"
+ depends on PCI && XILINX_VIRTEX
+
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..2d1c87d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC) += ipic.o
obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
+obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/xilinx_pci.c b/arch/powerpc/sysdev/xilinx_pci.c
new file mode 100644
index 0000000..1453b0e
--- /dev/null
+++ b/arch/powerpc/sysdev/xilinx_pci.c
@@ -0,0 +1,132 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written
+ * by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt <benh@kernel.crashing.org>, IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/ioport.h>
+#include <linux/of.h>
+#include <linux/pci.h>
+#include <mm/mmu_decl.h>
+#include <asm/io.h>
+#include <asm/xilinx_pci.h>
+
+#define XPLB_PCI_ADDR 0x10c
+#define XPLB_PCI_DATA 0x110
+#define XPLB_PCI_BUS 0x114
+
+#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
+
+static struct of_device_id xilinx_pci_match[] = {
+ { .compatible = "xlnx,plbv46-pci-1.03.a", },
+ {}
+};
+
+/**
+ * xilinx_pci_fixup_bridge - Block Xilinx PHB configuration.
+ */
+static void xilinx_pci_fixup_bridge(struct pci_dev *dev)
+{
+ struct pci_controller *hose;
+ int i;
+
+ if (dev->devfn || dev->bus->self)
+ return;
+
+ hose = pci_bus_to_host(dev->bus);
+ if (!hose)
+ return;
+
+ if (!of_match_node(xilinx_pci_match, hose->dn))
+ return;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ dev->resource[i].start = 0;
+ dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+
+ dev_info(&dev->dev, "Hiding Xilinx plb-pci host bridge resources %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, xilinx_pci_fixup_bridge);
+
+/**
+ * xilinx_pci_exclude_device - Don't do config access for non-root bus
+ *
+ * This is a hack. Config access to any bus other than bus 0 does not
+ * currently work on the ML510 so we prevent it here.
+ */
+static int
+xilinx_pci_exclude_device(struct pci_controller *hose, u_char bus, u8 devfn)
+{
+ return (bus != 0);
+}
+
+/**
+ * xilinx_pci_init - Find and register a Xilinx PCI host bridge
+ */
+void __init xilinx_pci_init(void)
+{
+ struct pci_controller *hose;
+ struct resource r;
+ void __iomem *pci_reg;
+ struct device_node *pci_node;
+
+ pci_node = of_find_matching_node(NULL, xilinx_pci_match);
+ if(!pci_node)
+ return;
+
+ if (of_address_to_resource(pci_node, 0, &r)) {
+ pr_err("xilinx-pci: cannot resolve base address\n");
+ return;
+ }
+
+ hose = pcibios_alloc_controller(pci_node);
+ if (!hose) {
+ pr_err("xilinx-pci: pcibios_alloc_controller() failed\n");
+ return;
+ }
+
+ /* Setup config space */
+ setup_indirect_pci(hose, r.start + XPLB_PCI_ADDR,
+ r.start + XPLB_PCI_DATA,
+ PPC_INDIRECT_TYPE_SET_CFG_TYPE);
+
+ /* According to the xilinx plbv46_pci documentation the soft-core starts
+ * a self-init when the bus master enable bit is set. Without this bit
+ * set the pci bus can't be scanned.
+ */
+ early_write_config_word(hose, 0, 0, PCI_COMMAND, PCI_HOST_ENABLE_CMD);
+
+ /* Set the max latency timer to 255 */
+ early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0xff);
+
+ /* Set the max bus number to 255 */
+ pci_reg = of_iomap(pci_node, 0);
+ out_8(pci_reg + XPLB_PCI_BUS, 0xff);
+ iounmap(pci_reg);
+
+ /* Nothing past the root bridge is working right now. By default
+ * exclude config access to anything except bus 0 */
+ if (!ppc_md.pci_exclude_device)
+ ppc_md.pci_exclude_device = xilinx_pci_exclude_device;
+
+ /* Register the host bridge with the linux kernel! */
+ pci_process_bridge_OF_ranges(hose, pci_node, 1);
+
+ pr_info("xilinx-pci: Registered PCI host bridge\n");
+}
^ permalink raw reply related
* [PATCH v5 4/4] powerpc/virtex: Add ml510 reference design device tree
From: Grant Likely @ 2009-05-25 14:41 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090525144023.13016.23071.stgit@localhost.localdomain>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
As subject says, add dts files for Xilinx ML510 reference design with
the PCI host bridge device.
Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +++++++++++++++++++++++++++++
1 files changed, 465 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 0000000..81a8dc2
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,465 @@
+/*
+ * Xilinx ML510 Reference Design support
+ *
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains a bug which prevent PCI DMA from working
+ * properly. A description of the bug is given in the plbv46_pci section. It
+ * needs to be fixed by the user until Xilinx updates their reference design.
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,ml510-ref-design", "xlnx,virtex440";
+ dcr-parent = <&ppc440_0>;
+ DDR2_SDRAM_DIMM0: memory@0 {
+ device_type = "memory";
+ reg = < 0x0 0x20000000 >;
+ } ;
+ alias {
+ ethernet0 = &Hard_Ethernet_MAC;
+ serial0 = &RS232_Uart_1;
+ } ;
+ chosen {
+ bootargs = "console=ttyS0 root=/dev/ram";
+ linux,stdout-path = "/plb@0/serial@83e00000";
+ } ;
+ cpus {
+ #address-cells = <1>;
+ #cpus = <0x1>;
+ #size-cells = <0>;
+ ppc440_0: cpu@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clock-frequency = <300000000>;
+ compatible = "PowerPC,440", "ibm,ppc440";
+ d-cache-line-size = <0x20>;
+ d-cache-size = <0x8000>;
+ dcr-access-method = "native";
+ dcr-controller ;
+ device_type = "cpu";
+ i-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ model = "PowerPC,440";
+ reg = <0>;
+ timebase-frequency = <300000000>;
+ xlnx,apu-control = <0x2000>;
+ xlnx,apu-udi-0 = <0x0>;
+ xlnx,apu-udi-1 = <0x0>;
+ xlnx,apu-udi-10 = <0x0>;
+ xlnx,apu-udi-11 = <0x0>;
+ xlnx,apu-udi-12 = <0x0>;
+ xlnx,apu-udi-13 = <0x0>;
+ xlnx,apu-udi-14 = <0x0>;
+ xlnx,apu-udi-15 = <0x0>;
+ xlnx,apu-udi-2 = <0x0>;
+ xlnx,apu-udi-3 = <0x0>;
+ xlnx,apu-udi-4 = <0x0>;
+ xlnx,apu-udi-5 = <0x0>;
+ xlnx,apu-udi-6 = <0x0>;
+ xlnx,apu-udi-7 = <0x0>;
+ xlnx,apu-udi-8 = <0x0>;
+ xlnx,apu-udi-9 = <0x0>;
+ xlnx,dcr-autolock-enable = <0x1>;
+ xlnx,dcu-rd-ld-cache-plb-prio = <0x0>;
+ xlnx,dcu-rd-noncache-plb-prio = <0x0>;
+ xlnx,dcu-rd-touch-plb-prio = <0x0>;
+ xlnx,dcu-rd-urgent-plb-prio = <0x0>;
+ xlnx,dcu-wr-flush-plb-prio = <0x0>;
+ xlnx,dcu-wr-store-plb-prio = <0x0>;
+ xlnx,dcu-wr-urgent-plb-prio = <0x0>;
+ xlnx,dma0-control = <0x0>;
+ xlnx,dma0-plb-prio = <0x0>;
+ xlnx,dma0-rxchannelctrl = <0x1010000>;
+ xlnx,dma0-rxirqtimer = <0x3ff>;
+ xlnx,dma0-txchannelctrl = <0x1010000>;
+ xlnx,dma0-txirqtimer = <0x3ff>;
+ xlnx,dma1-control = <0x0>;
+ xlnx,dma1-plb-prio = <0x0>;
+ xlnx,dma1-rxchannelctrl = <0x1010000>;
+ xlnx,dma1-rxirqtimer = <0x3ff>;
+ xlnx,dma1-txchannelctrl = <0x1010000>;
+ xlnx,dma1-txirqtimer = <0x3ff>;
+ xlnx,dma2-control = <0x0>;
+ xlnx,dma2-plb-prio = <0x0>;
+ xlnx,dma2-rxchannelctrl = <0x1010000>;
+ xlnx,dma2-rxirqtimer = <0x3ff>;
+ xlnx,dma2-txchannelctrl = <0x1010000>;
+ xlnx,dma2-txirqtimer = <0x3ff>;
+ xlnx,dma3-control = <0x0>;
+ xlnx,dma3-plb-prio = <0x0>;
+ xlnx,dma3-rxchannelctrl = <0x1010000>;
+ xlnx,dma3-rxirqtimer = <0x3ff>;
+ xlnx,dma3-txchannelctrl = <0x1010000>;
+ xlnx,dma3-txirqtimer = <0x3ff>;
+ xlnx,endian-reset = <0x0>;
+ xlnx,generate-plb-timespecs = <0x1>;
+ xlnx,icu-rd-fetch-plb-prio = <0x0>;
+ xlnx,icu-rd-spec-plb-prio = <0x0>;
+ xlnx,icu-rd-touch-plb-prio = <0x0>;
+ xlnx,interconnect-imask = <0xffffffff>;
+ xlnx,mplb-allow-lock-xfer = <0x1>;
+ xlnx,mplb-arb-mode = <0x0>;
+ xlnx,mplb-awidth = <0x20>;
+ xlnx,mplb-counter = <0x500>;
+ xlnx,mplb-dwidth = <0x80>;
+ xlnx,mplb-max-burst = <0x8>;
+ xlnx,mplb-native-dwidth = <0x80>;
+ xlnx,mplb-p2p = <0x0>;
+ xlnx,mplb-prio-dcur = <0x2>;
+ xlnx,mplb-prio-dcuw = <0x3>;
+ xlnx,mplb-prio-icu = <0x4>;
+ xlnx,mplb-prio-splb0 = <0x1>;
+ xlnx,mplb-prio-splb1 = <0x0>;
+ xlnx,mplb-read-pipe-enable = <0x1>;
+ xlnx,mplb-sync-tattribute = <0x0>;
+ xlnx,mplb-wdog-enable = <0x1>;
+ xlnx,mplb-write-pipe-enable = <0x1>;
+ xlnx,mplb-write-post-enable = <0x1>;
+ xlnx,num-dma = <0x0>;
+ xlnx,pir = <0xf>;
+ xlnx,ppc440mc-addr-base = <0x0>;
+ xlnx,ppc440mc-addr-high = <0x1fffffff>;
+ xlnx,ppc440mc-arb-mode = <0x0>;
+ xlnx,ppc440mc-bank-conflict-mask = <0x1800000>;
+ xlnx,ppc440mc-control = <0xf810008f>;
+ xlnx,ppc440mc-max-burst = <0x8>;
+ xlnx,ppc440mc-prio-dcur = <0x2>;
+ xlnx,ppc440mc-prio-dcuw = <0x3>;
+ xlnx,ppc440mc-prio-icu = <0x4>;
+ xlnx,ppc440mc-prio-splb0 = <0x1>;
+ xlnx,ppc440mc-prio-splb1 = <0x0>;
+ xlnx,ppc440mc-row-conflict-mask = <0x7ffe00>;
+ xlnx,ppcdm-asyncmode = <0x0>;
+ xlnx,ppcds-asyncmode = <0x0>;
+ xlnx,user-reset = <0x0>;
+ } ;
+ } ;
+ plb_v46_0: plb@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,plb-v46-1.03.a", "simple-bus";
+ ranges ;
+ FLASH: flash@fc000000 {
+ bank-width = <2>;
+ compatible = "xlnx,xps-mch-emc-2.00.a", "cfi-flash";
+ reg = < 0xfc000000 0x2000000 >;
+ xlnx,family = "virtex5";
+ xlnx,include-datawidth-matching-0 = <0x1>;
+ xlnx,include-datawidth-matching-1 = <0x0>;
+ xlnx,include-datawidth-matching-2 = <0x0>;
+ xlnx,include-datawidth-matching-3 = <0x0>;
+ xlnx,include-negedge-ioregs = <0x0>;
+ xlnx,include-plb-ipif = <0x1>;
+ xlnx,include-wrbuf = <0x1>;
+ xlnx,max-mem-width = <0x10>;
+ xlnx,mch-native-dwidth = <0x20>;
+ xlnx,mch-plb-clk-period-ps = <0x2710>;
+ xlnx,mch-splb-awidth = <0x20>;
+ xlnx,mch0-accessbuf-depth = <0x10>;
+ xlnx,mch0-protocol = <0x0>;
+ xlnx,mch0-rddatabuf-depth = <0x10>;
+ xlnx,mch1-accessbuf-depth = <0x10>;
+ xlnx,mch1-protocol = <0x0>;
+ xlnx,mch1-rddatabuf-depth = <0x10>;
+ xlnx,mch2-accessbuf-depth = <0x10>;
+ xlnx,mch2-protocol = <0x0>;
+ xlnx,mch2-rddatabuf-depth = <0x10>;
+ xlnx,mch3-accessbuf-depth = <0x10>;
+ xlnx,mch3-protocol = <0x0>;
+ xlnx,mch3-rddatabuf-depth = <0x10>;
+ xlnx,mem0-width = <0x10>;
+ xlnx,mem1-width = <0x20>;
+ xlnx,mem2-width = <0x20>;
+ xlnx,mem3-width = <0x20>;
+ xlnx,num-banks-mem = <0x1>;
+ xlnx,num-channels = <0x2>;
+ xlnx,priority-mode = <0x0>;
+ xlnx,synch-mem-0 = <0x0>;
+ xlnx,synch-mem-1 = <0x0>;
+ xlnx,synch-mem-2 = <0x0>;
+ xlnx,synch-mem-3 = <0x0>;
+ xlnx,synch-pipedelay-0 = <0x2>;
+ xlnx,synch-pipedelay-1 = <0x2>;
+ xlnx,synch-pipedelay-2 = <0x2>;
+ xlnx,synch-pipedelay-3 = <0x2>;
+ xlnx,tavdv-ps-mem-0 = <0x1adb0>;
+ xlnx,tavdv-ps-mem-1 = <0x3a98>;
+ xlnx,tavdv-ps-mem-2 = <0x3a98>;
+ xlnx,tavdv-ps-mem-3 = <0x3a98>;
+ xlnx,tcedv-ps-mem-0 = <0x1adb0>;
+ xlnx,tcedv-ps-mem-1 = <0x3a98>;
+ xlnx,tcedv-ps-mem-2 = <0x3a98>;
+ xlnx,tcedv-ps-mem-3 = <0x3a98>;
+ xlnx,thzce-ps-mem-0 = <0x88b8>;
+ xlnx,thzce-ps-mem-1 = <0x1b58>;
+ xlnx,thzce-ps-mem-2 = <0x1b58>;
+ xlnx,thzce-ps-mem-3 = <0x1b58>;
+ xlnx,thzoe-ps-mem-0 = <0x1b58>;
+ xlnx,thzoe-ps-mem-1 = <0x1b58>;
+ xlnx,thzoe-ps-mem-2 = <0x1b58>;
+ xlnx,thzoe-ps-mem-3 = <0x1b58>;
+ xlnx,tlzwe-ps-mem-0 = <0x88b8>;
+ xlnx,tlzwe-ps-mem-1 = <0x0>;
+ xlnx,tlzwe-ps-mem-2 = <0x0>;
+ xlnx,tlzwe-ps-mem-3 = <0x0>;
+ xlnx,twc-ps-mem-0 = <0x1adb0>;
+ xlnx,twc-ps-mem-1 = <0x3a98>;
+ xlnx,twc-ps-mem-2 = <0x3a98>;
+ xlnx,twc-ps-mem-3 = <0x3a98>;
+ xlnx,twp-ps-mem-0 = <0x11170>;
+ xlnx,twp-ps-mem-1 = <0x2ee0>;
+ xlnx,twp-ps-mem-2 = <0x2ee0>;
+ xlnx,twp-ps-mem-3 = <0x2ee0>;
+ xlnx,xcl0-linesize = <0x4>;
+ xlnx,xcl0-writexfer = <0x1>;
+ xlnx,xcl1-linesize = <0x4>;
+ xlnx,xcl1-writexfer = <0x1>;
+ xlnx,xcl2-linesize = <0x4>;
+ xlnx,xcl2-writexfer = <0x1>;
+ xlnx,xcl3-linesize = <0x4>;
+ xlnx,xcl3-writexfer = <0x1>;
+ } ;
+ Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,compound";
+ ethernet@81c00000 {
+ compatible = "xlnx,xps-ll-temac-1.01.b";
+ device_type = "network";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 8 2 >;
+ llink-connected = <&Hard_Ethernet_MAC_fifo>;
+ local-mac-address = [ 02 00 00 00 00 00 ];
+ reg = < 0x81c00000 0x40 >;
+ xlnx,bus2core-clk-ratio = <0x1>;
+ xlnx,phy-type = <0x3>;
+ xlnx,phyaddr = <0x1>;
+ xlnx,rxcsum = <0x0>;
+ xlnx,rxfifo = <0x8000>;
+ xlnx,temac-type = <0x0>;
+ xlnx,txcsum = <0x0>;
+ xlnx,txfifo = <0x8000>;
+ } ;
+ } ;
+ Hard_Ethernet_MAC_fifo: xps-ll-fifo@81a00000 {
+ compatible = "xlnx,xps-ll-fifo-1.01.a";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 6 2 >;
+ reg = < 0x81a00000 0x10000 >;
+ xlnx,family = "virtex5";
+ } ;
+ IIC_EEPROM: i2c@81600000 {
+ compatible = "xlnx,xps-iic-2.00.a";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 9 2 >;
+ reg = < 0x81600000 0x10000 >;
+ xlnx,clk-freq = <0x5f5e100>;
+ xlnx,family = "virtex5";
+ xlnx,gpo-width = <0x1>;
+ xlnx,iic-freq = <0x186a0>;
+ xlnx,scl-inertial-delay = <0x5>;
+ xlnx,sda-inertial-delay = <0x5>;
+ xlnx,ten-bit-adr = <0x0>;
+ } ;
+ LCD_OPTIONAL: gpio@81420000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = < 0x81420000 0x10000 >;
+ xlnx,all-inputs = <0x0>;
+ xlnx,all-inputs-2 = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,dout-default-2 = <0x0>;
+ xlnx,family = "virtex5";
+ xlnx,gpio-width = <0xb>;
+ xlnx,interrupt-present = <0x0>;
+ xlnx,is-bidir = <0x1>;
+ xlnx,is-bidir-2 = <0x1>;
+ xlnx,is-dual = <0x0>;
+ xlnx,tri-default = <0xffffffff>;
+ xlnx,tri-default-2 = <0xffffffff>;
+ } ;
+ LEDs_4Bit: gpio@81400000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = < 0x81400000 0x10000 >;
+ xlnx,all-inputs = <0x0>;
+ xlnx,all-inputs-2 = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,dout-default-2 = <0x0>;
+ xlnx,family = "virtex5";
+ xlnx,gpio-width = <0x4>;
+ xlnx,interrupt-present = <0x0>;
+ xlnx,is-bidir = <0x1>;
+ xlnx,is-bidir-2 = <0x1>;
+ xlnx,is-dual = <0x0>;
+ xlnx,tri-default = <0xffffffff>;
+ xlnx,tri-default-2 = <0xffffffff>;
+ } ;
+ RS232_Uart_1: serial@83e00000 {
+ clock-frequency = <100000000>;
+ compatible = "xlnx,xps-uart16550-2.00.b", "ns16550";
+ current-speed = <9600>;
+ device_type = "serial";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 11 2 >;
+ reg = < 0x83e00000 0x10000 >;
+ reg-offset = <0x1003>;
+ reg-shift = <2>;
+ xlnx,family = "virtex5";
+ xlnx,has-external-rclk = <0x0>;
+ xlnx,has-external-xin = <0x0>;
+ xlnx,is-a-16550 = <0x1>;
+ } ;
+ SPI_EEPROM: xps-spi@feff8000 {
+ compatible = "xlnx,xps-spi-2.00.b";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 10 2 >;
+ reg = < 0xfeff8000 0x80 >;
+ xlnx,family = "virtex5";
+ xlnx,fifo-exist = <0x1>;
+ xlnx,num-ss-bits = <0x1>;
+ xlnx,num-transfer-bits = <0x8>;
+ xlnx,sck-ratio = <0x80>;
+ } ;
+ SysACE_CompactFlash: sysace@83600000 {
+ compatible = "xlnx,xps-sysace-1.00.a";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 7 2 >;
+ reg = < 0x83600000 0x10000 >;
+ xlnx,family = "virtex5";
+ xlnx,mem-width = <0x10>;
+ } ;
+ plbv46_pci_0: plbv46-pci@85e00000 {
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "xlnx,plbv46-pci-1.03.a";
+ device_type = "pci";
+ reg = < 0x85e00000 0x10000 >;
+
+ /*
+ * The default ML510 BSB has C_IPIFBAR2PCIBAR_0 set to
+ * 0 which means that a read/write to the memory mapped
+ * i/o region (which starts at 0xa0000000) for pci
+ * bar 0 on the plb side translates to 0.
+ * It is important to set this value to 0xa0000000, so
+ * that inbound and outbound pci transactions work
+ * properly including DMA.
+ */
+ ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf0000000 0 0x00010000>;
+
+ #interrupt-cells = <1>;
+ interrupt-parent = <&xps_intc_0>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IRQ mapping for pci slots and ALI M1533
+ * periperhals. In total there are 5 interrupt
+ * lines connected to a xps_intc controller.
+ * Four of them are PCI IRQ A, B, C, D and
+ * which correspond to respectively xpx_intc
+ * 5, 4, 3 and 2. The fifth interrupt line is
+ * connected to the south bridge and this one
+ * uses irq 1 and is active high instead of
+ * active low.
+ *
+ * The M1533 contains various peripherals
+ * including AC97 audio, a modem, USB, IDE and
+ * some power management stuff. The modem
+ * isn't connected on the ML510 and the power
+ * management core also isn't used.
+ */
+
+ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
+ 0x3000 0 0 1 &xps_intc_0 3 2
+ 0x3000 0 0 2 &xps_intc_0 2 2
+ 0x3000 0 0 3 &xps_intc_0 5 2
+ 0x3000 0 0 4 &xps_intc_0 4 2
+
+ /* IDSEL 0x13 / dev=3, bus=1 / PCI slot 4 */
+ /*
+ 0x11800 0 0 1 &xps_intc_0 5 0 2
+ 0x11800 0 0 2 &xps_intc_0 4 0 2
+ 0x11800 0 0 3 &xps_intc_0 3 0 2
+ 0x11800 0 0 4 &xps_intc_0 2 0 2
+ */
+
+ /* According to the datasheet + schematic
+ * ABCD [FPGA] of slot 5 is mapped to DABC.
+ * Testing showed that at least A maps to B,
+ * the mapping of the other pins is a guess
+ * and for that reason the lines have been
+ * commented out.
+ */
+ /* IDSEL 0x15 / dev=5, bus=0 / PCI slot 5 */
+ 0x2800 0 0 1 &xps_intc_0 4 2
+ /*
+ 0x2800 0 0 2 &xps_intc_0 3 2
+ 0x2800 0 0 3 &xps_intc_0 2 2
+ 0x2800 0 0 4 &xps_intc_0 5 2
+ */
+
+ /* IDSEL 0x12 / dev=2, bus=1 / PCI slot 6 */
+ /*
+ 0x11000 0 0 1 &xps_intc_0 4 0 2
+ 0x11000 0 0 2 &xps_intc_0 3 0 2
+ 0x11000 0 0 3 &xps_intc_0 2 0 2
+ 0x11000 0 0 4 &xps_intc_0 5 0 2
+ */
+
+ /* IDSEL 0x11 / dev=1, bus=0 / AC97 audio */
+ 0x0800 0 0 1 &i8259 7 2
+
+ /* IDSEL 0x1b / dev=11, bus=0 / IDE */
+ 0x5800 0 0 1 &i8259 14 2
+
+ /* IDSEL 0x1f / dev 15, bus=0 / 2x USB 1.1 */
+ 0x7800 0 0 1 &i8259 7 2
+ >;
+ ali_m1533 {
+ #size-cells = <1>;
+ #address-cells = <2>;
+ i8259: interrupt-controller@20 {
+ reg = <1 0x20 2
+ 1 0xa0 2
+ 1 0x4d0 2>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ compatible = "chrp,iic";
+
+ /* south bridge irq is active high */
+ interrupts = <1 3>;
+ interrupt-parent = <&xps_intc_0>;
+ };
+ };
+ } ;
+ xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffff0000 {
+ compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
+ reg = < 0xffff0000 0x10000 >;
+ xlnx,family = "virtex5";
+ } ;
+ xps_intc_0: interrupt-controller@81800000 {
+ #interrupt-cells = <0x2>;
+ compatible = "xlnx,xps-intc-1.00.a";
+ interrupt-controller ;
+ reg = < 0x81800000 0x10000 >;
+ xlnx,num-intr-inputs = <0xc>;
+ } ;
+ xps_tft_0: tft@86e00000 {
+ compatible = "xlnx,xps-tft-1.00.a";
+ reg = < 0x86e00000 0x10000 >;
+ xlnx,dcr-splb-slave-if = <0x1>;
+ xlnx,default-tft-base-addr = <0x0>;
+ xlnx,family = "virtex5";
+ xlnx,i2c-slave-addr = <0x76>;
+ xlnx,mplb-awidth = <0x20>;
+ xlnx,mplb-dwidth = <0x80>;
+ xlnx,mplb-native-dwidth = <0x40>;
+ xlnx,mplb-smallest-slave = <0x20>;
+ xlnx,tft-interface = <0x1>;
+ } ;
+ } ;
+} ;
^ permalink raw reply related
* [PATCH v5 3/4] powerpc/virtex: Add Xilinx ML510 reference design support
From: Grant Likely @ 2009-05-25 14:41 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
In-Reply-To: <20090525144023.13016.23071.stgit@localhost.localdomain>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/44x/Kconfig | 13 ++++++++++++-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 +++++++++++++++++++++++++++++
arch/powerpc/sysdev/xilinx_intc.c | 5 +++++
4 files changed, 47 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0d83a6a..90e3192 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -156,7 +156,7 @@ config YOSEMITE
# This option enables support for the IBM PPC440GX evaluation board.
config XILINX_VIRTEX440_GENERIC_BOARD
- bool "Generic Xilinx Virtex 440 board"
+ bool "Generic Xilinx Virtex 5 FXT board support"
depends on 44x
default n
select XILINX_VIRTEX_5_FXT
@@ -171,6 +171,17 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config XILINX_ML510
+ bool "Xilinx ML510 extra support"
+ depends on XILINX_VIRTEX440_GENERIC_BOARD
+ select PPC_PCI_CHOICE
+ select XILINX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+ help
+ This option enables extra support for features on the Xilinx ML510
+ board. The ML510 has a PCI bus with ALI south bridge.
+
config PPC44x_SIMPLE
bool "Simple PowerPC 44x board support"
depends on 44x
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 01f51da..ee6185a 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c b/arch/powerpc/platforms/44x/virtex_ml510.c
new file mode 100644
index 0000000..ba4a6e3
--- /dev/null
+++ b/arch/powerpc/platforms/44x/virtex_ml510.c
@@ -0,0 +1,29 @@
+#include <asm/i8259.h>
+#include <linux/pci.h>
+#include "44x.h"
+
+/**
+ * ml510_ail_quirk
+ */
+static void __devinit ml510_ali_quirk(struct pci_dev *dev)
+{
+ /* Enable the IDE controller */
+ pci_write_config_byte(dev, 0x58, 0x4c);
+ /* Assign irq 14 to the primary ide channel */
+ pci_write_config_byte(dev, 0x44, 0x0d);
+ /* Assign irq 15 to the secondary ide channel */
+ pci_write_config_byte(dev, 0x75, 0x0f);
+ /* Set the ide controller in native mode */
+ pci_write_config_byte(dev, 0x09, 0xff);
+
+ /* INTB = disabled, INTA = disabled */
+ pci_write_config_byte(dev, 0x48, 0x00);
+ /* INTD = disabled, INTC = disabled */
+ pci_write_config_byte(dev, 0x4a, 0x00);
+ /* Audio = INT7, Modem = disabled. */
+ pci_write_config_byte(dev, 0x4b, 0x60);
+ /* USB = INT7 */
+ pci_write_config_byte(dev, 0x74, 0x06);
+}
+DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ml510_ali_quirk);
+
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index 90b5772..3ee1fd3 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -257,6 +257,11 @@ static void __init xilinx_i8259_setup_cascade(void)
i8259_init(cascade_node, 0);
set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ /* This looks like a dirty hack to me --gcl */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+
out:
of_node_put(cascade_node);
}
^ permalink raw reply related
* [PATCH v5 0/4] Series short description
From: Grant Likely @ 2009-05-25 14:41 UTC (permalink / raw)
To: linuxppc-dev, Roderick Colenbrander
Repost of ml510 series. This time against 2.6.30-rc7 and with the .dts
file included.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
From: Jon Smirl @ 2009-05-25 14:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <fa686aa40905242334o4867d701n9de332721eb2f3b4@mail.gmail.com>
On Mon, May 25, 2009 at 2:34 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> This is ugly. =A0I'd really rather have a generic mechanism for creating
> a fabric driver based on the OF data. =A0But failing that, it seems to
> me that this platform device registration should be done in the
> platform code (arch/powerpc/platforms/52xx). =A0Doing it in a module
> init looks wrong.
I'm all for deleting it as soon as AC97 is capable of auto-loading. I
thought it was better to leave it in the sound directories to keep it
isolated since the intention is to remove it when possible.
BTW, my binding files are quite simple compared to mpc8610_hpcd.c.
>
> I was trying to do a sort of generic matching mechanism with the of
> simple stuff; but admittedly it was hacky and half-assed. =A0However, I
> do still think it is viable to have OF hooks that kick in when codec
> and machine drivers are registered. =A0If linkage data is encoded in the
> device tree, then generic code should be able to hook them up; pulling
> additional data out of the device tree as needed to configure the
> coded.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* 82xx multiple soc support/initialization
From: Carl-Erwin GRIFFITH @ 2009-05-25 14:23 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
Hi guys,
I'm working on an derived muas3001 board (kernel version 2.6.30-rc5),
and so far I did not find an example of multiple SOCs initialization.
The board has 3 cpus (only one core activated).
1) Is there a special syntax to use in the device tree ?
2) Do the kernel provide an API to support multiple SOCs ?
Best regards,
Carl-Erwin Griffith
[-- Attachment #2: Type: text/html, Size: 1019 bytes --]
^ permalink raw reply
* Re: AMCC 405ex memory size issue
From: Hunter Cobbs @ 2009-05-25 13:22 UTC (permalink / raw)
To: konamo; +Cc: linuxppc-dev@ozlabs.org
Have you modified the hardware? The default hardware specs says there
is only 256MB of ram. Regardless, if you upped the ram amount, you
might need to modify u-boot itself to turn on more address lines or
you might consider looking at your memory management allocation (slab,
slub, etc).
Hunter Cobbs
On May 25, 2009, at 1:15 AM, konamo <dai.michael@gmail.com> wrote:
>
> any ideas?
>
>
>
> konamo wrote:
>>
>> Hi all,
>> we are using AMCC 405ex kilauea eval board as a demo, not use any
>> pci/nand function,
>> the board configuration is below:
>> u-boot 2009.01,
>> linux-2.6.25-rc2,
>> 1GB DDR2 memory(2Gbit * 4, 1 rank),
>> AMCC powerpc 405ex,
>> both 1G and 512MB memory works fine under u-boot, but linux boot
>> fails in
>> 1G memory, if we limit mem=512M, linux could boot over nfs. Could
>> anyone
>> pls help us how to find the root cause? thanks
>>
>
> --
> View this message in context: http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23701685.html
> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code
From: Grant Likely @ 2009-05-25 13:22 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090525093439.GA18290@sirena.org.uk>
On Mon, May 25, 2009 at 3:34 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, May 25, 2009 at 12:26:27AM -0600, Grant Likely wrote:
>> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> > +/* ------------------------------------------------------------------=
---
>> > + * Sysfs attributes for error monitoring
>> > + */
>
>> All this sysfs stuff should be dropped from this patch. =A0It is an
>> abuse of sysfs and I never should have written it this way. =A0Feel free
>> to put it in a separate patch so others can use it if they really need
>> it, but I'd like it to not be kept in mainline.
>
> If this is going to be kept it should be in debugfs like I said in
> response to the v2 posting.
exactly.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
From: Stanislaw Gruszka @ 2009-05-25 12:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo, Peter Zijlstra, linuxppc-dev, linux-kernel@vger.kernel.org,
Nesterov, Oleg, Molnar, Andrew Morton
In-Reply-To: <alpine.LFD.2.00.0905251423490.3582@localhost.localdomain>
On Mon, 25 May 2009 14:32:14 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 25 May 2009, Stanislaw Gruszka wrote:
> > @@ -904,6 +905,7 @@ void __init time_init(void)
> > tb_ticks_per_usec = ppc_tb_freq / 1000000;
> > tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 1000000);
> > calc_cputime_factors();
> > + cputime_one = jiffies_to_cputime(1);
>
> 1) The variable name is misleading.
What about cputime_one_jiffy ?
> 2) The patch breaks all powerpc platforms which have
> CONFIG_VIRT_CPU_ACCOUNTING=n and ia64 with
> CONFIG_VIRT_CPU_ACCOUNTING=y
Stupid me, in asm-generic/cputime.h should be
#define cputime_one jiffies_to_cputime(1)
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
From: Thomas Gleixner @ 2009-05-25 12:32 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org, Oleg Nesterov,
linuxppc-dev, Ingo Molnar, Andrew Morton
In-Reply-To: <20090525132814.442877e5@dhcp-lab-109.englab.brq.redhat.com>
On Mon, 25 May 2009, Stanislaw Gruszka wrote:
> @@ -904,6 +905,7 @@ void __init time_init(void)
> tb_ticks_per_usec = ppc_tb_freq / 1000000;
> tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 1000000);
> calc_cputime_factors();
> + cputime_one = jiffies_to_cputime(1);
1) The variable name is misleading.
2) The patch breaks all powerpc platforms which have
CONFIG_VIRT_CPU_ACCOUNTING=n and ia64 with
CONFIG_VIRT_CPU_ACCOUNTING=y
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
From: Stanislaw Gruszka @ 2009-05-25 11:28 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo, Peter Zijlstra, linuxppc-dev, linux-kernel@vger.kernel.org,
Nesterov, Oleg, Molnar, Andrew Morton
In-Reply-To: <alpine.LFD.2.00.0905221611380.3570@localhost.localdomain>
(linuxppc-dev CC added)
On Fri, 22 May 2009 16:27:40 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:
> > if (cputime_ge(cur_time, it->expires)) {
> > - it->expires = it->incr;
> > - if (!cputime_eq(it->expires, cputime_zero))
> > - it->expires = cputime_add(it->expires, cur_time);
> > + if (!cputime_eq(it->incr, cputime_zero)) {
> > + it->expires = cputime_add(it->expires, it->incr);
> > + it->error += it->incr_error;
> > + if (it->error >= onecputick) {
> > + it->expires = cputime_sub(it->expires,
> > + jiffies_to_cputime(1));
> > + it->error -= onecputick;
> > + }
>
> Yep, that's a sane solution except for jiffies_to_cputime(), which
> can be precomputed as well.
I think precomputed is only needed for PPC where jiffies_to_cputime(1) is not
compile time constant. To not affect other architectures, I wrote a patch with
cputime_one value, it is global variable for PPC and preprocessor definition
for others. This patch is against current Linus' tree. I send it as RFC, it
was only compile tested for x86.
diff --git a/arch/ia64/include/asm/cputime.h b/arch/ia64/include/asm/cputime.h
index d20b998..df88b07 100644
--- a/arch/ia64/include/asm/cputime.h
+++ b/arch/ia64/include/asm/cputime.h
@@ -30,6 +30,7 @@ typedef u64 cputime_t;
typedef u64 cputime64_t;
#define cputime_zero ((cputime_t)0)
+#define cputime_one jiffies_to_cputime(1)
#define cputime_max ((~((cputime_t)0) >> 1) - 1)
#define cputime_add(__a, __b) ((__a) + (__b))
#define cputime_sub(__a, __b) ((__a) - (__b))
diff --git a/arch/powerpc/include/asm/cputime.h b/arch/powerpc/include/asm/cputime.h
index f42e623..e57f951 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -48,6 +48,8 @@ typedef u64 cputime64_t;
#ifdef __KERNEL__
+extern cputime_t cputime_one;
+
/*
* Convert cputime <-> jiffies
*/
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 48571ac..e46e210 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -498,6 +498,7 @@ static int __init iSeries_tb_recal(void)
tb_to_xs = divres.result_low;
vdso_data->tb_ticks_per_sec = tb_ticks_per_sec;
vdso_data->tb_to_xs = tb_to_xs;
+ cputime_one = jiffies_to_cputime(1);
}
else {
printk( "Titan recalibrate: FAILED (difference > 4 percent)\n"
@@ -904,6 +905,7 @@ void __init time_init(void)
tb_ticks_per_usec = ppc_tb_freq / 1000000;
tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 1000000);
calc_cputime_factors();
+ cputime_one = jiffies_to_cputime(1);
/*
* Calculate the length of each tick in ns. It will not be
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index 941384f..f7bbdc9 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -39,6 +39,7 @@ __div(unsigned long long n, unsigned int base)
#endif /* __s390x__ */
#define cputime_zero (0ULL)
+#define cputime_one jiffies_to_cputime(1)
#define cputime_max ((~0UL >> 1) - 1)
#define cputime_add(__a, __b) ((__a) + (__b))
#define cputime_sub(__a, __b) ((__a) - (__b))
diff --git a/include/asm-generic/cputime.h b/include/asm-generic/cputime.h
index 1c1fa42..f2b18be 100644
--- a/include/asm-generic/cputime.h
+++ b/include/asm-generic/cputime.h
@@ -7,6 +7,7 @@
typedef unsigned long cputime_t;
#define cputime_zero (0UL)
+#define cputime_one (1UL)
#define cputime_max ((~0UL >> 1) - 1)
#define cputime_add(__a, __b) ((__a) + (__b))
#define cputime_sub(__a, __b) ((__a) - (__b))
diff --git a/kernel/itimer.c b/kernel/itimer.c
index 58762f7..ba378c6 100644
--- a/kernel/itimer.c
+++ b/kernel/itimer.c
@@ -65,7 +65,7 @@ int do_getitimer(int which, struct itimerval *value)
thread_group_cputimer(tsk, &cputime);
utime = cputime.utime;
if (cputime_le(cval, utime)) { /* about to fire */
- cval = jiffies_to_cputime(1);
+ cval = cputime_one;
} else {
cval = cputime_sub(cval, utime);
}
@@ -85,7 +85,7 @@ int do_getitimer(int which, struct itimerval *value)
thread_group_cputimer(tsk, ×);
ptime = cputime_add(times.utime, times.stime);
if (cputime_le(cval, ptime)) { /* about to fire */
- cval = jiffies_to_cputime(1);
+ cval = cputime_one;
} else {
cval = cputime_sub(cval, ptime);
}
@@ -182,8 +182,7 @@ again:
if (!cputime_eq(cval, cputime_zero) ||
!cputime_eq(nval, cputime_zero)) {
if (cputime_gt(nval, cputime_zero))
- nval = cputime_add(nval,
- jiffies_to_cputime(1));
+ nval = cputime_add(nval, cputime_one);
set_process_cpu_timer(tsk, CPUCLOCK_VIRT,
&nval, &cval);
}
@@ -204,8 +203,7 @@ again:
if (!cputime_eq(cval, cputime_zero) ||
!cputime_eq(nval, cputime_zero)) {
if (cputime_gt(nval, cputime_zero))
- nval = cputime_add(nval,
- jiffies_to_cputime(1));
+ nval = cputime_add(nval, cputime_one);
set_process_cpu_timer(tsk, CPUCLOCK_PROF,
&nval, &cval);
}
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index bece7c0..a86333c 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -1456,7 +1456,7 @@ void set_process_cpu_timer(struct task_struct *tsk, unsigned int clock_idx,
if (!cputime_eq(*oldval, cputime_zero)) {
if (cputime_le(*oldval, now.cpu)) {
/* Just about to fire. */
- *oldval = jiffies_to_cputime(1);
+ *oldval = cputime_one;
} else {
*oldval = cputime_sub(*oldval, now.cpu);
}
diff --git a/kernel/sched.c b/kernel/sched.c
index 26efa47..b17fe3c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4726,17 +4726,16 @@ void account_idle_time(cputime_t cputime)
*/
void account_process_tick(struct task_struct *p, int user_tick)
{
- cputime_t one_jiffy = jiffies_to_cputime(1);
- cputime_t one_jiffy_scaled = cputime_to_scaled(one_jiffy);
+ cputime_t one_jiffy_scaled = cputime_to_scaled(cputime_one);
struct rq *rq = this_rq();
if (user_tick)
- account_user_time(p, one_jiffy, one_jiffy_scaled);
+ account_user_time(p, cputime_one, one_jiffy_scaled);
else if ((p != rq->idle) || (irq_count() != HARDIRQ_OFFSET))
- account_system_time(p, HARDIRQ_OFFSET, one_jiffy,
+ account_system_time(p, HARDIRQ_OFFSET, cputime_one,
one_jiffy_scaled);
else
- account_idle_time(one_jiffy);
+ account_idle_time(cputime_one);
}
/*
^ permalink raw reply related
* Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code
From: Mark Brown @ 2009-05-25 10:51 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <200905250956.28206.jbe@pengutronix.de>
On Mon, May 25, 2009 at 09:56:27AM +0200, Juergen Beisert wrote:
> Do you know this (from our website)?
> "The AC97 mixer needs a hardware patch to make it wake up from power down
> mode. Download here the instruction how to do so."
> http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/TN-015e_1.pdf
This modification should not be required - a warm reset should be enough
to bring the AC97 link up. The current ASoC driver for the WM9712 will
do this automatically - the expectation for non-ASoC systems is that the
warm reset will always be issued.
That said, I'd be surprised if it were the same problem given that
iterating cold resets appears to resolve whatever the issues is.
^ permalink raw reply
* Re: [PATCH V3 0/4] mpc5200 audio rework for AC97
From: Mark Brown @ 2009-05-25 10:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090525013606.3073.86753.stgit@terra>
On Sun, May 24, 2009 at 09:38:45PM -0400, Jon Smirl wrote:
> The following series implements audio support for the mpc5200. It adds an AC97 driver and STAC9766 codec driver.
> Board support for the Efika and Phytec pcm030 are also included.
> I've tried to implement the feedback received on the previous two versions.
Please also add the fixes for the reset code in the CODEC driver that I
asked for.
^ permalink raw reply
* Re: [PATCH V3 2/4] AC97 driver for mpc5200
From: Mark Brown @ 2009-05-25 10:26 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090525013849.3073.96729.stgit@terra>
On Sun, May 24, 2009 at 09:38:49PM -0400, Jon Smirl wrote:
> I've implemented retries for when the AC97 hardware doesn't reset on
> first try. About 10% of the time both the Efika and pcm030 AC97 codecs
> don't reset on first try and need to be poked multiple times. Failure
> is indicated by not having the link clock start ticking. Every once in
> a while even five pokes won't get the link started and I have to power
> cycle.
This smells like either a very broken board or some issue with starting
the master clock for the CODEC - if the CODEC is clocked by the AC97
controller you may need to do something to ensure that it has finished
starting up before initiating the reset.
> +static int psc_ac97_cold_reset_check(struct snd_ac97 *ac97)
> +{
> + int max_reset, timeout;
> + struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
> +
> + /* AC97 clock is generated by the codec.
> + * Ensure that it starts ticking after codec reset.
> + */
The AC97 standard allows CODECs to come out of cold reset with the link
disabled. With those CODECs this is going fail every time - they need a
warm reset to come on-line.
If this really is a general issue with the AC97 controller here you'll
need to do a warm reset in here. It's not ideal but extra warm resets
will cause less harm than completely failing to come on-line.
> +static int psc_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
> + struct snd_soc_dai *dai)
I keep mentioning the indentation issues with your code without seeing
any response from you. If you run checkpatch over your code you'll also
see a bunch of complaints about using spaces instead of tabs for
indentation. It looks for all the world like you're using 4 character
tabs instead of the 8 character tabs which are the kernel standard.
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_STOP:
> + if (substream->pstr->stream == SNDRV_PCM_STREAM_CAPTURE)
> + psc_dma->slots &= 0xFFFF0000;
> + else
> + psc_dma->slots &= 0x0000FFFF;
> +
> + spin_lock(&psc_dma->lock);
> + out_be32(&psc_dma->psc_regs->ac97_slots, psc_dma->slots);
> + spin_unlock(&psc_dma->lock);
> + break;
This locking looks wrong - I'd expect it to also cover the modification
of psc_dma->slots? Otherwise it's hard to see what it buys you.
> + /* AC97 clock is generated by the codec.
> + * Ensure that it starts ticking after codec reset.
> + */
> + rc = psc_ac97_cold_reset_check(&ac97);
> + if (rc != 0) {
> + dev_err(&op->dev, "AC97 codec failed to reset\n");
> + mpc5200_audio_dma_destroy(op);
> + return rc;
> + }
Your AC97 driver should not be doing this - leave it to the card and
CODEC driver to bring things on line.
> +
> + /* Go */
> + out_8(®s->command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE);
As I said last time I'd expect this to be deferred to the ASoC device
probe.
^ permalink raw reply
* Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
From: Mark Brown @ 2009-05-25 9:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090525013851.3073.79847.stgit@terra>
On Sun, May 24, 2009 at 09:38:51PM -0400, Jon Smirl wrote:
> +static __exit void pcm030_fabric_exit(void)
> +{
> +}
Remove or implement, please.
^ permalink raw reply
* Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
From: Mark Brown @ 2009-05-25 9:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40905242334o4867d701n9de332721eb2f3b4@mail.gmail.com>
On Mon, May 25, 2009 at 12:34:57AM -0600, Grant Likely wrote:
> This is ugly. I'd really rather have a generic mechanism for creating
> a fabric driver based on the OF data. But failing that, it seems to
> me that this platform device registration should be done in the
> platform code (arch/powerpc/platforms/52xx). Doing it in a module
> init looks wrong.
It's ugly but it's idiomatic for ASoC until someone has time to
implement multiple card support.
> I was trying to do a sort of generic matching mechanism with the of
> simple stuff; but admittedly it was hacky and half-assed. However, I
It's adequate for the cases it tries to cover, it just needs to be
merged into the core. The problem here is AC97 since it can't be probed
until the platform comes up.
> do still think it is viable to have OF hooks that kick in when codec
> and machine drivers are registered. If linkage data is encoded in the
> device tree, then generic code should be able to hook them up; pulling
> additional data out of the device tree as needed to configure the
> coded.
As I explained in response to Jon's original posting AC97 is a
particular problem here since it can only be probed using the CPU DAI
and may require machine-specific work to set it up prior to use.
There's problems fixing this due to AC97 not having fully developed bus
infrastructure in the kernel at the minute.
^ permalink raw reply
* Re: [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code
From: Mark Brown @ 2009-05-25 9:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40905242326y6a88af84n40f23759661a6cd0@mail.gmail.com>
On Mon, May 25, 2009 at 12:26:27AM -0600, Grant Likely wrote:
> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > +/* ---------------------------------------------------------------------
> > + * Sysfs attributes for error monitoring
> > + */
> All this sysfs stuff should be dropped from this patch. It is an
> abuse of sysfs and I never should have written it this way. Feel free
> to put it in a separate patch so others can use it if they really need
> it, but I'd like it to not be kept in mainline.
If this is going to be kept it should be in debugfs like I said in
response to the v2 posting.
^ permalink raw reply
* Re: U-boot and linux command line parameters
From: Mirek23 @ 2009-05-25 8:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090525000618.GD8059@yookeroo.seuss>
Thank you for your answer. When studying the u-boot source code I have found
that
it is indeed register r6 and r7 which pass the location of the command line
parameters and the
size.
The location of the parameters could be changed in u-boot according to the
macro:
CFG_BOOTMAPSZ
There is however the message in all configuration files for u-boot that
Linux can only map first initial 8MB
so it seems to be not possible to set CFG_BOOTMAPSZ to something higher than
8MB?
/*
* For booting Linux, the board info and command line data
* have to be in the first 8 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
#define CFG_BOOTMAPSZ (8 << 20) /* Initial Memory map for
Linux */
Does somebody have an idea how to bypass this limitation in linux 2.6.23 or
higher?
M.
--
View this message in context: http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23703397.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Wolfgang Grandegger @ 2009-05-25 8:15 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux Netdev List, devicetree-discuss, linuxppc-dev
In-Reply-To: <fa686aa40905242353v21c08209x2e443f42ef4096fa@mail.gmail.com>
Grant Likely wrote:
> On Sat, May 23, 2009 at 10:44 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Wolfgang Grandegger wrote:
>>> Grant Likely wrote:
>>>>> +- clock-frequency : CAN system clock frequency in Hz, which is normally
>>>>> + half of the oscillator clock frequency. If not specified, a
>>>>> + default value of 8000000 (8 MHz) is used.
>>>> A clock-frequency property typically refers to the bus clock
>>>> frequency. Something like can-frequency would be better.
>>> Ah, right, but I'm also not happy with "can-frequency". The manual
>>> speaks about the "internal clock", which is half of the external
>>> oscillator frequency. Maybe "internal-clock-frequency" might be better.
>
> Would it be better to specify the external clock frequency, and the
> driver know that internal freq is half that? I ask because external
> clock freq is a value the HW designer actually has control over.
I'm sharing your arguments: "external-clock-frequency". There is always
some confusion about external and internal clock frequency but the name
should make it clear.
>>>>> +- cdr-reg : value of the SJA1000 clock divider register according to
>>>>> + the SJA1000 data sheet. If not specified, a default value of
>>>>> + 0x48 is used.
>>>> Ewh. The driver should be clueful enough to derive the clock divider
>>>> value given both the bus and can frequencies. I don't like this
>>>> property.
>>> The clock divider register controls the CLKOUT frequency for the
>>> microcontroller another CAN controller and allows to deactivate the
>>> CLKOUT pin. It's not used to configure the CAN bus frequency.
>>>
>>>>> +- ocr-reg : value of the SJA1000 output control register according to
>>>>> + the SJA1000 data sheet. If not specified, a default value of
>>>>> + 0x0a is used.
>>>> Ditto here; the binding should describe the usage mode; not the
>>>> register settings to get the usage mode. What sort of settings will
>>>> the .dts author be writing here?
>>> Unfortunately, there are many:
>>>
>>> clkout-frequency
>>> bypass-comperator
>>> tx1-output-on-rx-irq
>>>
>>> #define OCR_MODE_BIPHASE 0x00
>>> #define OCR_MODE_TEST 0x01
>>> #define OCR_MODE_NORMAL 0x02
>>> #define OCR_MODE_CLOCK 0x03
>>>
>>> #define OCR_TX0_INVERT 0x04
>>> #define OCR_TX0_PULLDOWN 0x08
>>> #define OCR_TX0_PULLUP 0x10
>>> #define OCR_TX0_PUSHPULL 0x18
>>> #define OCR_TX1_INVERT 0x20
>>> #define OCR_TX1_PULLDOWN 0x40
>>> #define OCR_TX1_PULLUP 0x80
>>> #define OCR_TX1_PUSHPULL 0xc0
>>>
>>> I think implementing properties for each option is overkill.
>
> Ugh, I see what you mean.
>
>> Would the following more descriptive properties be OK?
>>
>> clock-out-frequency = <0>, // CLKOUT pin clock off
>> = <4000000>; // frequency on CLKOUT pin
>
> Or how about CLKOUT pin off if the property isn't present? Otherwise,
Yep, that will be the default anyhow.
> this looks okay. BTW, I'd consider prefixing this with 'nxp,' or
> 'sja1000,' to protect the namespace. clock-out-frequency sounds like
> one of those names which could be commonly used in the future. I'd so
> the same for the other chip-specific properties too.
> Segher, what's your opinion on this?
I personally don't have a real preference.
>> bypass-input-comparator; // allows to bypass the CAN input comparator.
>>
>> tx1-output-on-rx-irq; // allows the TX1 output to be used as a
>> // dedicated RX interrupt output.
>>
>> output-control-mode = <0x0> // bi-phase output mode
>> <0x1> // test output mode
>> <0x2> // normal output mode (default)
>> <0x3> // clock output mode
>>
>> output-pin-config = <0x01> // TX0 invert
>> <0x02> // TX0 pull-down
>> <0x04> // TX0 pull-up
>> <0x06> // TX0 push-pull
>> <0x08> // TX1 invert
>> <0x10> // TX1 pull-down
>> <0x20> // TX1 pull-up
>> <0x30> // TX1 push-pull
>
> hmmm; It is very chip specific and it is a lot of mucking around. If
> you prefix the property with the manufacturer name, then perhaps the
> explicit register setting is okay.
OK.
> Are TX0 & TX1 protocol pins or GPIOs? If gpio, then maybe it is worth
> the mucking about to then use the gpios binding to specify the pin
> mode.
These are the output from the CAN output driver 0 or 1 to the physical
bus line. E.g., in normal output mode the CAN bit sequence is sent via
TX0 or TX1. From a non-hardware expert point of view, they must be
programmed properly to get the hardware to work.
Wolfgang.
^ permalink raw reply
* Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code
From: Juergen Beisert @ 2009-05-25 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alsa-devel, broonie
In-Reply-To: <9e4733910905241310n59952fd2oaafd7f1363db324@mail.gmail.com>
Jon,
On Sonntag, 24. Mai 2009, Jon Smirl wrote:
> On Sun, May 24, 2009 at 2:55 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> >> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it
> >> more robust.
> >
> > Why is it more robust?
>
> I've implemented retries for when the AC97 hardware doesn't reset on
> first try. About 10% of the time both the Efika and pcm030 AC97 codecs
> don't reset on first try and need to be poked multiple times. Failure
> is indicated by not having the link clock start ticking. Every once in
> a while even five pokes won't get the link started and I have to power
> cycle.
Do you know this (from our website)?
"The AC97 mixer needs a hardware patch to make it wake up from power down
mode. Download here the instruction how to do so."
http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/TN-015e_1.pdf
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
^ 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