Re: Combining defconfigs for 44x based boards
Dear Tirumala Marri, In message 49073d172310031addb3aa7d08a60...@mail.gmail.com you wrote: I am thinking that we can combine arches, Canyonlands, glacier, redwood and eiger can be combined as ppc46x_defconfig. We already have arch/powerpc/configs/ppc40x_defconfig and arch/powerpc/configs/ppc44x_defconfig in mainline. What's wrong with using these? 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: w...@denx.de CONSUMER NOTICE: Because of the Uncertainty Principle, It Is Impossible for the Consumer to Find Out at the Same Time Both Precisely Where This Product Is and How Fast It Is Moving. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
On Thu, Sep 09, 2010 at 03:28:34AM +0100, Chris Ball wrote: [...] [7.372843] [b04193ce] __might_sleep+0xd9/0xe0 [7.387864] [b07260cc] mutex_lock+0x1c/0x2a [7.402576] [b06396e8] sdhci_led_control+0x1a/0x41 [7.417727] [b063bece] led_trigger_event+0x42/0x5c led_trigger_even grabs a readlock. :-( [7.432807] [b06326f8] mmc_request_done+0x56/0x6f [7.447597] [b063a2d1] sdhci_finish_work+0xc8/0xcd [7.462643] [b063a209] ? sdhci_finish_work+0x0/0xcd [7.477941] [b0432776] worker_thread+0x165/0x1ed [7.492856] [b063a209] ? sdhci_finish_work+0x0/0xcd [7.508204] [b0435591] ? autoremove_wake_function+0x0/0x34 [7.524178] [b0432611] ? worker_thread+0x0/0x1ed [7.538953] [b04352a0] kthread+0x63/0x68 [7.552659] [b043523d] ? kthread+0x0/0x68 [7.566349] [b0402cf6] kernel_thread_helper+0x6/0x10 [7.709931] udev: starting version 141 [7.940374] mmc2: new high speed SDHC card at address e4da [8.058165] mmcblk0: mmc2:e4da SU04G 3.69 GiB [8.135730] mmcblk0: p1 p2 Full dmesg is at http://chris.printf.net/anton-mutex-dmesg.txt. Anton, the kernel is 2.6.35.4-olpc plus your patchset from -mm. I can think about how to test on an upstream kernel instead, but perhaps your own tests simply didn't hit sdhci_led_control(). Yep, LEDS support was turned off. Andrew, if you want to drop this while the BUG() and potential performance regressions are worked out, I'd be happy to keep testing patches from Anton until it's without regressions here. Thanks Chris. I also think that it's better to drop these series now, and meanwhile I'll try to prepare another patchset. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/dts: add interrupt parent for lbc node for p4080
Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- arch/powerpc/boot/dts/p4080ds.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts index 2f0de24..0a18138 100644 --- a/arch/powerpc/boot/dts/p4080ds.dts +++ b/arch/powerpc/boot/dts/p4080ds.dts @@ -431,6 +431,7 @@ compatible = fsl,p4080-elbc, fsl,elbc, simple-bus; reg = 0xf 0xfe124000 0 0x1000; interrupts = 25 2; + interrupt-parent = mpic; #address-cells = 2; #size-cells = 1; -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_request_regions() failure
Ravi Gupta wrote:
Hi Tiejun,
Thanks for the reply.
Your PCI device should be one virtual device so I think the above should be
as
we understood. You know 0x ~ 0x3 should not be allowed to
reserved.
Can you explain a little more that what do you mean by Your PCI device
should be one virtual device?
I means your PCI example from LDD3. That is only emulated for configure space.
No BARs, no irq, ..
I think you should do the following sequence in the probe function of your
PCI
driver.
1. pci_enable_device(pdev);
2. pci_request_regions(pdev, DRV_NAME);
3. pci_set_master(pdev);
..
Okay, I have changed my drive code to follow this sequence, but still no
success. It fails with the same errors as before.
I means you do this on your real PCI device driver. When you fix my comments in
below, try to update this on your PCI device e250 again.
# insmod ./pci_skel.ko
PCI driver: Init function
PCI driver: Probe function
pci_skel 0001:02:00.0: device not available (can't reserve [mem
0x-0x0003])
Unable to Enable PCI device:-22
pci_skel: probe of 0001:02:00.0 failed with error -22
Looks we need some pci_fixup to modify them. Firstly I think you'd better
'zero'
all BARs of your PCI device on the function, pci_scan_device, on the file,
drivers/pci/probe.c. On there you can dedicate that once your device is
probed.
Please check the each BAR's value again after the above fix.
Okay, I have set the BARs with all zeros in the pci_scan_device() function.
Below is the diff of the changes done by me.
--- /data/sources/linux-2.6.35/drivers/pci/probe.c 2010-08-02
03:41:14.0 +0530
+++ probe.c 2010-09-08 14:45:40.0 +0530
@@ -1172,6 +1172,45 @@ static struct pci_dev *pci_scan_device(s
}
}
+ printk(KERN_WARNING pci : vendor id = 0x%x\n, l 0x);
+ if ((l 0x) == 0x1204) {
+ /* zero's all BAR registers */
+ printk(KERN_WARNING pci %04x:%02x:%02x.%d: trying to set all zeros in
+ BARs\n, pci_domain_nr(bus),
+ bus-number, PCI_SLOT(devfn),
+ PCI_FUNC(devfn));
+
+ if(pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_0, 0x0) ||
+ pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_1, 0x0) ||
+ pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_2, 0x0) ||
+ pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_3, 0x0) ||
+ pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_4, 0x0) ||
+ pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_5, 0x0)) {
+
+ printk(KERN_WARNING pci %04x:%02x:%02x.%d: failed to reset bits
+ of BARs\n, pci_domain_nr(bus),
+ bus-number, PCI_SLOT(devfn),
+ PCI_FUNC(devfn));
+ return NULL;
+ }
+ }
+
dev = alloc_pci_dev();
if (!dev)
return NULL;
The difference I have seen in the dmesg is that the following two messages
are not coming now.
PCI: Cannot allocate resource region 0 of device 0001:02:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0001:02:00.0, will remap
Good.
But my driver is still fails with the same error as before. I am attaching
the new dmesg log.
Dmesg with all BARs set to zero
Using MPC837x RDB/WLAN machine description
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.35 (ok...@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
4.2-171)) #28 Wed Sep 8 13:20:27 IST 2010
Found initrd at 0xcf46c000:0xcf7b05b7
Found legacy serial port 0 for /i...@e000/ser...@4500
mem=e0004500, taddr=e0004500, irq=0, clk=40002, speed=0
Found legacy serial port 1 for /i...@e000/ser...@4600
mem=e0004600, taddr=e0004600, irq=0, clk=40002, speed=0
bootconsole [udbg0] enabled
Found FSL PCI host bridge at 0xe0008500. Firmware bus number: 0-0
PCI host bridge /p...@e0008500 (primary) ranges:
MEM 0x9000..0x9fff - 0x9000
MEM 0x8000..0x8fff - 0x8000 Prefetch
IO 0xe030..0xe03f - 0x
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0xe0009000. Firmware bus number: 0-255
PCI host bridge /p...@e0009000 ranges:
MEM 0xa800..0xb7ff - 0xa800
IO 0xb800..0xb87f - 0x
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0xe000a000. Firmware bus number: 0-255
PCI host bridge /p...@e000a000 ranges:
MEM 0xc800..0xd7ff - 0xc800
IO 0xd800..0xd87f - 0x
Top of RAM: 0x1000, Total RAM: 0x1000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x - 0x0001
Normal empty
HighMem empty
Movable zone start PFN for each node
[PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Lan Chunhe-B25806 b25...@freescale.com
Move Freescale elbc interrupt from nand dirver to elbc driver.
Then all elbc devices can use the interrupt instead of ONLY nand.
Signed-off-by: Lan Chunhe-B25806 b25...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
Comparing with v1, according to the feedback, add some decorations.
arch/powerpc/Kconfig |7 +-
arch/powerpc/include/asm/fsl_lbc.h | 34 +-
arch/powerpc/sysdev/fsl_lbc.c | 248 ++--
3 files changed, 247 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 631e5a0..44df1ba 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -687,9 +687,12 @@ config 4xx_SOC
bool
config FSL_LBC
- bool
+ bool Freescale Local Bus support
+ depends on FSL_SOC
help
- Freescale Localbus support
+ Enables reporting of errors from the Freescale local bus
+ controller. Also contains some common code used by
+ drivers for specific local bus peripherals.
config FSL_GTM
bool
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 1b5a210..9b95eab 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -1,9 +1,10 @@
/* Freescale Local Bus Controller
*
- * Copyright (c) 2006-2007 Freescale Semiconductor
+ * Copyright (c) 2006-2007, 2010 Freescale Semiconductor
*
* Authors: Nick Spence nick.spe...@freescale.com,
* Scott Wood scottw...@freescale.com
+ * Jack Lan jack@freescale.com
*
* 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
@@ -27,6 +28,9 @@
#include linux/types.h
#include linux/io.h
+#include linux/of_platform.h
+#include linux/interrupt.h
+
struct fsl_lbc_bank {
__be32 br; /** Base Register */
#define BR_BA 0x8000
@@ -125,13 +129,23 @@ struct fsl_lbc_regs {
#define LTESR_ATMW 0x0080
#define LTESR_ATMR 0x0040
#define LTESR_CS 0x0008
+#define LTESR_UPM 0x0002
#define LTESR_CC 0x0001
#define LTESR_NAND_MASK (LTESR_FCT | LTESR_PAR | LTESR_CC)
+#define LTESR_MASK (LTESR_BM | LTESR_FCT | LTESR_PAR | LTESR_WP \
+| LTESR_ATMW | LTESR_ATMR | LTESR_CS | LTESR_UPM \
+| LTESR_CC)
+#define LTESR_CLEAR0x
+#define LTECCR_CLEAR 0x
+#define LTESR_STATUS LTESR_MASK
+#define LTEIR_ENABLE LTESR_MASK
+#define LTEDR_ENABLE 0x
__be32 ltedr; /** Transfer Error Disable Register */
__be32 lteir; /** Transfer Error Interrupt Register */
__be32 lteatr; /** Transfer Error Attributes Register */
__be32 ltear; /** Transfer Error Address Register */
- u8 res6[0xC];
+ __be32 lteccr; /** Transfer Error ECC Register */
+ u8 res6[0x8];
__be32 lbcr;/** Configuration Register */
#define LBCR_LDIS 0x8000
#define LBCR_LDIS_SHIFT31
@@ -265,7 +279,23 @@ static inline void fsl_upm_end_pattern(struct fsl_upm *upm)
cpu_relax();
}
+/* overview of the fsl lbc controller */
+
+struct fsl_lbc_ctrl {
+ /* device info */
+ struct device *dev;
+ struct fsl_lbc_regs __iomem *regs;
+ int irq;
+ wait_queue_head_t irq_wait;
+ spinlock_t lock;
+ void*nand;
+
+ /* status read from LTESR by irq handler */
+ unsigned intirq_status;
+};
+
extern int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base,
u32 mar);
+extern struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
#endif /* __ASM_FSL_LBC_H */
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index dceb8d1..f4eca8d 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -2,8 +2,11 @@
* Freescale LBC and UPM routines.
*
* Copyright (c) 2007-2008 MontaVista Software, Inc.
+ * Copyright (c) 2010 Freescale Semiconductor
*
* Author: Anton Vorontsov avoront...@ru.mvista.com
+ * Author: Jack Lan jack@freescale.com
+ * Author: Roy Zang tie-fei.z...@freescale.com
*
* 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
@@ -21,37 +24,11 @@
#include linux/of.h
#include asm/prom.h
#include asm/fsl_lbc.h
+#include linux/slab.h
static spinlock_t fsl_lbc_lock = __SPIN_LOCK_UNLOCKED(fsl_lbc_lock);
-static struct fsl_lbc_regs __iomem *fsl_lbc_regs;
-
-static char __initdata *compat_lbc[] = {
- fsl,pq2-localbus,
- fsl,pq2pro-localbus,
- fsl,pq3-localbus,
- fsl,elbc,
-};
-
[PATCH 2/3 v2][MTD] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Jack Lan jack@freescale.com
The former driver had the two functions:
1. detecting nand flash partitions;
2. registering elbc interrupt.
Now, second function is removed to fsl_lbc.c.
Signed-off-by: Lan Chunhe-B25806 b25...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
Comparing with v1, according to the feedback, remove global variables.
drivers/mtd/nand/Kconfig |1 +
drivers/mtd/nand/fsl_elbc_nand.c | 476 +++---
2 files changed, 183 insertions(+), 294 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8b4b67c..4132c46 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -458,6 +458,7 @@ config MTD_NAND_ORION
config MTD_NAND_FSL_ELBC
tristate NAND support for Freescale eLBC controllers
depends on PPC_OF
+ select FSL_LBC
help
Various Freescale chips, including the 8313, include a NAND Flash
Controller Module with built-in hardware ECC capabilities.
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 80de0bf..64c840f 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -1,9 +1,10 @@
/* Freescale Enhanced Local Bus Controller NAND driver
*
- * Copyright (c) 2006-2007 Freescale Semiconductor
+ * Copyright (c) 2006-2007, 2010 Freescale Semiconductor
*
* Authors: Nick Spence nick.spe...@freescale.com,
* Scott Wood scottw...@freescale.com
+ * Jack Lan jack@freescale.com
*
* 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
@@ -24,32 +25,22 @@
#include linux/types.h
#include linux/init.h
#include linux/kernel.h
-#include linux/string.h
-#include linux/ioport.h
-#include linux/of_platform.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include linux/mtd/mtd.h
#include linux/mtd/nand.h
-#include linux/mtd/nand_ecc.h
#include linux/mtd/partitions.h
-
-#include asm/io.h
#include asm/fsl_lbc.h
+#include linux/slab.h
#define MAX_BANKS 8
#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */
#define FCM_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait for FCM */
-struct fsl_elbc_ctrl;
-
/* mtd information per set */
struct fsl_elbc_mtd {
struct mtd_info mtd;
struct nand_chip chip;
- struct fsl_elbc_ctrl *ctrl;
+ struct fsl_lbc_ctrl *ctrl;
struct device *dev;
int bank; /* Chip select bank number */
@@ -58,18 +49,12 @@ struct fsl_elbc_mtd {
unsigned int fmr; /* FCM Flash Mode Register value */
};
-/* overview of the fsl elbc controller */
+/* Freescale eLBC FCM controller infomation */
-struct fsl_elbc_ctrl {
+struct fsl_elbc_fcm_ctrl {
struct nand_hw_control controller;
struct fsl_elbc_mtd *chips[MAX_BANKS];
- /* device info */
- struct device *dev;
- struct fsl_lbc_regs __iomem *regs;
- int irq;
- wait_queue_head_t irq_wait;
- unsigned int irq_status; /* status read from LTESR by irq handler */
u8 __iomem *addr;/* Address of assigned FCM buffer*/
unsigned int page; /* Last page written to / read from */
unsigned int read_bytes; /* Number of bytes read during command */
@@ -164,11 +149,12 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
{
struct nand_chip *chip = mtd-priv;
struct fsl_elbc_mtd *priv = chip-priv;
- struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+ struct fsl_lbc_ctrl *ctrl = priv-ctrl;
struct fsl_lbc_regs __iomem *lbc = ctrl-regs;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl-nand;
int buf_num;
- ctrl-page = page_addr;
+ elbc_fcm_ctrl-page = page_addr;
out_be32(lbc-fbar,
page_addr (chip-phys_erase_shift - chip-page_shift));
@@ -185,16 +171,18 @@ static void set_addr(struct mtd_info *mtd, int column,
int page_addr, int oob)
buf_num = page_addr 7;
}
- ctrl-addr = priv-vbase + buf_num * 1024;
- ctrl-index = column;
+ elbc_fcm_ctrl-addr = priv-vbase + buf_num * 1024;
+ elbc_fcm_ctrl-index = column;
/* for OOB data point to the second half of the buffer */
if (oob)
- ctrl-index += priv-page_size ? 2048 : 512;
+ elbc_fcm_ctrl-index += priv-page_size ? 2048 : 512;
- dev_vdbg(ctrl-dev, set_addr: bank=%d, ctrl-addr=0x%p (0x%p),
+ dev_vdbg(priv-dev, set_addr: bank=%d,
+ elbc_fcm_ctrl-addr=0x%p (0x%p),
index %x, pes %d ps %d\n,
-buf_num, ctrl-addr, priv-vbase, ctrl-index,
+buf_num, elbc_fcm_ctrl-addr, priv-vbase,
+elbc_fcm_ctrl-index,
[PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
From: Lan Chunhe-B25806 b25...@freescale.com
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
Signed-off-by: Lan Chunhe-B25806 b25...@freescale.com
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
Comparing with v1, according to the feedback, add some decorations.
arch/powerpc/include/asm/fsl_lbc.h |1 +
arch/powerpc/sysdev/fsl_lbc.c | 26 +-
drivers/mtd/nand/fsl_elbc_nand.c |2 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h
b/arch/powerpc/include/asm/fsl_lbc.h
index 9b95eab..bff85c8 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -249,6 +249,7 @@ struct fsl_upm {
int width;
};
+extern unsigned int fsl_lbc_addr(phys_addr_t addr_base);
extern int fsl_lbc_find(phys_addr_t addr_base);
extern int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm *upm);
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index f4eca8d..3a09e90 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -31,6 +31,30 @@ struct fsl_lbc_ctrl *fsl_lbc_ctrl_dev;
EXPORT_SYMBOL(fsl_lbc_ctrl_dev);
/**
+ * fsl_lbc_addr - convert the base address
+ * @addr_base: base address of the memory bank
+ *
+ * This function converts a base address of lbc into the right format for the
BR
+ * registers. If the SOC has eLBC then it returns 32bit physical address else
+ * it returns 34bit physical address for local bus(Example: MPC8641).
+ */
+unsigned int fsl_lbc_addr(phys_addr_t addr_base)
+{
+ void *dev;
+ int compatible;
+
+ dev = fsl_lbc_ctrl_dev-dev-of_node;
+ compatible = of_device_is_compatible(dev, fsl,elbc);
+
+ if (compatible)
+ return addr_base 0x8000;
+ else
+ return (addr_base 0x08000ull)
+ | ((addr_base 0x3ull) 19);
+}
+EXPORT_SYMBOL(fsl_lbc_addr);
+
+/**
* fsl_lbc_find - find Localbus bank
* @addr_base: base address of the memory bank
*
@@ -52,7 +76,7 @@ int fsl_lbc_find(phys_addr_t addr_base)
__be32 br = in_be32(lbc-bank[i].br);
__be32 or = in_be32(lbc-bank[i].or);
- if (br BR_V (br or BR_BA) == addr_base)
+ if (br BR_V (br or BR_BA) == fsl_lbc_addr(addr_base))
return i;
}
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 64c840f..6dec268 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -851,7 +851,7 @@ static int __devinit fsl_elbc_nand_probe(struct
platform_device *dev,
(in_be32(lbc-bank[bank].br) BR_MSEL) == BR_MS_FCM
(in_be32(lbc-bank[bank].br)
in_be32(lbc-bank[bank].or) BR_BA)
-== res.start)
+== fsl_lbc_addr(res.start))
break;
if (bank = MAX_BANKS) {
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
On Thu, Sep 9, 2010 at 12:20, Roy Zang tie-fei.z...@freescale.com wrote:
From: Lan Chunhe-B25806 b25...@freescale.com
When system uses 36bit physical address, res.start is 36bit
physical address. But the function of in_be32 returns 32bit
physical address. Then both of them compared each other is
wrong. So by converting the address of res.start into
the right format fixes this issue.
/**
+ * fsl_lbc_addr - convert the base address
+ * @addr_base: base address of the memory bank
+ *
+ * This function converts a base address of lbc into the right format for
the BR
+ * registers. If the SOC has eLBC then it returns 32bit physical address else
+ * it returns 34bit physical address for local bus(Example: MPC8641).
+ */
+unsigned int fsl_lbc_addr(phys_addr_t addr_base)
Shouldn't this be u32 or __be32, for consistency with the actual
comparisons below?
@@ -52,7 +76,7 @@ int fsl_lbc_find(phys_addr_t addr_base)
__be32 br = in_be32(lbc-bank[i].br);
__be32 or = in_be32(lbc-bank[i].or);
- if (br BR_V (br or BR_BA) == addr_base)
+ if (br BR_V (br or BR_BA) == fsl_lbc_addr(addr_base))
return i;
@@ -851,7 +851,7 @@ static int __devinit fsl_elbc_nand_probe(struct
platform_device *dev,
(in_be32(lbc-bank[bank].br) BR_MSEL) == BR_MS_FCM
(in_be32(lbc-bank[bank].br)
in_be32(lbc-bank[bank].or) BR_BA)
- == res.start)
+ == fsl_lbc_addr(res.start))
break;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3 v2][MTD] P4080/mtd: Only make elbc nand driver detect nand flash partitions
On Thu, Sep 09, 2010 at 06:20:31PM +0800, Roy Zang wrote:
[...]
#include linux/types.h
#include linux/init.h
#include linux/kernel.h
-#include linux/string.h
-#include linux/ioport.h
-#include linux/of_platform.h
-#include linux/slab.h
-#include linux/interrupt.h
-#include linux/mtd/mtd.h
#include linux/mtd/nand.h
-#include linux/mtd/nand_ecc.h
#include linux/mtd/partitions.h
-
-#include asm/io.h
#include asm/fsl_lbc.h
+#include linux/slab.h
Why move slab.h?
[...]
for (i = 0; i len; i++)
- if (in_8(ctrl-addr[ctrl-index + i]) != buf[i])
+ if (in_8(elbc_fcm_ctrl-addr[elbc_fcm_ctrl-index + i])
+ != buf[i])
break;
- ctrl-index += len;
- return i == len ctrl-status == LTESR_CC ? 0 : -EIO;
+ elbc_fcm_ctrl-index += len;
+ return i == len elbc_fcm_ctrl-status == LTESR_CC ? 0 : -EIO;
}
/* This function is called after Program and Erase Operations to
@@ -635,22 +625,21 @@ static int fsl_elbc_verify_buf(struct mtd_info *mtd,
const u_char *buf, int len)
static int fsl_elbc_wait(struct mtd_info *mtd, struct nand_chip *chip)
{
struct fsl_elbc_mtd *priv = chip-priv;
- struct fsl_elbc_ctrl *ctrl = priv-ctrl;
-
Please keep the empty line between variables declaration and the code.
- if (ctrl-status != LTESR_CC)
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv-ctrl-nand;
+ if (elbc_fcm_ctrl-status != LTESR_CC)
return NAND_STATUS_FAIL;
[...]
@@ -750,18 +739,18 @@ static void fsl_elbc_write_page(struct mtd_info *mtd,
const uint8_t *buf)
{
struct fsl_elbc_mtd *priv = chip-priv;
- struct fsl_elbc_ctrl *ctrl = priv-ctrl;
-
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv-ctrl-nand;
Ditto.
fsl_elbc_write_buf(mtd, buf, mtd-writesize);
fsl_elbc_write_buf(mtd, chip-oob_poi, mtd-oobsize);
- ctrl-oob_poi = chip-oob_poi;
+ elbc_fcm_ctrl-oob_poi = chip-oob_poi;
}
[...]
-static int __devinit fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl,
- struct device_node *node)
+static int __devinit fsl_elbc_nand_probe(struct platform_device *dev,
+ const struct of_device_id *match)
{
- struct fsl_lbc_regs __iomem *lbc = ctrl-regs;
+ struct fsl_lbc_regs __iomem *lbc;
struct fsl_elbc_mtd *priv;
struct resource res;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
(***1)
#ifdef CONFIG_MTD_PARTITIONS
static const char *part_probe_types[]
= { cmdlinepart, RedBoot, NULL };
@@ -843,11 +832,16 @@ static int __devinit fsl_elbc_chip_probe(struct
fsl_elbc_ctrl *ctrl,
#endif
int ret;
int bank;
+ struct device_node *node = dev-dev.of_node;
+
+ if (!fsl_lbc_ctrl_dev || !fsl_lbc_ctrl_dev-regs)
+ return -ENODEV;
+ lbc = fsl_lbc_ctrl_dev-regs;
/* get, allocate and map the memory resource */
ret = of_address_to_resource(node, 0, res);
if (ret) {
- dev_err(ctrl-dev, failed to get resource\n);
+ dev_err(fsl_lbc_ctrl_dev-dev, failed to get resource\n);
return ret;
}
@@ -861,7 +855,8 @@ static int __devinit fsl_elbc_chip_probe(struct
fsl_elbc_ctrl *ctrl,
break;
if (bank = MAX_BANKS) {
- dev_err(ctrl-dev, address did not match any chip selects\n);
+ dev_err(fsl_lbc_ctrl_dev-dev, address did not match any
+ chip selects\n);
return -ENODEV;
}
@@ -869,14 +864,28 @@ static int __devinit fsl_elbc_chip_probe(struct
fsl_elbc_ctrl *ctrl,
if (!priv)
return -ENOMEM;
- ctrl-chips[bank] = priv;
+ if (fsl_lbc_ctrl_dev-nand == NULL) {
+ elbc_fcm_ctrl = kzalloc(sizeof(*elbc_fcm_ctrl), GFP_KERNEL);
+ if (!elbc_fcm_ctrl)
+ return -ENOMEM;
'priv' leaked.
+
+ elbc_fcm_ctrl-read_bytes = 0;
+ elbc_fcm_ctrl-index = 0;
+ elbc_fcm_ctrl-addr = NULL;
+
+ spin_lock_init(elbc_fcm_ctrl-controller.lock);
+ init_waitqueue_head(elbc_fcm_ctrl-controller.wq);
+ fsl_lbc_ctrl_dev-nand = elbc_fcm_ctrl;
+ }
+
+ elbc_fcm_ctrl-chips[bank] = priv;
The driver will oops on the second probe.
You probably meant
struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = fsl_lbc_ctrl_dev-nand;
at (***1).
Also, nowadays the kernel may probe devices in parallel, which
means that you probably need a mutex for fsl_lbc_ctrl_dev-nand.
[...]
-static const struct of_device_id fsl_elbc_match[] = {
+static const struct of_device_id fsl_elbc_nand_match[] = {
linux/mod_devicetable.h is needed for this.
{
- .compatible = fsl,elbc,
+ .compatible = fsl,elbc-fcm-nand,
},
{}
Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
On Thu, Sep 09, 2010 at 06:20:32PM +0800, Roy Zang wrote:
[...]
/**
+ * fsl_lbc_addr - convert the base address
+ * @addr_base: base address of the memory bank
+ *
+ * This function converts a base address of lbc into the right format for
the BR
+ * registers. If the SOC has eLBC then it returns 32bit physical address else
+ * it returns 34bit physical address for local bus(Example: MPC8641).
+ */
It returns 34bit physical address encoded in a 32 bit word,
right? Because, IIRC, 'unsigned int' is always 32 bit.
Worth mentioning this fact.
+unsigned int fsl_lbc_addr(phys_addr_t addr_base)
+{
+ void *dev;
struct device_node *np;
+ int compatible;
+
+ dev = fsl_lbc_ctrl_dev-dev-of_node;
+ compatible = of_device_is_compatible(dev, fsl,elbc);
+
+ if (compatible)
+ return addr_base 0x8000;
+ else
+ return (addr_base 0x08000ull)
+ | ((addr_base 0x3ull) 19);
+}
+EXPORT_SYMBOL(fsl_lbc_addr);
Almost perfect. I'm not sure if 'unsigned int' is technically
correct return type for this function though. I guess it should
be u32.
Also, the function may be a bit more understandable and shorter:
u32 fsl_lbc_addr(phys_addr_t addr)
{
struct device_node *np = fsl_lbc_ctrl_dev-dev-of_node;
u32 addrl = addr 0x8000;
if (of_device_is_compatible(np, fsl,elbc))
return addrl;
return addrl | ((addr 0x3ull) 19);
}
EXPORT_SYMBOL(fsl_lbc_addr);
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
Just a few cosmetic nits for this patch...
On Thu, Sep 09, 2010 at 06:20:30PM +0800, Roy Zang wrote:
[...]
@@ -94,22 +73,26 @@ int fsl_upm_find(phys_addr_t addr_base, struct fsl_upm
*upm)
{
int bank;
__be32 br;
+ struct fsl_lbc_regs __iomem *lbc;
bank = fsl_lbc_find(addr_base);
if (bank 0)
return bank;
- br = in_be32(fsl_lbc_regs-bank[bank].br);
+ if (!fsl_lbc_ctrl_dev || !fsl_lbc_ctrl_dev-regs)
+ return -ENODEV;
I'd add an empty line here.
+ lbc = fsl_lbc_ctrl_dev-regs;
+ br = in_be32(lbc-bank[bank].br);
switch (br BR_MSEL) {
case BR_MS_UPMA:
- upm-mxmr = fsl_lbc_regs-mamr;
+ upm-mxmr = lbc-mamr;
break;
case BR_MS_UPMB:
- upm-mxmr = fsl_lbc_regs-mbmr;
+ upm-mxmr = lbc-mbmr;
break;
case BR_MS_UPMC:
- upm-mxmr = fsl_lbc_regs-mcmr;
+ upm-mxmr = lbc-mcmr;
break;
default:
return -EINVAL;
@@ -143,14 +126,18 @@ EXPORT_SYMBOL(fsl_upm_find);
* thus UPM pattern actually executed. Note that mar usage depends on the
* pre-programmed AMX bits in the UPM RAM.
*/
+
int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
{
int ret = 0;
unsigned long flags;
+ if (!fsl_lbc_ctrl_dev || !fsl_lbc_ctrl_dev-regs)
+ return -ENODEV;
+
spin_lock_irqsave(fsl_lbc_lock, flags);
- out_be32(fsl_lbc_regs-mar, mar);
+ out_be32(fsl_lbc_ctrl_dev-regs-mar, mar);
switch (upm-width) {
case 8:
@@ -172,3 +159,188 @@ int fsl_upm_run_pattern(struct fsl_upm *upm, void
__iomem *io_base, u32 mar)
return ret;
}
EXPORT_SYMBOL(fsl_upm_run_pattern);
+
+static int __devinit fsl_lbc_ctrl_init(struct fsl_lbc_ctrl *ctrl)
+{
+ struct fsl_lbc_regs __iomem *lbc = ctrl-regs;
+
+ /* clear event registers */
+ setbits32(lbc-ltesr, LTESR_CLEAR);
+ out_be32(lbc-lteatr, 0);
+ out_be32(lbc-ltear, 0);
+ out_be32(lbc-lteccr, LTECCR_CLEAR);
+ out_be32(lbc-ltedr, LTEDR_ENABLE);
+
+ /* Enable interrupts for any detected events */
+ out_be32(lbc-lteir, LTEIR_ENABLE);
+
+ return 0;
+}
+
+static int __devexit fsl_lbc_ctrl_remove(struct platform_device *ofdev)
+{
+ struct fsl_lbc_ctrl *ctrl = dev_get_drvdata(ofdev-dev);
+
+ if (ctrl-irq)
+ free_irq(ctrl-irq, ctrl);
+
+ if (ctrl-regs)
+ iounmap(ctrl-regs);
+
+ dev_set_drvdata(ofdev-dev, NULL);
+
+ kfree(ctrl);
+
+ return 0;
+}
+
+/*
+ * NOTE: This interrupt is used to report localbus events of various kinds,
+ * such as transaction errors on the chipselects.
+ */
+
+static irqreturn_t fsl_lbc_ctrl_irq(int irqno, void *data)
+{
+ struct fsl_lbc_ctrl *ctrl = data;
+ struct fsl_lbc_regs __iomem *lbc = ctrl-regs;
+ u32 status;
+
+ status = in_be32(lbc-ltesr);
+
+ if (status) {
You could save indentation and improve readability by writing
status = in_be32(lbc-ltesr);
if (!status)
return IRQ_NONE;
...the rest of the function...
I understand that you just move the code around though.
+ out_be32(lbc-ltesr, LTESR_CLEAR);
+ out_be32(lbc-lteatr, 0);
+ out_be32(lbc-ltear, 0);
+ ctrl-irq_status = status;
+
+ if (status LTESR_BM)
+ dev_err(ctrl-dev, Local bus monitor time-out:
+ LTESR 0x%08X\n, status);
+ if (status LTESR_WP)
+ dev_err(ctrl-dev, Write protect error:
+ LTESR 0x%08X\n, status);
+ if (status LTESR_ATMW)
+ dev_err(ctrl-dev, Atomic write error:
+ LTESR 0x%08X\n, status);
+ if (status LTESR_ATMR)
+ dev_err(ctrl-dev, Atomic read error:
+ LTESR 0x%08X\n, status);
+ if (status LTESR_CS)
+ dev_err(ctrl-dev, Chip select error:
+ LTESR 0x%08X\n, status);
+ if (status LTESR_UPM)
+ ;
+ if (status LTESR_FCT) {
+ dev_err(ctrl-dev, FCM command time-out:
+ LTESR 0x%08X\n, status);
+ smp_wmb();
+ wake_up(ctrl-irq_wait);
+ }
+ if (status LTESR_PAR) {
+ dev_err(ctrl-dev, Parity or Uncorrectable ECC error:
+ LTESR 0x%08X\n, status);
+ smp_wmb();
+ wake_up(ctrl-irq_wait);
+ }
+ if (status LTESR_CC) {
+ smp_wmb();
+ wake_up(ctrl-irq_wait);
+ }
+ if (status ~LTESR_MASK)
Re: pci_request_regions() failure
Hi Tiejun, Thanks for the reply. Omm. Often we always disable this pref windows so please disable this window. Try use the following ways to clear PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT. -- pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0); pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, 0); I have a little confusion about what you said. You said I should disable prefetched window corresponds to PCI Bridge to [bus 02-ff], the dmesgs shows that it is already disabled. pci 0001:01:00.0: PCI bridge to [bus 02-ff] pci 0001:01:00.0: bridge window [io 0x-0x] (disabled) pci 0001:01:00.0: bridge window [mem 0x-0x000f] (disabled) *pci 0001:01:00.0: bridge window [mem 0x-0x000f pref] (disabled)* Is it something that I am not getting right or you have miss read something? If it is problem with me, then what should be the O/P in case when I disable the prefetch window (by issuing pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0); and pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, 0); function calls)? And also, I will be really thankful to you if you also tell me the function in which I should place there function calls as I am new to linux device driver programming. Regards, Ravi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote: I will attempt to get the debugger to stop at start_kernel. I'm having trouble driving the JTAG debugger (a BDI2000). I have used Denx's guide [1] in the past, but the section on debugging the kernel itself is now missing. [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel I'll keep trying. start_kernel might be too late... You can also hack thing :-) Like in the asm, before machine_init(), stick something in the DABR and put a HW breakpoint with the BDI2000 on the Data Access exception handler to catch when it faults. I have succeeded in getting the debugger to break early on during boot. I have it set to break at start_here, in arch/powerpc/kernel/head_32.S. My U-Boot bootloader indicates that the fdt is being loaded to address 0x7f8000, which translates to VA 0xc07f8000. See this output: Booting using the fdt blob at 0x2269f1c Uncompressing Kernel Image ... OK Loading Ramdisk to 0fea, end 0ff76699 ... OK Loading Device Tree to 007f8000, end 007ff78f ... OK As soon an the debugger hit the start_here breakpoint, I ran the following command. It should dump out the flat device tree to a file, which I can then analyze: (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree in fdt.bin. I see the stuff I would expect. On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin. So clearly something is overwriting the fdt. However, note that this happens *before* lockdep_init() runs. Grepping for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing. I'm not sure exactly how this is related to lockdep. Some more suggestions for things to try would be great. For now, I'm going to try getting the debugger to break near the end of U-Boot, to see if the memory is overwritten there, and not in Linux. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Combining defconfigs for 44x based boards
We already have arch/powerpc/configs/ppc40x_defconfig and arch/powerpc/configs/ppc44x_defconfig in mainline. What's wrong with using these? [Marri] Great we already have it. We should remove the defconfigs under 44x then ? Regards, Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to define an I2C-to-SPI bridge device ?
On Fri, Sep 03, 2010 at 10:36:19AM +0200, André Schwarz wrote:
Hi,
we're about to get new MPC8377 based hardware with various peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
how to define a proper dts...
Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI bus ?
Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
I2C slave or an SPI host driver ?
Both! The driver would get probed from the i2c bus, and it would
create and register an spi master. If the spi bus registration
includes a pointer to the device tree node, then the child nodes will
automatically be registered as spi_devices.
The dts is also fairly straight forward:
i2c-bus: i...@80001000 {
compatible = blah;
#address-cells = 1;
#size-cells = 0;
spi-bus: s...@28{
compatible = nxp,sc18is602;
#address-cells = 1;
#size-cells = 0x28;
reg = 0;
spi-dev...@0 {
compatible = blah;
reg = 0;
};
spi-dev...@1 {
compatible = blah;
reg = 1;
};
spi-dev...@2 {
compatible = blah;
reg = 2;
};
};
};
Cheers,
g.
Any help is welcome.
--
Mit freundlichen Grüßen / Best regards
André Schwarz
___
MATRIX VISION GmbH
- Entwicklung / Development -
Talstraße 16
D-71570 Oppenweiler
Fon: ++49-07191-9432-420
Fax: ++49-07191-9432-288
eMail: andre.schw...@matrix-vision.de
web: www.matrix-vision.de
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Combining defconfigs for 44x based boards
On Thu, 9 Sep 2010 09:49:14 -0700 Tirumala Marri tma...@apm.com wrote: [Marri] Great we already have it. We should remove the defconfigs under 44x then ? I'd rather we didn't. I thought Linus' beef was over the churn in the defconfigs, not the fact that they exist. The 44x defconfigs change very rarely. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to define an I2C-to-SPI bridge device ?
Andre Schwarz andre.schw...@matrix-vision.de wrote:
Anton,
we're about to get new MPC8377 based hardware with various peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
how to define a proper dts...
Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI bus ?
Um.. the same as the other SPI buses? I.e.
i2c-controller { /* SOC I2C controller */
spi-controller { /* The I2C-to-SPI bridge */
spi-dev...@0 {
};
spi-dev...@1 {
};
};
};
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C
or SPI device registration/linking ?
Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
I2C slave or an SPI host driver ?
It should be an I2C driver that registers an SPI master (i.e.
calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...
Yes, but this is the case for non-of drivers too. The i2c to spi device driver
must always create (and trigger population of) the spi bus instance.
I still wonder how to make the driver arch-generic *and* of-capable.
Do we need a generic I2C slave driver that can be probed along with an
of glue driver or should the of-binding be part of a single device
driver ?
There is no longer any need for separate of and non-of drivers for the same
hardware. Any device may have the of_node pointer in struct device set, and
drivers can use the pointer as an alternative to platform_data to get
information about the hardware configuration.
Just read the data out of the node in the driver's probe hook.
For i2c and (soon) spi, the core code will even register child devices for you.
g.
Sorry for the dumb questions - looks like I expected a little too much
functionality already existing.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
The device tree for Freescale's P1022DS reference board is missing the node
for the ngPIXIS FPGA.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/boot/dts/p1022ds.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dts
b/arch/powerpc/boot/dts/p1022ds.dts
index 8bcb10b..e61b42d 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -148,6 +148,15 @@
label = reserved-nand;
};
};
+
+ board-cont...@3,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,fpga-pixis;
+ reg = 3 0 0x30;
+ interrupt-parent = mpic;
+ interrupts = 8 8;
+ };
};
s...@fffe0 {
--
1.7.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
The Freescale P1022DS has an on-chip video controller called the DIU, and a driver for this device already exists. Update the platform file for the P1022DS reference board to enable the driver, and update the defconfig for Freescale MPC85xx boards to add the driver. Signed-off-by: Timur Tabi ti...@freescale.com --- The following patch is a pre-requisite for this patch: powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board arch/powerpc/configs/mpc85xx_defconfig |3 + arch/powerpc/configs/mpc85xx_smp_defconfig |3 + arch/powerpc/platforms/85xx/p1022_ds.c | 213 +++- 3 files changed, 217 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index c3b113b..3aeb594 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -124,6 +124,9 @@ CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y +CONFIG_FB=y +CONFIG_FB_FSL_DIU=y +# CONFIG_VGA_CONSOLE is not set CONFIG_SOUND=y CONFIG_SND=y # CONFIG_SND_SUPPORT_OLD_API is not set diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index a075da2..d62c801 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -126,6 +126,9 @@ CONFIG_I2C_CPM=m CONFIG_I2C_MPC=y # CONFIG_HWMON is not set CONFIG_VIDEO_OUTPUT_CONTROL=y +CONFIG_FB=y +CONFIG_FB_FSL_DIU=y +# CONFIG_VGA_CONSOLE is not set CONFIG_SOUND=y CONFIG_SND=y # CONFIG_SND_SUPPORT_OLD_API is not set diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c index 34e0090..3340071 100644 --- a/arch/powerpc/platforms/85xx/p1022_ds.c +++ b/arch/powerpc/platforms/85xx/p1022_ds.c @@ -8,7 +8,6 @@ * Copyright 2010 Freescale Semiconductor, Inc. * * This file is taken from the Freescale P1022DS BSP, with modifications: - * 1) No DIU support (pending rewrite of DIU code) * 2) No AMP support * 3) No PCI endpoint support * @@ -17,15 +16,216 @@ * kind, whether express or implied. */ +#define DEBUG + #include linux/pci.h #include linux/of_platform.h #include linux/memblock.h - +#include asm/div64.h #include asm/mpic.h #include asm/swiotlb.h #include sysdev/fsl_soc.h #include sysdev/fsl_pci.h +#include asm/fsl_guts.h + +#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE) + +/* + * Board-specific initialization of the DIU. This code should probably be + * executed when the DIU is opened, rather than in arch code, but the DIU + * driver does not have a mechanism for this (yet). + * + * This is especially problematic on the P1022DS because the local bus (eLBC) + * and the DIU video signals share the same pins, which means that enabling the + * DIU will disable access to NOR flash. + */ + +/* DIU Pixel Clock bits of the CLKDVDR Global Utilities register */ +#define CLKDVDR_PXCKEN 0x8000 +#define CLKDVDR_PXCKINV0x1000 +#define CLKDVDR_PXCKDLY0x0600 +#define CLKDVDR_PXCLK_MASK 0x00FF + +/* Some ngPIXIS register definitions */ +#define PX_BRDCFG1_DVIEN 0x80 +#define PX_BRDCFG1_DFPEN 0x40 +#define PX_BRDCFG1_BACKLIGHT 0x20 +#define PX_BRDCFG1_DDCEN 0x10 + +/* + * DIU Area Descriptor + * + * Note that we need to byte-swap the value before it's written to the AD + * register. So even though the registers don't look like they're in the same + * bit positions as they are on the MPC8610, the same value is written to the + * AD register on the MPC8610 and on the P1022. + */ +#define AD_BYTE_F 0x1000 +#define AD_ALPHA_C_MASK0x0E00 +#define AD_ALPHA_C_SHIFT 25 +#define AD_BLUE_C_MASK 0x0180 +#define AD_BLUE_C_SHIFT23 +#define AD_GREEN_C_MASK0x0060 +#define AD_GREEN_C_SHIFT 21 +#define AD_RED_C_MASK 0x0018 +#define AD_RED_C_SHIFT 19 +#define AD_PALETTE 0x0004 +#define AD_PIXEL_S_MASK0x0003 +#define AD_PIXEL_S_SHIFT 16 +#define AD_COMP_3_MASK 0xF000 +#define AD_COMP_3_SHIFT12 +#define AD_COMP_2_MASK 0x0F00 +#define AD_COMP_2_SHIFT8 +#define AD_COMP_1_MASK 0x00F0 +#define AD_COMP_1_SHIFT4 +#define AD_COMP_0_MASK 0x000F +#define AD_COMP_0_SHIFT0 + +#define MAKE_AD(alpha, red, blue, green, size, c0, c1, c2, c3) \ + cpu_to_le32(AD_BYTE_F | (alpha AD_ALPHA_C_SHIFT) | \ + (blue AD_BLUE_C_SHIFT) | (green AD_GREEN_C_SHIFT) | \ + (red AD_RED_C_SHIFT) | (c3 AD_COMP_3_SHIFT) | \ + (c2 AD_COMP_2_SHIFT) | (c1 AD_COMP_1_SHIFT) | \ + (c0 AD_COMP_0_SHIFT) | (size AD_PIXEL_S_SHIFT)) + +/** + * p1022ds_get_pixel_format: return the Area Descriptor for a given pixel depth + * + * The
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 09, 2010 at 09:23:07AM -0700, Ira W. Snyder wrote: On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote: I will attempt to get the debugger to stop at start_kernel. I'm having trouble driving the JTAG debugger (a BDI2000). I have used Denx's guide [1] in the past, but the section on debugging the kernel itself is now missing. [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel I'll keep trying. start_kernel might be too late... You can also hack thing :-) Like in the asm, before machine_init(), stick something in the DABR and put a HW breakpoint with the BDI2000 on the Data Access exception handler to catch when it faults. I have succeeded in getting the debugger to break early on during boot. I have it set to break at start_here, in arch/powerpc/kernel/head_32.S. My U-Boot bootloader indicates that the fdt is being loaded to address 0x7f8000, which translates to VA 0xc07f8000. See this output: Booting using the fdt blob at 0x2269f1c Uncompressing Kernel Image ... OK Loading Ramdisk to 0fea, end 0ff76699 ... OK Loading Device Tree to 007f8000, end 007ff78f ... OK As soon an the debugger hit the start_here breakpoint, I ran the following command. It should dump out the flat device tree to a file, which I can then analyze: (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree in fdt.bin. I see the stuff I would expect. On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin. So clearly something is overwriting the fdt. However, note that this happens *before* lockdep_init() runs. Grepping for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing. I'm not sure exactly how this is related to lockdep. Some more suggestions for things to try would be great. For now, I'm going to try getting the debugger to break near the end of U-Boot, to see if the memory is overwritten there, and not in Linux. Here is some more information. After tracing U-Boot's execution, I've found that U-Boot is not the problem. The FDT is correct in-memory at the point it jumps into the kernel. I literally halted it on the instruction before the jmp and checked. I've also found that setting a breakpoint at 0x0 stops right when the Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet enabled, so I have to subtract 0xc000 from all addresses. Single stepping through the initial assembly portion of kernel startup shows that the FDT gets clobbered during the function early_init(). This trace is reproduced below. For whatever reason, even when single stepping, the debugger absolutely refuses to enter the early_init function. Misc Information: 1) 0xd00dfeed is an FDT magic number 2) 0x7f8000 is the physical address of the FDT in memory (gdb) info break Num Type Disp Enb AddressWhat 2 hw breakpoint keep y 0x /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72 breakpoint already hit 3 times (gdb) detach Ending remote debugging. (gdb) target remote bdi2k:2001 Remote debugging using bdi2k:2001 0x0ffbe760 in ?? () (gdb) continue Continuing. Breakpoint 2, _stext () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72 72 nop /* used by __secondary_hold on prep (mtx) and chrp smp */ Current language: auto; currently asm (gdb) print /x *0x7f8000 $6 = 0xd00dfeed (gdb) s 73 nop /* used by __secondary_hold on prep (mtx) and chrp smp */ (gdb) s 74 nop (gdb) s __start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:113 113 cmpwi 0,r5,0 (gdb) s 114 beq 1f (gdb) s 142 1: mr r31,r3 /* save parameters */ (gdb) s 143 mr r30,r4 (gdb) s 144 li r24,0 /* cpu # */ (gdb) s 151 bl early_init (gdb) print /x *0x7f8000 $7 = 0xd00dfeed (gdb) s __start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:156 156 bl mmu_off (gdb) print /x *0x7f8000 $8 = 0x0 Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder i...@ovro.caltech.edu wrote: Single stepping through the initial assembly portion of kernel startup shows that the FDT gets clobbered during the function early_init(). This trace is reproduced below. Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two config options are related. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 09, 2010 at 11:44:46AM -0700, Ira W. Snyder wrote:
[ snip a bunch of info: summary below ]
I've also found that setting a breakpoint at 0x0 stops right when the
Linux kernel starts, at symbol _start. AFAIK, the MMU is not yet
enabled, so I have to subtract 0xc000 from all addresses.
Single stepping through the initial assembly portion of kernel startup
shows that the FDT gets clobbered during the function early_init(). This
trace is reproduced below.
For whatever reason, even when single stepping, the debugger absolutely
refuses to enter the early_init function.
Misc Information:
1) 0xd00dfeed is an FDT magic number
2) 0x7f8000 is the physical address of the FDT in memory
I have gotten the debugger to enter early_init(). I had to remove the
__init annotation on the function. I guess the debugger doesn't cope
with the extra sections that Linux uses.
(gdb) target remote bdi2k:2001
Remote debugging using bdi2k:2001
0xfc0034e8 in ?? ()
(gdb) info break
Num Type Disp Enb AddressWhat
1 hw breakpoint keep y 0x
/home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
breakpoint already hit 1 time
(gdb) continue
Continuing.
Breakpoint 1, _stext () at
/home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:72
72 nop /* used by __secondary_hold on prep (mtx) and chrp smp
*/
Current language: auto; currently asm
(gdb) s
73 nop /* used by __secondary_hold on prep (mtx) and chrp smp
*/
(gdb) s
74 nop
(gdb) s
__start () at /home/iws/devel/linux-2.6/arch/powerpc/kernel/head_32.S:113
113 cmpwi 0,r5,0
(gdb) s
114 beq 1f
(gdb) s
142 1: mr r31,r3 /* save parameters */
(gdb) s
143 mr r30,r4
(gdb) s
144 li r24,0 /* cpu # */
(gdb) s
151 bl early_init
(gdb) s
early_init (dt_ptr=8355840) at
/home/iws/devel/linux-2.6/arch/powerpc/kernel/setup_32.c:82
82 {
Current language: auto; currently c
(gdb) s
88 memset_io((void __iomem *)PTRRELOC(__bss_start), 0,
(gdb) print /x *0x7f8000
$22 = 0xd00dfeed
(gdb) n
82 {
(gdb) n
88 memset_io((void __iomem *)PTRRELOC(__bss_start), 0,
(gdb) print __bss_start
$23 = 0xc0369000 Address 0xc0369000 out of bounds
(gdb) print __bss_stop
$25 = 0xc08a0c48 Address 0xc08a0c48 out of bounds
(gdb) print /x *0x7f8000
$26 = 0xd00dfeed
(gdb) n
83 unsigned long offset = reloc_offset();
(gdb) print /x *0x7f8000
$27 = 0xd00dfeed
(gdb) n
88 memset_io((void __iomem *)PTRRELOC(__bss_start), 0,
(gdb) print /x *0x7f8000
$28 = 0xd00dfeed
(gdb) n
55 DEF_PCI_AC_NORET(memset_io, (PCI_IO_ADDR a, int c, unsigned long n),
(gdb) print /x *0x7f8000
$29 = 0xd00dfeed
(gdb) n
95 spec = identify_cpu(offset, mfspr(SPRN_PVR));
(gdb) print /x *0x7f8000
$30 = 0x0
This shows that the memset_io() in early_init() is zeroing the FDT. It
appears that CONFIG_PROVE_LOCKING increases the BSS size significantly,
and that's what is causing the true error. It isn't a lockdep problem,
it is a the BSS is too big problem.
Unfortunately, I'm now at a loss on how to fix this. Why does the
bootloader put the FDT so close to the kernel? Is this a bootloader
problem? Is it a configuration problem on my part?
I'm booting with a FIT image. The source file is inlined below. By
U-Boot bootm command is trivial:
dhcp 200 carma.itb ; bootm 200
Thanks,
Ira
/*
* U-boot uImage source file with CARMA kernel, ramdisk, and FDT blob
*
* Compile with:
* $ mkimage -f carma.its carma.itb
*/
/dts-v1/;
/ {
description = CARMA kernel, ramdisk, and FDT blob;
#address-cells = 1;
images {
ker...@1 {
description = Linux 2.6.36rc3;
data = /incbin/(./vmlinux.bin.gz);
type = kernel;
arch = ppc;
os = linux;
compression = gzip;
load = 0x0;
entry = 0x0;
h...@1 {
algo = md5;
};
h...@2 {
algo = sha1;
};
};
ramd...@1 {
description = CARMA PPC Generic Ramdisk;
data = /incbin/(./initramfs-generic-ppc.cpio.gz);
type = ramdisk;
arch = ppc;
os = linux;
compression = gzip;
load = 0x0;
h...@1 {
algo = sha1;
};
};
f...@1 {
description = CARMA FDT;
data = /incbin/(./carma.dtb);
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote: On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder i...@ovro.caltech.edu wrote: Single stepping through the initial assembly portion of kernel startup shows that the FDT gets clobbered during the function early_init(). This trace is reproduced below. Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two config options are related. Yes, I have had it enabled the whole time. As noted in another email, it appears that U-Boot puts the FDT in such a place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y option expands the BSS by a large amount, which causes the error. It isn't directly lockdep related. I don't know if this is a U-Boot problem or a Linux problem. I have no idea how to fix the bug. Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Ira W. Snyder wrote: As noted in another email, it appears that U-Boot puts the FDT in such a place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y option expands the BSS by a large amount, which causes the error. It isn't directly lockdep related. I don't know if this is a U-Boot problem or a Linux problem. I have no idea how to fix the bug. I wonder if this patch that I wrote for U-Boot will fix the problem: http://lists.denx.de/pipermail/u-boot/2010-May/071822.html -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 09, 2010 at 02:40:50PM -0500, Timur Tabi wrote: Ira W. Snyder wrote: As noted in another email, it appears that U-Boot puts the FDT in such a place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y option expands the BSS by a large amount, which causes the error. It isn't directly lockdep related. I don't know if this is a U-Boot problem or a Linux problem. I have no idea how to fix the bug. I wonder if this patch that I wrote for U-Boot will fix the problem: http://lists.denx.de/pipermail/u-boot/2010-May/071822.html Nope, I tried it and it doesn't fix the problem. It relocates the FDT to exactly the same address as before the patch. I think the problem is that the U-Boot loader doesn't take into account the Linux kernel's BSS size, and puts the FDT too close. Here is the relevant U-Boot output after applying your patch. It was not changed from the previous output. Booting using the fdt blob at 0x226a278 Uncompressing Kernel Image ... OK Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK Loading Device Tree to 007f8000, end 007ff78f ... OK My ramdisk is right near the end of RAM. This board has 256MB of RAM. 0x0ff75699 / 1024 / 1024 == 255.4586 The FDT is just before the 8MB boundary: 0x007ff78f / 1024 / 1024 == 7.9979 My uncompressed vmlinux.bin.gz is ~3.5MB: i...@rena ~/devel/correlator/fit-image $ zcat vmlinux.bin.gz vmlinux.bin i...@rena ~/devel/correlator/fit-image $ du -b vmlinux.bin 3573068 vmlinux.bin As posted in my other email, Linux's BSS is ~5.2MB: (gdb) print __bss_start $23 = 0xc0369000 Address 0xc0369000 out of bounds (gdb) print __bss_stop $25 = 0xc08a0c48 Address 0xc08a0c48 out of bounds (0xc08a0c48 - 0xc0369000) / 1024 / 1024 == 5.21784210205078125 Total (code + BSS): 3573068 + 5471304 == 9044372 (~8.62MB) That easily overruns the location where U-Boot puts the FDT. Is this a U-Boot bug, meaning I should post this information on the U-Boot mailing list? Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Ira W. Snyder wrote: That easily overruns the location where U-Boot puts the FDT. Is this a U-Boot bug, meaning I should post this information on the U-Boot mailing list? Possibly. I am under the impression that the memory in the boot block that contains the FDT is marked as reserved in the device tree, so that the kernel doesn't overwrite it. However, that obviously isn't helpful if we haven't parsed the device tree yet. What concerns me is this in U-Boot: /* * For booting Linux, the board info and command line data * have to be in the first 16 MB of memory, since this is * the maximum mapped by the Linux kernel during initialization. */ #define CONFIG_SYS_BOOTMAPSZ(16 20) /* Initial Memory map for Linux*/ If the 16MB mapping limit is true, then does this mean that the Linux's BSS is larger than the memory that is mapped? If so, that means that Linux can't even access all of its BSS at this point. Somehow, I doubt that. Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ? Combined with my always-relocate-fdt, I think this will force the FDT to be placed higher in memory. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Ira W. Snyder wrote: That did it! Yea! I'm using include/configs/MPC8349EMDS.h. On that board, CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and the kernel now boots. Ah, yes. I believe the reason that is the case is because some of those boards were shipped with only 8MB of RAM. I'll make a post to the U-Boot list asking if this should be boosted for MPC8349EMDS (and others?). It is easy to build a kernel that overruns this limit. Other than debugging options, my kernel is fairly minimal, only a few drivers are built in. I think we should first determine if the kernel boot map limit really is 16MB. If it's more than that, then we should consider making it match. Assuming, of course, that the U-Boot code can handle a situation where CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM. I'm using your always-relocate-fdt patch. Your patch made no difference to the FDT location. U-Boot with and without your patch bo My patch only does something if the FDT is already located inside the boot map. Since you were expanding the size of the boot map, there's a chance that the FDT was located between 8MB and 16MB, and if so, my patch would have made a difference. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, Sep 09, 2010 at 03:36:31PM -0500, Timur Tabi wrote: Ira W. Snyder wrote: That did it! Yea! I'm using include/configs/MPC8349EMDS.h. On that board, CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and the kernel now boots. Ah, yes. I believe the reason that is the case is because some of those boards were shipped with only 8MB of RAM. I'll make a post to the U-Boot list asking if this should be boosted for MPC8349EMDS (and others?). It is easy to build a kernel that overruns this limit. Other than debugging options, my kernel is fairly minimal, only a few drivers are built in. I think we should first determine if the kernel boot map limit really is 16MB. If it's more than that, then we should consider making it match. Assuming, of course, that the U-Boot code can handle a situation where CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM. I have no idea how to determine this. The code that caused the problem runs so early in boot that the MMU is not running yet. Looking through the tiny bit of code, it appears that it just uses whatever the bootloader set up for it. It hasn't gotten to the initial_bats function yet. The comment in initial_bats (arch/powerpc/kernel/head_32.S) says: /* * On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET * (we keep one for debugging) and on others, we use one 256M BAT. */ I think the MPC8349EA would be a 603 CPU, meaning that we could increase CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM). I'm using your always-relocate-fdt patch. Your patch made no difference to the FDT location. U-Boot with and without your patch bo My patch only does something if the FDT is already located inside the boot map. Since you were expanding the size of the boot map, there's a chance that the FDT was located between 8MB and 16MB, and if so, my patch would have made a difference. Yep, you're exactly correct. I tried loading my FIT image to a lower address (0xa0 == 10MB), both with and without your patch: Without your patch (vanilla U-Boot): Verifying Hash Integrity ... crc32+ OK Booting using the fdt blob at 0xc6a278 Uncompressing Kernel Image ... OK Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK With your patch: Verifying Hash Integrity ... crc32+ OK Booting using the fdt blob at 0xc42d6c Uncompressing Kernel Image ... OK Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK Loading Device Tree to 00ff8000, end 00fff84f ... OK You'll see that your patch now relocated the FDT. It didn't cause any problems. I'll post to the thread on the U-Boot ML. [ dropped mingo and peterz from the CC list, they're not powerpc people ] Thanks, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Ira W. Snyder wrote: I have no idea how to determine this. The code that caused the problem runs so early in boot that the MMU is not running yet. Looking through the tiny bit of code, it appears that it just uses whatever the bootloader set up for it. It hasn't gotten to the initial_bats function yet. I just spoke to Kumar, and he said that the 8MB is just historical. We ran into the same exact problem that you ran into, except it was with a normal kernel, so we changed 8MB to 16MB on our 85xx boards, but we never went back and made the same change to 83xx boards. So it should be safe to change CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB on all 83xx systems. However, U-Boot does not verify that CONFIG_SYS_BOOTMAPSZ = the actual amount of RAM in the system, so we need to make sure that CONFIG_SYS_BOOTMAPSZ isn't increased on any board that actually did ship with only 8MB of RAM. My guess is that no such board exists, but I will get confirmation. However, this comment for CONFIG_SYS_BOOTMAPSZ still bothers me: /* * For booting Linux, the board info and command line data * have to be in the first 8 MB of memory, since this is * the maximum mapped by the Linux kernel during initialization. */ This same comment says 16MB on 85xx systems, so I don't think the statement about maximum mapped by the Linux kernel is really true. Maybe someone else can shed some light on this. I think the MPC8349EA would be a 603 CPU, meaning that we could increase CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM). Except that I'm still not sure what CONFIG_SYS_BOOTMAPSZ really means. I was under the impression that CONFIG_MAX_MEM_MAPPED is the actual value of the size of the mapping that U-Boot creates for the kernel. When the kernel initializes the MMU for its own purposes, does it limit anything to 16MB? I seriously doubt it. You'll see that your patch now relocated the FDT. It didn't cause any problems. I'll post to the thread on the U-Boot ML. Yes, please. I need someone to confirm that he tested my patch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
I have succeeded in getting the debugger to break early on during boot. I have it set to break at start_here, in arch/powerpc/kernel/head_32.S. My U-Boot bootloader indicates that the fdt is being loaded to address 0x7f8000, which translates to VA 0xc07f8000. See this output: Booting using the fdt blob at 0x2269f1c Uncompressing Kernel Image ... OK Loading Ramdisk to 0fea, end 0ff76699 ... OK Loading Device Tree to 007f8000, end 007ff78f ... OK As soon an the debugger hit the start_here breakpoint, I ran the following command. It should dump out the flat device tree to a file, which I can then analyze: (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree in fdt.bin. I see the stuff I would expect. On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin. So clearly something is overwriting the fdt. However, note that this happens *before* lockdep_init() runs. Grepping for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing. I'm not sure exactly how this is related to lockdep. Some more suggestions for things to try would be great. For now, I'm going to try getting the debugger to break near the end of U-Boot, to see if the memory is overwritten there, and not in Linux. I suspect your uboot setup. The one thing lockdep does is massively increase the amount of kernel bss. I suspect you are just overlapping DT and bss and hence wiping out the DT when clearing the bss. I would have expected uboot to warn (the kernel ELF header contains the BSS size) but apparently that isn't the case. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, 2010-09-09 at 12:36 -0700, Ira W. Snyder wrote: On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote: On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder i...@ovro.caltech.edu wrote: Single stepping through the initial assembly portion of kernel startup shows that the FDT gets clobbered during the function early_init(). This trace is reproduced below. Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two config options are related. Yes, I have had it enabled the whole time. As noted in another email, it appears that U-Boot puts the FDT in such a place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y option expands the BSS by a large amount, which causes the error. It isn't directly lockdep related. I don't know if this is a U-Boot problem or a Linux problem. I have no idea how to fix the bug. Definitely a u-boot problem. There must be a way to set where the fdt goes somewhere. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote: I would have expected uboot to warn (the kernel ELF header contains the BSS size) but apparently that isn't the case. U-Boot doesn't use ELF files with Linux, so it has no idea where the BSS is. uImage is just a wrapper around a flat binary. Oh, right, I forgot about that... -1 for uboot there. Seriously, it's time it grows the ability to load ELF or to at least stick an ELF in a uImage... I've never understood the reasoning for that uImage wrapper thingy. Definitely causes more problems than it solves in my experience. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Fri, 2010-09-10 at 08:13 +1000, Benjamin Herrenschmidt wrote: On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote: I would have expected uboot to warn (the kernel ELF header contains the BSS size) but apparently that isn't the case. U-Boot doesn't use ELF files with Linux, so it has no idea where the BSS is. uImage is just a wrapper around a flat binary. Oh, right, I forgot about that... -1 for uboot there. Seriously, it's time it grows the ability to load ELF or to at least stick an ELF in a uImage... I've never understood the reasoning for that uImage wrapper thingy. Definitely causes more problems than it solves in my experience. Note that with ePAPR we know the top of mapped memory on entry, so in theory, if the bootloader is fully ePAPR compliant we -could- detect that case and move the FDT up to after the .dts before we clear the bss... do we care enough tho ? Even if we aren't totally ePAPR compliant, we could still try to move it, if we hit the end of memory well... we won't do more damage than we already did by by overwriting the dts in the first place. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Combining defconfigs for 44x based boards
On Thu, 9 Sep 2010 09:49:14 -0700 Tirumala Marri tma...@apm.com wrote: [Marri] Great we already have it. We should remove the defconfigs under 44x then ? I'd rather we didn't. I thought Linus' beef was over the churn in the defconfigs, not the fact that they exist. The 44x defconfigs change very rarely. [Marri]That is kind of true. Can we create new defconfigs then ? I am trying to check-in new defconfig. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Fri, 10 Sep 2010 07:58:54 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: I would have expected uboot to warn (the kernel ELF header contains the BSS size) but apparently that isn't the case. U-Boot doesn't use ELF files with Linux, so it has no idea where the BSS is. uImage is just a wrapper around a flat binary. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Fri, 10 Sep 2010 08:13:53 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote: I would have expected uboot to warn (the kernel ELF header contains the BSS size) but apparently that isn't the case. U-Boot doesn't use ELF files with Linux, so it has no idea where the BSS is. uImage is just a wrapper around a flat binary. Oh, right, I forgot about that... -1 for uboot there. Seriously, it's time it grows the ability to load ELF or to at least stick an ELF in a uImage... It actually can load an ELF file, but it doesn't currently support passing a device tree to it (only argc/argv text arguments, or some vxworks stuff). I've never understood the reasoning for that uImage wrapper thingy. Definitely causes more problems than it solves in my experience. Wolfgang was just defending it on the U-Boot list the past couple days... seems like the main thing in its favor is the CRC, especially as a final check before reflashing an image. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Combining defconfigs for 44x based boards
Hi, On Thu, 9 Sep 2010 15:17:10 -0700 Tirumala Marri tma...@apm.com wrote: [Marri]That is kind of true. Can we create new defconfigs then ? I am trying to check-in new defconfig. Just make sure that it is minimal by using make savedefconfig. This will create a file defconfig in the current directory which should have the minimal amount of stuff in it to reproduce the current .config. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpha4DcBvzEZ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
On Thu, 2010-09-09 at 17:37 -0500, Scott Wood wrote: Wolfgang was just defending it on the U-Boot list the past couple days... seems like the main thing in its favor is the CRC, especially as a final check before reflashing an image. Right, then fwd my 2 cents: Makes sense to have a wrapper like that for flashing, but - It could/should contain an ELF - u-boot should be capable to just load/boot the ELF, not everybody uses flashable images (netboot anyone ? espectially when debugging) and it's really a burden to do the wrapping all the time. In addition, we just see how it can actually hurt due to losing information such as the BSS size. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc64: increase TREEWORDS value in ppc64
[ CCed linuxppc-dev ] On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote: hey- Got a segfault recently on ppc64 kexec with a system with 256Gb of ram. Tracked it back to running over the end of the device tree buffer that we have allocated. I can't find any docs on how big the device tree can legally be, so for now I figure just upping its size is sufficient. Confirmed that this fixed the segfault. Thanks Neil, though it would be nice to know what the limit actually is. I'll hold off on applying this for a few days to see of the ppc people have any comments on that. Signed-off-by: Neil Horman nhor...@tuxdriver.com fs2dt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c index 238a3f2..2f0f937 100644 --- a/kexec/arch/ppc/fs2dt.c +++ b/kexec/arch/ppc/fs2dt.c @@ -33,7 +33,7 @@ #define MAXPATH 1024/* max path name length */ #define NAMESPACE16384 /* max bytes for property names */ -#define TREEWORDS65536 /* max 32 bit words for properties */ +#define TREEWORDS131070 /* max 32 bit words for properties */ #define MEMRESERVE 256 /* max number of reserved memory blks */ #define MAX_MEMORY_RANGES1024 #define COMMAND_LINE_SIZE512 /* from kernel */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc64: increase TREEWORDS value in ppc64
[ Repost with correct kexec ML address ] [ CCed linuxppc-dev ] On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote: hey- Got a segfault recently on ppc64 kexec with a system with 256Gb of ram. Tracked it back to running over the end of the device tree buffer that we have allocated. I can't find any docs on how big the device tree can legally be, so for now I figure just upping its size is sufficient. Confirmed that this fixed the segfault. Thanks Neil, though it would be nice to know what the limit actually is. I'll hold off on applying this for a few days to see of the PPC people have any comments on that. Signed-off-by: Neil Horman nhor...@tuxdriver.com fs2dt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c index 238a3f2..2f0f937 100644 --- a/kexec/arch/ppc/fs2dt.c +++ b/kexec/arch/ppc/fs2dt.c @@ -33,7 +33,7 @@ #define MAXPATH 1024/* max path name length */ #define NAMESPACE16384 /* max bytes for property names */ -#define TREEWORDS65536 /* max 32 bit words for properties */ +#define TREEWORDS131070 /* max 32 bit words for properties */ #define MEMRESERVE 256 /* max number of reserved memory blks */ #define MAX_MEMORY_RANGES1024 #define COMMAND_LINE_SIZE512 /* from kernel */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc, perf: Fix sampling enable for PPC970
The logic to distinguish marked instruction events from ordinary events
on PPC970 and derivatives was flawed. The result is that instruction
sampling didn't get enabled in the PMU for some marked instruction
events, so they would never trigger. This fixes it by adding the
appropriate break statements in the switch statement.
Reported-by: David Binderman dcb...@hotmail.com
Cc: sta...@kernel.org
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/kernel/ppc970-pmu.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/ppc970-pmu.c b/arch/powerpc/kernel/ppc970-pmu.c
index 8eff48e..3fee685 100644
--- a/arch/powerpc/kernel/ppc970-pmu.c
+++ b/arch/powerpc/kernel/ppc970-pmu.c
@@ -169,9 +169,11 @@ static int p970_marked_instr_event(u64 event)
switch (unit) {
case PM_VPU:
mask = 0x4c;/* byte 0 bits 2,3,6 */
+ break;
case PM_LSU0:
/* byte 2 bits 0,2,3,4,6; all of byte 1 */
mask = 0x085dff00;
+ break;
case PM_LSU1L:
mask = 0x50 24; /* byte 3 bits 4,6 */
break;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci_request_regions() failure
Ravi Gupta wrote:
Hi Tiejun,
Thanks for the reply.
Omm.
Often we always disable this pref windows so please disable this window.
Try use
the following ways to clear PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT.
--
pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0);
pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, 0);
I have a little confusion about what you said. You said I should disable
prefetched window corresponds to PCI Bridge to [bus 02-ff], the dmesgs shows
that it is already disabled.
pci 0001:01:00.0: PCI bridge to [bus 02-ff]
pci 0001:01:00.0: bridge window [io 0x-0x] (disabled)
pci 0001:01:00.0: bridge window [mem 0x-0x000f] (disabled)
*pci 0001:01:00.0: bridge window [mem 0x-0x000f pref]
(disabled)*
Sorry I miss this line.
Is it something that I am not getting right or you have miss read something?
If it is problem with me, then what should be the O/P in case when I disable
the prefetch window (by issuing pci_write_config_word(dev,
PCI_PREF_MEMORY_BASE, 0); and pci_write_config_word(dev,
PCI_PREF_MEMORY_LIMIT, 0); function calls)? And also, I will be really
thankful to you if you also tell me the function in which I should place
there function calls as I am new to linux device driver programming.
Firstly I think we'd better print the BAR0 and BAR1 on the probe function of
your device driver because you have to make sure if a800-a803 is
assigned to BAR0 and 0xa804-0xa807 for BAR1 as we expect.
u32 value;
pci_read_config_word(pdev, PCI_BASE_ADDRESS_0, value); printk...
pci_read_config_word(pdev, PCI_BASE_ADDRESS_1, value); printk
And you can print this pci_resource_start(pdev, bar), pci_resource_len(pdev,
bar) from the function, __pci_request_region, on the file drivers/pci/pci.c.
Please check this as well.
And currently we have to debug this so on the function, __pci_assign_resource,
from the file drivers/pci/setup-res.c, we can force skipping temporarily
pci_bus_alloc_resource for bus 0001:01 since that will call pci_update_resource
for bus 0001:01.
static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
int resno)
{
struct resource *res = dev-resource + resno;
resource_size_t size, min, align;
int ret;
size = resource_size(res);
min = (res-flags IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
align = pci_resource_alignment(dev, res);
---
if (bus-number == 0x01) {
ret = -ENOMEM
return ret;
}
---
I means we don't want to assign resource as the below line on the log.
--
pci 0001:01:00.0: BAR 8: assigned [mem 0xa800-0xa80f]
I expect the following output:
--
pci 0001:01:00.0: BAR 8: can't assign mem pref (size 0x10)
Best Regards
Tiejun
Regards,
Ravi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
how to understand powerpc's BRx ORx
I didn't understand the address mask. it's said that: BR[BA] is the base address,the OR[AM] is the address mask, Provides masking for corresponding BRx bits. By masking address bits independently, SDRAM devices of different size address ranges can be used. Clearing bits masks the corresponding address bit. Setting bits causes the corresponding address bit to be compared with the address pins. Address mask bits can be set or cleared in any order, allowing a resource to reside in more than one area of the address map. SDAM can be read or written at any time. how to understand it? for instance, if my BR0[BA]=0111____0, OR0[AM]=__ if I want to access the 0x7000 or the 0x7101.what address calculate will be taken? thanks all -- hacklu 2010-09-10 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
