* Re: simple MPC5200B system
From: Andre Schwarz @ 2008-03-18 10:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list
In-Reply-To: <47DF821B.6090600@matrix-vision.de>
[-- Attachment #1: Type: text/plain, Size: 4976 bytes --]
Grant,
sorry for having troubled you. Looks like the build system has been in
an invalid state...
After doing a git-pull and "make distclean" + "make mpc5200_defconfig"
the system is finally up and running.
Using mpc5200-simple-platform machine description
Linux version 2.6.25-rc6-00978-g275c005-dirty (root@nova) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #9 Tue Mar 18 11:25:07 CET 2008
Found initrd at 0xc397a000:0xc3c00000
arch/powerpc/platforms/52xx/mpc52xx_common.c: Error mapping XLB in
mpc52xx_setup_cpu(). Expect some abnormal behavior
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 16384
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: root=/dev/ram ro rootfstype=squashfs
ip=192.168.65.57::192.168.65.15:255.255.255.0 console=ttyPSC0,115200N8
e1000.TxDescriptors=1500 e1000.SmartPowerDownEnable=1
MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
clocksource: timebase mult[79364d9] shift[22] registered
console [ttyPSC0] enabled
....
regards,
Andre
Andre Schwarz schrieb:
> Grant,
>
> I've pulled the latest git and built a mpc5200_simple system with a
> minimal dts.
> There's not a single char put on the console ....
>
>
>
> Grant Likely schrieb:
>> On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz
>> <Andre.Schwarz@matrix-vision.de> wrote:
>>
>>> All,
>>>
>>> I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
>>> ... maybe someone could give me some hints.
>>> Up to now the systems have been running on 2.6.19 without any problems.
>>>
>>> This is what I've done so far :
>>>
>>> - get a recent system with 2.6.19 running and keep the toolchain (gcc
>>> 4.0) including RFS uImage.
>>> - latest bootloader (u-boot 1.3.2) is running fine with dtb support.
>>> - Kernel and RFS images are available via bootp/tftp
>>> - device tree blob seems ok, i.e. u-boot can display the blob and fill
>>> in all clocks correctly.
>>> - Kernel gets called with Kernel, RFS and dtb on suitable adresses
>>> (0x100000, 0x600000, 0x5F0000).
>>> - nothing more happens. It looks like the console isn't working properly
>>> - maybe worse ...
>>>
>>
>> Can you either halt the processor or reset the board and access memory
>> after this point? You should see if you can access __log_buf (Look in
>> System.map for the address and subtract 0xc0000000 to get the physical
>> address). __log_buf should give you clues about how far booting
>> progresses.
>>
>>
> (c033d4b4 b __log_buf) yields all zeroes - nothing logged at all.
>
> Examining the CPU state with the bdi shows :
>
> Target CPU : MPC8280/8220/5200 (Zeppo)
> Target state : debug mode
> Debug entry cause : COP halt
> Current PC : 0xc000552c
> Current CR : 0x48000042
> Current MSR : 0x00009032
> Current LR : 0xc00166c0
>
> The program counter shows the adress of "irq_set_virq_count" which has
> a BUG() macro. Looks like this one evaluates to true.
>
> What do you think ?
>
>>> The kernel has been build using the "MPC5200 simple" setup. I've added
>>> our board identifier "mv,mvbluecougar" to the list of supported boards
>>> in the "mpc52xx_simple.c" file. This identifier is used in the dtb as
>>> well of course. This should be enough along with a valid device tree
>>> blob, isn't it ? Did I miss anything already ?
>>>
>>
>> Yes, this should be enough (on a side note; it should probably be
>> "matrix-vision,bluecougar" unless of''mv' is your company's stock
>> ticker symbol).
>>
>>
>>> As far as I did understand by reading the docs it should be possible
>>> running a general MPC52xx kernel with a custom dtb ? Is this correct ?
>>>
>>
>> That is correct.
>>
>>
>>> The dts file has already been reduced to a minimum, i.e. only the cpu,
>>> pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,
>>> pci, ata or "advanced" features like mtd partitions. All I want to get
>>> working is the serial console on "/dev/ttyPSC0".
>>>
>>
>> Cheers,
>> g.
>>
>>
>
> regards,
> Andre
>
> MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler -
> Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer:
> Gerhard Thullner, Werner Armingeon, Uwe Furtner
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 6666 bytes --]
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Josh Boyer @ 2008-03-18 12:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803171942u78d2aa68y47c1de3321f727f1@mail.gmail.com>
On Mon, 17 Mar 2008 20:42:14 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Grant,
> >
> >
> > in message <fa686aa40803171643y7db21cadsc454a713ba6c4342@mail.gmail.com> you wrote:
> > >
> > > However, I have declined (for now) to pick up the defconfigs for those
> > > boards and instead merged in the config features they require into the
> > > mpc5200 defconfig. My primary reason for doing so is to increase the
> > > likelyhood that full featured kernels are built and tested so that
> > > situations where board ports conflict with each other are caught and
> > > fixed.
> >
> > I know what you mean, and I agree with the idea.
> >
> > Unfortunately I think it's impossible to implement, especially on such
> > embedded processors with their high level of pin multiplexing.
> >
> > For example, if you want to include testing of the FEC ethernet
> > driver, you will probably fail to test the second USB port. I think
> > it's simply not possible to test all possible options in a single
> > kernel configuration - first it doesn't work (for example because of
> > pin multiplexing issues), second you will likely not be able to find
> > hardware that implements all features at once.
>
> I don't think this example really applies. Yes, I agree that I cannot
> test all the functions, but that does not preclude building in all the
> drivers and making sure that they don't cause a conflict by just being
> present. For instance, I can build a single kernel image right now
> that should boot and fully run on the Efika, lite5200, tqm and motion
> pro boards (although the Efika has a different wrapper). I can only
> test it on the Efika and lite5200 boards and I have to rely on other
> people for the boards I don't have. If it breaks; I expect to receive
> an irate email in my Inbox telling me to fix it!
>
> pin multiplexing shouldn't be an issue at all. Only the devices which
> are instantiated in the device tree will actually get initialized so
> if the pins aren't hooked up then it shouldn't be in the tree.
That's not entirely true. Devices that are muxed can be added to the
tree just fine. What I've done on 440 boards that have devices that
share pins is to add a status = "disabled"; property to the device that
doesn't have pins at the moment.
See my patch for of_device_is_available for how to query that. I'll be
throwing that in my tree soon if Paul doesn't pick it up.
josh
^ permalink raw reply
* [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Stefan Roese @ 2008-03-18 13:36 UTC (permalink / raw)
To: linuxppc-dev
This patch adds support for the 256k L2 cache found on some IBM/AMCC
4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
which currently "only" adds the L2 cache init code. Other common 4xx
stuff can be added later here.
The L2 cache handling code is just a copy of Eugene's code in arch/ppc
with small modifications.
Tested on AMCC Taishan 440GX and Canyonlands 460EX.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/Kconfig | 3 +
arch/powerpc/platforms/44x/Kconfig | 2 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_soc.c | 174 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/dcr-regs.h | 78 ++++++++++++++++
5 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_soc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1189d8d..69d4738 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -490,6 +490,9 @@ config FSL_PCI
bool
select PPC_INDIRECT_PCI
+config 4xx_SOC
+ bool
+
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
bool
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 83155fe..061ba3c 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -120,6 +120,7 @@ config 440GP
config 440GX
bool
+ select 4xx_SOC
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII #test only
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 15f3e85..851a0be 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
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_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
new file mode 100644
index 0000000..4847555
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -0,0 +1,174 @@
+/*
+ * IBM/AMCC PPC4xx SoC setup code
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * L2 cache routines cloned from arch/ppc/syslib/ibm440gx_common.c which is:
+ * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ * Copyright (c) 2003 - 2006 Zultys Technologies
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/of_platform.h>
+
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
+
+static u32 dcrbase;
+
+/*
+ * L2-cache
+ */
+
+/* Issue L2C diagnostic command */
+static inline u32 l2c_diag(u32 addr)
+{
+ mtdcr(dcrbase + DCRN_L2C0_ADDR, addr);
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_DIAG);
+ while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
+ ;
+
+ return mfdcr(dcrbase + DCRN_L2C0_DATA);
+}
+
+static irqreturn_t l2c_error_handler(int irq, void *dev)
+{
+ u32 sr = mfdcr(dcrbase + DCRN_L2C0_SR);
+
+ if (sr & L2C_SR_CPE) {
+ /* Read cache trapped address */
+ u32 addr = l2c_diag(0x42000000);
+ printk(KERN_EMERG "L2C: Cache Parity Error, addr[16:26] = 0x%08x\n",
+ addr);
+ }
+ if (sr & L2C_SR_TPE) {
+ /* Read tag trapped address */
+ u32 addr = l2c_diag(0x82000000) >> 16;
+ printk(KERN_EMERG "L2C: Tag Parity Error, addr[16:26] = 0x%08x\n",
+ addr);
+ }
+
+ /* Clear parity errors */
+ if (sr & (L2C_SR_CPE | L2C_SR_TPE)){
+ mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
+ } else {
+ printk(KERN_EMERG "L2C: LRU error\n");
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int __init ppc4xx_l2c_probe(void)
+{
+ struct device_node *np = NULL;
+ u32 r;
+ unsigned long flags;
+ int irq;
+ const u32 *dcrreg;
+ u32 dcrbase_isram;
+ int len;
+
+ np = of_find_compatible_node(np, NULL, "ibm,l2-cache");
+ if (!np)
+ return 0;
+
+ /* Map DCRs */
+ dcrreg = of_get_property(np, "dcr-reg", &len);
+ if (!dcrreg || (len != 4*sizeof(u32))) {
+ printk(KERN_ERR "%s: Can't get DCR register base !",
+ np->full_name);
+ return -ENODEV;
+ }
+ dcrbase_isram = dcrreg[0];
+ dcrbase = dcrreg[2];
+
+ /* Get and map irq number from device tree */
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ printk(KERN_ERR "irq_of_parse_and_map failed\n");
+ return -ENODEV;
+ }
+
+ /* Install error handler */
+ if (request_irq(irq, l2c_error_handler, IRQF_DISABLED, "L2C", 0) < 0) {
+ printk(KERN_ERR "Cannot install L2C error handler"
+ ", cache is not enabled\n");
+ return -ENODEV;
+ }
+
+ local_irq_save(flags);
+ asm volatile ("sync" ::: "memory");
+
+ /* Disable SRAM */
+ mtdcr(dcrbase_isram + DCRN_SRAM0_DPC,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_DPC) & ~SRAM_DPC_ENABLE);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB0CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB0CR) & ~SRAM_SBCR_BU_MASK);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB1CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB1CR) & ~SRAM_SBCR_BU_MASK);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB2CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB2CR) & ~SRAM_SBCR_BU_MASK);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB3CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB3CR) & ~SRAM_SBCR_BU_MASK);
+
+ /* Enable L2_MODE without ICU/DCU */
+ r = mfdcr(dcrbase + DCRN_L2C0_CFG) &
+ ~(L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_SS_MASK);
+ r |= L2C_CFG_L2M | L2C_CFG_SS_256;
+ mtdcr(dcrbase + DCRN_L2C0_CFG, r);
+
+ mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
+
+ /* Hardware Clear Command */
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_HCC);
+ while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
+ ;
+
+ /* Clear Cache Parity and Tag Errors */
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
+
+ /* Enable 64G snoop region starting at 0 */
+ r = mfdcr(dcrbase + DCRN_L2C0_SNP0) &
+ ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
+ r |= L2C_SNP_SSR_32G | L2C_SNP_ESR;
+ mtdcr(dcrbase + DCRN_L2C0_SNP0, r);
+
+ r = mfdcr(dcrbase + DCRN_L2C0_SNP1) &
+ ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
+ r |= 0x80000000 | L2C_SNP_SSR_32G | L2C_SNP_ESR;
+ mtdcr(dcrbase + DCRN_L2C0_SNP1, r);
+
+ asm volatile ("sync" ::: "memory");
+
+ /* Enable ICU/DCU ports */
+ r = mfdcr(dcrbase + DCRN_L2C0_CFG);
+ r &= ~(L2C_CFG_DCW_MASK | L2C_CFG_PMUX_MASK | L2C_CFG_PMIM
+ | L2C_CFG_TPEI | L2C_CFG_CPEI | L2C_CFG_NAM | L2C_CFG_NBRM);
+ r |= L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_TPC | L2C_CFG_CPC | L2C_CFG_FRAN
+ | L2C_CFG_CPIM | L2C_CFG_TPIM | L2C_CFG_LIM | L2C_CFG_SMCM;
+
+ /* Check for 460EX/GT special handling */
+ if (of_device_is_compatible(np, "ibm,l2-cache-460ex"))
+ r |= L2C_CFG_RDBW;
+
+ mtdcr(dcrbase + DCRN_L2C0_CFG, r);
+
+ asm volatile ("sync; isync" ::: "memory");
+ local_irq_restore(flags);
+
+ printk(KERN_INFO "256k L2-cache enabled\n");
+
+ return 0;
+}
+arch_initcall(ppc4xx_l2c_probe);
diff --git a/include/asm-powerpc/dcr-regs.h b/include/asm-powerpc/dcr-regs.h
index 9f1fb98..29b0ece 100644
--- a/include/asm-powerpc/dcr-regs.h
+++ b/include/asm-powerpc/dcr-regs.h
@@ -68,4 +68,82 @@
#define SDR0_UART3 0x0123
#define SDR0_CUST0 0x4000
+/*
+ * All those DCR register addresses are offsets from the base address
+ * for the SRAM0 controller (e.g. 0x20 on 440GX). The base address is
+ * excluded here and configured in the device tree.
+ */
+#define DCRN_SRAM0_SB0CR 0x00
+#define DCRN_SRAM0_SB1CR 0x01
+#define DCRN_SRAM0_SB2CR 0x02
+#define DCRN_SRAM0_SB3CR 0x03
+#define SRAM_SBCR_BU_MASK 0x00000180
+#define SRAM_SBCR_BS_64KB 0x00000800
+#define SRAM_SBCR_BU_RO 0x00000080
+#define SRAM_SBCR_BU_RW 0x00000180
+#define DCRN_SRAM0_BEAR 0x04
+#define DCRN_SRAM0_BESR0 0x05
+#define DCRN_SRAM0_BESR1 0x06
+#define DCRN_SRAM0_PMEG 0x07
+#define DCRN_SRAM0_CID 0x08
+#define DCRN_SRAM0_REVID 0x09
+#define DCRN_SRAM0_DPC 0x0a
+#define SRAM_DPC_ENABLE 0x80000000
+
+/*
+ * All those DCR register addresses are offsets from the base address
+ * for the SRAM0 controller (e.g. 0x30 on 440GX). The base address is
+ * excluded here and configured in the device tree.
+ */
+#define DCRN_L2C0_CFG 0x00
+#define L2C_CFG_L2M 0x80000000
+#define L2C_CFG_ICU 0x40000000
+#define L2C_CFG_DCU 0x20000000
+#define L2C_CFG_DCW_MASK 0x1e000000
+#define L2C_CFG_TPC 0x01000000
+#define L2C_CFG_CPC 0x00800000
+#define L2C_CFG_FRAN 0x00200000
+#define L2C_CFG_SS_MASK 0x00180000
+#define L2C_CFG_SS_256 0x00000000
+#define L2C_CFG_CPIM 0x00040000
+#define L2C_CFG_TPIM 0x00020000
+#define L2C_CFG_LIM 0x00010000
+#define L2C_CFG_PMUX_MASK 0x00007000
+#define L2C_CFG_PMUX_SNP 0x00000000
+#define L2C_CFG_PMUX_IF 0x00001000
+#define L2C_CFG_PMUX_DF 0x00002000
+#define L2C_CFG_PMUX_DS 0x00003000
+#define L2C_CFG_PMIM 0x00000800
+#define L2C_CFG_TPEI 0x00000400
+#define L2C_CFG_CPEI 0x00000200
+#define L2C_CFG_NAM 0x00000100
+#define L2C_CFG_SMCM 0x00000080
+#define L2C_CFG_NBRM 0x00000040
+#define L2C_CFG_RDBW 0x00000008 /* only 460EX/GT */
+#define DCRN_L2C0_CMD 0x01
+#define L2C_CMD_CLR 0x80000000
+#define L2C_CMD_DIAG 0x40000000
+#define L2C_CMD_INV 0x20000000
+#define L2C_CMD_CCP 0x10000000
+#define L2C_CMD_CTE 0x08000000
+#define L2C_CMD_STRC 0x04000000
+#define L2C_CMD_STPC 0x02000000
+#define L2C_CMD_RPMC 0x01000000
+#define L2C_CMD_HCC 0x00800000
+#define DCRN_L2C0_ADDR 0x02
+#define DCRN_L2C0_DATA 0x03
+#define DCRN_L2C0_SR 0x04
+#define L2C_SR_CC 0x80000000
+#define L2C_SR_CPE 0x40000000
+#define L2C_SR_TPE 0x20000000
+#define L2C_SR_LRU 0x10000000
+#define L2C_SR_PCS 0x08000000
+#define DCRN_L2C0_REVID 0x05
+#define DCRN_L2C0_SNP0 0x06
+#define DCRN_L2C0_SNP1 0x07
+#define L2C_SNP_BA_MASK 0xffff0000
+#define L2C_SNP_SSR_MASK 0x0000f000
+#define L2C_SNP_SSR_32G 0x0000f000
+#define L2C_SNP_ESR 0x00000800
+
#endif /* __DCR_REGS_H__ */
--
1.5.4.4
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: Stefan Roese @ 2008-03-18 13:37 UTC (permalink / raw)
To: linuxppc-dev
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/taishan.dts | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..d0bff33 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -104,6 +104,16 @@
// FIXME: anything else?
};
+ L2C0: l2c@30 {
+ compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
+ dcr-reg = <20 8 /* Internal SRAM DCR's */
+ 30 8>; /* L2 cache DCR's */
+ cache-line-size = <20>; /* 32 bytes */
+ cache-size = <40000>; /* L2, 256K */
+ interrupt-parent = <&UIC2>;
+ interrupts = <17 1>;
+ };
+
plb {
compatible = "ibm,plb-440gx", "ibm,plb4";
#address-cells = <2>;
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
From: Valentine Barshak @ 2008-03-18 14:21 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, Jeff Garzik, linuxppc-dev
In-Reply-To: <1205808100.26869.204.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> http://marc.info/?l=linux-netdev&m=120449748701492&w=2
>>
>> I sent it to Ben with netdev on CC because you asked the various people
>> sending NEWEMAC patches to you to find a single person.
>>
>> So from now on, what are we going to do? It seems we're playing net
>> maintainer russian roulette for NEWEMAC and it's getting old.
>
> I'm happy to collect the patches. I said I would do it, I was just taken
> aback a bit by Jeff suddenly merging two of Stefan patches directly :-)
>
> I was actually planning this week to post a serie of all the pending
> EMAC patches for final review.
>
> Cheers,
> Ben.
>
>
FYI, These are the NEWEMAC patches I've sent:
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052114.html
(This is a TAH csum fix, that I don't see on the patchwork for some reason)
and a couple of PHY clock workarounds
http://patchwork.ozlabs.org/linuxppc/patch?id=17211
http://patchwork.ozlabs.org/linuxppc/patch?id=17212
The latter two patches depend on the "dcri_clrset" one:
http://patchwork.ozlabs.org/linuxppc/patch?id=17199
Ben, could you please also take a look at the PCIe dcri_clrset stuff here
http://patchwork.ozlabs.org/linuxppc/patch?id=17214
(not EMAC related)
Thanks,
Valentine.
^ permalink raw reply
* Re: simple MPC5200B system
From: Grant Likely @ 2008-03-18 14:31 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <47DF9ABB.2020607@matrix-vision.de>
On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
>
> Grant,
>
> sorry for having troubled you. Looks like the build system has been in an
> invalid state...
>
> After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the
> system is finally up and running.
Heh; I hate it when that happens. :-)
Congratulations.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Timur Tabi @ 2008-03-18 14:32 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1205831779.7589.80.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund wrote:
> Found it, the eth1 i/f on this board isn't working and does not generate
> any clocks which makes ugeth_graceful_stop_tx() hang forever.
Well, that doesn't make it very graceful, does it? :-)
Can you fix this yourself, or do you want me to file an internal bug report? If
so, can you email me a detailed description of the problem?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Nathan Lynch @ 2008-03-18 14:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, LinuxPPC-dev, Jan-Bernd Themann, Paul Mackerras,
Stephen Rothwell
In-Reply-To: <1205808221.26869.207.camel@pasglop>
Benjamin Herrenschmidt wrote:
>
> On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
> > On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> > > Currently HEA requires 4K pages for IO resources. Just set the pages size to
> > > IO to 4K.
> >
> > Well, that's too bad. Why penalize all platforms for it?
> >
> > I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
> > waste tlb and erat space.
>
> We would have to make that pSeries specific for now I suppose...
>
> We don't have a way to know that there "can" be an EHEA right ? It may
> not be in the device-tree at boot and dynamically added to the
> partition...
The ibm,drc-names property of the root node should have "HEA" strings
in it on systems where EHEA can potentially be present.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-18 14:47 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, rpurdie
In-Reply-To: <47DF7D6F.8010808@semihalf.com>
On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant,
>
> Yes, the Motion-PRO LED driver has been reworked and posted:
> http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
>
>
> > I need to look at it again,
> > but it is a lot of code for a very simple thing and I wasn't sure if I
> > should be the one to pick it up because it is in drivers/leds which
> > has a different maintainer.
>
> I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer.
>
> Richard -- could pick up the above mentioned Motion-PRO LED driver for
> upstream inclusion? It started as a MPC5200-specific thing posted to
> linuxppc-dev and got reviewed there, with the intent to go upstream via
> Grant (MPC52XX maintainer). However, it seems that it should be merged
> through your subsystem.
Okay, I've taken another look at the driver and I've figured out what
has been bothering me about it. It seems to me that the motion pro
led driver is just the first of many that we will see (seeing as some
many people find the blinking lights rather soothing) and it's a non
trivial amount of code.
(Note: I'm not actually opposed to this driver if Richard is okay with
it; but I do think that in the long term we should move towards a more
generic approach)
In essence, this driver sets up two GPIO pins to drive LEDs. A pretty
common approach for putting LEDs on a board. In this case each GPIO
bank only contains 1 pin; but I imagine that on other boards there
will be multiple pins in a GPIO bank, only some of which actually used
for blinking LEDs.
I've started thinking that it would be better to split things up in
the device tree to have one node for each GPIO block and a single LED
node that maps LEDs to gpio pins. That would allow a common driver to
be written for all GPIO driven LEDs with a single block of device tree
parsing code. Plus, it allows other devices to use GPIO pins within
the same block (not an issue for the motion pro board; but when other
boards start coming on-line it would allow us to reduce the amount of
board specific code). Finally, it means that the timer pin GPIO
driver can be used for more than just flashing an attached LED.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Scott Wood @ 2008-03-18 15:11 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <47DF777E.2030103@denx.de>
On Tue, Mar 18, 2008 at 09:04:14AM +0100, Heiko Schocher wrote:
> OK. Another thought about this. Shouldnt this table go in the dts?
> A device node like
>
> cpm_pin {
> pins = <port pin flags>;
> };
>
> would be nice, or?
Well, the device tree is a mechanism for communicating from the firmware
to the kernel, and if we could control the firmware better we'd just make
it set the pins properly to begin with. :-)
-Scott
^ permalink raw reply
* Re: simple MPC5200B system
From: Andre Schwarz @ 2008-03-18 15:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list
In-Reply-To: <fa686aa40803180731g3892e737h29db0cb917946588@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]
Grant Likely schrieb:
> On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
>
>> Grant,
>>
>> sorry for having troubled you. Looks like the build system has been in an
>> invalid state...
>>
>> After doing a git-pull and "make distclean" + "make mpc5200_defconfig" the
>> system is finally up and running.
>>
>
> Heh; I hate it when that happens. :-)
>
> Congratulations.
>
> g.
>
>
>
Grant,
this leads to the next questions ... :-)
I've read some discussions about the "interrupt-map" attribute of the
pci node. I tried to follow Ben and David in their explanations -
obviously I didn't really get it.
Looks like there are a lot of people outside who need some enlightenment
... including me, of course.
Maybe you can clarify this ?
Taken from motionpro.dts ...
interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
c000 0 0 2 &mpc5200_pic 1 1 3
c000 0 0 3 &mpc5200_pic 1 2 3
c000 0 0 4 &mpc5200_pic 1 3 3
c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
c800 0 0 2 &mpc5200_pic 1 2 3
c800 0 0 3 &mpc5200_pic 1 3 3
c800 0 0 4 &mpc5200_pic 0 0 3>;
First parameter seems to be the slot number, i.e. IDSEL line of the PCI
device.
How is this value coded ? Are these the bits 15..11 of the configuration
address ?
2nd + 3rd paramter : no clue ! can you explain ?
4th : seem to be INT_A ... _D of a PCI device. Usually a device uses
only INT_A. Do we need 4 entries in any case ?
5th : ok - parent pic
6th ... 8th : IRQ representation of the parent pic, which gives :
6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
number 1..3 inside MAIN level.
8th : should be 3 = "level low" which is default for PCI.
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 4089 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Joakim Tjernlund @ 2008-03-18 15:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47DFD29B.5050502@freescale.com>
On Tue, 2008-03-18 at 09:32 -0500, Timur Tabi wrote:
> Joakim Tjernlund wrote:
>
> > Found it, the eth1 i/f on this board isn't working and does not generate
> > any clocks which makes ugeth_graceful_stop_tx() hang forever.
>
> Well, that doesn't make it very graceful, does it? :-)
Nope, :)
>
> Can you fix this yourself, or do you want me to file an internal bug report? If
> so, can you email me a detailed description of the problem?
I fixed it by adding a counter which aborts after 100 loops. If you
could move along the 2 patches I sent today, "Add Fixed PHY support for
ucc_geth" and "ucc_geth: Add 8 bytes to max TX frame for VLANs" into
2.6.25 that would be great :)
Jocke
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
From: Timur Tabi @ 2008-03-18 15:21 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev
In-Reply-To: <1205853588.7589.110.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund wrote:
> I fixed it by adding a counter which aborts after 100 loops. If you
> could move along the 2 patches I sent today, "Add Fixed PHY support for
> ucc_geth" and "ucc_geth: Add 8 bytes to max TX frame for VLANs" into
> 2.6.25 that would be great :)
I have no control over that, sorry. You'll have to ask Jeff G or maybe Kumar to
pick up those patches.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] fsl_elbc_nand: fix mtd name
From: Anton Vorontsov @ 2008-03-18 15:43 UTC (permalink / raw)
To: linux-mtd; +Cc: Scott Wood, linuxppc-dev
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "NAND 32MiB 3,3V 8-bit"
mtd0 is physmap_of flash (normal name), and mtd1 is fsl_elbc_nand.
Despite inconsistency, with mtd name like this specifying paritions
from the kernel command line becomes a torture (though, I didn't tried
and not sure if mtdparts= can handle spaces at all). Plus, this causes
real bugs when multiple fsl_elbc_nand chips registered.
With this patch applied fsl_elbc_nand chip will have proper name:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "e0600000.flash"
p.s. We can't use priv->dev->bus_id as in physmap_of, because
fsl_elbc_nand pretends to be a localbus controller, so its bus_id is
"address.localbus", which is incorrect and thus will also not work
for multiple chips.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index b025dfe..54a9d83 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -974,6 +974,8 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
nand_release(&priv->mtd);
+ kfree(priv->mtd.name);
+
if (priv->vbase)
iounmap(priv->vbase);
@@ -1050,6 +1052,8 @@ static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
if (ret)
goto err;
+ priv->mtd.name = kasprintf(GFP_KERNEL, "%x.flash", res.start);
+
#ifdef CONFIG_MTD_PARTITIONS
/* First look for RedBoot table or partitions on the command
* line, these take precedence over device tree information */
--
1.5.2.2
^ permalink raw reply related
* [PATCH] [POWERPC] 83xx: mpc837x_rdb: add simple-bus compatible matching
From: Anton Vorontsov @ 2008-03-18 15:43 UTC (permalink / raw)
To: linuxppc-dev
This is needed to probe nor and nand flashes on the localbus.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
index 9c498b7..a653a38 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
@@ -81,6 +81,7 @@ static void __init mpc837x_rdb_setup_arch(void)
static struct of_device_id mpc837x_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
+ { .compatible = "simple-bus", },
{},
};
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] fsl_elbc_nand: fix mtd name
From: Scott Wood @ 2008-03-18 15:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20080318154344.GA31173@localhost.localdomain>
On Tue, Mar 18, 2008 at 06:43:44PM +0300, Anton Vorontsov wrote:
> With this patch applied fsl_elbc_nand chip will have proper name:
>
> root@b1:~# cat /proc/mtd
> dev: size erasesize name
> mtd0: 00800000 00010000 "fe000000.flash"
> mtd1: 02000000 00004000 "e0600000.flash"
>
> p.s. We can't use priv->dev->bus_id as in physmap_of, because
> fsl_elbc_nand pretends to be a localbus controller, so its bus_id is
> "address.localbus", which is incorrect and thus will also not work
> for multiple chips.
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* [PATCH v2] fsl_elbc_nand: fix mtd name
From: Anton Vorontsov @ 2008-03-18 15:58 UTC (permalink / raw)
To: linux-mtd; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080318154344.GA31173@localhost.localdomain>
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "NAND 32MiB 3,3V 8-bit"
mtd0 is physmap_of flash (normal name), and mtd1 is fsl_elbc_nand.
Despite inconsistency, with mtd name like this specifying paritions
from the kernel command line becomes a torture (though, I didn't tried
and not sure if mtdparts= can handle spaces at all). Plus, this causes
real bugs when multiple fsl_elbc_nand chips registered.
With this patch applied fsl_elbc_nand chip will have proper name:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "e0600000.flash"
p.s. We can't use priv->dev->bus_id as in physmap_of, because
fsl_elbc_nand pretends to be a localbus controller, so its bus_id is
"address.localbus", which is incorrect and thus will also not work
for multiple chips.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Oops, forgot the NULL checking.
drivers/mtd/nand/fsl_elbc_nand.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index b025dfe..9fff5d1 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -974,6 +974,9 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
nand_release(&priv->mtd);
+ if (priv->mtd.name)
+ kfree(priv->mtd.name);
+
if (priv->vbase)
iounmap(priv->vbase);
@@ -1050,6 +1053,12 @@ static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
if (ret)
goto err;
+ priv->mtd.name = kasprintf(GFP_KERNEL, "%x.flash", res.start);
+ if (!priv->mtd.name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
/* First look for RedBoot table or partitions on the command
* line, these take precedence over device tree information */
--
1.5.2.2
^ permalink raw reply related
* Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
From: Michael Neuling @ 2008-03-18 16:04 UTC (permalink / raw)
To: skumar; +Cc: Poornima Nayak, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080318052921.GA32259@in.ibm.com>
In message <20080318052921.GA32259@in.ibm.com> you wrote:
> Hi,
> I found the following bug at kernel boot up on my power machine
> with 2.6.25-rc6 kernel.
>
> USB Mass Storage support registered.
> mice: PS/2 mouse device common for all mice
> Unable to handle kernel paging request for data at address
> 0xd00008000000002e
> Faulting instruction address: 0xc00000000074ded8
> cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
> pc: c00000000074ded8: .f71805f_find+0x44/0x32c
> lr: c00000000074e1f8: .f71805f_init+0x38/0x194
> sp: c00000003e073d20
> msr: 8000000000009032
> dar: d00008000000002e
> dsisr: 42000000
> current = 0xc0000000220851c0
> paca = 0xc0000000007c2700
> pid = 1, comm = swapper
> enter ? for help
> [c00000003e073dc0] c00000000074e1f8 .f71805f_init+0x38/0x194
> [c00000003e073ea0] c000000000724bdc .kernel_init+0x204/0x3c8
> [c00000003e073f90] c000000000025df4 .kernel_thread+0x4c/0x68
Is this an all yes or random config? CONFIG_SENSORS_F71805F doesn't
appear in any of the powerpc def configs.
Anyway, I'm guessing the driver hasn't checked the device tree and is
probing somewhere it shouldn't.
Mikey
>
> For further reference some of the debug info is:
> 0:mon> r
> R00 = d00008000000002e R16 = 4000000001c00000
> R01 = c00000003e073d20 R17 = c00000000066ecc8
> R02 = c0000000008f4458 R18 = 0000000000000000
> R03 = 000000000000002e R19 = 00000000003a1000
> R04 = c00000003e073e30 R20 = 000000000235a3d0
> R05 = c00000003e073e34 R21 = c00000000075a3d0
> R06 = 0000000024000044 R22 = 000000000235a640
> R07 = c000000000010bcc R23 = c00000000075a640
> R08 = c00000003e073570 R24 = c00000000066fe90
> R09 = d000080000000000 R25 = 0000000000000000
> R10 = cf000000009c2d60 R26 = c00000003e070000
> R11 = ffffffffffffff87 R27 = c00000003e073e30
> R12 = 0000000000000000 R28 = c00000003e073e34
> R13 = c0000000007c2700 R29 = 000000000000002e
> R14 = 0000000000000000 R30 = c000000000880278
> R15 = c000000000670448 R31 = c00000000078e050
> pc = c00000000074ded8 .f71805f_find+0x44/0x32c
> lr = c00000000074e1f8 .f71805f_init+0x38/0x194
> msr = 8000000000009032 cr = 24000042
> ctr = c00000000074e1c0 xer = 0000000000000005 trap = 300
> dar = d00008000000002e dsisr = 42000000
>
> 0:mon> e
> cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
> pc: c00000000074ded8: .f71805f_find+0x44/0x32c
> lr: c00000000074e1f8: .f71805f_init+0x38/0x194
> sp: c00000003e073d20
> msr: 8000000000009032
> dar: d00008000000002e
> dsisr: 42000000
> current = 0xc0000000220851c0
> paca = 0xc0000000007c2700
> pid = 1, comm = swapper
>
> 0:mon> di %pc
> c00000000074ded8 7d6919ae stbx r11,r9,r3
> c00000000074dedc 39000001 li r8,1
> c00000000074dee0 990d01dc stb r8,476(r13)
> c00000000074dee4 e93f0000 ld r9,0(r31)
> c00000000074dee8 7c034a14 add r0,r3,r9
> c00000000074deec 7c0004ac sync
> c00000000074def0 7d6919ae stbx r11,r9,r3
> c00000000074def4 990d01dc stb r8,476(r13)
> c00000000074def8 38800023 li r4,35
> c00000000074defc 4bcc95e1 bl c0000000004174dc #
> .superio_inw+0x0/0x134
> c00000000074df00 3940ffed li r10,-19
> c00000000074df04 5463043e clrlwi r3,r3,16
> c00000000074df08 2f831934 cmpwi cr7,r3,6452
> c00000000074df0c 409e0260 bne cr7,c00000000074e16c #
> .f71805f_find+0x2d8/0x32c
> c00000000074df10 e93e8038 ld r9,-32712(r30)
> c00000000074df14 a0690000 lhz r3,0(r9)
> 0:mon>
>
> Thanks
> Sudhir Kumar
> ISTL, IBM
> Bangalore
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH v2] fsl_elbc_nand: fix mtd name
From: Scott Wood @ 2008-03-18 16:11 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20080318155814.GA5223@localhost.localdomain>
On Tue, Mar 18, 2008 at 06:58:14PM +0300, Anton Vorontsov wrote:
> Oops, forgot the NULL checking.
[snip]
> + if (priv->mtd.name)
> + kfree(priv->mtd.name);
> +
Not needed; kfree(NULL) is a no-op.
-Scott
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Vitaly Bordug @ 2008-03-18 16:19 UTC (permalink / raw)
To: hs; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <47DF777E.2030103@denx.de>
On Tue, 18 Mar 2008 09:04:14 +0100
Heiko Schocher wrote:
> Hello Stephen,
>
> Stephen Rothwell wrote:
> > On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher <hs@denx.de>
> > wrote:
> >> Stephen Rothwell wrote:
> >>> On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <hs@denx.de>
> >>> wrote:
> >> [...]
> >>>> +struct cpm_pin {
> >>>> + int port, pin, flags;
> >>>> +};
> >>> I wish someone would consolidate all these definitions of cpm_pin.
> >> Hmm... do you mean something like, moving this struct
> >> in cpm1.h and ...
> >
> > Yes or somewhere else appropriate.
> >
> >>>> + for (i = 0; i < ARRAY_SIZE(mgsuvd_pins); i++) {
> >>>> + struct cpm_pin *pin = &mgsuvd_pins[i];
> >>>> + cpm1_set_pin(pin->port, pin->pin, pin->flags);
> >>>> + }
> >>> And the code that uses them ...
> >> making in arch/powerpc/sysdev/cpm1.c a function
> >> cpm1_setup_pins (struct cpm_pin *pins) ?
> >
> > Yes.
> >
> > This is not necessary for your patch, but would be a nice cleanup
> > later. N.B. this struct is alos used by users of cpm2_set_pin().
>
> OK. Another thought about this. Shouldnt this table go in the dts?
> A device node like
>
> cpm_pin {
> pins = <port pin flags>;
> };
>
> would be nice, or?
>
This has been a disputable question some time ago, and decided (or it looks like decided) that devtree describes hardware, and not the way it is configured at the moment. Therefor, best way for pin stuff is considered, as Scott mentioned, to set up stuff inside the firmware.
-Vitaly
> bye,
> Heiko
>
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Wolfgang Denk @ 2008-03-18 16:19 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, Heiko Schocher, linuxppc-dev
In-Reply-To: <20080318151132.GA17402@ld0162-tx32.am.freescale.net>
Dear Scott,
in message <20080318151132.GA17402@ld0162-tx32.am.freescale.net> you wrote:
>
> Well, the device tree is a mechanism for communicating from the firmware
> to the kernel, and if we could control the firmware better we'd just make
> it set the pins properly to begin with. :-)
Is this just a comment, or do you oppose Heiko's suggestion?
Other uses of the device tree seem possible and reasonable, too. For
example, we can use the device tree to configure the firmware (U-Boot
in this case).
Using the device tree to describe the pin configuration of the
hardware sounds easier to me than hard-coding it in some source (or
header) file - no matter if this is in the kernel and/or in the
firmware.
What do you think?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A quarrel is quickly settled when deserted by one party; there is no
battle unless there be two. - Seneca
^ permalink raw reply
* Re: simple MPC5200B system
From: Grant Likely @ 2008-03-18 16:21 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <47DFDC5B.90304@matrix-vision.de>
On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
<andre.schwarz@matrix-vision.de> wrote:
> I've read some discussions about the "interrupt-map" attribute of the pci
> node. I tried to follow Ben and David in their explanations - obviously I
> didn't really get it.
> Looks like there are a lot of people outside who need some enlightenment
> ... including me, of course.
>
> Maybe you can clarify this ?
>
> Taken from motionpro.dts ...
>
First, you also need to look at interrupt-map-mask to interpret these
values; from motionpro.dts:
interrupt-map-mask = <f800 0 0 7>;
which is applied to the unit interrupt specifier to figure out how to
map onto the interrupt controller. The /size/ of this field is
obtained by adding #address-cells with #interrupt-cells. (3+1=4).
'f8' refers to the upper 5 bits of the interrupt identifier which is a
number from 0-31 which relates to the IDSEL line as you guessed. The
'7' covers the lower 3 bits of the interrupt specifier which can be 1,
2, 3 or 4.
The 120 bits in the middle are irrelevant, so interrupt-map-mask
leaves them as zeros.
> interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
> c000 0 0 2 &mpc5200_pic 1 1 3
> c000 0 0 3 &mpc5200_pic 1 2 3
> c000 0 0 4 &mpc5200_pic 1 3 3
>
> c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
> c800 0 0 2 &mpc5200_pic 1 2 3
> c800 0 0 3 &mpc5200_pic 1 3 3
> c800 0 0 4 &mpc5200_pic 0 0 3>;
>
>
> First parameter seems to be the slot number, i.e. IDSEL line of the PCI
> device.
> How is this value coded ? Are these the bits 15..11 of the configuration
> address ?
I don't remember how this is encoded. On the lite5200, idsel is wired
to d0 and d1 for slots 1 and 2 respectively, yet these values suggest
slots 24 and 25. I'll need to look at this again later.
>
> 2nd + 3rd paramter : no clue ! can you explain ?
first 3 cells are the unit address and is #address-cells large. Only
the first cell contains real data.
>
> 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
> INT_A. Do we need 4 entries in any case ?
you only need entries for irq lines that are wired up. If your board
does not wire up _B, _C and _D, then don't have an entry for them.
However, if they are wired up then you should describe them.
>
> 5th : ok - parent pic
Correct.
>
> 6th ... 8th : IRQ representation of the parent pic, which gives :
>
> 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
> 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
> number 1..3 inside MAIN level.
> 8th : should be 3 = "level low" which is default for PCI.
Correct.
There is also some good information here:
http://playground.sun.com/1275/practice/imap/imap0_9d.pdf
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Add Fixed PHY support for ucc_geth
From: Vitaly Bordug @ 2008-03-18 16:32 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Tjernlund, Joakim, Netdev, linuxppc-dev@ozlabs.org,
Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <1205833615-15833-1-git-send-email-Joakim.Tjernlund@transmode.se>
On Tue, 18 Mar 2008 10:46:55 +0100
Joakim Tjernlund wrote:
> The new Fixed PHY method, fixed-link property, isn't
> impl. for ucc_geth which makes fixed PHYs non functional.
> Add support for the new method to restore the Fixed PHY
> functionality.
>
Makes sense to me, but let's cc linuxppc-devel
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
>
> This is a regression as fixed PHYs works in 2.6.23 and I am
> using it.
>
> drivers/net/ucc_geth.c | 53
> +++++++++++++++++++++++++++-------------------- 1 files changed, 30
> insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index ecc5712..18c8b39 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3836,6 +3836,7 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma struct device_node *phy;
> int err, ucc_num, max_speed = 0;
> const phandle *ph;
> + const u32 *fixed_link;
> const unsigned int *prop;
> const char *sprop;
> const void *mac_addr;
> @@ -3926,18 +3927,38 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma
> ug_info->uf_info.regs = res.start;
> ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
> + fixed_link = of_get_property(np, "fixed-link", NULL);
> + if (fixed_link) {
> + ug_info->mdio_bus = 0;
> + ug_info->phy_address = fixed_link[0];
> + phy = NULL;
> + } else {
> + ph = of_get_property(np, "phy-handle", NULL);
> + phy = of_find_node_by_phandle(*ph);
>
> - ph = of_get_property(np, "phy-handle", NULL);
> - phy = of_find_node_by_phandle(*ph);
> + if (phy == NULL)
> + return -ENODEV;
>
> - if (phy == NULL)
> - return -ENODEV;
> + /* set the PHY address */
> + prop = of_get_property(phy, "reg", NULL);
> + if (prop == NULL)
> + return -1;
> + ug_info->phy_address = *prop;
> +
> + /* Set the bus id */
> + mdio = of_get_parent(phy);
> +
> + if (mdio == NULL)
> + return -1;
>
> - /* set the PHY address */
> - prop = of_get_property(phy, "reg", NULL);
> - if (prop == NULL)
> - return -1;
> - ug_info->phy_address = *prop;
> + err = of_address_to_resource(mdio, 0, &res);
> + of_node_put(mdio);
> +
> + if (err)
> + return -1;
> +
> + ug_info->mdio_bus = res.start;
> + }
>
> /* get the phy interface type, or default to MII */
> prop = of_get_property(np, "phy-connection-type", NULL);
> @@ -3982,20 +4003,6 @@ static int ucc_geth_probe(struct of_device*
> ofdev, const struct of_device_id *ma ug_info->numThreadsRx =
> UCC_GETH_NUM_OF_THREADS_4; }
>
> - /* Set the bus id */
> - mdio = of_get_parent(phy);
> -
> - if (mdio == NULL)
> - return -1;
> -
> - err = of_address_to_resource(mdio, 0, &res);
> - of_node_put(mdio);
> -
> - if (err)
> - return -1;
> -
> - ug_info->mdio_bus = res.start;
> -
> if (netif_msg_probe(&debug))
> printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq =
> %d) \n", ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
^ permalink raw reply
* [PATCH v3] fsl_elbc_nand: fix mtd name
From: Anton Vorontsov @ 2008-03-18 16:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20080318161139.GD17944@ld0162-tx32.am.freescale.net>
Currently fsl_elbc_nand doesn't initialize mtd->name, and this causes
nand_get_flash_type() to assign name that is equal to chip type, like
this:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "NAND 32MiB 3,3V 8-bit"
mtd0 is physmap_of flash (normal name), and mtd1 is fsl_elbc_nand.
Despite inconsistency, with mtd name like this specifying paritions
from the kernel command line becomes a torture (though, I didn't tried
and not sure if mtdparts= can handle spaces at all). Plus, this causes
real bugs when multiple fsl_elbc_nand chips registered.
With this patch applied fsl_elbc_nand chip will have proper name:
root@b1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "fe000000.flash"
mtd1: 02000000 00004000 "e0600000.flash"
p.s. We can't use priv->dev->bus_id as in physmap_of, because
fsl_elbc_nand pretends to be a localbus controller, so its bus_id is
"address.localbus", which is incorrect and thus will also not work
for multiple chips.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Tue, Mar 18, 2008 at 11:11:39AM -0500, Scott Wood wrote:
> On Tue, Mar 18, 2008 at 06:58:14PM +0300, Anton Vorontsov wrote:
> > Oops, forgot the NULL checking.
> [snip]
> > + if (priv->mtd.name)
> > + kfree(priv->mtd.name);
> > +
>
> Not needed; kfree(NULL) is a no-op.
D'oh, right. Also, we should fill the name prior to nand_scan_ident,
otherwise if error happened between nand_scan_ident and kasprintf
then we'll kfree chip's type name.
drivers/mtd/nand/fsl_elbc_nand.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index b025dfe..9c86d9b 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -974,6 +974,8 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
nand_release(&priv->mtd);
+ kfree(priv->mtd.name);
+
if (priv->vbase)
iounmap(priv->vbase);
@@ -1034,6 +1036,12 @@ static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
goto err;
}
+ priv->mtd.name = kasprintf(GFP_KERNEL, "%x.flash", res.start);
+ if (!priv->mtd.name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
ret = fsl_elbc_chip_init(priv);
if (ret)
goto err;
--
1.5.2.2
^ permalink raw reply related
* Re: Please pull linux-2.6-mpc52xx.git
From: Richard Purdie @ 2008-03-18 16:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803180747u532f6a0bq1e64e01662bdb6bd@mail.gmail.com>
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> > Grant,
> >
> > Yes, the Motion-PRO LED driver has been reworked and posted:
> > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
> Okay, I've taken another look at the driver and I've figured out what
> has been bothering me about it. It seems to me that the motion pro
> led driver is just the first of many that we will see (seeing as some
> many people find the blinking lights rather soothing) and it's a non
> trivial amount of code.
>
> (Note: I'm not actually opposed to this driver if Richard is okay with
> it; but I do think that in the long term we should move towards a more
> generic approach)
>
> In essence, this driver sets up two GPIO pins to drive LEDs. A pretty
> common approach for putting LEDs on a board. In this case each GPIO
> bank only contains 1 pin; but I imagine that on other boards there
> will be multiple pins in a GPIO bank, only some of which actually used
> for blinking LEDs.
>
> I've started thinking that it would be better to split things up in
> the device tree to have one node for each GPIO block and a single LED
> node that maps LEDs to gpio pins. That would allow a common driver to
> be written for all GPIO driven LEDs with a single block of device tree
> parsing code. Plus, it allows other devices to use GPIO pins within
> the same block (not an issue for the motion pro board; but when other
> boards start coming on-line it would allow us to reduce the amount of
> board specific code). Finally, it means that the timer pin GPIO
> driver can be used for more than just flashing an attached LED.
I don't mind having a specific driver but I don't know anything about
the hardware its creating the interface for so I need the community's
help with that part. There is drivers/leds/leds-gpio.c if that would
work better.
Regards,
Richard
^ 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