* Re: [Ipw2100-admin] [BUILD FAILURE 04/12] Next April 14 : PPC64 randconfig [drivers/staging/built-in.o]
From: Greg KH @ 2009-04-15 1:06 UTC (permalink / raw)
To: reinette chatre
Cc: sachinp, Stephen Rothwell, Andrea Merello, linux-kernel,
Rafael J. Wysocki, Linuxppc-dev, linux-next,
subrata@linux.vnet.ibm.com, Alexander Beregalov,
James P. Ketrenos
In-Reply-To: <1239735595.15115.60.camel@rc-desk>
On Tue, Apr 14, 2009 at 11:59:55AM -0700, reinette chatre wrote:
> Hi Subrata,
>
> On Tue, 2009-04-14 at 11:28 -0700, Subrata Modak wrote:
> > Observed the following build error:
> > ---
> > LD drivers/built-in.o
> > drivers/staging/built-in.o: In function `ieee80211_xmit':
> > drivers/staging/rtl8187se/ieee80211/ieee80211_tx.c:528: multiple
> > definition of `ieee80211_xmit'
> > drivers/net/built-in.o:drivers/net/wireless/ipw2x00/libipw_tx.c:256:
> > first defined here
> > make[1]: *** [drivers/built-in.o] Error 1
> > make: *** [drivers] Error 2
>
> Looks like the rtl8187se driver started with a copy of ipw2x00's
> library. Errors like this can thus be expected and should be addressed
> by rtl8187se as they are the ones who made the copy.
Yes, at this point in time, don't build the staging drivers into the
kernel, it's not advised at all.
thanks,
greg k-h
^ permalink raw reply
* Re: [BUILD FAILURE 02/12] Next April 14 : PPC64 randconfig [arch/powerpc/kernel/of_platform.c]
From: Michael Ellerman @ 2009-04-15 1:37 UTC (permalink / raw)
To: subrata
Cc: sachinp, Stephen Rothwell, linux-kernel, Rafael J. Wysocki,
Linuxppc-dev, linux-next, Alexander Beregalov
In-Reply-To: <1239733694.5344.74.camel@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
On Tue, 2009-04-14 at 23:58 +0530, Subrata Modak wrote:
> Observed the following build error:
> ---
> arch/powerpc/kernel/of_platform.c: In function ‘of_pci_phb_probe’:
> arch/powerpc/kernel/of_platform.c:270: error: implicit declaration of
> function ‘pci_devs_phb_init_dynamic’
> arch/powerpc/kernel/of_platform.c:279: error: implicit declaration of
> function ‘scan_phb’
> arch/powerpc/kernel/of_platform.c:295: error: implicit declaration of
> function ‘pci_bus_add_devices’
> make[1]: *** [arch/powerpc/kernel/of_platform.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
> ---
>
> I saw some discussion(s) happening last year, but could not find out if
> some fixes are already available:
> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg26215.html,
It's a different problem.
You have CONFIG_PPC_OF_PLATFORM_PCI=y but CONFIG_PCI=n.
That's because PPC_CELL_NATIVE selects PLATFORM_PCI, without regard to
whether PCI is enabled.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Please pull from 'merge' branch (for 2.6.30)
From: Paul Mackerras @ 2009-04-15 3:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0904141142240.1013@localhost.localdomain>
Kumar Gala writes:
> Please pull from 'merge' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
Thanks, pulled. I'll collect up a few more patches for .30 and send
Linus a pull request shortly.
By the way, I'm not planning to run test or next branches while Ben is
away. He'll be back in plenty of time to collect the patches for .31
before the next merge window.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: VRM unused page hinting
From: Paul Mackerras @ 2009-04-15 4:46 UTC (permalink / raw)
To: Robert Jennings; +Cc: Brian King, linuxppc-dev
In-Reply-To: <20090414013741.GA8678@austin.ibm.com>
Robert Jennings writes:
> Adds support for the "unused" page hint which can be used in shared
> memory partitions to flag pages not in use, which will then be stolen
> before active pages by the hypervisor when memory needs to be moved to
> LPARs in need of additional memory. Failure to mark pages as 'unused'
> makes the LPAR slower to give up unused memory to other partitions.
The patch also adds a kernel command line option. That should be
mentioned in the patch description and documented in
Documentation/kernel-parameters.txt. Also, I'd like you to choose a
better name for the kernel command line option than "cmma", which is
completely opaque to me -- it doesn't seem to be the name or even the
initials of anything in the patch. Presumably it's somehow related to
CMO, but just how is not at all clear.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] keywest: Convert to new-style i2c driver
From: Paul Mackerras @ 2009-04-15 4:57 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090410170726.3616b6d5@hyperion.delvare>
Jean Delvare writes:
> The legacy i2c binding model is going away soon,
But not before 2.6.30, right?
Paul.
^ permalink raw reply
* Re: Please pull from 'merge' branch (for 2.6.30)
From: Kumar Gala @ 2009-04-15 6:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18917.21789.425744.170039@drongo.ozlabs.ibm.com>
On Apr 14, 2009, at 10:31 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Please pull from 'merge' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
>
> Thanks, pulled. I'll collect up a few more patches for .30 and send
> Linus a pull request shortly.
>
> By the way, I'm not planning to run test or next branches while Ben is
> away. He'll be back in plenty of time to collect the patches for .31
> before the next merge window.
that's fine. I figured as much for next.
- k
^ permalink raw reply
* pci32 code - early_*config*
From: Kumar Gala @ 2009-04-15 6:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development
Ben,
I was looking at what I need to get some additional bits of PCI code
building w/your ppc64 booke patches. One thing it looks like we need
is the early config cycle code. The question I have is do we think we
still need the null_ops support? Also do we think we every get called
with a NULL hose?
This is fake_pci_bus() in arch/powerpc/kernel/pci_32.c
- k
^ permalink raw reply
* Re: [PATCH] Set error_state to pci_channel_io_normal in eeh_report_reset()
From: Paul Mackerras @ 2009-04-15 6:08 UTC (permalink / raw)
To: Mike Mason; +Cc: linuxppc-dev, linasvepstas
In-Reply-To: <49DF967F.4000205@us.ibm.com>
Mike Mason writes:
> diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c
> b/arch/powerpc/platforms/pseries/eeh_driver.c
> index 380420f..9a2a6e3 100644
> --- a/arch/powerpc/platforms/pseries/eeh_driver.c
> +++ b/arch/powerpc/platforms/pseries/eeh_driver.c
> @@ -182,6 +182,8 @@ static void eeh_report_reset(struct pci_dev *dev,
> void *userdata)
> if (!driver)
> return;
>
> + dev->error_state = pci_channel_io_normal;
> +
> eeh_enable_irq(dev);
>
> if (!driver->err_handler ||
Your mail client totally mangled the whitespace. I fixed it up and
applied it, since the patch was small, but in future please fix your
mail client so it doesn't do that.
It sounds like this patch needs to be applied to earlier kernel
versions -- do you agree?
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] keywest: Convert to new-style i2c driver
From: Jean Delvare @ 2009-04-15 7:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <18917.26938.10873.119892@drongo.ozlabs.ibm.com>
Hi Paul,
On Wed, 15 Apr 2009 14:57:30 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
>
> > The legacy i2c binding model is going away soon,
>
> But not before 2.6.30, right?
Ideally, yes, before 2.6.30. This is what
Documentation/feature-removal-schedule.txt says:
---------------------------
What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client(),
i2c_adapter->client_register(), i2c_adapter->client_unregister
When: 2.6.30
Check: i2c_attach_client i2c_detach_client
Why: Deprecated by the new (standard) device driver binding model. Use
i2c_driver->probe() and ->remove() instead.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
There are only 10 legacy i2c drivers remaining (not counting staging),
9 of which are ppc drivers. My hope was that ppc developers would see
the deprecation warning and convert the drivers themselves, but it did
not happen. Which is why I am trying to do it myself now, admittedly
quite late in the 2.6.30 development cycle.
This seems doable to me if my patches get proper testing fast (which
seems to be the case, thanks!) and positive results (not true for onyx,
but tas and therm_pm72 are apparently OK). Now I know I have to be
realistic, if problems arise and/or ppc people feel too bad about me
pushing these patches at about rc3 time, I will refrain from doing so
and wait for 2.6.31. But there are a number or i2c-core improvements
other developers are asking for for quite some times now, which depend
on the removal of the legacy model, so delaying this wound not make me
happy at all.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] powerpc: Fix bug in __futex_atomic_op
From: Norbert van Bolhuis @ 2009-04-15 7:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Richard Henderson
In-Reply-To: <18915.54309.632699.346771@cargo.ozlabs.ibm.com>
I'd like to understand the implications of this bug.
Obviously applications using the futex system can be affected, but
does anybody know whether GNU software packages suffer from this problem.
I mean glibc (nptl) uses futexes, so does gdb and gcc. will this bug hurt
them ?
Paul Mackerras wrote:
> Richard Henderson pointed out that the powerpc __futex_atomic_op has a
> bug: it will write the wrong value if the stwcx. fails and it has to
> retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten
> by the result from the first time around the loop. This happens
> because it uses the same register for 'oparg' (an input) as it uses
> for the result.
>
> This fixes it by using separate registers for 'oparg' and 'ret'.
>
> Cc: stable@kernel.org
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Can anyone see any reason why the FUTEX_OP_SET case can't just do a
> __put_user?
>
> diff --git a/arch/powerpc/include/asm/futex.h b/arch/powerpc/include/asm/futex.h
> index 6d406c5..9696cc3 100644
> --- a/arch/powerpc/include/asm/futex.h
> +++ b/arch/powerpc/include/asm/futex.h
> @@ -27,7 +27,7 @@
> PPC_LONG "1b,4b,2b,4b\n" \
> ".previous" \
> : "=&r" (oldval), "=&r" (ret) \
> - : "b" (uaddr), "i" (-EFAULT), "1" (oparg) \
> + : "b" (uaddr), "i" (-EFAULT), "r" (oparg) \
> : "cr0", "memory")
>
> static inline int futex_atomic_op_inuser (int encoded_op, int __user *uaddr)
> @@ -47,19 +47,19 @@ static inline int futex_atomic_op_inuser (int encoded_op, int __user *uaddr)
>
> switch (op) {
> case FUTEX_OP_SET:
> - __futex_atomic_op("", ret, oldval, uaddr, oparg);
> + __futex_atomic_op("mr %1,%4\n", ret, oldval, uaddr, oparg);
> break;
> case FUTEX_OP_ADD:
> - __futex_atomic_op("add %1,%0,%1\n", ret, oldval, uaddr, oparg);
> + __futex_atomic_op("add %1,%0,%4\n", ret, oldval, uaddr, oparg);
> break;
> case FUTEX_OP_OR:
> - __futex_atomic_op("or %1,%0,%1\n", ret, oldval, uaddr, oparg);
> + __futex_atomic_op("or %1,%0,%4\n", ret, oldval, uaddr, oparg);
> break;
> case FUTEX_OP_ANDN:
> - __futex_atomic_op("andc %1,%0,%1\n", ret, oldval, uaddr, oparg);
> + __futex_atomic_op("andc %1,%0,%4\n", ret, oldval, uaddr, oparg);
> break;
> case FUTEX_OP_XOR:
> - __futex_atomic_op("xor %1,%0,%1\n", ret, oldval, uaddr, oparg);
> + __futex_atomic_op("xor %1,%0,%4\n", ret, oldval, uaddr, oparg);
> break;
> default:
> ret = -ENOSYS;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] stop send queue before resetting gianfar
From: Markus Brunner @ 2009-04-15 7:51 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: netdev, rini, Andy Fleming
After a transmit timed out, the reset task will be called, which will free the
allocated resources(stop_gfar). If gfar_poll will be called before the
resources get allocated again gfar_clean_tx_ring will call
dev_kfree_skb_any(NULL).
This Patch calls netif_stop_queue before calling stop_gfar.
Signed-off-by: Markus Brunner <super.firetwister@gmail.com>
---
ops: Kernel access of bad area, sig: 11 [#1]
PREEMPT RSBBA100
Modules linked in:
NIP: c01a10c4 LR: c013b254 CTR: c013c038
REGS: c02e7d20 TRAP: 0300 Not tainted (2.6.27.20)
MSR: 00001032 <ME,IR,DR> CR: 24000082 XER: 20000000
DAR: 000000a0, DSISR: 20000000
TASK = c02ce578[0] 'swapper' THREAD: c02e6000
GPR00: 000000a0 c02e7dd0 c02ce578 00000000 00000040 00000001 c02ec1c0
00001032
GPR08: c080d1e0 df9ea800 00000000 00000000 24000082 ffffffff 0404f000
00000000
GPR16: ffffffbf ffffffff ffffffff ffdff7ff ffffffff c02d0fd4 00100100
00200200
GPR24: c031220c 00000001 00000001 00000000 00000000 df849800 ff109000
df849b80
NIP [c01a10c4] dev_kfree_skb_irq+0x18/0x70
LR [c013b254] gfar_clean_tx_ring+0x70/0x11c
Call Trace:
[c02e7dd0] [c003e978] update_wall_time+0x730/0x744 (unreliable)
[c02e7df0] [c013b254] gfar_clean_tx_ring+0x70/0x11c
[c02e7e10] [c013c07c] gfar_poll+0x44/0x150
[c02e7e30] [c01a064c] net_rx_action+0xa8/0x19c
[c02e7e70] [c00251d4] __do_softirq+0x64/0xc0
[c02e7e90] [c0006384] do_softirq+0x40/0x58
[c02e7ea0] [c00250a8] irq_exit+0x40/0x9c
[c02e7eb0] [c000642c] do_IRQ+0x90/0xac
[c02e7ec0] [c0010ab4] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x9c/0xf8
LR = cpu_idle+0x9c/0xf8
[c02e7f80] [c0009820] cpu_idle+0x58/0xf8 (unreliable)
[c02e7fa0] [c01fb8c8] __got2_end+0x7c/0x90
[c02e7fc0] [c026c794] start_kernel+0x2c0/0x2d4
[c02e7ff0] [00003438] 0x3438
Instruction dump:
7fa00124 80010024 bba10014 38210020 7c0803a6 4e800020 9421ffe0 7c0802a6
7c6b1b78 90010024 380300a0 bfa10014 <7d200028> 3129ffff 7d20012d 40a2fff4
Kernel panic - not syncing: Fatal exception in interrupt
--- linux-2.6.29/drivers/net/gianfar.c.orig 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/drivers/net/gianfar.c 2009-04-15 09:47:04.000000000 +0200
@@ -1534,8 +1534,10 @@ static void gfar_reset_task(struct work_
struct net_device *dev = priv->dev;
if (dev->flags & IFF_UP) {
+ netif_stop_queue(dev);
stop_gfar(dev);
startup_gfar(dev);
+ netif_start_queue(dev);
}
netif_tx_schedule_all(dev);
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Jean Delvare @ 2009-04-15 8:19 UTC (permalink / raw)
To: Andreas Schwab
Cc: Takashi Iwai, linuxppc-dev, Johannes Berg, Benjamin, alsa-devel
In-Reply-To: <m2prfe26on.fsf@igel.home>
On Wed, 15 Apr 2009 00:48:08 +0200, Andreas Schwab wrote:
> Jean Delvare <khali@linux-fr.org> writes:
>
> > Hi Johannes,
> >
> > On Tue, 14 Apr 2009 19:41:55 +0200, Johannes Berg wrote:
> >> Alright, with the patch Andreas pointed out it loads, but segfaults, as
> >> below. Works fine without your patch.
> >
> > Thanks for the quick test and sorry that it didn't work. I'll take a
> > look at the trace below and try to figure out what went wrong.
> >
> > Did you remove the 2 MODULE_DEVICE_TABLE from my patch? If you didn't,
> > please pick the latest version of my patch which doesn't have them:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/sound-aoa-codecs-convert-to-new-style.patch
> > I don't think they are the reason of the crash, but who knows...
>
> I tried with a tas-based iBook, and it works fine here.
Good news, thanks Andreas!
--
Jean Delvare
^ permalink raw reply
* Patch 1/2: Add support for Xilinx PLB PCI soft-core [attempt2]
From: Roderick Colenbrander @ 2009-04-15 8:40 UTC (permalink / raw)
To: linuxppc-dev
Hi,
This is an updated version of the patch which takes into account a few changes suggested by Grant which I forgot to add.
Regards,
Roderick Colenbrander
>From 2b34a315b18834448c0a8218d4da85ffaf76039e Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander <thunderbird2k@gmail.com>
Date: Tue, 14 Apr 2009 15:45:07 +0200
Subject: [PATCH] Add support for the Xilinx PLB PCI soft-core which is used on Xilinx ML410 and ML510 FPGA boards.
---
arch/powerpc/sysdev/Kconfig | 4 ++
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/virtex_pci.c | 99 ++++++++++++++++++++++++++++++++++++++
3 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/virtex_pci.c
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..2d0be14 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -12,3 +12,7 @@ config PPC_MSI_BITMAP
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+
+config XILINX_VIRTEX_PCI
+ bool
+ depends on PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..b93794e 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_VIRTEX_PCI) += virtex_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/virtex_pci.c b/arch/powerpc/sysdev/virtex_pci.c
new file mode 100644
index 0000000..b5137b5
--- /dev/null
+++ b/arch/powerpc/sysdev/virtex_pci.c
@@ -0,0 +1,99 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * 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/pci.h>
+#include <mm/mmu_decl.h>
+#include <asm/io.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 void fixup_virtex_pci_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_device_is_compatible(hose->dn, "xlnx,plbv46-pci-1.03.a"))
+ 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, "PCI: Hiding Xilinx plb-pci host bridge resources %s\n", pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, fixup_virtex_pci_bridge);
+
+void virtex_pci_init(void)
+{
+ struct pci_controller *hose;
+ struct resource r;
+ void __iomem *pci_reg;
+ struct device_node *pci_node = of_find_compatible_node(NULL, NULL, "xlnx,plbv46-pci-1.03.a");
+
+ if(!pci_node)
+ return;
+
+ printk("Found a Xilinx plb-pci host bridge\n");
+
+ if(of_address_to_resource(pci_node, 0, &r))
+ {
+ printk("No address for Xilinx plb-pci host bridge\n");
+ return;
+ }
+
+ hose = pcibios_alloc_controller(pci_node);
+ if (!hose)
+ return;
+
+ hose->first_busno = 0;
+ hose->last_busno = 0;
+
+ /* 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);
+
+ /* Register the host bridge with the linux kernel! */
+ pci_process_bridge_OF_ranges(hose, pci_node, 1);
+}
--
1.5.6.3
^ permalink raw reply related
* Patch 2/2: Add Xilinx ML510 reference design support [attempt2]
From: Roderick Colenbrander @ 2009-04-15 8:42 UTC (permalink / raw)
To: linuxppc-dev
Hi,
This is an updated version of my patch from yesterday it contains some fixes. I had some c++ style comments
left in my previous version of this patch and there was a small error in the dts file.
Regards,
Roderick Colenbrander
>From 018041061bc233c09340eff20fcd4e8bc75da1d3 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander <thunderbird2k@gmail.com>
Date: Tue, 14 Apr 2009 15:49:32 +0200
Subject: [PATCH] Add Xilinx ML510 reference design support.
---
arch/powerpc/boot/dts/virtex440-ml510.dts | 452 +++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/Kconfig | 10 +
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/ml510.c | 165 +++++++++++
4 files changed, 628 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/platforms/44x/ml510.c
diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 0000000..908517a
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,452 @@
+/*
+ * 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";
+ dcr-parent = <&ppc440_0>;
+ model = "testing";
+ 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 this value to 0xa0000000, so that inbound and outbound pci transactions
+ * work properly including DMA.
+ */
+ ranges = <0x02000000 0x00000000 0xa0000000 0xa0000000 0x00000000 0x20000000
+ 0x01000000 0x00000000 0x00000000 0xf0000000 0x00000000 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.
+ */
+ /* 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";
+
+ /* The south bridge connection 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>;
+ } ;
+ } ;
+} ;
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index bf5c7ff..cf706a7 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -171,6 +171,16 @@ 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 Reference Design support"
+ depends on 44x
+ default n
+ select XILINX_VIRTEX_5_FXT
+ select PPC_PCI_CHOICE
+ select XILINX_VIRTEX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+
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..6793f4e 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) += ml510.o
diff --git a/arch/powerpc/platforms/44x/ml510.c b/arch/powerpc/platforms/44x/ml510.c
new file mode 100644
index 0000000..3e64f5a
--- /dev/null
+++ b/arch/powerpc/platforms/44x/ml510.c
@@ -0,0 +1,165 @@
+/*
+ * Xilinx ML510 Reference Design support, derived from
+ * the generic Xilinx Virtex 5 board support
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ * Copyright 2008 Xilinx, Inc.
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * The i8259 cascade code was derived from 86xx/pic.c which is copyrighted by Freescale Semiconductor, Inc.
+ * Xilinx ML510 PCI initialization code, derived from the Xilinx ML300/ML410 based board support.
+ *
+ * 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/init.h>
+#include <linux/of_platform.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/time.h>
+#include <asm/xilinx_intc.h>
+#include <asm/reg.h>
+#include <asm/ppc4xx.h>
+#ifdef CONFIG_PPC_I8259
+#include <asm/i8259.h>
+#endif
+#ifdef CONFIG_PCI
+#include <linux/pci.h>
+#endif
+#include "44x.h"
+
+static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = "simple-bus", },
+ { .compatible = "xlnx,plb-v46-1.00.a", },
+ { .compatible = "xlnx,plb-v46-1.02.a", },
+ { .compatible = "xlnx,plb-v34-1.01.a", },
+ { .compatible = "xlnx,plb-v34-1.02.a", },
+ { .compatible = "xlnx,opb-v20-1.10.c", },
+ { .compatible = "xlnx,dcr-v29-1.00.a", },
+ { .compatible = "xlnx,compound", },
+ {}
+};
+
+#ifdef CONFIG_PPC_I8259
+static void ml510_8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ /* Let xilinx_intc end the interrupt */
+ desc->chip->ack(irq);
+ desc->chip->unmask(irq);
+}
+
+static void __init ml510_setup_i8259_cascade(void)
+{
+ struct device_node *np, *cascade_node = NULL;
+ int cascade_irq;
+
+ /* Initialize i8259 controller */
+ for_each_node_by_type(np, "interrupt-controller")
+ if (of_device_is_compatible(np, "chrp,iic")) {
+ cascade_node = np;
+ break;
+ }
+
+ if (cascade_node == NULL) {
+ printk(KERN_DEBUG "Could not find i8259 PIC\n");
+ return;
+ }
+
+ cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+ if (cascade_irq == NO_IRQ) {
+ printk(KERN_ERR "Failed to map cascade interrupt\n");
+ return;
+ }
+
+ i8259_init(cascade_node, 0);
+
+ of_node_put(cascade_node);
+ set_irq_chained_handler(cascade_irq, ml510_8259_cascade);
+}
+#endif /* CONFIG_PPC_I8259 */
+
+#ifdef CONFIG_PCI
+static int ml510_pci_exclude_device(struct pci_controller *hose, u_char bus, u8 devfn)
+{
+ if (bus != 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ else
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static void __devinit 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, ali_quirk);
+#endif /* CONFIG_PCI */
+
+static int __init ml510_device_probe(void)
+{
+ of_platform_bus_probe(NULL, xilinx_of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(ml510, ml510_device_probe);
+
+static int __init ml510_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "xlnx,ml510-ref-design");
+}
+
+void virtex_pci_init(void);
+static void __init ml510_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ /* Register the host bridge */
+ virtex_pci_init();
+#endif /* CONFIG_PCI */
+}
+
+static void ml510_init_IRQ(void)
+{
+ xilinx_intc_init_tree();
+
+#ifdef CONFIG_PPC_I8259
+ /* The devices on the ALI M1553 south bridge are connected to an internal i8259 */
+ ml510_setup_i8259_cascade();
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+#endif /* CONFIG_PPC_I8259 */
+}
+
+define_machine(ml510) {
+ .name = "Xilinx ML510 Reference Design support",
+ .probe = ml510_probe,
+ .setup_arch = ml510_setup_arch,
+ .pci_exclude_device = ml510_pci_exclude_device,
+ .init_IRQ = ml510_init_IRQ,
+ .get_irq = xilinx_intc_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc4xx_reset_system,
+};
--
1.5.6.3
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2009-04-15 9:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug fixes, a documentation update and a
defconfig update for powerpc.
The commit from Hugh Dickins is not strictly a bugfix, but it is
small, obvious, only affects people using a very specialized embedded
setup (those using 256kB pages on PPC44x embedded systems), and I got
prodded by Andrew Morton about it, so I put it in.
Thanks,
Paul.
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 46 +++++--
arch/powerpc/Kconfig | 2
arch/powerpc/boot/dts/tqm8540.dts | 4 -
arch/powerpc/boot/dts/tqm8541.dts | 4 -
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 8 +
arch/powerpc/boot/dts/tqm8548.dts | 8 +
arch/powerpc/boot/dts/tqm8555.dts | 4 -
arch/powerpc/boot/dts/tqm8560.dts | 4 -
arch/powerpc/configs/85xx/tqm8548_defconfig | 164 +++++++-----------------
arch/powerpc/include/asm/futex.h | 12 +-
arch/powerpc/include/asm/mmu.h | 6 +
arch/powerpc/include/asm/ppc-opcode.h | 13 ++
arch/powerpc/kernel/cputable.c | 2
arch/powerpc/mm/tlb_nohash.c | 1
arch/powerpc/mm/tlb_nohash_low.S | 14 ++
arch/powerpc/platforms/pseries/dtl.c | 1
arch/powerpc/platforms/pseries/eeh_driver.c | 2
include/linux/fsl_devices.h | 4 -
18 files changed, 136 insertions(+), 163 deletions(-)
Hugh Dickins (1):
powerpc: Allow 256kB pages with SHMEM
Kumar Gala (3):
powerpc: Fix tlbilx opcode
powerpc: Add support for early tlbilx opcode
powerpc/mm: Fix compile warning
Mike Mason (1):
powerpc/pseries: Set error_state to pci_channel_io_normal in eeh_report_reset()
Paul Mackerras (1):
powerpc: Fix data-corrupting bug in __futex_atomic_op
Sachin Sant (1):
powerpc: pseries/dtl.c should include asm/firmware.h
Wolfgang Grandegger (4):
powerpc/85xx: TQM85xx: correct address of LM75 I2C device nodes
powerpc/85xx: TQM8548: use proper phy-handles for enet2 and enet3
powerpc/85xx: TQM8548: update defconfig
powerpc: Document new FSL I2C bindings and cleanup
^ permalink raw reply
* Re: [PATCH] stop send queue before resetting gianfar
From: David Miller @ 2009-04-15 9:35 UTC (permalink / raw)
To: super.firetwister; +Cc: Linuxppc-dev, rini, afleming, netdev
In-Reply-To: <200904150951.23711.super.firetwister@gmail.com>
From: Markus Brunner <super.firetwister@googlemail.com>
Date: Wed, 15 Apr 2009 09:51:23 +0200
> After a transmit timed out, the reset task will be called, which will free the
> allocated resources(stop_gfar). If gfar_poll will be called before the
> resources get allocated again gfar_clean_tx_ring will call
> dev_kfree_skb_any(NULL).
> This Patch calls netif_stop_queue before calling stop_gfar.
>
> Signed-off-by: Markus Brunner <super.firetwister@gmail.com>
Applied, thanks.
^ permalink raw reply
* Looking for good supported South bridge for mpc6841d
From: Zhivko Yordanov @ 2009-04-15 11:23 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm on designing of a new embedded board, based on mpc6841d and South Bridg=
e=20
ULi M1575. As =D0=B0 reference design, I use Freescale HPCN board. However =
after=20
consult with chip's distributor, it became clear that the M1575 is already=
=20
discounted. Now I'm in looking of an another solution. Can somebody recomme=
nd=20
me an alternative, good supported from u-boot and have SATA, USB, Audio on=
=20
it? The chip must be connected with mpc6841d over PCI-Express.
Best regarsds,
Yordanov
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Jean Delvare @ 2009-04-15 12:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: Benjamin, linuxppc-dev, alsa-devel, Takashi Iwai
In-Reply-To: <1239746399.4205.21.camel@johannes.local>
On Tue, 14 Apr 2009 23:59:59 +0200, Johannes Berg wrote:
> Hi Jean,
>
> > Thanks for the quick test and sorry that it didn't work. I'll take a
> > look at the trace below and try to figure out what went wrong.
>
> No worries, seems some error path is going wrong but I can't see what it
> is right now.
>
> > Did you remove the 2 MODULE_DEVICE_TABLE from my patch? If you didn't,
> > please pick the latest version of my patch which doesn't have them:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/sound-aoa-codecs-convert-to-new-style.patch
> > I don't think they are the reason of the crash, but who knows...
>
> No, I didn't, but I was loading the modules manually so that didn't kick
> in.
>
> > Are you using a machine with onyx or tas? I guess onyx but I want to be
> > sure.
>
> onyx only.
>
> > > [ 10.267137] snd-aoa-codec-onyx: found pcm3052
> > > [ 10.267238] PM: Adding info for i2c:2-0046
> > > [ 10.267926] snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> >
> > Does this error also happen without my patch? It would help to see the
> > logs without my patch to see where it starts diverging.
>
> Yes -- this happens normally.
OK. I couldn't see how my patch would cause this error, so if it was
already there before, it's good news.
> > > [ 10.267930] snd-aoa: fabric didn't like codec onyx
> > > [ 10.268041] aoa_codec_onyx: probe of 2-0046 failed with error -22
> >
> > Apparently aoa_codec_register failed in onyx_i2c_probe(), I have to
> > understand why.
>
> Because the device-tree is broken -- there are two nodes for the same
> device, and only one of them can be used. Then the fabric rejects the
> first instantiation from the broken node. Here's how it looks normally:
>
> ...
> [ 10.398296] snd-aoa-codec-onyx: found pcm3052
> [ 10.398472] PM: Adding info for i2c:2-0046
> [ 10.412189] snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> [ 10.462593] snd-aoa: fabric didn't like codec onyx
> [ 10.468030] PM: Removing info for i2c:2-0046
> [ 10.473892] snd-aoa-codec-onyx: found pcm3052
> [ 10.479317] PM: Adding info for i2c:3-0046
> [ 10.485631] snd-aoa-fabric-layout: can use this codec
> ...
OK, I understand better what is going on now. I do not understand the
crash at the end though, but I suspect it isn't a bug in my code but
simply a faulty error path which had never been taken before.
Now, the fact that there are two nodes, one right and one wrong, is
quite a problem. My code expected the device tree to be trustworthy.
The new i2c binding model cleanly separates the instantiation of
devices and their binding to a driver. The codec check which fails,
will cause the i2c device to not bind to its driver, but it will still
be present, while there is no underlying physical I2C device if I
understand properly. In the new i2c model, you have to ensure that an
i2c device exists _before_ you instantiate it.
Well, there is a dirty workaround, which I will apply for now, but...
ideally the layout factory should be revisited so that the codec check
happens earlier. Is this something you could help with?
That's something which isn't too clear to me: is there a physical
device at 2-0046 and 3-0046? The onyx codec is accepted for the latter,
however it seems that the test of a device presence at 2-0046 succeeds
as well...
--
Jean Delvare
^ permalink raw reply
* [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers (v3)
From: Jean Delvare @ 2009-04-15 12:22 UTC (permalink / raw)
To: linuxppc-dev, Johannes Berg; +Cc: Takashi Iwai, alsa-devel
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: Andreas Schwab <schwab@linux-m68k.org>
---
Johannes, this is a reworked patch which assumes that the onyx codec
probing can fail. It's not exactly clean but that's the easiest
approach for now. Can you please give it a try? Thanks.
sound/aoa/codecs/onyx.c | 76 ++++++++++++++++++++++++++++++++---------------
sound/aoa/codecs/tas.c | 66 +++++++++++++++++++++++++---------------
2 files changed, 95 insertions(+), 47 deletions(-)
--- linux-2.6.30-rc2.orig/sound/aoa/codecs/onyx.c 2009-04-15 09:55:20.000000000 +0200
+++ linux-2.6.30-rc2/sound/aoa/codecs/onyx.c 2009-04-15 14:07:50.000000000 +0200
@@ -47,7 +47,7 @@ MODULE_DESCRIPTION("pcm3052 (onyx) codec
struct onyx {
/* cache registers 65 to 80, they are write-only! */
u8 cache[16];
- struct i2c_client i2c;
+ struct i2c_client *i2c;
struct aoa_codec codec;
u32 initialised:1,
spdif_locked:1,
@@ -72,7 +72,7 @@ static int onyx_read_register(struct ony
*value = onyx->cache[reg-FIRSTREGISTER];
return 0;
}
- v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
+ v = i2c_smbus_read_byte_data(onyx->i2c, reg);
if (v < 0)
return -1;
*value = (u8)v;
@@ -84,7 +84,7 @@ static int onyx_write_register(struct on
{
int result;
- result = i2c_smbus_write_byte_data(&onyx->i2c, reg, value);
+ result = i2c_smbus_write_byte_data(onyx->i2c, reg, value);
if (!result)
onyx->cache[reg-FIRSTREGISTER] = value;
return result;
@@ -996,12 +996,45 @@ static void onyx_exit_codec(struct aoa_c
onyx->codec.soundbus_dev->detach_codec(onyx->codec.soundbus_dev, onyx);
}
-static struct i2c_driver onyx_driver;
-
static int onyx_create(struct i2c_adapter *adapter,
struct device_node *node,
int addr)
{
+ struct i2c_board_info info;
+ struct i2c_client *client;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
+ info.addr = addr;
+ info.platform_data = node;
+ client = i2c_new_device(adapter, &info);
+ if (!client)
+ return -ENODEV;
+
+ /*
+ * We know the driver is already loaded, so the device should be
+ * already bound. If not it means binding failed, which suggests
+ * the device doesn't really exist and should be deleted.
+ * Ideally this would be replaced by better checks _before_
+ * instantiating the device.
+ */
+ if (!client->driver) {
+ i2c_unregister_device(client);
+ return -ENODEV;
+ }
+
+ /*
+ * Let i2c-core delete that device on driver removal.
+ * This is safe because i2c-core holds the core_lock mutex for us.
+ */
+ list_add_tail(&client->detected, &client->driver->clients);
+ return 0;
+}
+
+static int onyx_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device_node *node = client->dev.platform_data;
struct onyx *onyx;
u8 dummy;
@@ -1011,20 +1044,12 @@ static int onyx_create(struct i2c_adapte
return -ENOMEM;
mutex_init(&onyx->mutex);
- onyx->i2c.driver = &onyx_driver;
- onyx->i2c.adapter = adapter;
- onyx->i2c.addr = addr & 0x7f;
- strlcpy(onyx->i2c.name, "onyx audio codec", I2C_NAME_SIZE);
-
- if (i2c_attach_client(&onyx->i2c)) {
- printk(KERN_ERR PFX "failed to attach to i2c\n");
- goto fail;
- }
+ onyx->i2c = client;
+ i2c_set_clientdata(client, onyx);
/* we try to read from register ONYX_REG_CONTROL
* to check if the codec is present */
if (onyx_read_register(onyx, ONYX_REG_CONTROL, &dummy) != 0) {
- i2c_detach_client(&onyx->i2c);
printk(KERN_ERR PFX "failed to read control register\n");
goto fail;
}
@@ -1036,14 +1061,14 @@ static int onyx_create(struct i2c_adapte
onyx->codec.node = of_node_get(node);
if (aoa_codec_register(&onyx->codec)) {
- i2c_detach_client(&onyx->i2c);
goto fail;
}
printk(KERN_DEBUG PFX "created and attached onyx instance\n");
return 0;
fail:
+ i2c_set_clientdata(client, NULL);
kfree(onyx);
- return -EINVAL;
+ return -ENODEV;
}
static int onyx_i2c_attach(struct i2c_adapter *adapter)
@@ -1080,28 +1105,33 @@ static int onyx_i2c_attach(struct i2c_ad
return onyx_create(adapter, NULL, 0x47);
}
-static int onyx_i2c_detach(struct i2c_client *client)
+static int onyx_i2c_remove(struct i2c_client *client)
{
- struct onyx *onyx = container_of(client, struct onyx, i2c);
- int err;
+ struct onyx *onyx = i2c_get_clientdata(client);
- if ((err = i2c_detach_client(client)))
- return err;
aoa_codec_unregister(&onyx->codec);
of_node_put(onyx->codec.node);
if (onyx->codec_info)
kfree(onyx->codec_info);
+ i2c_set_clientdata(client, onyx);
kfree(onyx);
return 0;
}
+static const struct i2c_device_id onyx_i2c_id[] = {
+ { "aoa_codec_onyx", 0 },
+ { }
+};
+
static struct i2c_driver onyx_driver = {
.driver = {
.name = "aoa_codec_onyx",
.owner = THIS_MODULE,
},
.attach_adapter = onyx_i2c_attach,
- .detach_client = onyx_i2c_detach,
+ .probe = onyx_i2c_probe,
+ .remove = onyx_i2c_remove,
+ .id_table = onyx_i2c_id,
};
static int __init onyx_init(void)
--- linux-2.6.30-rc2.orig/sound/aoa/codecs/tas.c 2009-04-15 09:55:20.000000000 +0200
+++ linux-2.6.30-rc2/sound/aoa/codecs/tas.c 2009-04-15 09:56:39.000000000 +0200
@@ -82,7 +82,7 @@ MODULE_DESCRIPTION("tas codec driver for
struct tas {
struct aoa_codec codec;
- struct i2c_client i2c;
+ struct i2c_client *i2c;
u32 mute_l:1, mute_r:1 ,
controls_created:1 ,
drc_enabled:1,
@@ -108,9 +108,9 @@ static struct tas *codec_to_tas(struct a
static inline int tas_write_reg(struct tas *tas, u8 reg, u8 len, u8 *data)
{
if (len == 1)
- return i2c_smbus_write_byte_data(&tas->i2c, reg, *data);
+ return i2c_smbus_write_byte_data(tas->i2c, reg, *data);
else
- return i2c_smbus_write_i2c_block_data(&tas->i2c, reg, len, data);
+ return i2c_smbus_write_i2c_block_data(tas->i2c, reg, len, data);
}
static void tas3004_set_drc(struct tas *tas)
@@ -882,12 +882,34 @@ static void tas_exit_codec(struct aoa_co
}
-static struct i2c_driver tas_driver;
-
static int tas_create(struct i2c_adapter *adapter,
struct device_node *node,
int addr)
{
+ struct i2c_board_info info;
+ struct i2c_client *client;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
+ info.addr = addr;
+ info.platform_data = node;
+
+ client = i2c_new_device(adapter, &info);
+ if (!client)
+ return -ENODEV;
+
+ /*
+ * Let i2c-core delete that device on driver removal.
+ * This is safe because i2c-core holds the core_lock mutex for us.
+ */
+ list_add_tail(&client->detected, &client->driver->clients);
+ return 0;
+}
+
+static int tas_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device_node *node = client->dev.platform_data;
struct tas *tas;
tas = kzalloc(sizeof(struct tas), GFP_KERNEL);
@@ -896,17 +918,11 @@ static int tas_create(struct i2c_adapter
return -ENOMEM;
mutex_init(&tas->mtx);
- tas->i2c.driver = &tas_driver;
- tas->i2c.adapter = adapter;
- tas->i2c.addr = addr;
+ tas->i2c = client;
+ i2c_set_clientdata(client, tas);
+
/* seems that half is a saner default */
tas->drc_range = TAS3004_DRC_MAX / 2;
- strlcpy(tas->i2c.name, "tas audio codec", I2C_NAME_SIZE);
-
- if (i2c_attach_client(&tas->i2c)) {
- printk(KERN_ERR PFX "failed to attach to i2c\n");
- goto fail;
- }
strlcpy(tas->codec.name, "tas", MAX_CODEC_NAME_LEN);
tas->codec.owner = THIS_MODULE;
@@ -915,14 +931,12 @@ static int tas_create(struct i2c_adapter
tas->codec.node = of_node_get(node);
if (aoa_codec_register(&tas->codec)) {
- goto detach;
+ goto fail;
}
printk(KERN_DEBUG
"snd-aoa-codec-tas: tas found, addr 0x%02x on %s\n",
- addr, node->full_name);
+ (unsigned int)client->addr, node->full_name);
return 0;
- detach:
- i2c_detach_client(&tas->i2c);
fail:
mutex_destroy(&tas->mtx);
kfree(tas);
@@ -970,14 +984,11 @@ static int tas_i2c_attach(struct i2c_ada
return -ENODEV;
}
-static int tas_i2c_detach(struct i2c_client *client)
+static int tas_i2c_remove(struct i2c_client *client)
{
- struct tas *tas = container_of(client, struct tas, i2c);
- int err;
+ struct tas *tas = i2c_get_clientdata(client);
u8 tmp = TAS_ACR_ANALOG_PDOWN;
- if ((err = i2c_detach_client(client)))
- return err;
aoa_codec_unregister(&tas->codec);
of_node_put(tas->codec.node);
@@ -989,13 +1000,20 @@ static int tas_i2c_detach(struct i2c_cli
return 0;
}
+static const struct i2c_device_id tas_i2c_id[] = {
+ { "aoa_codec_tas", 0 },
+ { }
+};
+
static struct i2c_driver tas_driver = {
.driver = {
.name = "aoa_codec_tas",
.owner = THIS_MODULE,
},
.attach_adapter = tas_i2c_attach,
- .detach_client = tas_i2c_detach,
+ .probe = tas_i2c_probe,
+ .remove = tas_i2c_remove,
+ .id_table = tas_i2c_id,
};
static int __init tas_init(void)
--
Jean Delvare
^ permalink raw reply
* Re: Looking for good supported South bridge for mpc6841d
From: Roderick Colenbrander @ 2009-04-15 12:17 UTC (permalink / raw)
To: Zhivko Yordanov; +Cc: linuxppc-dev
In-Reply-To: <200904151323.52505.jivkojj@uni-kassel.de>
On Wed, Apr 15, 2009 at 1:23 PM, Zhivko Yordanov <jivkojj@uni-kassel.de> wr=
ote:
> Hello,
>
> I'm on designing of a new embedded board, based on mpc6841d and South Bri=
dge
> ULi M1575. As =C1 reference design, I use Freescale HPCN board. However a=
fter
> consult with chip's distributor, it became clear that the M1575 is alread=
y
> discounted. Now I'm in looking of an another solution. Can somebody recom=
mend
> me an alternative, good supported from u-boot and have SATA, USB, Audio o=
n
> it? The chip must be connected with mpc6841d over PCI-Express.
>
> Best regarsds,
>
> Yordanov
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
I think the only alternatives you have are chips from Via and perhaps
Sis. It looks like Via has some nice south bridges which do what you
want, see:
http://www.via.com.tw/en/products/chipsets/south-bridges.jsp
Roderick
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Johannes Berg @ 2009-04-15 12:52 UTC (permalink / raw)
To: Jean Delvare; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <20090415141530.0d5e47fc@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
Hi,
> > Because the device-tree is broken -- there are two nodes for the same
> > device, and only one of them can be used. Then the fabric rejects the
> > first instantiation from the broken node. Here's how it looks normally:
> >
> > ...
> > [ 10.398296] snd-aoa-codec-onyx: found pcm3052
> > [ 10.398472] PM: Adding info for i2c:2-0046
> > [ 10.412189] snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> > [ 10.462593] snd-aoa: fabric didn't like codec onyx
> > [ 10.468030] PM: Removing info for i2c:2-0046
> > [ 10.473892] snd-aoa-codec-onyx: found pcm3052
> > [ 10.479317] PM: Adding info for i2c:3-0046
> > [ 10.485631] snd-aoa-fabric-layout: can use this codec
> > ...
>
> OK, I understand better what is going on now. I do not understand the
> crash at the end though, but I suspect it isn't a bug in my code but
> simply a faulty error path which had never been taken before.
That would be weird -- the error path _has_ to be taken always in onyx.
Unless you're talking about something in the i2c core or whatever?
> Now, the fact that there are two nodes, one right and one wrong, is
> quite a problem. My code expected the device tree to be trustworthy.
No such luck.
> The new i2c binding model cleanly separates the instantiation of
> devices and their binding to a driver. The codec check which fails,
> will cause the i2c device to not bind to its driver, but it will still
> be present, while there is no underlying physical I2C device if I
> understand properly. In the new i2c model, you have to ensure that an
> i2c device exists _before_ you instantiate it.
Oh, no, there _is_ an underlying i2c device, the same one. The DT
accidentally has two almost identical nodes for the same chip, but we
can only use the one with the correct reference.
> Well, there is a dirty workaround, which I will apply for now, but...
> ideally the layout factory should be revisited so that the codec check
> happens earlier. Is this something you could help with?
That's not really possible unless the factory post-processes the entire
device-tree -- very ugly.
> That's something which isn't too clear to me: is there a physical
> device at 2-0046 and 3-0046? The onyx codec is accepted for the latter,
> however it seems that the test of a device presence at 2-0046 succeeds
> as well...
It's the _same_ physical device.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* OF PCI howto?
From: Joakim Tjernlund @ 2009-04-15 12:54 UTC (permalink / raw)
To: linuxppc-dev
I have just started to add PCI support to our custom MPC832x board
and I have a hard time figuring out how to describe this in the
dts. Looking at mpc832x_mds.dts I see:
pci0: pci@e0008500 {
cell-index = <1>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x11 AD17 */
0x8800 0x0 0x0 0x1 &ipic 20 0x8
0x8800 0x0 0x0 0x2 &ipic 21 0x8
0x8800 0x0 0x0 0x3 &ipic 22 0x8
0x8800 0x0 0x0 0x4 &ipic 23 0x8
/* IDSEL 0x12 AD18 */
0x9000 0x0 0x0 0x1 &ipic 22 0x8
0x9000 0x0 0x0 0x2 &ipic 23 0x8
0x9000 0x0 0x0 0x3 &ipic 20 0x8
0x9000 0x0 0x0 0x4 &ipic 21 0x8
/* IDSEL 0x13 AD19 */
0x9800 0x0 0x0 0x1 &ipic 23 0x8
0x9800 0x0 0x0 0x2 &ipic 20 0x8
0x9800 0x0 0x0 0x3 &ipic 21 0x8
0x9800 0x0 0x0 0x4 &ipic 22 0x8
/* IDSEL 0x15 AD21*/
0xa800 0x0 0x0 0x1 &ipic 20 0x8
0xa800 0x0 0x0 0x2 &ipic 21 0x8
0xa800 0x0 0x0 0x3 &ipic 22 0x8
0xa800 0x0 0x0 0x4 &ipic 23 0x8
/* IDSEL 0x16 AD22*/
0xb000 0x0 0x0 0x1 &ipic 23 0x8
0xb000 0x0 0x0 0x2 &ipic 20 0x8
0xb000 0x0 0x0 0x3 &ipic 21 0x8
0xb000 0x0 0x0 0x4 &ipic 22 0x8
/* IDSEL 0x17 AD23*/
0xb800 0x0 0x0 0x1 &ipic 22 0x8
0xb800 0x0 0x0 0x2 &ipic 23 0x8
0xb800 0x0 0x0 0x3 &ipic 20 0x8
0xb800 0x0 0x0 0x4 &ipic 21 0x8
/* IDSEL 0x18 AD24*/
0xc000 0x0 0x0 0x1 &ipic 21 0x8
0xc000 0x0 0x0 0x2 &ipic 22 0x8
0xc000 0x0 0x0 0x3 &ipic 23 0x8
0xc000 0x0 0x0 0x4 &ipic 20 0x8>;
interrupt-parent = <&ipic>;
interrupts = <66 0x8>;
bus-range = <0x0 0x0>;
ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0
0x10000000
0x42000000 0x0 0x80000000 0x80000000 0x0
0x10000000
0x01000000 0x0 0x00000000 0xd0000000 0x0
0x00100000>;
clock-frequency = <0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0xe0008500 0x100 /* internal registers */
0xe0008300 0x8>; /* config space access
registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
But I can't figure out what all this mean.
The board will have one PCI device connected directly to the CPU. Is the
above
dts fragment correct for my setup? If not, is there a better example I can
look at?
Jocke
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers (v3)
From: Johannes Berg @ 2009-04-15 13:00 UTC (permalink / raw)
To: Jean Delvare; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <20090415142225.2bfd37f6@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Wed, 2009-04-15 at 14:22 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the AOA
> codec drivers to the new model or they'll break.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Tested-by: Andreas Schwab <schwab@linux-m68k.org>
> ---
> Johannes, this is a reworked patch which assumes that the onyx codec
> probing can fail. It's not exactly clean but that's the easiest
> approach for now. Can you please give it a try? Thanks.
This works.
Tested-by: Johannes Berg <johannes@sipsolutions.net> [quad G5]
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Jean Delvare @ 2009-04-15 13:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: Benjamin, linuxppc-dev, alsa-devel, Takashi Iwai
In-Reply-To: <1239799934.9071.4.camel@johannes.local>
On Wed, 15 Apr 2009 14:52:14 +0200, Johannes Berg wrote:
> > OK, I understand better what is going on now. I do not understand the
> > crash at the end though, but I suspect it isn't a bug in my code but
> > simply a faulty error path which had never been taken before.
>
> That would be weird -- the error path _has_ to be taken always in onyx.
> Unless you're talking about something in the i2c core or whatever?
Yes, i2c core or even driver core. I'll see if I can reproduce it.
> > (...)
> > Well, there is a dirty workaround, which I will apply for now, but...
> > ideally the layout factory should be revisited so that the codec check
> > happens earlier. Is this something you could help with?
>
> That's not really possible unless the factory post-processes the entire
> device-tree -- very ugly.
What I had in mind was not so complex. Simply, we could move the
i2c_new_device() calls into layout_found_codec(). That way we can
decide to instantiate the I2C device if and only if check_codec() is
successful. This is more efficient that creating the device, letting
the driver attach to it, with probing eventually failing, and then
removing the device if it wasn't the right one.
That is, the i2c client would be a mere helper on top of struct
aoa_codec, rather than the other way around.
There may be preliminary work needed, for example switching powermac to
numbered I2C buses.
> > That's something which isn't too clear to me: is there a physical
> > device at 2-0046 and 3-0046? The onyx codec is accepted for the latter,
> > however it seems that the test of a device presence at 2-0046 succeeds
> > as well...
>
> It's the _same_ physical device.
Wow. One I2C device which can be reached through 2 different I2C buses?
First time I hear about something like this. Very odd. I can't see the
point of doing this.
--
Jean Delvare
^ permalink raw reply
* Re: OF PCI howto?
From: Wolfram Sang @ 2009-04-15 13:08 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OF2E7A8F65.EA7B7D26-ONC1257599.004624DB-C1257599.0046F2EB@transmode.se>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
> dts fragment correct for my setup? If not, is there a better example I can
> look at?
Maybe this message/thread can help you:
http://ozlabs.org/pipermail/devicetree-discuss/2009-March/000597.html
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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