Re: [PATCH v2] powerpc: Allow perf_counters to access user memory at interrupt time
On Thu, 2009-08-06 at 14:57 +1000, Paul Mackerras wrote: This provides a mechanism to allow the perf_counters code to access user memory in a PMU interrupt routine. Such an access can cause various kinds of interrupt: SLB miss, MMU hash table miss, segment table miss, or TLB miss, depending on the processor. This commit only deals with the classic/server processors that use an MMU hash table, not processors that have software-loaded TLBs. .../... Signed-off-by: Paul Mackerras pau...@samba.org Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org As discussed in the lab, you should also do a pre-req patch to pgtable.h that changes ppc32 with 64-bit PTE without CONFIG_SMP to use the same path as SMP to order the stores to the two halves of the PTEs though. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PowerPC kernel linux-2.6.29.6 PANIC's at include/linux/cred.h for ipsec enabled kernel
Hi All, Target : PowerPC (ppc440) While testing kernel linux-2.6.29.6 with IPSEC enabled I observed frequent panic messages as shown below while bootup: VFS: Mounted root (nfs filesystem) on device 0:13. Freeing unused kernel memory: 184k init INIT: version 2.86 booting Starting udevudevd version 124 started Remounting root file system... logger: mount: mount point /proc/bus/usb does not exist FAT: invalid media value (0x01) VFS: Can't find a valid FAT filesystem on dev xsa. [ cut here ] kernel BUG at include/linux/cred.h:206! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT LTT NESTING LEVEL : 0 Xilinx Virtex440 Modules linked in: nls_iso8859_1 NIP: c0031800 LR: c0031864 CTR: c0033e2c REGS: c0515d00 TRAP: 0700 Not tainted (2.6.29.6.xilinx-ml507.0908071454-ipsec) MSR: 00029000 EE,ME,CE CR: 24028028 XER: 0005 TASK = c04e74c0[0] 'swapper' THREAD: c0514000 GPR00: c0515db0 c04e74c0 cf9e0120 c00539b4 0002 c04f2224 GPR08: 02fd 0001 02fc c05255e8 44022024 d6c4 dce9ee1f bfefe53f GPR16: c0456690 c0511188 c05111a8 c0525624 0001 c0522ca0 c0514034 GPR24: c0511328 c0514034 c0514000 c05255e8 000a cf3e7920 ce89e050 ce89e050 NIP [c0031800] __put_task_struct+0x8c/0xf4 LR [c0031864] __put_task_struct+0xf0/0xf4 Call Trace: [c0515db0] [c0031864] __put_task_struct+0xf0/0xf4 (unreliable) [c0515dc0] [c0033ecc] delayed_put_task_struct+0xa0/0xbc [c0515de0] [c0067804] __rcu_process_callbacks+0x1e4/0x400 [c0515e10] [c0067a4c] rcu_process_callbacks+0x2c/0x4c [c0515e30] [c0038cb0] __do_softirq+0xfc/0x1e0 [c0515e80] [c0004124] do_softirq+0x5c/0x60 [c0515e90] [c0038b18] irq_exit+0x98/0xc4 [c0515ea0] [c000b2b4] timer_interrupt+0x104/0x1cc [c0515ec0] [c000e7d8] ret_from_except+0x0/0x18 [c0515f80] [c0007294] cpu_idle+0x58/0xf4 [c0515fa0] [c03db4dc] __got2_end+0x80/0x94 [c0515fc0] [c04b6734] start_kernel+0x25c/0x2b0 [c0515ff0] [c218] skpinv+0x1a8/0x1e4 Instruction dump: 0f09 7c001828 3000 7c00192d 40a2fff4 2f80 419e0078 807f01a4 8123 3809 7d290378 55290ffe 0f09 7c001828 3000 7c00192d Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 180 seconds.. Attachment: kernel config your early comments are appreciated ! Regards Srikanth Krishnakar ** # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29.6 # Mon Aug 3 20:22:33 2009 # # CONFIG_PPC64 is not set # # Processor support # # CONFIG_6xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set CONFIG_44x=y # CONFIG_E200 is not set CONFIG_PPC_FPU=y CONFIG_4xx=y CONFIG_BOOKE=y CONFIG_PTE_64BIT=y CONFIG_PHYS_64BIT=y CONFIG_PPC_MMU_NOHASH=y # CONFIG_PPC_MM_SLICES is not set CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_PPC_DCR_NATIVE=y CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-ipsec # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_HAVE_GET_CYCLES is not set CONFIG_HAVE_TRACE_CLOCK=y # CONFIG_HAVE_TRACE_CLOCK_GENERIC is not set # CONFIG_HAVE_TRACE_CLOCK_32_TO_64 is not set # CONFIG_HAVE_UNSYNCHRONIZED_TSC is not set # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED
Re: [PATCH v2] perf_counter: powerpc: Add callchain support
On Thu, 2009-08-06 at 14:58 +1000, Paul Mackerras wrote:
+
+#else /* CONFIG_PPC64 */
+/*
+ * On 32-bit we just access the address and let hash_page create a
+ * HPTE if necessary, so there is no need to fall back to reading
+ * the page tables. Since this is called at interrupt level,
+ * do_page_fault() won't treat a DSI as a page fault.
+ */
Minor nit here... The comment makes it think there's only hash based
32-bit processors :-) In fact, there's a little issue with non-hash ones
here, which is that they rely on
do_page_fault-handle_mm_fault-ptep_set_access_flags to set
_PAGE_ACCESSED, and the TLB miss handlers are going to fault if that's
not set.
Not a big deal, but it does mean that if you have stack pages that
aren't young, they will fail to backtrace (though that's probably
unlikely unless you spend a lot of time very deep down a huge call
chain).
+static int read_user_stack_32(unsigned int __user *ptr, unsigned int *ret)
+{
+ if ((unsigned long)ptr TASK_SIZE - sizeof(unsigned int) ||
+ ((unsigned long)ptr 3))
+ return -EFAULT;
+
+ return __get_user_inatomic(*ret, ptr);
+}
+
+static inline void perf_callchain_user_64(struct pt_regs *regs,
+ struct perf_callchain_entry *entry)
+{
+}
+
+static inline int current_is_64bit(void)
+{
+ return 0;
+}
+
+static inline int valid_user_sp(unsigned long sp, int is_64)
+{
+ if (!sp || (sp 7) || sp TASK_SIZE - 32)
I know the above is right but I would still have preferred () around
TASK_SIZE - 32 :-) In fact, || has lower precedence than (I checked !)
so in theory if you really wanted to get rid of braces, you could have
written
if (!sp || sp 7 || sp TASK_SIZE - 32)
But heh, that sucks :-)
+struct signal_frame_32 {
+ chardummy[__SIGNAL_FRAMESIZE32];
+ struct sigcontext32 sctx;
+ struct mcontext32 mctx;
+ int abigap[56];
+};
+
+/*
+ * Layout for RT signal frames
+ */
+struct rt_signal_frame_32 {
+ chardummy[__SIGNAL_FRAMESIZE32 + 16];
+ compat_siginfo_tinfo;
+ struct ucontext32 uc;
+ int abigap[56];
+};
Should we put those somewhere shared ? They are almost the same
as the ones in signal_32.c apart from the initial gap... oh well, no big
deal if you want to keep them here for now.
Overall looks fine and I suppose it also works but I may have missed
something subtle.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Added 36-bit physical device tree for mpc8572ds board
Hi, Kumar
Patch subject does not match the contents. The patch is about mpc8536ds.
Felix.
Kumar Gala wrote:
Added a device tree that should be similiar to mpc8536ds.dtb except
the physical addresses for all IO are above the 4G boundary.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 467 +++
1 files changed, 467 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8536ds_36b.dts
diff --git a/arch/powerpc/boot/dts/mpc8536ds_36b.dts
b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
new file mode 100644
index 000..113ed8b
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8536ds_36b.dts
@@ -0,0 +1,467 @@
+/*
+ * MPC8536 DS Device Tree Source
+ *
+ * Copyright 2008-2009 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = fsl,mpc8536ds;
+ compatible = fsl,mpc8536ds;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ pci2 = pci2;
+ pci3 = pci3;
+ };
+
+ cpus {
+ #cpus = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,8...@0 {
+ device_type = cpu;
+ reg = 0;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0 0; // Filled by U-Boot
+ };
+
+ s...@fffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
+ ranges = 0x0 0xf 0xffe0 0x10;
+ bus-frequency = 0; // Filled out by uboot.
+
+ ecm-...@0 {
+ compatible = fsl,ecm-law;
+ reg = 0x0 0x1000;
+ fsl,num-laws = 12;
+ };
+
+ e...@1000 {
+ compatible = fsl,mpc8536-ecm, fsl,ecm;
+ reg = 0x1000 0x1000;
+ interrupts = 17 2;
+ interrupt-parent = mpic;
+ };
+
+ memory-control...@2000 {
+ compatible = fsl,mpc8536-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 0x2;
+ };
+
+ L2: l2-cache-control...@2 {
+ compatible = fsl,mpc8536-l2-cache-controller;
+ reg = 0x2 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 16 0x2;
+ };
+
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 0x2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ i...@3100 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 0x2;
+ interrupt-parent = mpic;
+ dfsrr;
+ r...@68 {
+ compatible = dallas,ds3232;
+ reg = 0x68;
+ interrupts = 0 0x1;
+ interrupt-parent = mpic;
+ };
+ };
+
+ d...@21300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8536-dma, fsl,eloplus-dma;
+ reg = 0x21300 4;
+ ranges = 0 0x21100 0x200;
+ cell-index = 0;
+ dma-chan...@0 {
+ compatible = fsl,mpc8536-dma-channel,
+fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ cell-index = 0;
+ interrupt-parent = mpic;
+ interrupts = 20 2;
+ };
+
[PATCH] Disable PowerMac cpufreq on SMP kernels
The build of a PowerMac 32bit kernel currently fails with error: #warning WARNING, CPUFREQ not recommended on SMP kernels This patch just disables this driver on SMP kernels, as it is obviously not supported. Signed-off-by: Bastian Blank wa...@debian.org diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 04a8061..99d3564 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -149,7 +149,7 @@ menu CPU Frequency drivers config CPU_FREQ_PMAC bool Support for Apple PowerBooks - depends on ADB_PMU PPC32 + depends on ADB_PMU PPC32 !SMP select CPU_FREQ_TABLE help This adds support for frequency switching on Apple PowerBooks, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
On Aug 11, 2009, at 4:04 AM, Felix Radensky wrote:
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky fe...@embedded-sol.com
---
arch/powerpc/sysdev/mpc8xxx_gpio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/
sysdev/mpc8xxx_gpio.c
index 103eace..0b996f3 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -56,9 +56,13 @@ static void mpc8xxx_gpio_save_regs(struct
of_mm_gpio_chip *mm)
static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
+ u32 val;
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR);
it would be good to add a comment in the code about working around the
errata.
- return in_be32(mm-regs + GPIO_DAT) mpc8xxx_gpio2mask(gpio);
+ return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio);
}
static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int
gpio, int val)
--
1.5.4.3
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Added 36-bit physical device tree for mpc8572ds board
On Aug 11, 2009, at 2:18 AM, Felix Radensky wrote: Hi, Kumar Patch subject does not match the contents. The patch is about mpc8536ds. Felix. Oops, copy/paste error on my part. The subject is the one that is wrong. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
On Aug 7, 2009, at 10:35 AM, Poonam Aggrwal wrote:
+ enet2: ether...@26000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 2;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 0x26000 0x1000;
+ ranges = 0x0 0x26000 0x1000;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = 31 2 32 2 33 2;
+ interrupt-parent = mpic;
+ phy-handle = phy1;
+ phy-connection-type = rgmii-id;
+ };
was there an answer to why we don't have an mdio node for enet2?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/2] 82xx, mgcoge: update defconfig for 2.6.32
On Aug 7, 2009, at 1:41 AM, Heiko Schocher wrote: - add I2C support - add FCC1 and FCC2 support Signed-off-by: Heiko Schocher h...@denx.de --- - against git://git.kernel.org/pub/scm/linux/kernel/git/galak/ powerpc.git next branch - checked with checkpatch.pl: $ ./scripts/checkpatch.pl 0001-82xx-mgcoge-update-defconfig- for-2.6.32.patch total: 0 errors, 0 warnings, 134 lines checked 0001-82xx-mgcoge-update-defconfig-for-2.6.32.patch has no obvious style problems and is ready for submission. $ thanks for respinning. Applied to next. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 7/7] powerpc/85xx: Add eSDHC support for MPC8536DS boards
On Aug 7, 2009, at 2:58 PM, Anton Vorontsov wrote: This patch simply adds sdhci node to the device tree. We specify clock-frequency manually, so that eSDHC will work without upgrading U-Boot. Though, that'll only work for default setup (1500 MHz) on new board revisions. For non-default setups, it's recommended to upgrade U-Boot, since it will fixup clock-frequency automatically. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/boot/dts/mpc8536ds.dts |8 1 files changed, 8 insertions(+), 0 deletions(-) Can you update the mpc8536ds_36b.dts as well (its in my next branch) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
On Aug 11, 2009, at 8:44 AM, Anton Vorontsov wrote:
On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky fe...@embedded-sol.com
---
arch/powerpc/sysdev/mpc8xxx_gpio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/
sysdev/mpc8xxx_gpio.c
index 103eace..0b996f3 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -56,9 +56,13 @@ static void mpc8xxx_gpio_save_regs(struct
of_mm_gpio_chip *mm)
static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
+ u32 val;
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs +
GPIO_DIR);
Are you sure about ?
Plus, this are two reads instead of just one. I think it'll be better
to implement mpc8536_gpio_get(), and then do
if (of_device_is_compatible(np, ... 8536-gpio-bank ...))
gc-get = mpc8536_gpio_get;
else
gc-get = mpc8xxx_gpio_get;
I think 8572 has the same errata.
- return in_be32(mm-regs + GPIO_DAT) mpc8xxx_gpio2mask(gpio);
+ return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio);
}
static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int
gpio, int val)
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Tuesday, August 11, 2009 7:11 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-...@ozlabs.org
Subject: Re: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
On Aug 7, 2009, at 10:35 AM, Poonam Aggrwal wrote:
+ enet2: ether...@26000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 2;
+ device_type = network;
+ model = eTSEC;
+ compatible = gianfar;
+ reg = 0x26000 0x1000;
+ ranges = 0x0 0x26000 0x1000;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = 31 2 32 2 33 2;
+ interrupt-parent = mpic;
+ phy-handle = phy1;
+ phy-connection-type = rgmii-id;
+ };
was there an answer to why we don't have an mdio node for enet2?
Yes I already replied to it, actually the enet2 (eTSEC3) on RDB is only
exposed as RGMII, and the mdio lines it will use is those of enet0. In
case it also could be configured in SGMII(as in P2020DS), then we would
have needed the mdio node for enet2 to configure the TBI PHY.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
Anton Vorontsov wrote:
On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky fe...@embedded-sol.com
---
arch/powerpc/sysdev/mpc8xxx_gpio.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c
b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 103eace..0b996f3 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -56,9 +56,13 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip
*mm)
static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
+ u32 val;
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR);
Are you sure about ?
No, that's obviously a typo. Bitwise intended.
Plus, this are two reads instead of just one. I think it'll be better
to implement mpc8536_gpio_get(), and then do
if (of_device_is_compatible(np, ... 8536-gpio-bank ...))
gc-get = mpc8536_gpio_get;
else
gc-get = mpc8xxx_gpio_get;
The reads are from 2 different registers, how do you propose to replace
them by a single read ?
I'll implement mpc8572_gpio_get(), suitable for both 8572 and 8536.
- return in_be32(mm-regs + GPIO_DAT) mpc8xxx_gpio2mask(gpio);
+ return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio);
}
static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
Thanks,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Workaround MPC8536 GPIO 1 errata.
On Tue, Aug 11, 2009 at 06:12:12PM +0300, Felix Radensky wrote: [...] Plus, this are two reads instead of just one. I think it'll be better to implement mpc8536_gpio_get(), and then do if (of_device_is_compatible(np, ... 8536-gpio-bank ...)) gc-get = mpc8536_gpio_get; else gc-get = mpc8xxx_gpio_get; The reads are from 2 different registers, how do you propose to replace them by a single read ? I didn't propose that, I proposed to not do 2 reads for CPUs that don't have the errata. ;-) I'll implement mpc8572_gpio_get(), suitable for both 8572 and 8536. Great, 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: need help getting SPI controller working on 405EX
This is good news. Can you point me towards the patch for that? Nathan On Tue, 2009-08-11 at 01:44 -0400, Stefan Roese wrote: On Monday 10 August 2009 18:07:15 Nathan French wrote: At least something similar worked for me some months ago (before we switched to a real driver for some custom peripheral). Did this work on a 4xx PowerPC platform? Or something else? I've been told that there is no SPI driver for 4xx. If you have done this on 4xx then I'm very interested. The 4xx SPI driver is (finally) queued for 2.6.32. So you either need to manually apply it now or wait a while. Best regards, Stefan ___ 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: need help getting SPI controller working on 405EX
On Tuesday 11 August 2009 17:59:26 Nathan French wrote: This is good news. Can you point me towards the patch for that? Sure. Latest version is: [PATCH v8] spi: Add PPC4xx SPI driver: http://article.gmane.org/gmane.linux.ports.ppc64.devel/57940 Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
cross compiling wind river linux for ppc architecture
Hi, Am trying to compile my WRL 2.6.21 kernel for PPC architecture. The processor am using is AMCC powerpc 440EP . I just built the file system by running the configure command with --enable-rootfs=glibc-small and --enable-cpu-ppc-440 and i got a cross compiler. I took the linux kernel image and updated the PATH variable to the path of my cross compiler.I did a make with ARCH=powerpc and CROSS_COMPILER=/my cross compiler,except gcc/. When I try to do this I get the following error. arch/powerpc/mm/44x_mmu.c: In function 'mmu_mapin_ram': arch/powerpc/mm/44x_mmu.c:106: error: 'PPC_PIN_SIZE' undeclared (first use in this function) arch/powerpc/mm/44x_mmu.c:106: error: (Each undeclared identifier is reported only once arch/powerpc/mm/44x_mmu.c:106: error: for each function it appears in.) arch/powerpc/mm/44x_mmu.c:106: error: 'PPC44x_PIN_SHIFT' undeclared (first use in this function) arch/powerpc/mm/44x_mmu.c:109: error: 'PPC44x_LOW_SLOT' undeclared (first use in this function) make[1]: *** [arch/powerpc/mm/44x_mmu.o] Error 1 make: *** [arch/powerpc/mm] Error 2 It ll be very helpful for me if I could get a solution for this. Regards Sridhar M ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
On Mon, Aug 10, 2009 at 05:22:17PM -0700, Pallipadi, Venkatesh wrote: Also, I don't think using just the ACPI/BIOS supplied states in _CST is right thing to do for offline. _CST is meant for C-state and BIOS may not include some C-state in _CST if the system manufacturer thinks that the latency is too high for the state to be used as a C-state. That limitation applies for C-state as the cpu is expected to come out of C-state often and execute code handle interrupts etc. But, that restriction does not apply for offline online which is not as frequent as C-state entry and it already has big latency with startup IPI, and a whole baggage of CPU setup code. So, using BIOS CST info for CPU offline state doesn't seem right. May be having (to pick a number) 3 possible offline states for all platforms with one for halt equivalent and one for deepest possible that CPU can handle and one for deepest possible that platform likes for C-states may make sense. Will keeps things simpler in terms of usage expectations and possibly reduce the misuse oppurtubity? Yes, I think we should let specific archs advertise a small set of possible offline states and let the cpu state be set to one of those only keeping the platform implementation robust. Here is variant of the original proposal from Gautham - /sys/devices/system/cpu/cpunumber/available_states For example, available state for an Intel platform could be exported as online dealloc C1 C6 online = fully up dealloc = offline and de-allocated (as in virtualized environment) C1 = C1 or C1E halt C6 = C6 sleep /sys/devices/system/cpu/cpunumber/state Writing any of the available states to this file triggers transition to that state barring some transitions that are disallowed to keep things simple (e.g. dealloc cpus support only transition to online). /sys/devices/system/cpu/cpunumber/online Backward compatibility - online = 0 changes state to C6 or dealloc depending on the platform. online = 1 changes state to online. Would this make sense ? Thanks Dipankar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cross compiling wind river linux for ppc architecture
On Tue, Aug 11, 2009 at 10:09 AM, Sridhar Mahadevanmsridha...@gmail.com wrote: Hi, Am trying to compile my WRL 2.6.21 kernel for PPC architecture. The processor am using is AMCC powerpc 440EP . This isn't really the best choice of forum for trying to get help like this. Most of the people here are focused on working with the latest development kernels, and won't have the time to go back and look at year-old kernels based on the now removed PPC architecture. Plus they won't necessarily have any knowledge of what the WRL specific changes may or may not contain. If you have the opportunity to do so, the best choice for you would be to go through the normal WR support channels with full details of your problem. At a glance, it looks like you are trying to build with ARCH=powerpc, and yet I don't think (from memory) that the 4xx boards had migrated from ARCH=ppc until sometime around the 2.6.24-ish timeframe. Paul. I just built the file system by running the configure command with --enable-rootfs=glibc-small and --enable-cpu-ppc-440 and i got a cross compiler. I took the linux kernel image and updated the PATH variable to the path of my cross compiler.I did a make with ARCH=powerpc and CROSS_COMPILER=/my cross compiler,except gcc/. When I try to do this I get the following error. arch/powerpc/mm/44x_mmu.c: In function 'mmu_mapin_ram': arch/powerpc/mm/44x_mmu.c:106: error: 'PPC_PIN_SIZE' undeclared (first use in this function) arch/powerpc/mm/44x_mmu.c:106: error: (Each undeclared identifier is reported only once arch/powerpc/mm/44x_mmu.c:106: error: for each function it appears in.) arch/powerpc/mm/44x_mmu.c:106: error: 'PPC44x_PIN_SHIFT' undeclared (first use in this function) arch/powerpc/mm/44x_mmu.c:109: error: 'PPC44x_LOW_SLOT' undeclared (first use in this function) make[1]: *** [arch/powerpc/mm/44x_mmu.o] Error 1 make: *** [arch/powerpc/mm] Error 2 It ll be very helpful for me if I could get a solution for this. Regards Sridhar M ___ 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: cross compiling wind river linux for ppc architecture
On Tue, Aug 11, 2009 at 05:42:26PM -0400, Paul Gortmaker wrote: On Tue, Aug 11, 2009 at 10:09 AM, Sridhar Mahadevanmsridha...@gmail.com wrote: Hi, Am trying to compile my WRL 2.6.21 kernel for PPC architecture. The processor am using is AMCC powerpc 440EP . This isn't really the best choice of forum for trying to get help like this. Most of the people here are focused on working with the latest development kernels, and won't have the time to go back and look at year-old kernels based on the now removed PPC architecture. Plus they won't necessarily have any knowledge of what the WRL specific changes may or may not contain. If you have the opportunity to do so, the best choice for you would be to go through the normal WR support channels with full details of your problem. At a glance, it looks like you are trying to build with ARCH=powerpc, and yet I don't think (from memory) that the 4xx boards had migrated from ARCH=ppc until sometime around the 2.6.24-ish timeframe. Basic support was in 2.6.22. 440EP was in 2.6.24. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem with PCIe - PCI bridge on MPC8377E-RDB
Hey Folks, I have been trying to use a PCIe FireWire card on a MPC8377E-RDB board. I have tried this with both the LTIB/BSP (2.6.25) and the head of the kernel.org tree (at least from a couple of days ago). With 2.6.25, the PCIe buss(es) don't show up at all during boot. With 2.6.31-rc? the PCIe busses do show up, and the PCIe - PCI bridge is recognized, but no devices behind the bridge are probed or identified. Here is the boot log: [0.00] Linux version 2.6.31-rc5-00381-g7b2aa03-dirty (adminu...@debian.virtualboximages ) (gcc version 4.3.2 (Sourcery G++ Lite 4.3-74) ) #32 Tue Aug 11 17:32:27 EDT 2009 [0.00] console [udbg0] enabled setup_arch: bootmem mpc837x_rdb_setup_arch() [0.00] Found FSL PCI host bridge at 0xe0008500. Firmware bus number: 0-0 [0.00] PCI host bridge /p...@e0008500 (primary) ranges: [0.00] MEM 0x9000..0x9fff - 0x9000 [0.00] MEM 0x8000..0x8fff - 0x8000 Prefetch [0.00] IO 0xe030..0xe03f - 0x [0.00] No pci config register base in dev tree, using default [0.00] Found FSL PCI host bridge at 0xe0009000. Firmware bus number: 0-255 [0.00] PCI host bridge /p...@e0009000 ranges: [0.00] MEM 0xa800..0xb7ff - 0xa800 [0.00] IO 0xb800..0xb87f - 0x [0.00] No pci config register base in dev tree, using default [0.00] Found FSL PCI host bridge at 0xe000a000. Firmware bus number: 0-255 [0.00] PCI host bridge /p...@e000a000 ranges: [0.00] MEM 0xc800..0xd7ff - 0xc800 [0.00] IO 0xd800..0xd87f - 0x [...] [0.129452] PCI: Probing PCI hardware [0.133549] pci :00:00.0: PME# supported from D0 D1 D2 D3hot [0.139448] pci :00:00.0: PME# disabled [0.143727] pci :00:0f.0: PME# supported from D0 D1 D2 D3hot [0.149624] pci :00:0f.0: PME# disabled [0.154791] pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01) [0.162100] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot [0.168057] pci 0001:01:00.0: PME# disabled [0.202566] pci 0001:03:00.0: PCI bridge, secondary bus 0001:04 [0.208477] pci 0001:03:00.0: IO window: disabled [0.213311] pci 0001:03:00.0: MEM window: disabled [0.218170] pci 0001:03:00.0: PREFETCH window: disabled [0.223528] pci 0001:03:01.0: PCI bridge, secondary bus 0001:05 [0.229399] pci 0001:03:01.0: IO window: disabled [0.234239] pci 0001:03:01.0: MEM window: disabled [0.239163] pci 0001:03:01.0: PREFETCH window: disabled [0.244522] pci 0001:03:02.0: PCI bridge, secondary bus 0001:06 [0.250394] pci 0001:03:02.0: IO window: disabled [0.255234] pci 0001:03:02.0: MEM window: disabled [0.260158] pci 0001:03:02.0: PREFETCH window: disabled [0.265517] pci 0001:03:03.0: PCI bridge, secondary bus 0001:07 [0.271389] pci 0001:03:03.0: IO window: disabled [0.276229] pci 0001:03:03.0: MEM window: disabled [0.281153] pci 0001:03:03.0: PREFETCH window: disabled [0.286513] pci 0001:03:04.0: PCI bridge, secondary bus 0001:08 [0.292384] pci 0001:03:04.0: IO window: disabled [0.297224] pci 0001:03:04.0: MEM window: disabled [0.302149] pci 0001:03:04.0: PREFETCH window: disabled [0.307508] pci 0001:03:05.0: PCI bridge, secondary bus 0001:09 [0.313380] pci 0001:03:05.0: IO window: disabled [0.318220] pci 0001:03:05.0: MEM window: disabled [0.323144] pci 0001:03:05.0: PREFETCH window: disabled [0.328503] pci 0001:03:06.0: PCI bridge, secondary bus 0001:0a [0.334375] pci 0001:03:06.0: IO window: disabled [0.339215] pci 0001:03:06.0: MEM window: disabled [0.344139] pci 0001:03:06.0: PREFETCH window: disabled [0.349498] pci 0001:03:07.0: PCI bridge, secondary bus 0001:0b [0.355370] pci 0001:03:07.0: IO window: disabled [0.360210] pci 0001:03:07.0: MEM window: disabled [0.365134] pci 0001:03:07.0: PREFETCH window: disabled [0.370493] pci 0001:03:08.0: PCI bridge, secondary bus 0001:0c [0.376365] pci 0001:03:08.0: IO window: disabled [0.381205] pci 0001:03:08.0: MEM window: disabled [0.386129] pci 0001:03:08.0: PREFETCH window: disabled [0.391489] pci 0001:03:09.0: PCI bridge, secondary bus 0001:0d [0.397360] pci 0001:03:09.0: IO window: disabled [0.402200] pci 0001:03:09.0: MEM window: disabled [0.407125] pci 0001:03:09.0: PREFETCH window: disabled [0.412484] pci 0001:03:0a.0: PCI bridge, secondary bus 0001:0e [0.418356] pci 0001:03:0a.0: IO window: disabled [0.423196] pci 0001:03:0a.0: MEM window: disabled [0.428120] pci 0001:03:0a.0: PREFETCH
Re: Problem with PCIe - PCI bridge on MPC8377E-RDB
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote: So it seems like the XIO2000(A) is being misconfigured or misidentified, and rather than finding the configured bus behind the bridge, it is doing something else, and as a result, not finding the PCI OHCI FireWire controller on the PCI side of the bridge. Unfortunately I have no real idea where to start looking at this... Any ideas? Or is there a better place to be posting about this? This is a reasonable place to post this. Can you see what u-boot reports for its PCI/e bus scan? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCIe - PCI bridge on MPC8377E-RDB
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote: I have been trying to use a PCIe FireWire card on a MPC8377E-RDB board. is this an off the shelf PCIe FireWire card? If so which one? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCIe - PCI bridge on MPC8377E-RDB
On Aug 11, 2009, at 9:43 PM, Kumar Gala wrote: On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote: So it seems like the XIO2000(A) is being misconfigured or misidentified, and rather than finding the configured bus behind the bridge, it is doing something else, and as a result, not finding the PCI OHCI FireWire controller on the PCI side of the bridge. Unfortunately I have no real idea where to start looking at this... Any ideas? Or is there a better place to be posting about this? This is a reasonable place to post this. Can you see what u-boot reports for its PCI/e bus scan? Thanks, This is what u-boot says: U-Boot 1.3.3 (Jun 19 2008 - 10:47:48) MPC83XX Reset Status: Software Hard, External/Internal Soft, External/Internal Hard CPU: e300c4, MPC8377E, Rev: 1.0 at 666.666 MHz, CSB: 333.333 MHz Board: Freescale MPC837xERDB I2C: ready DRAM: 256 MB PCIE0: Link PCIE1: No link FLASH: 8 MB NAND: 32 MiB In:serial Out: serial Err: serial Net: TSEC0, TSEC1 eSDHC: No SD/MMC card found SATA: SATA0 (No RDY) SATA1 (No RDY) Hit any key to stop autoboot: 0 = set serverip 10.0.1.40 = run tftpnfsboot If there is additional information to be found, I'd be happy to collect it. Best regards, B.J. Buchalter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCIe - PCI bridge on MPC8377E-RDB
On Aug 11, 2009, at 9:43 PM, Kumar Gala wrote: On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote: I have been trying to use a PCIe FireWire card on a MPC8377E-RDB board. is this an off the shelf PCIe FireWire card? Yes. If so which one? I don't know the model of the board off the top of my head. I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind the bridge. The same board definitely works as expected in a Mac Pro. In doing some Google searches about this, I have seen the TI part listed in the PCI configuration of folks running linux (though probably on Intel) and apparently having no problems with the busses behind the bridge being enumerated. I am guessing that the problem is related the the PCIe root complex on the 8377, but I am just guessing. Is PCIe known to work on the MPC837x? Thanks! B.J. Buchalter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] spi: Prefix modalias with spi:
On Wed, Jul 29, 2009 at 13:05, Anton Vorontsov wrote: This makes it consistent with other buses (platform, i2c, vio, ...). I'm not sure why we use the prefixes, but there must be a reason. This was easy enough to do it, and I did it. acked-by-me for misc blackfin/adi drivers, thanks -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCIe - PCI bridge on MPC8377E-RDB
On Aug 11, 2009, at 10:25 PM, B.J. Buchalter wrote: I don't know the model of the board off the top of my head. I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind the bridge. The same board definitely works as expected in a Mac Pro. In doing some Google searches about this, I have seen the TI part listed in the PCI configuration of folks running linux (though probably on Intel) and apparently having no problems with the busses behind the bridge being enumerated. I am guessing that the problem is related the the PCIe root complex on the 8377, but I am just guessing. Is PCIe known to work on the MPC837x? It is suppose to. I would recommend updating u-boot to something newer and see what you get on that side. Also I'll try see if we have a PCIe board w/a p2p bridge on it. I'm guessing no one has tried PCIe on 83xx w/a p2p bridge on it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Workaround MPC8572/MPC8536 GPIO 1 errata.
On MPC8572 and MPC8536 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky fe...@embedded-sol.com
---
arch/powerpc/sysdev/mpc8xxx_gpio.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c
b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 103eace..ee1c0e1 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -54,6 +54,22 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip
*mm)
mpc8xxx_gc-data = in_be32(mm-regs + GPIO_DAT);
}
+/* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs
+ * defined as output cannot be determined by reading GPDAT register,
+ * so we use shadow data register instead. The status of input pins
+ * is determined by reading GPDAT register.
+ */
+static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ u32 val;
+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
+
+ val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR);
+
+ return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio);
+}
+
static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
@@ -136,7 +152,10 @@ static void __init mpc8xxx_add_controller(struct
device_node *np)
gc-ngpio = MPC8XXX_GPIO_PINS;
gc-direction_input = mpc8xxx_gpio_dir_in;
gc-direction_output = mpc8xxx_gpio_dir_out;
- gc-get = mpc8xxx_gpio_get;
+ if (of_device_is_compatible(np, fsl,mpc8572-gpio))
+ gc-get = mpc8572_gpio_get;
+ else
+ gc-get = mpc8xxx_gpio_get;
gc-set = mpc8xxx_gpio_set;
ret = of_mm_gpiochip_add(np, mm_gc);
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
