* Re: New Patchwork beta
From: Kumar Gala @ 2008-08-22 8:12 UTC (permalink / raw)
To: jwboyer
Cc: bazaar-ng, linuxppc-dev, linux-mtd, Jeremy Kerr,
linuxppc-embedded, cbe-oss-dev
In-Reply-To: <1219359163.26429.62.camel@jdub.homelinux.org>
On Aug 21, 2008, at 5:52 PM, Josh Boyer wrote:
> On Thu, 2008-08-21 at 15:32 -0500, Kumar Gala wrote:
>> Some feedback:
>>
>> * Can we increase the font size a bit?
>
> NOO. Just use CTRL-SHIFT-+.
ok
>> * For the list of patches can we change the background of every other
>> line (light gray)
>
> That would work well.
thanks this looks better, easier to read.
>> * Parsing subject header for determining state -- "[RFC]"
>
> That is going to fail miserably because people tend to do silly things
> like post final patches in the middle of an [RFC] thread.
gotcha.
Now that I can log in, can I get "maintainer" privileges (user: galak)
also is it possible to put the patch controls in a separate frame so
they are always visible (dont have to scoll to the bottom to find them).
- k
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Christian Ehrhardt @ 2008-08-22 8:08 UTC (permalink / raw)
To: Scott Wood; +Cc: kvm-ppc, linuxppc-dev, hollisb
In-Reply-To: <20080821161622.GB15669@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote:
>
>> Where is the other discussion? I'd like to understand what's going on
>> here.. (especially since I added the wrtee[i] changes to kernel way
>> back when).
>>
>
> Presumably, they want to be able to replace wrtee with a store to a
> hypervisor/guest shared memory area, and there's no store-immediate
> instruction.
>
> -Scott
>
Exactly Scott
And for your question Kumar, in the last submission I was asked to split
host and guest patches.
So the host discussion lives on kvm-ppc@vger.kernel.org as I mentioned
(maybe a bit too hidden)
in the [0/4] mail of this series.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
^ permalink raw reply
* [PATCH] Add AMCC 4XX PCIe MSI support
From: fkan @ 2008-08-22 4:42 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Preetesh Parekh
From: Preetesh Parekh <pparekh@amcc.com>
Signed-off-by: Preetesh Parekh <pparekh@amcc.com>
---
arch/powerpc/platforms/40x/kilauea.c | 13 ++++
arch/powerpc/platforms/44x/canyonlands.c | 14 ++++
arch/powerpc/sysdev/ppc4xx_pci.c | 115 ++++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.h | 45 ++++++++++++
include/asm-powerpc/dcr-native.h | 12 +++
5 files changed, 199 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
index 1dd24ff..3610be2 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -22,6 +22,11 @@
#include <asm/pci-bridge.h>
#include <asm/ppc4xx.h>
+#ifdef CONFIG_PCI_MSI
+extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
+extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
+#endif
+
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
@@ -46,6 +51,14 @@ static int __init kilauea_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+#ifdef CONFIG_PCI_MSI
+ /*
+ * Setting callback functions for MSI support
+ */
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+#endif
+
return 1;
}
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
index 3949289..ee38fb7 100644
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -25,6 +25,12 @@
#include <asm/pci-bridge.h>
#include <asm/ppc4xx.h>
+
+#ifdef CONFIG_PCI_MSI
+extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
+extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
+#endif
+
static __initdata struct of_device_id canyonlands_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
@@ -49,6 +55,14 @@ static int __init canyonlands_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+#ifdef CONFIG_PCI_MSI
+ /*
+ * Setting callback functions for MSI support
+ */
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+#endif
+
return 1;
}
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index fb368df..bdb3663 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -35,6 +35,11 @@
static int dma_offset_set;
+#ifdef CONFIG_PCI_MSI
+#include <linux/msi.h>
+#include "../../../drivers/pci/msi.h"
+#endif
+
/* Move that to a useable header */
extern unsigned long total_memory;
@@ -1587,12 +1592,26 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
out_le16(mbase + 0x202, val);
if (!port->endpoint) {
+#ifdef CONFIG_PCI_MSI
+ /* Set MSI enable, multiple msg cap = 4 */
+ /* 4 messages allocated, 64 bit capability */
+ out_le32(mbase + 0x048, in_le32(mbase + 0x048) | 0x00a50000);
+
+ /* Enable interrupts in BCR */
+ out_le32(mbase + 0x03C, in_le32(mbase + 0x03C) | 0xFF000000);
+#endif
+
/* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
out_le32(mbase + 0x208, 0x06040001);
printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
port->index);
} else {
+#ifdef CONFIG_PCI_MSI
+ /* Enable MSI for End-Point */
+ out_le32(mbase + 0x048, (in_le32(mbase + 0x048) | 0x00a50000));
+#endif
+
/* Set Class Code to Processor/PPC */
out_le32(mbase + 0x208, 0x0b200001);
@@ -1704,6 +1723,97 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
ppc4xx_pciex_port_setup_hose(port);
}
+#ifdef CONFIG_PCI_MSI
+int ppc4xx_setup_peih(void)
+{
+ void __iomem *peih_base;
+
+ printk(KERN_INFO " %s \n",__FUNCTION__);
+ /* Set base address for PEIH and enable PEIH */
+ SDR_WRITE(PESDR0_4XX_IHS1, PPC4XX_PEIH_REGBASE_HADDR);
+ SDR_WRITE(PESDR0_4XX_IHS2, PPC4XX_PEIH_REGBASE_LADDR);
+
+ /* Map in PCI-E Interrupt Handler Registers */
+ peih_base = ioremap(PPC4XX_PEIH_REGBASE, PPC4XX_PEIH_REGSIZE);
+ if(!peih_base) {
+ printk(KERN_ERR "%s: ioremap64 failed for addr 0x%08x\n",
+ __FUNCTION__, PPC4XX_PEIH_REGBASE);
+ return -ENODEV;
+ }
+
+ /* Progam the Interrupt handler Termination addr registers */
+ out_be32(peih_base + PEIH_TERMADH, PPC4XX_PCIE_MSI_HADDR);
+ out_be32(peih_base + PEIH_TERMADL, PPC4XX_PCIE_MSI_LADDR);
+
+ /* Program MSI Expected data and Mask bits */
+ out_be32(peih_base + PEIH_MSIED, PPC4XX_MSI_DATA_PTRN);
+ out_be32(peih_base + PEIH_MSIMK, PPC4XX_MSI_DATA_VALD);
+
+ iounmap(peih_base);
+
+ return 0; /* success */
+}
+
+
+int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+{
+ /* Setup MSI Capabilities structure for dev func */
+ int pos;
+ u16 control, ctrl;
+
+ printk(KERN_INFO " %s \n",__FUNCTION__);
+ pos = desc->msi_attrib.pos;
+ pci_read_config_word(dev, msi_control_reg(pos), &control);
+
+ /* Multiple msg enable */
+ ctrl = multi_msi_enable(control, 4);
+ pci_write_config_dword(dev, msi_control_reg(pos), ctrl);
+
+ /* setup MSI address registers */
+ if(is_64bit_address(control))
+ pci_write_config_dword(dev, msi_upper_address_reg(pos), PPC4XX_PCIE_MSI_HADDR);
+
+ pci_write_config_dword(dev, msi_lower_address_reg(pos),
+ PPC4XX_PCIE_MSI_LADDR);
+
+ if(is_64bit_address(control)) {
+ /* setup MSI data register */
+ pci_write_config_dword(dev, msi_data_reg(pos, 1),
+ PPC4XX_MSI_DATA_PTRN_EP);
+ /* setup MSI mask bits reg */
+ pci_write_config_dword(dev, msi_mask_bits_reg(pos, 1), 0x00000000);
+ }
+ else {
+ pci_write_config_dword(dev, msi_data_reg(pos, 0),
+ PPC4XX_MSI_DATA_PTRN_EP);
+ pci_write_config_dword(dev, msi_mask_bits_reg(pos, 0), 0x00000000);
+ }
+
+ return 0;
+}
+
+int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ struct msi_desc *entry;
+ int ret;
+
+ list_for_each_entry(entry, &dev->msi_list, list) {
+ ret = arch_setup_msi_irq(dev, entry);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
+{
+ return;
+}
+
+
+#endif /* CONFIG_PCI_MSI */
+
#endif /* CONFIG_PPC4xx_PCI_EXPRESS */
static int __init ppc4xx_pci_find_bridges(void)
@@ -1713,6 +1823,11 @@ static int __init ppc4xx_pci_find_bridges(void)
#ifdef CONFIG_PPC4xx_PCI_EXPRESS
for_each_compatible_node(np, NULL, "ibm,plb-pciex")
ppc4xx_probe_pciex_bridge(np);
+
+#ifdef CONFIG_PCI_MSI
+ ppc4xx_setup_peih();
+#endif
+
#endif
for_each_compatible_node(np, NULL, "ibm,plb-pcix")
ppc4xx_probe_pcix_bridge(np);
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h b/arch/powerpc/sysdev/ppc4xx_pci.h
index d04e40b..d5fcaa9 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.h
+++ b/arch/powerpc/sysdev/ppc4xx_pci.h
@@ -158,6 +158,51 @@
#define GPL_DMER_MASK_DISA 0x02000000
/*
+ * 4xx PCIe IRQ Handler register definitions
+ */
+#ifdef CONFIG_PCI_MSI
+
+#if defined(CONFIG_405EX)
+#define PESDR0_4XX_IHS1 0x04B0
+#define PESDR0_4XX_IHS2 0x04B1
+#define PPC4XX_PEIH_REGBASE 0x0EF620000
+#define PPC4XX_PEIH_REGBASE_HADDR 0x0
+#define PPC4XX_PEIH_REGBASE_LADDR 0xEF620000
+#define PPC4XX_PCIE_MSI_ADDR 0x080000000
+#define PPC4XX_PCIE_MSI_HADDR 0x0
+#define PPC4XX_PCIE_MSI_LADDR 0x80000000
+
+#elif defined(CONFIG_460EX)
+#define PESDR0_4XX_IHS1 0x036C
+#define PESDR0_4XX_IHS2 0x036D
+#define PPC4XX_PEIH_REGBASE 0xC10000000
+#define PPC4XX_PEIH_REGBASE_HADDR 0xC
+#define PPC4XX_PEIH_REGBASE_LADDR 0x10000000
+#define PPC4XX_PCIE_MSI_ADDR 0xe80000000
+#define PPC4XX_PCIE_MSI_HADDR 0xe
+#define PPC4XX_PCIE_MSI_LADDR 0x80000000
+#endif
+
+#define PPC4XX_PEIH_REGSIZE 0x100
+#define PPC4XX_MSI_DATA_PTRN 0x44440000
+#define PPC4XX_MSI_DATA_VALD 0xFFFF0000
+#define PPC4XX_MSI_DATA_PTRN_EP 0x00004444
+
+#define PEIH_TERMADH 0x00
+#define PEIH_TERMADL 0x08
+#define PEIH_MSIED 0x10
+#define PEIH_MSIMK 0x18
+#define PEIH_MSIASS 0x20
+#define PEIH_FLUSH0 0x30
+#define PEIH_FLUSH1 0x38
+#define PEIH_CNTRST 0x48
+
+
+#endif /* CONFIG_PCI_MSI */
+
+
+
+/*
* System DCRs (SDRs)
*/
#define PESDR0_PLLLCT1 0x03a0
diff --git a/include/asm-powerpc/dcr-native.h b/include/asm-powerpc/dcr-native.h
index 72d2b72..357ba36 100644
--- a/include/asm-powerpc/dcr-native.h
+++ b/include/asm-powerpc/dcr-native.h
@@ -111,6 +111,18 @@ static inline void __dcri_clrset(int base_addr, int base_data, int reg,
DCRN_ ## base ## _CONFIG_DATA, \
reg, clr, set)
+/* SDR read/write helper macros */
+
+#define DCRN_SDR_CONFIG_ADDR 0x00E
+#define DCRN_SDR_CONFIG_DATA 0x00F
+
+#define SDR_READ(offset) ({ \
+ mtdcr(DCRN_SDR_CONFIG_ADDR, offset); \
+ mfdcr(DCRN_SDR_CONFIG_DATA);})
+#define SDR_WRITE(offset, data) ({ \
+ mtdcr(DCRN_SDR_CONFIG_ADDR, offset); \
+ mtdcr(DCRN_SDR_CONFIG_DATA, data);})
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_NATIVE_H */
--
1.5.5
^ permalink raw reply related
* Re: [machdep_calls] IRQ
From: Michael Ellerman @ 2008-08-22 5:20 UTC (permalink / raw)
To: Sébastien Chrétien; +Cc: linuxppc-dev
In-Reply-To: <319b0ac50808210123m81e8364od983d5dbbb601104@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Thu, 2008-08-21 at 10:23 +0200, Sébastien Chrétien wrote:
> Exactly, I mean ppc_md.init_IRQ().
> Ok. What have I to setup in this function ? I set the mask and other
> registers. Is it right ? How do I chose the mask ?
It totally depends on your platform, I really can't tell you. You can
look at similar platform code if there is some, otherwise the reference
manual for your hardware or similar should have what you need.
> At the end of this funtion, IRQ are disable. Is that right ? So who
> does enable IRQs ?
Yes, irqs get enabled a bit later in start_kernel().
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Mitch Bradley @ 2008-08-22 5:19 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, sparclinux, devicetree-discuss, scottwood
In-Reply-To: <20080821.213747.159824681.davem@davemloft.net>
David Miller wrote:
> From: "Grant Likely" <grant.likely@secretlab.ca>
> Date: Thu, 21 Aug 2008 22:34:31 -0600
>
>
>> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>
>>> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>>>
>>>> Hi, I wrote most of 1275.
>>>>
>>>> Mitch Bradley (wmb@firmworks.com)
>>>>
>>> Hi Mitch,
>>>
>>> What is your suggestion. Where should we be discussing new device
>>> tree bindings? Whether it be real Open Firmware, or flattened device
>>> tree, or something in between
>>>
>> ...and along those lines: is there a place for documenting new
>> bindings? Lacking anything better, those of us in PowerPC-Linux-land
>> have been adding documentation to Documentation/powerpc/dts-bindings/*
>> in the Linux kernel tree.
>>
>
> In a discussion I am having with Greg Onufer, David K. and Tayfun
> at Sun, Greg said the some of the newer binding documents are
> being published on the opensolaris site, and he is trying to
> get some of the older cases (like this I2C one) published there
> too.
>
>
This collection of mailing lists is as good a place as any to discuss
new bindings. I don't know how many Sun people are on the lists, but we
might be able to persuade various Sun people to lurk on one or more of
them; I lurk on devicetree-discuss.
The opensolaris site seems as good as anywhere for publishing the
bindings, especially if they can pull over the old ones from e.g.
playground.sun.com .
Another possible site might be openbios.org .
^ permalink raw reply
* Re: TLB programming in powerpc tree. Was: Accessing peripheral bus devices on 460GT
From: vb @ 2008-08-22 5:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f608b67d0808211929g3ae2cf7dm2ba2d65b0043d306@mail.gmail.com>
On Thu, Aug 21, 2008 at 7:29 PM, vb <vb@vsbe.com> wrote:
>
> But the main problem is that the kernel never sets up TLBs for neither
> the peripheral device, nor the onboard flash. I don't seem to be able
> to find the place where this is supposed to happen. I assumed that
> ioremap_nocache would take care of that, but this is not the case.
>
well, in fact the TLB is set up as soon as an attempt to access the
peripheral is made. The problem apparently is the fact that the TLB
entry uses a wrong value in the nibble specifying the internal 460GT
block...
^ permalink raw reply
* [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
From: fkan @ 2008-08-22 4:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Tirumala R Marri
From: Tirumala R Marri <tmarri@amcc.com>
During recent tests with PCI-E , it has been found the
DRV + De-Emphasis values are not optimum. These new values
are tested thouroughly.
Signed-off-by: Tirumala R Marri <tmarri@amcc.com>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index bdb3663..0ce3f46 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -815,7 +815,7 @@ static int ppc460ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
switch (port->index) {
case 0:
mtdcri(SDR0, PESDR0_460EX_L0CDRCTL, 0x00003230);
- mtdcri(SDR0, PESDR0_460EX_L0DRV, 0x00000136);
+ mtdcri(SDR0, PESDR0_460EX_L0DRV, 0x00000130);
mtdcri(SDR0, PESDR0_460EX_L0CLK, 0x00000006);
mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST,0x10000000);
@@ -826,10 +826,10 @@ static int ppc460ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
mtdcri(SDR0, PESDR1_460EX_L1CDRCTL, 0x00003230);
mtdcri(SDR0, PESDR1_460EX_L2CDRCTL, 0x00003230);
mtdcri(SDR0, PESDR1_460EX_L3CDRCTL, 0x00003230);
- mtdcri(SDR0, PESDR1_460EX_L0DRV, 0x00000136);
- mtdcri(SDR0, PESDR1_460EX_L1DRV, 0x00000136);
- mtdcri(SDR0, PESDR1_460EX_L2DRV, 0x00000136);
- mtdcri(SDR0, PESDR1_460EX_L3DRV, 0x00000136);
+ mtdcri(SDR0, PESDR1_460EX_L0DRV, 0x00000130);
+ mtdcri(SDR0, PESDR1_460EX_L1DRV, 0x00000130);
+ mtdcri(SDR0, PESDR1_460EX_L2DRV, 0x00000130);
+ mtdcri(SDR0, PESDR1_460EX_L3DRV, 0x00000130);
mtdcri(SDR0, PESDR1_460EX_L0CLK, 0x00000006);
mtdcri(SDR0, PESDR1_460EX_L1CLK, 0x00000006);
mtdcri(SDR0, PESDR1_460EX_L2CLK, 0x00000006);
--
1.5.5
^ permalink raw reply related
* [PATCH 2/2] powerpc: new copy_4K_page()
From: Mark Nelson @ 2008-08-22 4:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <200808141617.32033.markn@au1.ibm.com>
This new copy_4K_page() function was originally tuned for the best
performance on the Cell processor, but after testing on more 64bit
powerpc chips it was found that with a small modification it either
matched the performance offered by the current mainline version or
bettered it by a small amount.
It was found that on a Cell-based QS22 blade the amount of system
time measured when compiling a 2.6.26 pseries_defconfig decreased
by 4%. Using the same test, a 4-way 970MP machine saw a decrease of
2% in system time. No noticeable change was seen on Power4, Power5
or Power6.
The 4096 byte page is copied in thirty-two 128 byte strides. An
initial setup loop executes dcbt instructions for the whole source
page and dcbz instructions for the whole destination page. To do
this, the cache line size is retrieved from ppc64_caches.
A new CPU feature bit, CPU_FTR_CP_USE_DCBTZ, (introduced in the
previous patch) is used to make the modification to this new copy
routine - on Power4, 970 and Cell the feature bit is set so the
setup loop is executed, but on all other 64bit chips the setup
loop is nop'ed out.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/lib/copypage_64.S | 198 +++++++++++++++++++----------------------
1 file changed, 93 insertions(+), 105 deletions(-)
Index: upstream/arch/powerpc/lib/copypage_64.S
===================================================================
--- upstream.orig/arch/powerpc/lib/copypage_64.S
+++ upstream/arch/powerpc/lib/copypage_64.S
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2002 Paul Mackerras, IBM Corp.
+ * Copyright (C) 2008 Mark Nelson, IBM Corp.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -8,112 +8,100 @@
*/
#include <asm/processor.h>
#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+
+ .section ".toc","aw"
+PPC64_CACHES:
+ .tc ppc64_caches[TC],ppc64_caches
+ .section ".text"
+
_GLOBAL(copy_4K_page)
- std r31,-8(1)
- std r30,-16(1)
- std r29,-24(1)
- std r28,-32(1)
- std r27,-40(1)
- std r26,-48(1)
- std r25,-56(1)
- std r24,-64(1)
- std r23,-72(1)
- std r22,-80(1)
- std r21,-88(1)
- std r20,-96(1)
- li r5,4096/32 - 1
+ li r5,4096 /* 4K page size */
+BEGIN_FTR_SECTION
+ ld r10,PPC64_CACHES@toc(r2)
+ lwz r11,DCACHEL1LOGLINESIZE(r10) /* log2 of cache line size */
+ lwz r12,DCACHEL1LINESIZE(r10) /* get cache line size */
+ li r9,0
+ srd r8,r5,r11
+
+ mtctr r8
+setup:
+ dcbt r9,r4
+ dcbz r9,r3
+ add r9,r9,r12
+ bdnz setup
+END_FTR_SECTION_IFSET(CPU_FTR_CP_USE_DCBTZ)
addi r3,r3,-8
- li r12,5
-0: addi r5,r5,-24
- mtctr r12
- ld r22,640(4)
- ld r21,512(4)
- ld r20,384(4)
- ld r11,256(4)
- ld r9,128(4)
- ld r7,0(4)
- ld r25,648(4)
- ld r24,520(4)
- ld r23,392(4)
- ld r10,264(4)
- ld r8,136(4)
- ldu r6,8(4)
- cmpwi r5,24
-1: std r22,648(3)
- std r21,520(3)
- std r20,392(3)
- std r11,264(3)
- std r9,136(3)
- std r7,8(3)
- ld r28,648(4)
- ld r27,520(4)
- ld r26,392(4)
- ld r31,264(4)
- ld r30,136(4)
- ld r29,8(4)
- std r25,656(3)
- std r24,528(3)
- std r23,400(3)
- std r10,272(3)
- std r8,144(3)
- std r6,16(3)
- ld r22,656(4)
- ld r21,528(4)
- ld r20,400(4)
- ld r11,272(4)
- ld r9,144(4)
- ld r7,16(4)
- std r28,664(3)
- std r27,536(3)
- std r26,408(3)
- std r31,280(3)
- std r30,152(3)
- stdu r29,24(3)
- ld r25,664(4)
- ld r24,536(4)
- ld r23,408(4)
- ld r10,280(4)
- ld r8,152(4)
- ldu r6,24(4)
+ srdi r8,r5,7 /* page is copied in 128 byte strides */
+ addi r8,r8,-1 /* one stride copied outside loop */
+
+ mtctr r8
+
+ ld r5,0(r4)
+ ld r6,8(r4)
+ ld r7,16(r4)
+ ldu r8,24(r4)
+1: std r5,8(r3)
+ ld r9,8(r4)
+ std r6,16(r3)
+ ld r10,16(r4)
+ std r7,24(r3)
+ ld r11,24(r4)
+ std r8,32(r3)
+ ld r12,32(r4)
+ std r9,40(r3)
+ ld r5,40(r4)
+ std r10,48(r3)
+ ld r6,48(r4)
+ std r11,56(r3)
+ ld r7,56(r4)
+ std r12,64(r3)
+ ld r8,64(r4)
+ std r5,72(r3)
+ ld r9,72(r4)
+ std r6,80(r3)
+ ld r10,80(r4)
+ std r7,88(r3)
+ ld r11,88(r4)
+ std r8,96(r3)
+ ld r12,96(r4)
+ std r9,104(r3)
+ ld r5,104(r4)
+ std r10,112(r3)
+ ld r6,112(r4)
+ std r11,120(r3)
+ ld r7,120(r4)
+ stdu r12,128(r3)
+ ldu r8,128(r4)
bdnz 1b
- std r22,648(3)
- std r21,520(3)
- std r20,392(3)
- std r11,264(3)
- std r9,136(3)
- std r7,8(3)
- addi r4,r4,640
- addi r3,r3,648
- bge 0b
- mtctr r5
- ld r7,0(4)
- ld r8,8(4)
- ldu r9,16(4)
-3: ld r10,8(4)
- std r7,8(3)
- ld r7,16(4)
- std r8,16(3)
- ld r8,24(4)
- std r9,24(3)
- ldu r9,32(4)
- stdu r10,32(3)
- bdnz 3b
-4: ld r10,8(4)
- std r7,8(3)
- std r8,16(3)
- std r9,24(3)
- std r10,32(3)
-9: ld r20,-96(1)
- ld r21,-88(1)
- ld r22,-80(1)
- ld r23,-72(1)
- ld r24,-64(1)
- ld r25,-56(1)
- ld r26,-48(1)
- ld r27,-40(1)
- ld r28,-32(1)
- ld r29,-24(1)
- ld r30,-16(1)
- ld r31,-8(1)
+
+ std r5,8(r3)
+ ld r9,8(r4)
+ std r6,16(r3)
+ ld r10,16(r4)
+ std r7,24(r3)
+ ld r11,24(r4)
+ std r8,32(r3)
+ ld r12,32(r4)
+ std r9,40(r3)
+ ld r5,40(r4)
+ std r10,48(r3)
+ ld r6,48(r4)
+ std r11,56(r3)
+ ld r7,56(r4)
+ std r12,64(r3)
+ ld r8,64(r4)
+ std r5,72(r3)
+ ld r9,72(r4)
+ std r6,80(r3)
+ ld r10,80(r4)
+ std r7,88(r3)
+ ld r11,88(r4)
+ std r8,96(r3)
+ ld r12,96(r4)
+ std r9,104(r3)
+ std r10,112(r3)
+ std r11,120(r3)
+ std r12,128(r3)
blr
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-22 4:37 UTC (permalink / raw)
To: grant.likely; +Cc: wmb, linuxppc-dev, sparclinux, devicetree-discuss, scottwood
In-Reply-To: <fa686aa40808212134l1e226845q41831ee567bb1a2@mail.gmail.com>
From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 22:34:31 -0600
> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
> > On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> >> Hi, I wrote most of 1275.
> >>
> >> Mitch Bradley (wmb@firmworks.com)
> >
> > Hi Mitch,
> >
> > What is your suggestion. Where should we be discussing new device
> > tree bindings? Whether it be real Open Firmware, or flattened device
> > tree, or something in between
>
> ...and along those lines: is there a place for documenting new
> bindings? Lacking anything better, those of us in PowerPC-Linux-land
> have been adding documentation to Documentation/powerpc/dts-bindings/*
> in the Linux kernel tree.
In a discussion I am having with Greg Onufer, David K. and Tayfun
at Sun, Greg said the some of the newer binding documents are
being published on the opensolaris site, and he is trying to
get some of the older cases (like this I2C one) published there
too.
^ permalink raw reply
* [PATCH 1/2] powerpc: add new CPU feature: CPU_FTR_CP_USE_DCBTZ
From: Mark Nelson @ 2008-08-22 4:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <200808141617.32033.markn@au1.ibm.com>
Add a new CPU feature bit, CPU_FTR_CP_USE_DCBTZ, to be added to the
64bit powerpc chips that benefit from having dcbt and dcbz
instructions used in their memory copy routines.
This will be used in a subsequent patch that updates copy_4K_page().
The new bit is added to Cell, PPC970 and Power4 because they show
better performance with the new copy_4K_page() when dcbt and dcbz
instructions are used.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/include/asm/cputable.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: upstream/arch/powerpc/include/asm/cputable.h
===================================================================
--- upstream.orig/arch/powerpc/include/asm/cputable.h
+++ upstream/arch/powerpc/include/asm/cputable.h
@@ -192,6 +192,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_NO_SLBIE_B LONG_ASM_CONST(0x0008000000000000)
#define CPU_FTR_VSX LONG_ASM_CONST(0x0010000000000000)
#define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
+#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
#ifndef __ASSEMBLY__
@@ -387,10 +388,11 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_CTRL)
#define CPU_FTRS_POWER4 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
- CPU_FTR_MMCRA)
+ CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ)
#define CPU_FTRS_PPC970 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
- CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA)
+ CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
+ CPU_FTR_CP_USE_DCBTZ)
#define CPU_FTRS_POWER5 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
@@ -411,7 +413,8 @@ extern const char *powerpc_base_platform
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
- CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE | CPU_FTR_CELL_TB_BUG)
+ CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE | \
+ CPU_FTR_CELL_TB_BUG | CPU_FTR_CP_USE_DCBTZ)
#define CPU_FTRS_PA6T (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CI_LARGE_PAGE | \
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Grant Likely @ 2008-08-22 4:34 UTC (permalink / raw)
To: Mitch Bradley
Cc: sparclinux, linuxppc-dev, devicetree-discuss, David Miller,
scottwood
In-Reply-To: <fa686aa40808212130l365c6f5eu767b9969c8171e2@mail.gmail.com>
On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>> Hi, I wrote most of 1275.
>>
>> Mitch Bradley (wmb@firmworks.com)
>
> Hi Mitch,
>
> What is your suggestion. Where should we be discussing new device
> tree bindings? Whether it be real Open Firmware, or flattened device
> tree, or something in between
...and along those lines: is there a place for documenting new
bindings? Lacking anything better, those of us in PowerPC-Linux-land
have been adding documentation to Documentation/powerpc/dts-bindings/*
in the Linux kernel tree.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 0/2] powerpc: new copy_4K_page()
From: Mark Nelson @ 2008-08-22 4:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
In-Reply-To: <200808141617.32033.markn@au1.ibm.com>
On Thu, 14 Aug 2008 04:17:32 pm Mark Nelson wrote:
> Hi All,
>
> What follows is an updated version of copy_4K_page that has been tuned
> for the Cell processor. With this new routine it was found that the
> system time measured when compiling a 2.6.26 pseries_defconfig was
> reduced by ~10s:
>
> mainline (2.6.27-rc1-00632-g2e1e921):
>
> real 17m8.727s
> user 59m48.693s
> sys 3m56.089s
>
> real 17m9.350s
> user 59m44.822s
> sys 3m56.666s
>
> new routine:
>
> real 17m7.311s
> user 59m51.339s
> sys 3m47.043s
>
> real 17m7.863s
> user 59m49.028s
> sys 3m46.608s
>
> This same routine was also found to improve performance on 970 CPUs
> too (but by a much smaller amount):
>
> mainline (2.6.27-rc1-00632-g2e1e921):
>
> real 16m8.545s
> user 14m38.134s
> sys 1m55.156s
>
> real 16m7.089s
> user 14m37.974s
> sys 1m55.010s
>
> new routine:
>
> real 16m11.641s
> user 14m37.251s
> sys 1m52.618s
>
> real 16m6.139s
> user 14m38.282s
> sys 1m53.184s
>
>
> I also did testing on Power{3..6} and I found that Power3, Power5 and
> Power6 did better with this new routine when the dcbt and dcbz
> weren't used (in which case they achieved performance comparable to
> the existing kernel copy_4K_page routine). Power4 on other hand
> performed slightly better with the dcbt and dcbz included (still
> comparable to the current kernel copy_4K_page).
>
> So in order to get the best performance across the board I created a
> new CPU feature that will govern whether the dcbt and dcbz are used
> (and un-creatively named it CPU_FTR_CP_USE_DCBTZ). I added it to the
> CPU features of Cell, Power4 and 970.
> Unfortunately I don't have access to a PA6T but judging by the
> marketing material I could find, it looks like it has a strong enough
> hardware prefetcher that it probably wouldn't benefit from the dcbt
> and dcbz...
>
> Okay, that's probably enough prattling along - you can all go and look
> at the code now.
>
> All comments appreciated
>
> [I decided to post the whole copy routine rather than a diff between
> it and the current one because I found the diff quite unreadable. I'll post
> a real patchset after I've addressed any comments.]
>
> Many thanks!
>
The actual patches for the new copy_4K_page() follow this.
Note: I changed the order of the patches so that the new CPU feature
bit is introduced in the first patch and then the new copy_4K_page
is introduced in the second patch.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Grant Likely @ 2008-08-22 4:30 UTC (permalink / raw)
To: Mitch Bradley
Cc: sparclinux, linuxppc-dev, devicetree-discuss, David Miller,
scottwood
In-Reply-To: <48AE4093.8050504@firmworks.com>
On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> Hi, I wrote most of 1275.
>
> Mitch Bradley (wmb@firmworks.com)
Hi Mitch,
What is your suggestion. Where should we be discussing new device
tree bindings? Whether it be real Open Firmware, or flattened device
tree, or something in between
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Mitch Bradley @ 2008-08-22 4:29 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, sparclinux, devicetree-discuss, scottwood
In-Reply-To: <20080821.212241.186479683.davem@davemloft.net>
Hi, I wrote most of 1275.
Mitch Bradley (wmb@firmworks.com)
David Miller wrote:
> From: "Grant Likely" <grant.likely@secretlab.ca>
> Date: Thu, 21 Aug 2008 22:18:56 -0600
>
>
>> On Thu, Aug 21, 2008 at 9:53 PM, David Miller <davem@davemloft.net> wrote:
>>
>>>> Have patience with the embedded people that are both new to
>>>> OpenFirmware and trying to make stuff work at the same time. I
>>>> think the devicetree-discuss list will help here as new bindings are
>>>> proposed. I hope you're subscribed.
>>>>
>>> Why not ask the people who actually work on the standards? That's who
>>> I go to when I want to know something about openfirmware issues.
>>>
>> You mean email them privately? Outside of a public forum? That
>> doesn't help much when it comes to discussing/debating issues and
>> learning from other peoples conversations.
>>
>
> You can CC: them on the discussion to get their input, whatever
> is appropriate.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@ozlabs.org
> https://ozlabs.org/mailman/listinfo/devicetree-discuss
>
>
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-22 4:22 UTC (permalink / raw)
To: grant.likely
Cc: devicetree-discuss, linuxppc-dev, sparclinux, scottwood, paulus
In-Reply-To: <fa686aa40808212118u710050bbg8ca8e04e01252310@mail.gmail.com>
From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 22:18:56 -0600
> On Thu, Aug 21, 2008 at 9:53 PM, David Miller <davem@davemloft.net> wrote:
> >> Have patience with the embedded people that are both new to
> >> OpenFirmware and trying to make stuff work at the same time. I
> >> think the devicetree-discuss list will help here as new bindings are
> >> proposed. I hope you're subscribed.
> >
> > Why not ask the people who actually work on the standards? That's who
> > I go to when I want to know something about openfirmware issues.
>
> You mean email them privately? Outside of a public forum? That
> doesn't help much when it comes to discussing/debating issues and
> learning from other peoples conversations.
You can CC: them on the discussion to get their input, whatever
is appropriate.
^ permalink raw reply
* [PATCH 2/3]: of_i2c: Abstract out register property interpretation.
From: David Miller @ 2008-08-22 4:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, paulus, sparclinux
of_i2c: Abstract out register property interpretation.
Pull out client I2C device address calculation into a
helper function, of_i2c_fetch_addr.
At the top level we try to determine the reported
#address-cells property in the I2C bus adapter node,
and default to "1" if the property is not found.
We pass this down to of_i2c_fetch_addr() so that it does
not have to do this probe every iteration.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/powerpc/include/asm/of_i2c.h | 24 ++++++++++++++++++++++++
drivers/of/of_i2c.c | 26 ++++++++++++++++----------
2 files changed, 40 insertions(+), 10 deletions(-)
create mode 100644 arch/powerpc/include/asm/of_i2c.h
diff --git a/arch/powerpc/include/asm/of_i2c.h b/arch/powerpc/include/asm/of_i2c.h
new file mode 100644
index 0000000..501a24b
--- /dev/null
+++ b/arch/powerpc/include/asm/of_i2c.h
@@ -0,0 +1,24 @@
+#ifndef _ASM_POWERPC_OF_I2C_H
+#define _ASM_POWERPC_OF_I2C_H
+
+static inline int of_i2c_fetch_addr(struct i2c_board_info *bp,
+ struct device_node *client_node,
+ struct device_node *adap_node,
+ int num_addr_cells)
+{
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(client_node, "reg", &len);
+ if (!addr || len < (num_addr_cells * sizeof(int)) ||
+ addr[num_addr_cells - 1] > (1 << 10) - 1) {
+ printk(KERN_ERR "of-i2c: invalid i2c device entry\n");
+ return -EINVAL;
+ }
+
+ bp->addr = addr[num_addr_cells - 1];
+
+ return 0;
+}
+
+#endif /* _ASM_POWERPC_OF_I2C_H */
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6a98dc8..387c74e 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -16,31 +16,37 @@
#include <linux/of_i2c.h>
#include <linux/module.h>
+#include <asm/of_i2c.h>
+
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node)
{
- void *result;
struct device_node *node;
+ int num_addr_cells = 1;
+ const int *n_cells;
+ void *result;
+
+ n_cells = of_get_property(adap_node, "#address-cells", NULL);
+ if (n_cells)
+ num_addr_cells = *n_cells;
+
+ if (num_addr_cells != 1 && num_addr_cells != 2) {
+ printk(KERN_ERR "of-i2c: invalid address cells %d\n",
+ num_addr_cells);
+ return;
+ }
for_each_child_of_node(adap_node, node) {
struct i2c_board_info info = {};
- const u32 *addr;
- int len;
if (of_modalias_node(node, info.type, sizeof(info.type)) < 0)
continue;
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_ERR
- "of-i2c: invalid i2c device entry\n");
+ if (of_i2c_fetch_addr(&info, node, adap_node, num_addr_cells))
continue;
- }
info.irq = irq_of_parse_and_map(node, 0);
- info.addr = *addr;
-
request_module(info.type);
result = i2c_new_device(adap, &info);
--
1.5.6.5.GIT
^ permalink raw reply related
* [PATCH 3/3]: of_i2c: Add Sparc support.
From: David Miller @ 2008-08-22 4:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, paulus, sparclinux
of_i2c: Add Sparc support.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/sparc/include/asm/of_i2c.h | 67 +++++++++++++++++++++++++++++++++++++++
drivers/of/Kconfig | 2 +-
2 files changed, 68 insertions(+), 1 deletions(-)
create mode 100644 arch/sparc/include/asm/of_i2c.h
diff --git a/arch/sparc/include/asm/of_i2c.h b/arch/sparc/include/asm/of_i2c.h
new file mode 100644
index 0000000..93c7c05
--- /dev/null
+++ b/arch/sparc/include/asm/of_i2c.h
@@ -0,0 +1,67 @@
+#ifndef _ASM_SPARC_OF_I2C_H
+#define _ASM_SPARC_OF_I2C_H
+
+/* In my copy of the I2C bindings for IEEE1275 the register value is
+ * encoded as a 2-cell value:
+ *
+ * Bit # 33222222 22221111 11111100 00000000
+ * 10987654 32109876 54321098 76543210
+ *
+ * bus: 00000000 00000000 00000000 bbbbbbbb
+ * address: 00000000 00000000 00000sss sssssss0
+ *
+ * where:
+ * bbbbbbbb 8-bit unsigned number representing
+ * the I2C bus address within this I2C bus
+ * controller node
+ * ssssssssss 10-bit unsigned number representing the
+ * slave address
+ *
+ * When doing I2C transfers to a device the low bit of the address
+ * indicates whether the transfer is a read or a write, and the upper
+ * bits indicate the device address.
+ *
+ * The Linux I2C layer wants device addresses which elide this
+ * direction bit. Thus we should shift the OF provided reg property
+ * address down by one bit.
+ */
+static inline int of_i2c_fetch_addr(struct i2c_board_info *bp,
+ struct device_node *client_node,
+ struct device_node *adap_node,
+ int num_addr_cells)
+{
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(client_node, "reg", &len);
+ if (!addr)
+ goto out_inval;
+
+ if (len < (num_addr_cells * sizeof(int)))
+ goto out_inval;
+
+ if (addr[num_addr_cells - 1] > (1 << 10) - 1)
+ goto out_inval;
+
+ switch (num_addr_cells) {
+ case 1:
+ bp->addr = addr[0];
+ break;
+
+ case 2:
+ /* XXX cell 0 contains bus number XXX */
+ bp->addr = addr[1];
+ break;
+
+ default:
+ goto out_inval;
+ }
+
+ return 0;
+
+out_inval:
+ printk(KERN_ERR "of-i2c: invalid i2c device entry\n");
+ return -EINVAL;
+}
+
+#endif /* _ASM_SPARC_OF_I2C_H */
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index f821dbc..493c717 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -10,7 +10,7 @@ config OF_GPIO
config OF_I2C
def_tristate I2C
- depends on PPC_OF && I2C
+ depends on I2C
help
OpenFirmware I2C accessors
--
1.5.6.5.GIT
^ permalink raw reply related
* [PATCH 1/3]: sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
From: David Miller @ 2008-08-22 4:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, paulus, sparclinux
sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
This allows more OF layer code to be shared between powerpc and
sparc.
With feedback and suggestions from Anton Vorontsov.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/sparc/include/asm/prom.h | 10 ++++++++++
arch/sparc/kernel/of_device.c | 11 +++++++++++
arch/sparc64/kernel/of_device.c | 11 +++++++++++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index fd55522..b44e0c7 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -94,6 +94,16 @@ static inline void of_node_put(struct device_node *node)
{
}
+/* These routines are here to provide compatibility with how powerpc
+ * handles IRQ mapping for OF device nodes. We precompute and permanently
+ * register them in the of_device objects, whereas powerpc computes them
+ * on request.
+ */
+extern unsigned int irq_of_parse_and_map(struct device_node *node, int index);
+static inline void irq_dispose_mapping(unsigned int virq)
+{
+}
+
/*
* NB: This is here while we transition from using asm/prom.h
* to linux/of.h
diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
index cc4c235..aace71f 100644
--- a/arch/sparc/kernel/of_device.c
+++ b/arch/sparc/kernel/of_device.c
@@ -29,6 +29,17 @@ struct of_device *of_find_device_by_node(struct device_node *dp)
}
EXPORT_SYMBOL(of_find_device_by_node);
+unsigned int irq_of_parse_and_map(struct device_node *node, int index)
+{
+ struct of_device *op = of_find_device_by_node(node);
+
+ if (!op || index >= op->num_irqs)
+ return 0;
+
+ return op->irqs[index];
+}
+EXPORT_SYMBOL(irq_of_parse_and_map);
+
#ifdef CONFIG_PCI
struct bus_type ebus_bus_type;
EXPORT_SYMBOL(ebus_bus_type);
diff --git a/arch/sparc64/kernel/of_device.c b/arch/sparc64/kernel/of_device.c
index f8b50cb..a30f2af 100644
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -55,6 +55,17 @@ struct of_device *of_find_device_by_node(struct device_node *dp)
}
EXPORT_SYMBOL(of_find_device_by_node);
+unsigned int irq_of_parse_and_map(struct device_node *node, int index)
+{
+ struct of_device *op = of_find_device_by_node(node);
+
+ if (!op || index >= op->num_irqs)
+ return 0;
+
+ return op->irqs[index];
+}
+EXPORT_SYMBOL(irq_of_parse_and_map);
+
#ifdef CONFIG_PCI
struct bus_type ebus_bus_type;
EXPORT_SYMBOL(ebus_bus_type);
--
1.5.6.5.GIT
^ permalink raw reply related
* [PATCH 0/3]: Sparc OF I2C support v2.
From: David Miller @ 2008-08-22 4:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, paulus, sparclinux
Ok, I've integrated the feedback I got from various reviewers and for
now I'm going to handle the sparc vs. powerpc aspects with a helper
asm/of_i2c.h header file that implements the address fetching.
I think for the time being this is the best solution. If the
semantics converge, we can merge the logic back into the generic code.
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Grant Likely @ 2008-08-22 4:18 UTC (permalink / raw)
To: David Miller
Cc: devicetree-discuss, linuxppc-dev, sparclinux, scottwood, paulus
In-Reply-To: <20080821.205305.74123372.davem@davemloft.net>
On Thu, Aug 21, 2008 at 9:53 PM, David Miller <davem@davemloft.net> wrote:
>> Have patience with the embedded people that are both new to
>> OpenFirmware and trying to make stuff work at the same time. I
>> think the devicetree-discuss list will help here as new bindings are
>> proposed. I hope you're subscribed.
>
> Why not ask the people who actually work on the standards? That's who
> I go to when I want to know something about openfirmware issues.
You mean email them privately? Outside of a public forum? That
doesn't help much when it comes to discussing/debating issues and
learning from other peoples conversations.
As far as I can tell there aren't any other active mailing lists
purposed for discussing device tree bindings.
http://openfirmware.org, http://firmworks.com, and
http://playground.sun.com/1275/ don't list any mailing lists and the
last meeting shown on playground.sun.com was scheduled for 1999.
openbios.org has a mailing list which seems to be idle except for SVN
commit messages and doesn't seem to be used for discussing bindings.
We need a place to discuss these issues that I don't see anywhere
else. Please correct me if I'm missing a list.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-22 3:53 UTC (permalink / raw)
To: jwboyer; +Cc: devicetree-discuss, linuxppc-dev, sparclinux, paulus, scottwood
In-Reply-To: <1219367743.26429.66.camel@jdub.homelinux.org>
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Thu, 21 Aug 2008 21:15:37 -0400
> Huge? I'd say mistake, but not necessarily huge. I mean nobody other
> than you (at least in the context of this conversation) had access to
> the IEEE1275 proposed binding so it wasn't like there was tons to go on.
I guess all the PowerMAC G5 systems out there and their device trees
were locked up in a highly secure vault somewhere :-)
> Have patience with the embedded people that are both new to
> OpenFirmware and trying to make stuff work at the same time. I
> think the devicetree-discuss list will help here as new bindings are
> proposed. I hope you're subscribed.
Why not ask the people who actually work on the standards? That's who
I go to when I want to know something about openfirmware issues.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Jon Smirl @ 2008-08-22 2:39 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linuxppc-dev, sparclinux, paulus, Scott Wood,
David Miller
In-Reply-To: <fa686aa40808211933o72c2da60v557d5a58f2c9d1a7@mail.gmail.com>
On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Aug 21, 2008 at 5:45 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> >> Ugh, more like loads of pain. There are deployed platforms using the
> >> embedded 'invented' bindings. I don't think it is an option to break
> >> compatibility with older trees. If there is some backwards
> >> compatibility code then I'm all for migrating to the same binding as
> >> Sparc and PowerMac
> >
> > Has anything really been deployed? These bindings are only a few months old.
>
>
> It was over a year ago when support for i2c devices in the device tree
> was merged.
I see, the old support needed the drivers to be built-in. The newer
code dynamically loads the correct i2c driver and set its parameters.
Did the old code use anything besides compatible? It would have been
using the older i2c system that probed for the address.
>
> See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065.
>
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Grant Likely @ 2008-08-22 2:33 UTC (permalink / raw)
To: Jon Smirl
Cc: devicetree-discuss, linuxppc-dev, sparclinux, paulus, Scott Wood,
David Miller
In-Reply-To: <9e4733910808211645p27ff2c6ci6dba6f363e9ece15@mail.gmail.com>
On Thu, Aug 21, 2008 at 5:45 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> Ugh, more like loads of pain. There are deployed platforms using the
>> embedded 'invented' bindings. I don't think it is an option to break
>> compatibility with older trees. If there is some backwards
>> compatibility code then I'm all for migrating to the same binding as
>> Sparc and PowerMac
>
> Has anything really been deployed? These bindings are only a few months old.
It was over a year ago when support for i2c devices in the device tree
was merged.
See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* TLB programming in powerpc tree. Was: Accessing peripheral bus devices on 460GT
From: vb @ 2008-08-22 2:29 UTC (permalink / raw)
To: linuxppc-embedded
Gentlemen, I am back to this puzzling problem, must be missing
something obvious...
Again, I'm trying to bring up a 460GT based system in 2.6.25 kernel.
The problem is I can't gain access to the peripheral devices. The call
to ioremap_nocache() returns a valid pointer, but dereferencing that
pointer causes memory access error.
Naturally, right before the kernel starts up, the device is available
(u-boot configures access to it, both CS and TLB) and uses it. A
closer look shows that the CS registers are left intact, but all TLBs
are wiped out when the kernel starts up. Then just three TLB entries
are created for 3 256M blocks od SDRAM (even though the hardware has
1G of SDRAM, I wonder what's the deal with the last quarter of the
memory is.
But the main problem is that the kernel never sets up TLBs for neither
the peripheral device, nor the onboard flash. I don't seem to be able
to find the place where this is supposed to happen. I assumed that
ioremap_nocache would take care of that, but this is not the case.
So, something which should cause setting up the TLBs for these regions
is missing, can any one let me know what it is? Is this supposed to be
described in the flat device tree? Which part of the kernel code is
responsible for setting up these TLBs?
Any hints will be highly appreciated,
TIA,
vadim
On Wed, Aug 6, 2008 at 7:52 PM, vb <vb@vsbe.com> wrote:
> I am trying to bring up a 2.6.25 based system on a 460GT platform. I
> am using the OF tree cloned off canyonblands.dts, and I am not sure if
> something is missing in the tree, or in the kernel, or I am doing
> something stupid.
>
> The problem is that I don't seem to be able to access any peripheral
> device activated by cs1, 2, 3 (I have not tried touching the NOR flash
> (cs0) just yet). If I don't touch any peripherals the system can
> netbboot or diskboot all the way to the linux prompt.
>
> But unfortunately, the damn peripherals have to be touched :-)
>
> I do invoke ioremap_nocache(<phys addr>, <addr range size>), and it
> returns a virtual address. The thing is that as soon as I try
> accessing the device off this pointer an exception is thrown. From
> u-boot I can access the <phys addr>..+<addr range size> space no
> problem.
>
> I see that the dts file mentions that u-boot is supposed to supply
> the "ranges" property in the /plb/opb/ebc section; examining the
> u-boot code for different amcc platforms shows that only the NOR flash
> size is supplied there.
>
> I guess the real question is how do I gain access to the EBC mapped
> hardware configured by u-boot?
>
> can someone please shed any light on this,
>
> thanks a lot in advance,
>
> Vadim
>
^ permalink raw reply
* disable modules and get "multiple definition" errors?
From: Kevin Diggs @ 2008-08-22 1:28 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am trying to do some compile testing of my cpufreq driver. If
I disable modules I am getting multiple definition errors of inline
functions:
inline volatile unsigned int get_PLL(void)
{
unsigned int ret;
__asm__ __volatile__ ("mfspr %0,%1":
"=r"(ret):
"i"(SPRN_HID1)
);
return ret;
}
arch/powerpc/kernel/cpu/pll_if.o(.text+0x1c): In function `get_PLL':
: multiple definition of `get_PLL'
arch/powerpc/kernel/cpu/cpufreq/built-in.o(.text+0x0): first defined here
What am I doing wrong?
kevin
^ 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