Windfarm's max6690 sensor driver was not included in makefile
Hello, I had problems with fan speed in my XServe G5. It turned out drivers/macintosh/Makefile has a max6690 module missing from compilation list. I was advised to mail the patch to you guys. I'm not sure what's the proper format of the patch to be submitten (this is my first time). So I'm including it into the message body, and as an attached file. diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile index 6753b65..d2f0120 100644 --- a/drivers/macintosh/Makefile +++ b/drivers/macintosh/Makefile @@ -40,6 +40,7 @@ obj-$(CONFIG_WINDFARM_RM31) += windfarm_fcu_controls.o \ windfarm_ad7417_sensor.o \ windfarm_lm75_sensor.o \ windfarm_lm87_sensor.o \ + windfarm_max6690_sensor.o \ windfarm_pid.o \ windfarm_cpufreq_clamp.o \ windfarm_rm31.o Thank you. Stanislav Ponomarev. index 6753b65..d2f0120 100644 --- a/drivers/macintosh/Makefile +++ b/drivers/macintosh/Makefile @@ -40,6 +40,7 @@ obj-$(CONFIG_WINDFARM_RM31) += windfarm_fcu_controls.o \ windfarm_ad7417_sensor.o \ windfarm_lm75_sensor.o \ windfarm_lm87_sensor.o \ + windfarm_max6690_sensor.o \ windfarm_pid.o \ windfarm_cpufreq_clamp.o \ windfarm_rm31.o ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
On Fri, 22 Nov 2013, Scott Wood wrote: > This sounds like an incompatible change to userspace API. What about > older glibc? What about user code that directly manipulates these bits > rather than going through libc, or uses a libc other than glibc? Where > is this API requirement documented? The previous EGLIBC port, and the uClibc code copied from it, is fundamentally broken as regards any use of prctl for floating-point exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its prctl calls (and did various worse things, such as passing a pointer when prctl expected an integer). If you avoid anything where prctl is used, the clearing of sticky bits still means it will never give anything approximating correct exception semantics with existing kernels. I don't believe the patch makes things any worse for existing code that doesn't try to inform the kernel of changes to sticky bits - such code may get incorrect exceptions in some cases, but it would have done so anyway in other cases. This is the best API I could come up with to fix the fundamentally broken nature of what came before, taking into account that in many cases a prctl call is already needed along with userspace manipulation of exception bits. I'm not aware of any kernel documentation where this sort of subarchitecture-specific API detail is documented. (The API also includes such things as needing to leave the spefscr trap-enable bits set and use prctl to control whether SIGFPE results from exceptions.) > I think the impact of this could be reduced by using this mechanism only > to clear bits, rather than set them. That is, if the exception bit is > unset, don't set it just because it's set in spefscr_last -- but if it's > not set in spefscr_last, and the emulation code doesn't want to set it, > then clear it. It should already be the case in this patch that if a bit is clear in spefscr, and set in spefscr_last (i.e. userspace did not inform the kernel of clearing the bit, and no traps since then have resulted in the kernel noticing it was cleared), it won't get set unless the emulation code wants to set it. The sole place spefscr_last is read is in the statement "__FPU_FPSCR &= ~(FP_EX_INVALID | FP_EX_UNDERFLOW) | current->thread.spefscr_last;" - if the bit is already clear in spefscr, this statement has no effect on it. > Are there any cases where the exception bit can be set without the > kernel taking a trap, or is userspace manipulation limited to clearing > the bits? Userspace can both set and clear the bits without a trap. For example, fesetenv restores a saved value of spefscr which may both set and clear bits (and then it calls prctl because it needs to do so anyway to restore the saved state for which exceptions were enabled). fesetexceptflag restores saved state of particular exceptions without a trap (so needs to call prctl specially to inform the kernel of a change). -- Joseph S. Myers jos...@codesourcery.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
eth0: hw csum failure
I get a lot of "eth0: hw csum failure" with 3.13-rc1 on my G5. eth0: hw csum failure CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1 #1 Call Trace: [cffef1d0] [c000f97c] .show_stack+0x60/0x14c (unreliable) [cffef2a0] [c069fad8] .dump_stack+0x80/0xa0 [cffef320] [c0552bc0] .netdev_rx_csum_fault+0x4c/0x58 [cffef3a0] [c0546f88] .__skb_checksum_complete_head+0x54/0x78 [cffef420] [c05f1118] .nf_ip_checksum+0xf4/0x100 [cffef4b0] [c058e520] .udp_error+0x198/0x210 [cffef560] [c0587694] .nf_conntrack_in+0x14c/0xa20 [cffef690] [c05f195c] .ipv4_conntrack_in+0x24/0x38 [cffef700] [c058343c] .nf_iterate+0x64/0xb4 [cffef7c0] [c058353c] .nf_hook_slow+0xb0/0x188 [cffef890] [c059ea9c] .ip_rcv+0x390/0x3f0 [cffef930] [c0551578] .__netif_receive_skb_core+0x8c4/0x964 [cffefa30] [c0551c38] .netif_receive_skb+0xb0/0x130 [cffefae0] [c0552740] .napi_gro_receive+0x50/0xc0 [cffefb60] [c0447754] .gem_poll+0x10f0/0x1328 [cffefcc0] [c0552418] .net_rx_action+0xd8/0x240 [cffefd90] [c004dfc4] .__do_softirq+0x158/0x2c0 [cffefea0] [c004e448] .irq_exit+0x6c/0xc4 [cffeff10] [c000ce14] .__do_irq+0xec/0xf8 [cffeff90] [c0019474] .call_do_irq+0x14/0x24 [c001f615ba30] [c000cea0] .do_IRQ+0x80/0xc0 [c001f615bac0] [c00024b8] hardware_interrupt_common+0x138/0x180 --- Exception: 501 at .arch_cpu_idle+0x78/0x124 LR = .arch_cpu_idle+0x78/0x124 [c001f615bdb0] [c00a3af4] .rcu_idle_enter+0x98/0xb8 (unreliable) [c001f615be30] [c009a978] .cpu_startup_entry+0x110/0x1a0 [c001f615bee0] [c001f14c] .start_secondary+0x288/0x290 [c001f615bf90] [c00087fc] .start_secondary_prolog+0x10/0x14 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Pull request: scottwood/linux.git
The corenet64 patch fixes a regression introduced in 3.13-rc1 (commit
ef1313deafb7baa6d3382044e962d5ad5e8c8dd6, "powerpc: Add VMX optimised xor
for RAID5").
The 8xx patch fixes a regression introduced in 3.12 (commit
beb2dc0a7a84be003ce54e98b95d65cc66e6e536, "powerpc: Convert some
mftb/mftbu into mfspr").
The other two patches are fixes for minor, long standing bugs.
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
for you to fetch changes up to d742aa152f27448d39ce65fb829e396d10cd63a9:
powerpc/booke: Only check for hugetlb in flush if vma != NULL (2013-11-22
16:57:29 -0600)
Adam Borowski (1):
powerpc/85xx: typo in dts: "interupt" (four devices)
LEROY Christophe (1):
powerpc/8xx: mfspr SPRN_TBRx in lieu of mftb/mftbu is not supported
Scott Wood (1):
powerpc/booke: Only check for hugetlb in flush if vma != NULL
Tiejun Chen (1):
powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU well
arch/powerpc/Makefile | 5 +
arch/powerpc/boot/dts/xcalibur1501.dts| 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
arch/powerpc/boot/util.S | 14 ++
arch/powerpc/include/asm/ppc_asm.h| 2 ++
arch/powerpc/include/asm/reg.h| 7 +++
arch/powerpc/include/asm/timex.h | 8
arch/powerpc/kernel/vdso32/gettimeofday.S | 6 ++
arch/powerpc/mm/hugetlbpage-book3e.c | 3 +--
arch/powerpc/mm/tlb_nohash.c | 2 +-
12 files changed, 52 insertions(+), 11 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
On Mon, 2013-11-04 at 16:52 +, Joseph S. Myers wrote: > From: Joseph Myers > > The e500 SPE floating-point emulation code clears existing exceptions > (__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the > emulated operation. However, these exception bits are the "sticky", > cumulative exception bits, and should only be cleared by the user > program setting SPEFSCR, not implicitly by any floating-point > instruction (whether executed purely by the hardware or emulated). > The spurious clearing of these bits shows up as missing exceptions in > glibc testing. > > Fixing this, however, is not as simple as just not clearing the bits, > because while the bits may be from previous floating-point operations > (in which case they should not be cleared), the processor can also set > the sticky bits itself before the interrupt for an exception occurs, > and this can happen in cases when IEEE 754 semantics are that the > sticky bit should not be set. Specifically, the "invalid" sticky bit > is set in various cases with non-finite operands, where IEEE 754 > semantics do not involve raising such an exception, and the > "underflow" sticky bit is set in cases of exact underflow, whereas > IEEE 754 semantics are that this flag is set only for inexact > underflow. Thus, for correct emulation the kernel needs to know the > setting of these two sticky bits before the instruction being > emulated. > > When a floating-point operation raises an exception, the kernel can > note the state of the sticky bits immediately afterwards. Some > functions that affect the state of these bits, such as > fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and > PR_SET_FPEXC anyway, and so it is natural to record the state of those > bits during that call into the kernel and so avoid any need for a > separate call into the kernel to inform it of a change to those bits. > Thus, the interface I chose to use (in this patch and the glibc port) > is that one of those prctl calls must be made after any userspace > change to those sticky bits, other than through a floating-point > operation that traps into the kernel anyway. This sounds like an incompatible change to userspace API. What about older glibc? What about user code that directly manipulates these bits rather than going through libc, or uses a libc other than glibc? Where is this API requirement documented? I think the impact of this could be reduced by using this mechanism only to clear bits, rather than set them. That is, if the exception bit is unset, don't set it just because it's set in spefscr_last -- but if it's not set in spefscr_last, and the emulation code doesn't want to set it, then clear it. Are there any cases where the exception bit can be set without the kernel taking a trap, or is userspace manipulation limited to clearing the bits? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/8] IBM Akebono: Add support to AHCI platform driver
Hello, On Thu, Nov 21, 2013 at 9:08 PM, Alistair Popple wrote: > The new IBM Akebono board has a PPC476GTR SoC with an AHCI compliant > SATA controller. This patch adds a compatible property for the new SoC > to the AHCI platform driver. > > Signed-off-by: Alistair Popple Applied to libata/for-3.13-fixes w/ stable cc'd. Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Nov 22, 2013, at 2:12 AM, Liu Gang wrote: > For MPC8572/MPC8536, the status of GPIOs defined as output > cannot be determined by reading GPDAT register, so the code > use shadow data register instead. But the code may give the > wrong status of GPIOs defined as input under some scenarios: > > 1. If some pins were configured as inputs and were asserted > high before booting the kernel, the shadow data has been > initialized with those pin values. > 2. Some pins have been configured as output first and have > been set to the high value, then reconfigured as input. > > The above cases will make the shadow data for those input > pins to be set to high. Then reading the pin status will > always return high even if the actual pin status is low. > > The code should eliminate the effects of the shadow data to > the input pins, and the status of those pins should be > read directly from GPDAT. > > Signed-off-by: Liu Gang > --- > changes in v2: > - Added more description of the problem. > - Reduced one in_be32() call. > - Do not modify the shadow data. > > drivers/gpio/gpio-mpc8xxx.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c > index 914e859..d7d6d72 100644 > --- a/drivers/gpio/gpio-mpc8xxx.c > +++ b/drivers/gpio/gpio-mpc8xxx.c > @@ -70,10 +70,14 @@ 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); > + u32 out_mask, out_shadow; > > - val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); > + out_mask = in_be32(mm->regs + GPIO_DIR); > > - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); > + val = in_be32(mm->regs + GPIO_DAT) & ~out_mask; > + out_shadow = mpc8xxx_gc->data & out_mask; > + > + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio); > } I really think a comment is worth adding here about why we do this. - k > > static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio) > -- > 1.8.4.1 > > > ___ > 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: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Fri, 2013-11-22 at 16:12 +0800, Liu Gang wrote: > For MPC8572/MPC8536, the status of GPIOs defined as output > cannot be determined by reading GPDAT register, so the code > use shadow data register instead. But the code may give the > wrong status of GPIOs defined as input under some scenarios: > > 1. If some pins were configured as inputs and were asserted > high before booting the kernel, the shadow data has been > initialized with those pin values. > 2. Some pins have been configured as output first and have > been set to the high value, then reconfigured as input. > > The above cases will make the shadow data for those input > pins to be set to high. Then reading the pin status will > always return high even if the actual pin status is low. > > The code should eliminate the effects of the shadow data to > the input pins, and the status of those pins should be > read directly from GPDAT. > > Signed-off-by: Liu Gang > --- > changes in v2: > - Added more description of the problem. > - Reduced one in_be32() call. > - Do not modify the shadow data. > > drivers/gpio/gpio-mpc8xxx.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c > index 914e859..d7d6d72 100644 > --- a/drivers/gpio/gpio-mpc8xxx.c > +++ b/drivers/gpio/gpio-mpc8xxx.c > @@ -70,10 +70,14 @@ 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); > + u32 out_mask, out_shadow; > > - val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); > + out_mask = in_be32(mm->regs + GPIO_DIR); > > - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); > + val = in_be32(mm->regs + GPIO_DAT) & ~out_mask; > + out_shadow = mpc8xxx_gc->data & out_mask; > + > + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio); > } > > static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio) Acked-by: Scott Wood -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc 8xx: defconfig: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx.
On PPC_8xx, CRC32_SLICEBY4 is more efficient (almost twice) than CRC32_SLICEBY8, as shown below: With CRC32_SLICEBY8: [1.109204] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64 [1.114401] crc32: self tests passed, processed 225944 bytes in 15118910 nsec [1.130655] crc32c: CRC_LE_BITS = 64 [1.134235] crc32c: self tests passed, processed 225944 bytes in 4479879 nsec With CRC32_SLICEBY4: [1.097129] crc32: CRC_LE_BITS = 32, CRC_BE BITS = 32 [1.101878] crc32: self tests passed, processed 225944 bytes in 8616242 nsec [1.116298] crc32c: CRC_LE_BITS = 32 [1.119607] crc32c: self tests passed, processed 225944 bytes in 3289576 nsec Signed-off-by: Christophe Leroy diff -ur a/arch/powerpc/configs/adder875_defconfig b/arch/powerpc/configs.new/adder875_defconfig --- a/arch/powerpc/configs/adder875_defconfig 2013-11-22 18:20:10.342968268 +0100 +++ b/arch/powerpc/configs.new/adder875_defconfig 2013-11-22 18:17:46.499686457 +0100 @@ -70,3 +70,4 @@ CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y # CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_CRC32_SLICEBY4=y diff -ur a/arch/powerpc/configs/ep88xc_defconfig b/arch/powerpc/configs.new/ep88xc_defconfig --- a/arch/powerpc/configs/ep88xc_defconfig 2013-11-22 18:20:10.286961148 +0100 +++ b/arch/powerpc/configs.new/ep88xc_defconfig 2013-11-22 18:17:41.992113565 +0100 @@ -72,3 +72,4 @@ CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y # CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_CRC32_SLICEBY4=y diff -ur a/arch/powerpc/configs/mpc866_ads_defconfig b/arch/powerpc/configs.new/mpc866_ads_defconfig --- a/arch/powerpc/configs/mpc866_ads_defconfig 2013-11-22 18:20:10.323965853 +0100 +++ b/arch/powerpc/configs.new/mpc866_ads_defconfig 2013-11-22 18:17:32.480904735 +0100 @@ -55,3 +55,4 @@ CONFIG_CRC_CCITT=y # CONFIG_RCU_CPU_STALL_DETECTOR is not set # CONFIG_CRYPTO_ANSI_CPRNG is not set +CONFIG_CRC32_SLICEBY4=y diff -ur a/arch/powerpc/configs/mpc885_ads_defconfig b/arch/powerpc/configs.new/mpc885_ads_defconfig --- a/arch/powerpc/configs/mpc885_ads_defconfig 2013-11-22 18:20:10.326966235 +0100 +++ b/arch/powerpc/configs.new/mpc885_ads_defconfig 2013-11-22 18:17:25.760050546 +0100 @@ -78,3 +78,4 @@ CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y # CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_CRC32_SLICEBY4=y diff -ur a/arch/powerpc/configs/tqm8xx_defconfig b/arch/powerpc/configs.new/tqm8xx_defconfig --- a/arch/powerpc/configs/tqm8xx_defconfig 2013-11-22 18:20:10.317965090 +0100 +++ b/arch/powerpc/configs.new/tqm8xx_defconfig 2013-11-22 18:17:14.926673681 +0100 @@ -84,3 +84,4 @@ CONFIG_DETECT_HUNG_TASK=y CONFIG_DEBUG_INFO=y # CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_CRC32_SLICEBY4=y ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc 8xx: mfspr SPRN_TBRx in lieu of mftb/mftbu is not supported
Commit beb2dc0a7a84be003ce54e98b95d65cc66e6e536 breaks the MPC8xx which seems
to not support using mfspr SPRN_TBRx instead of mftb/mftbu despite
what is written in the reference manual
This patchs revert to the use of mftb/mftbu when CONFIG_8xx is selected
Signed-off-by: Christophe Leroy
diff -ur a/arch/powerpc/boot/util.S b/arch/powerpc/boot/util.S
--- a/arch/powerpc/boot/util.S 2013-11-20 21:54:45.0 +0100
+++ b/arch/powerpc/boot/util.S 2013-11-22 17:19:51.880386544 +0100
@@ -71,18 +71,32 @@
add r4,r4,r5
addir4,r4,-1
divwr4,r4,r5/* BUS ticks */
+#ifdef CONFIG_8xx
+1: mftbu r5
+ mftbr6
+ mftbu r7
+#else
1: mfspr r5, SPRN_TBRU
mfspr r6, SPRN_TBRL
mfspr r7, SPRN_TBRU
+#endif
cmpw0,r5,r7
bne 1b /* Get [synced] base time */
addcr9,r6,r4/* Compute end time */
addze r8,r5
+#ifdef CONFIG_8xx
+2: mftbu r5
+#else
2: mfspr r5, SPRN_TBRU
+#endif
cmpw0,r5,r8
blt 2b
bgt 3f
+#ifdef CONFIG_8xx
+ mftbr6
+#else
mfspr r6, SPRN_TBRL
+#endif
cmpw0,r6,r9
blt 2b
3: blr
diff -ur a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
--- a/arch/powerpc/include/asm/ppc_asm.h2013-11-20 21:54:45.0
+0100
+++ b/arch/powerpc/include/asm/ppc_asm.h2013-11-22 17:24:57.839272480
+0100
@@ -438,6 +438,8 @@
cmpwi dest,0; \
beq- 90b; \
END_FTR_SECTION_NESTED(CPU_FTR_CELL_TB_BUG, CPU_FTR_CELL_TB_BUG, 96)
+#elif defined(CONFIG_8xx)
+#define MFTB(dest) mftb dest
#else
#define MFTB(dest) mfspr dest, SPRN_TBRL
#endif
diff -ur a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
--- a/arch/powerpc/include/asm/reg.h2013-11-20 21:54:45.0 +0100
+++ b/arch/powerpc/include/asm/reg.h2013-11-22 17:27:44.009391916 +0100
@@ -1154,12 +1154,19 @@
#else /* __powerpc64__ */
+#if defined(CONFIG_8xx)
+#define mftbl()({unsigned long rval; \
+ asm volatile("mftbl %0" : "=r" (rval)); rval;})
+#define mftbu()({unsigned long rval; \
+ asm volatile("mftbu %0" : "=r" (rval)); rval;})
+#else
#define mftbl()({unsigned long rval; \
asm volatile("mfspr %0, %1" : "=r" (rval) : \
"i" (SPRN_TBRL)); rval;})
#define mftbu()({unsigned long rval; \
asm volatile("mfspr %0, %1" : "=r" (rval) : \
"i" (SPRN_TBRU)); rval;})
+#endif
#endif /* !__powerpc64__ */
#define mttbl(v) asm volatile("mttbl %0":: "r"(v))
diff -ur a/arch/powerpc/include/asm/timex.h b/arch/powerpc/include/asm/timex.h
--- a/arch/powerpc/include/asm/timex.h 2013-11-20 21:54:45.0 +0100
+++ b/arch/powerpc/include/asm/timex.h 2013-11-22 17:29:31.207016228 +0100
@@ -29,7 +29,11 @@
ret = 0;
__asm__ __volatile__(
+#ifdef CONFIG_8xx
+ "97:mftb %0\n"
+#else
"97:mfspr %0, %2\n"
+#endif
"99:\n"
".section __ftr_fixup,\"a\"\n"
".align 2\n"
@@ -41,7 +45,11 @@
" .long 0\n"
" .long 0\n"
".previous"
+#ifdef CONFIG_8xx
+ : "=r" (ret) : "i" (CPU_FTR_601));
+#else
: "=r" (ret) : "i" (CPU_FTR_601), "i" (SPRN_TBRL));
+#endif
return ret;
#endif
}
diff -ur a/arch/powerpc/kernel/vdso32/gettimeofday.S
b/arch/powerpc/kernel/vdso32/gettimeofday.S
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S 2013-11-20 21:54:46.0
+0100
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S 2013-11-22 17:30:53.646493897
+0100
@@ -232,9 +232,15 @@
lwz r6,(CFG_TB_ORIG_STAMP+4)(r9)
/* Get a stable TB value */
+#ifdef CONFIG_8xx
+2: mftbu r3
+ mftbl r4
+ mftbu r0
+#else
2: mfspr r3, SPRN_TBRU
mfspr r4, SPRN_TBRL
mfspr r0, SPRN_TBRU
+#endif
cmplw cr0,r3,r0
bne-2b
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 0/4] Add dual-fifo mode support of i.MX ssi
Hi all, I'm sorry to push this. But this series has been an orphan for a while. Could any one please receive and foster it? Thank you. Nicolin Chen On Wed, Nov 13, 2013 at 10:55:23PM +0800, Nicolin Chen wrote: > * ! This series of patches has a direct dependency between them. When > * ! applying them, we need to apply to one single branch. Otherwise, > * ! it would break currect branches. > > Changelog > v7: > * Appended missing Acked-by to all four patches. > * Sorry that I didn't add them at the first place. > v6: > * PATCH-1: Use goto err_firmware instead of return directly. > * > * Nothing changes for the other three ack-ed patches > v5: > * PATCH-3: Add period size constraint when using dual fifo mode > * > * Nothing changes for the other three patches > v4: > * PATCH-3: Drop useless register configuration. > * > * Nothing changes for the other three patches > v3: > * PATCH-1: Add comments to indicate the end of v1 and v2 array. > * PATCH-3: Use better way to keep watermark as even number. > * > * Nothing changes for PATCH-2 and PATCH-4 > v2: > * Instead of adding rogue scripts to current SDMA driver based on firmware > * V1, we define the new SDMA firmware as version 2 and bisect the PATCH-1 > * to two patches: The first is to add version check code to the SDMA driver; > * And the second is to add SSI dual FIFO DMATYPE. > * > * Nothing changes for the last two patches. > v1: > * SSI can reduce hardware overrun/underrun possibility when using dual > * fifo mode. To support this mode, we need to first update sdma sciprt > * list, and then enable dual fifo BIT in SSI driver, and last update DT > * bindings of i.MX series. > > Nicolin Chen (4): > dma: imx-sdma: Add sdma firmware version 2 support > dma: imx-sdma: Add new dma type for ssi dual fifo script > ASoC: fsl_ssi: Add dual fifo mode support > ARM: dts: imx: use dual-fifo sdma script for ssi > > .../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + > arch/arm/boot/dts/imx51.dtsi | 4 ++-- > arch/arm/boot/dts/imx53.dtsi | 4 ++-- > arch/arm/boot/dts/imx6qdl.dtsi | 12 +- > arch/arm/boot/dts/imx6sl.dtsi | 12 +- > drivers/dma/imx-sdma.c | 19 ++- > include/linux/platform_data/dma-imx-sdma.h | 5 > include/linux/platform_data/dma-imx.h | 1 + > sound/soc/fsl/fsl_ssi.c| 27 > +- > 9 files changed, 67 insertions(+), 18 deletions(-) > > -- > 1.8.4 > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4 v2] powerpc/fsl-booke: Add initial device tree support for T2080/T2081
Add initial device tree for T2080/T2081 without DPAA components.
The T2080 SoC includes the following function and features:
- Four dual-threaded 64-bit Power architecture e6500 cores, up to 1.8GHz
- 2MB L2 cache and 512KB CoreNet platform cache (CPC)
- Hierarchical interconnect fabric
- One 32-/64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- 16 SerDes lanes up to 10.3125 GHz
- 8 Ethernet interfaces (multiple 1G/2.5G/10G MACs)
- High-speed peripheral interfaces
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0)
- Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz
- Additional peripheral interfaces
- Two serial ATA (SATA 2.0) controllers
- Two high-speed USB 2.0 controllers with integrated PHY
- Enhanced secure digital host controller (SD/SDXC/eMMC)
- Enhanced serial peripheral interface (eSPI)
- Four I2C controllers
- Four 2-pin UARTs or two 4-pin UARTs
- Integrated Flash Controller supporting NAND and NOR flash
- Three eight-channel DMA engines
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0
T2081 personality is a reduced personality of T2080 without SATA, sRIO, RMan,
Aurora, and with less SerDes lanes and ethernet interfaces.
Signed-off-by: Shengzhou Liu
---
v2: separate patches per silicon-related.
arch/powerpc/boot/dts/fsl/t2080si-post.dtsi | 406
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 384 ++
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 100 +++
3 files changed, 890 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
new file mode 100644
index 000..be3d8de
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
@@ -0,0 +1,406 @@
+/*
+ * T2080 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ interrupts = <25 2 0 0>;
+};
+
+/* controller at 0x24 */
+&pci0 {
+ compatible = "fsl,t2080-pcie", "fsl,qoriq-pcie-v3.0", "fsl,qoriq-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0x0 0xff>;
+ interrupts = <20 2 0 0>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <20 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0 0 1 &mpic 40 1 0 0
+ 0 0 2 &mpic 1 1 0 0
+ 0 0 3 &mpic 2 1 0 0
+ 0 0 4 &mpic 3 1 0 0
+ >;
[PATCH 4/4 v2] powerpc/fsl-booke: Enable T208xQDS board
Signed-off-by: Shengzhou Liu
---
v2: add T2081QDS compatible.
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index 4d46349..b3436f8 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -259,7 +259,7 @@ config CORENET_GENERIC
For 32bit kernel, the following boards are supported:
P2041 RDB, P3041 DS and P4080 DS
For 64bit kernel, the following boards are supported:
- T4240 QDS and B4 QDS
+ T208x QDS, T4240 QDS and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
P5020 DS and P5040 DS
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..77fd71f 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -102,6 +102,8 @@ static const char * const boards[] __initconst = {
"fsl,P4080DS",
"fsl,P5020DS",
"fsl,P5040DS",
+ "fsl,T2080QDS",
+ "fsl,T2081QDS",
"fsl,T4240QDS",
"fsl,B4860QDS",
"fsl,B4420QDS",
@@ -115,6 +117,8 @@ static const char * const hv_boards[] __initconst = {
"fsl,P4080DS-hv",
"fsl,P5020DS-hv",
"fsl,P5040DS-hv",
+ "fsl,T2080QDS-hv",
+ "fsl,T2081QDS-hv"
"fsl,T4240QDS-hv",
"fsl,B4860QDS-hv",
"fsl,B4420QDS-hv",
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4 v2] powerpc/fsl-booke: Add initial T208x QDS board support
Add support for Freescale T2080/T2081 QDS Development System Board.
T2081QDS board shares the same PCB with T1040QDS with some differences.
The T2080QDS Development System is a high-performance computing,
evaluation, and development platform that supports T2080 QorIQ
Power Architecture processor, with following major features:
T2080QDS feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LV devices
- Two DDR3 memory, 4GB, Dual rank @ 1866 Mbps data rate, and ECC support
Ethernet interfaces:
- Two 1Gbps RGMII on-board ports
- Four 10Gbps XFI on-board cages
- 1Gbps/2.5Gbps SGMII Riser card
- 10Gbps XAUI Riser card
Accelerator:
- DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
SerDes:
- 16 lanes up to 10.3125GHz
- Supports Aurora debug, PEX, SATA, SGMII, sRIO, HiGig, XFI and XAUI
IFC:
- 128MB NOR Flash, 512MB NAND Flash, PromJet debug port and FPGA
eSPI:
- Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040)
USB:
- Two USB2.0 ports with internal PHY (one Type-A + one micro Type-AB)
PCIE:
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0)
SATA:
- Two SATA 2.0 ports on-board
SRIO:
- Two Serial RapidIO 2.0 ports up to 5 GHz
eSDHC:
- Supports SD/MMC/eMMC Card
DMA:
- Three 8-channels DMA controllers
I2C:
- Four I2C controllers.
UART:
- Dual 4-pins UART serial ports
System Logic:
- QIXIS-II FPGA system controll
Differences between T2080 and T2081:
Feature T2080 T2081
1G Ethernet numbers: 8 6
10G Ethernet numbers: 4 2
SerDes lanes: 168
Serial RapidIO,RMan: 2 no
SATA Controller: 2 no
Aurora: yes no
SoC Package: 896-pins 780-pins
Signed-off-by: Shengzhou Liu
---
v2: separate patches per board-related.
arch/powerpc/boot/dts/t2080qds.dts | 57
arch/powerpc/boot/dts/t2081qds.dts | 46 +++
arch/powerpc/boot/dts/t208xqds.dtsi | 259
arch/powerpc/include/asm/mpc85xx.h | 2 +
4 files changed, 364 insertions(+)
create mode 100644 arch/powerpc/boot/dts/t2080qds.dts
create mode 100644 arch/powerpc/boot/dts/t2081qds.dts
create mode 100644 arch/powerpc/boot/dts/t208xqds.dtsi
diff --git a/arch/powerpc/boot/dts/t2080qds.dts
b/arch/powerpc/boot/dts/t2080qds.dts
new file mode 100644
index 000..aa1d6d8
--- /dev/null
+++ b/arch/powerpc/boot/dts/t2080qds.dts
@@ -0,0 +1,57 @@
+/*
+ * T2080QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t208xsi-pre.dtsi"
+/include/ "t208xqds.dtsi"
+
+/ {
+ model = "fsl,T2080QDS";
+ compatible = "fsl,T2080QDS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ rio: rapidio@ffe0c {
+ reg = <0xf 0xfe0c 0 0x11000>;
+
+ port1 {
+ ranges = <0 0 0xc 0x2000 0 0x1000>;
+ };
+ port2 {
+ ranges = <0 0 0xc 0x3000 0 0x1000>;
+ };
+ };
+};
+
+/include/ "fsl/t2080si-post.dtsi"
diff --git a/arc
[PATCH 1/4 v2] powerpc/85xx/dts: add third elo3 dma component
Add elo3-dma-2.dtsi to support the third DMA controller.
This is used on T2080, T4240, etc.
Signed-off-by: Shengzhou Liu
Signed-off-by: Liu Gang
---
v2: no change
arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi | 82 +++
1 file changed, 82 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
b/arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
new file mode 100644
index 000..b89d816
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi
@@ -0,0 +1,82 @@
+/*
+ * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x102300 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma2: dma@102300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x102300 0x4>,
+ <0x102600 0x4>;
+ ranges = <0x0 0x102100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <256 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <257 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <258 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <259 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <260 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <261 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <262 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <263 2 0 0>;
+ };
+};
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Signed-off-by: Liu Gang --- changes in v2: - Added more description of the problem. - Reduced one in_be32() call. - Do not modify the shadow data. drivers/gpio/gpio-mpc8xxx.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 914e859..d7d6d72 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -70,10 +70,14 @@ 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); + u32 out_mask, out_shadow; - val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR); + out_mask = in_be32(mm->regs + GPIO_DIR); - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio); + val = in_be32(mm->regs + GPIO_DAT) & ~out_mask; + out_shadow = mpc8xxx_gc->data & out_mask; + + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio); } static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio) -- 1.8.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/powernv: Move PHB-diag dump functions around
Prior to the completion of PCI enumeration, we actively detects
EEH errors on PCI config cycles and dump PHB diag-data if necessary.
The EEH backend also dumps PHB diag-data in case of frozen PE or
fenced PHB. However, we are using different functions to dump the
PHB diag-data for those 2 cases.
The patch merges the functions for dumping PHB diag-data to one so
that we can avoid duplicate code. Also, we never dump PHB3 diag-data
during PCI config cycles with frozen PE. The patch fixes it as well.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 150 +-
arch/powerpc/platforms/powernv/pci.c | 196 -
arch/powerpc/platforms/powernv/pci.h |3 +
3 files changed, 144 insertions(+), 205 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 02245ce..be33a16 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -681,164 +681,20 @@ static void ioda_eeh_hub_diag(struct pci_controller
*hose)
}
}
-static void ioda_eeh_p7ioc_phb_diag(struct pci_controller *hose,
- struct OpalIoPhbErrorCommon *common)
-{
- struct OpalIoP7IOCPhbErrorData *data;
- int i;
-
- data = (struct OpalIoP7IOCPhbErrorData *)common;
-
- pr_info("P7IOC PHB#%x Diag-data (Version: %d)\n\n",
- hose->global_number, common->version);
-
- pr_info(" brdgCtl: %08x\n", data->brdgCtl);
-
- pr_info(" portStatusReg:%08x\n", data->portStatusReg);
- pr_info(" rootCmplxStatus: %08x\n", data->rootCmplxStatus);
- pr_info(" busAgentStatus: %08x\n", data->busAgentStatus);
-
- pr_info(" deviceStatus: %08x\n", data->deviceStatus);
- pr_info(" slotStatus: %08x\n", data->slotStatus);
- pr_info(" linkStatus: %08x\n", data->linkStatus);
- pr_info(" devCmdStatus: %08x\n", data->devCmdStatus);
- pr_info(" devSecStatus: %08x\n", data->devSecStatus);
-
- pr_info(" rootErrorStatus: %08x\n", data->rootErrorStatus);
- pr_info(" uncorrErrorStatus:%08x\n", data->uncorrErrorStatus);
- pr_info(" corrErrorStatus: %08x\n", data->corrErrorStatus);
- pr_info(" tlpHdr1: %08x\n", data->tlpHdr1);
- pr_info(" tlpHdr2: %08x\n", data->tlpHdr2);
- pr_info(" tlpHdr3: %08x\n", data->tlpHdr3);
- pr_info(" tlpHdr4: %08x\n", data->tlpHdr4);
- pr_info(" sourceId: %08x\n", data->sourceId);
-
- pr_info(" errorClass: %016llx\n", data->errorClass);
- pr_info(" correlator: %016llx\n", data->correlator);
- pr_info(" p7iocPlssr: %016llx\n", data->p7iocPlssr);
- pr_info(" p7iocCsr: %016llx\n", data->p7iocCsr);
- pr_info(" lemFir: %016llx\n", data->lemFir);
- pr_info(" lemErrorMask: %016llx\n", data->lemErrorMask);
- pr_info(" lemWOF: %016llx\n", data->lemWOF);
- pr_info(" phbErrorStatus: %016llx\n", data->phbErrorStatus);
- pr_info(" phbFirstErrorStatus: %016llx\n", data->phbFirstErrorStatus);
- pr_info(" phbErrorLog0: %016llx\n", data->phbErrorLog0);
- pr_info(" phbErrorLog1: %016llx\n", data->phbErrorLog1);
- pr_info(" mmioErrorStatus: %016llx\n", data->mmioErrorStatus);
- pr_info(" mmioFirstErrorStatus: %016llx\n",
data->mmioFirstErrorStatus);
- pr_info(" mmioErrorLog0:%016llx\n", data->mmioErrorLog0);
- pr_info(" mmioErrorLog1:%016llx\n", data->mmioErrorLog1);
- pr_info(" dma0ErrorStatus: %016llx\n", data->dma0ErrorStatus);
- pr_info(" dma0FirstErrorStatus: %016llx\n",
data->dma0FirstErrorStatus);
- pr_info(" dma0ErrorLog0:%016llx\n", data->dma0ErrorLog0);
- pr_info(" dma0ErrorLog1:%016llx\n", data->dma0ErrorLog1);
- pr_info(" dma1ErrorStatus: %016llx\n", data->dma1ErrorStatus);
- pr_info(" dma1FirstErrorStatus: %016llx\n",
data->dma1FirstErrorStatus);
- pr_info(" dma1ErrorLog0:%016llx\n", data->dma1ErrorLog0);
- pr_info(" dma1ErrorLog1:%016llx\n", data->dma1ErrorLog1);
-
- for (i = 0; i < OPAL_P7IOC_NUM_PEST_REGS; i++) {
- if ((data->pestA[i] >> 63) == 0 &&
- (data->pestB[i] >> 63) == 0)
- continue;
-
- pr_info(" PE[%3d] PESTA:%016llx\n", i, data->pestA[i]);
- pr_info(" PESTB:%016llx\n", data->pestB[i]);
- }
-}
-
-static void ioda_eeh_phb3_phb_diag(struct pci_controller *hose,
- struct OpalIoPhbErrorCommon *common)
-{
- struct OpalIoPhb3ErrorData *data;
- int i;
-
[PATCH 2/2] powerpc/eeh: Output PHB diag-data
When hitting frozen PE or fenced PHB, it's always indicative to
have dumped PHB diag-data for further analysis and diagnosis.
However, we never dump that for the cases. The patch intends to
dump PHB diag-data at the backend of eeh_ops::get_log() for PowerNV
platform.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index be33a16..31320c6 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -588,11 +588,8 @@ static int ioda_eeh_get_log(struct eeh_pe *pe, int
severity,
return -EIO;
}
- /*
-* FIXME: We probably need log the error in somewhere.
-* Lets make it up in future.
-*/
- /* pr_info("%s", phb->diag.blob); */
+ /* The PHB diag-data is always indicative */
+ pnv_pci_dump_phb_diag_data(hose, phb->diag.blob);
spin_unlock_irqrestore(&phb->lock, flags);
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
