* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Kumar Gala @ 2008-07-16 22:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, davej
In-Reply-To: <20080716214722.GA6251@ld0162-tx32.am.freescale.net>
On Jul 16, 2008, at 4:47 PM, Scott Wood wrote:
> On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
>> If we don't enable FS_ENET we get build issues:
>>
>> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
>> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
>> `alloc_mdio_bitbang'
>> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
>> `mdiobus_register'
>
> How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
>
>> +#ifdef CONFIG_FS_ENET_MDIO_FCC
>> static void ep8248e_set_mdc(struct mdiobb_ctrl *ctrl, int level)
>> {
>> if (level)
>> @@ -164,6 +165,7 @@ static struct of_platform_driver
>> ep8248e_mdio_driver = {
>> .probe = ep8248e_mdio_probe,
>> .remove = ep8248e_mdio_remove,
>> };
>> +#endif
>
> This is wrong -- ep8248e doesn't use the FS_ENET_MDIO_FCC code.
You're correct this should be CONFIG_MDIO_BITBANG
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc: fix ALSA options in Freescale 85xx and 86xx defconfigs
From: Kumar Gala @ 2008-07-16 21:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1214346902-4363-1-git-send-email-timur@freescale.com>
On Jun 24, 2008, at 5:35 PM, Timur Tabi wrote:
> The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for
> some
> audio related options. In particular, OSS emulation should be
> enabled,
> and the old ALSA API should be disabled.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
applied.
- k
^ permalink raw reply
* RE: 82xx performance
From: Rune Torgersen @ 2008-07-16 21:53 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <200807162345.26395.arnd@arndb.de>
Arnd Bergmann wrote:
> Ok, I think this could be related mostly to two changes:
>=20
> * In 2.6.23, the process scheduler was replaced, the new one
> is the CFS,
> the 'completely fair scheduler'. This has changed a lot of data.
> To verify this, you could check out a git version just before and
> just after CFS went in.=20
I'll check. Checking the context switch is fairly fast, so this is a
goot time to learn bisect...
> * Obviously, the 6 percent change between ppc and powerpc should not
> be there. You can still try to use 'readprofile', or oprofile in
> timer based mode (i.e. without HW performance counters) to get some
> more data about where the time is spent on an identical
> kernel version.
I did run oprofile, but I could not figure out how to get it to show me
where in the kernel it was spending time. It showed that a lot of time
was spent in vmlinux, but not anything specific. I probably just don't
know how to set up or run oprofile correctly.
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: Fix compile problem if !CONFIG_FS_ENET
From: Scott Wood @ 2008-07-16 21:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, davej
In-Reply-To: <Pine.LNX.4.64.0807160838520.14127@blarg.am.freescale.net>
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
> If we don't enable FS_ENET we get build issues:
>
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
How is this possible? CONFIG_EP8248E selects CONFIG_MDIO_BITBANG.
> +#ifdef CONFIG_FS_ENET_MDIO_FCC
> static void ep8248e_set_mdc(struct mdiobb_ctrl *ctrl, int level)
> {
> if (level)
> @@ -164,6 +165,7 @@ static struct of_platform_driver ep8248e_mdio_driver = {
> .probe = ep8248e_mdio_probe,
> .remove = ep8248e_mdio_remove,
> };
> +#endif
This is wrong -- ep8248e doesn't use the FS_ENET_MDIO_FCC code.
-Scott
^ permalink raw reply
* Re: 82xx performance
From: Arnd Bergmann @ 2008-07-16 21:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04B3490E@ismail.innsys.innovsys.com>
On Wednesday 16 July 2008, Rune Torgersen wrote:
> Turns out the story is no so simple.
> I redid the test wih all versions of arch/ppc from 2.6.18 to 2.6.26, and
> also arch/powerpc (2.6.24 and 25, 26 doesn't compile because of binutil
> issues)
>=20
> This time I made very sure that the tests were performed the same way,
> and I made a tabel showing relative performance:
>=20
> kernel =A0 =A0 =A0 =A0compile time =A0 rel =A0 context switch =A0rel
> v2.6.18 =A0 =A0 =A0 =A0 01:13:33.70 =A01.00 =A0 =A0 =A0 7.2 =A0 =A0 =A0 =
=A01.00
> v2.6.19 =A0 =A0 =A0 =A0 01:13:29.21 =A01.00 =A0 =A0 =A0 7.1 =A0 =A0 =A0 =
=A00.99
> v2.6.20 =A0 =A0 =A0 =A0 01:13:29.58 =A01.00 =A0 =A0 =A0 2.8 =A0 =A0 =A0 =
=A00.39
> v2.6.21 =A0 =A0 =A0 =A0 01:13:24.91 =A01.00 =A0 =A0 =A0 8.1 =A0 =A0 =A0 =
=A01.13
> v2.6.22 =A0 =A0 =A0 =A0 01:13:42.72 =A01.00 =A0 =A0 =A0 4.5 =A0 =A0 =A0 =
=A00.63
> v2.6.23 =A0 =A0 =A0 =A0 01:15:16.43 =A01.02 =A0 =A0 =A0 17 =A0 =A0 =A0 =
=A0 2.36
> v2.6.24 =A0 =A0 =A0 =A0 01:15:30.90 =A01.03 =A0 =A0 =A0 20 =A0 =A0 =A0 =
=A0 2.78
> v2.6.25 =A0 =A0 =A0 =A0 01:14:51.21 =A01.02 =A0 =A0 =A0 21 =A0 =A0 =A0 =
=A0 2.92
> v2.6.26 =A0 =A0 =A0 =A0 01:14:34.76 =A01.01 =A0 =A0 =A0 23.8 =A0 =A0 =A0 =
3.31
> v2.6.24-powerpc 01:17:41.99 =A01.06 =A0 =A0 =A0 25.8 =A0 =A0 =A0 3.58
> v2.6.25-powerpc 01:18:10.10 =A01.06 =A0 =A0 =A0 35.7 =A0 =A0 =A0 4.96
>=20
> This shows that arch/ppc no matter versin is fairly consistent in speed.
> Arch/powerpc is roughtly 6% worse.
>=20
> The contect swith column is found running lat_ctx 2 from lmbench3, and
> should be in microsecs.
Ok, I think this could be related mostly to two changes:
* In 2.6.23, the process scheduler was replaced, the new one is the CFS,
the 'completely fair scheduler'. This has changed a lot of data.
To verify this, you could check out a git version just before and just
after CFS went in.
* Obviously, the 6 percent change between ppc and powerpc should not
be there. You can still try to use 'readprofile', or oprofile in
timer based mode (i.e. without HW performance counters) to get some
more data about where the time is spent on an identical kernel version.
Arnd <><
^ permalink raw reply
* Re: SW TLB MMU rework and SMP issues (pte read/write)
From: Benjamin Herrenschmidt @ 2008-07-16 21:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <B2B96B0D-960F-4FB1-A5C1-6146EFB7E563@kernel.crashing.org>
On Wed, 2008-07-16 at 15:57 -0500, Kumar Gala wrote:
> This makes sense. I think we need to order the stores in set_pte_at
> regardless of CONFIG_SMP.
Nah, that shouldn't be necessary.
> Also, I think we should change pte_clear to
> use pte_update() so we only clear the low-order flag bits. Patch will
> be sent shortly for review.
Well... at one point at least we did rely on a PTE page with all PTEs
cleared to be blank. It don't know if that's still the case, I need to
look.
Ben.
^ permalink raw reply
* [patch 2/2] powerpc/ps3: Update ps3_defconfig
From: Geoff Levand @ 2008-07-16 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <487E654C.9030001@am.sony.com>
Update ps3_defconfig.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/configs/ps3_defconfig | 196 +++++++++++++++++++++++--------------
1 file changed, 122 insertions(+), 74 deletions(-)
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.25
-# Mon Apr 28 12:39:10 2008
+# Linux kernel version: 2.6.26
+# Wed Jul 16 13:59:24 2008
#
CONFIG_PPC64=y
@@ -14,8 +14,9 @@ CONFIG_POWER4=y
CONFIG_TUNE_CELL=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
+# CONFIG_VSX is not set
CONFIG_PPC_STD_MMU=y
-# CONFIG_PPC_MM_SLICES is not set
+CONFIG_PPC_MM_SLICES=y
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
@@ -31,6 +32,7 @@ CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -90,6 +92,7 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
@@ -117,12 +120,15 @@ CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_DMA_ATTRS=y
+CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
@@ -132,6 +138,7 @@ CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_BLK_DEV_BSG=y
+# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y
#
@@ -152,13 +159,8 @@ CONFIG_CLASSIC_RCU=y
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
-# CONFIG_PPC_82xx is not set
-# CONFIG_PPC_83xx is not set
-# CONFIG_PPC_86xx is not set
# CONFIG_PPC_PSERIES is not set
# CONFIG_PPC_ISERIES is not set
-# CONFIG_PPC_MPC512x is not set
-# CONFIG_PPC_MPC5121 is not set
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
# CONFIG_PPC_PASEMI is not set
@@ -187,6 +189,7 @@ CONFIG_PPC_CELL=y
# Cell Broadband Engine options
#
CONFIG_SPU_FS=y
+CONFIG_SPU_FS_64K_LS=y
CONFIG_SPU_BASE=y
# CONFIG_PQ2ADS is not set
# CONFIG_IPIC is not set
@@ -222,6 +225,7 @@ CONFIG_PREEMPT_NONE=y
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
+CONFIG_HUGETLB_PAGE_SIZE_VARIABLE=y
# CONFIG_IOMMU_VMERGE is not set
CONFIG_IOMMU_HELPER=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
@@ -248,18 +252,22 @@ CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
# CONFIG_SPARSEMEM_VMEMMAP is not set
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
+CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_ARCH_MEMORY_PROBE=y
-# CONFIG_PPC_HAS_HASH_64K is not set
+CONFIG_PPC_HAS_HASH_64K=y
# CONFIG_PPC_64K_PAGES is not set
CONFIG_FORCE_MAX_ZONEORDER=13
-# CONFIG_SCHED_SMT is not set
+CONFIG_SCHED_SMT=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
-# CONFIG_PM is not set
+CONFIG_EXTRA_TARGETS=""
+CONFIG_PM=y
+CONFIG_PM_DEBUG=y
+# CONFIG_PM_VERBOSE is not set
# CONFIG_SECCOMP is not set
CONFIG_ISA_DMA_API=y
@@ -273,6 +281,7 @@ CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set
+# CONFIG_HAS_RAPIDIO is not set
CONFIG_PAGE_OFFSET=0xc000000000000000
CONFIG_KERNEL_START=0xc000000000000000
CONFIG_PHYSICAL_START=0x00000000
@@ -412,6 +421,8 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
@@ -478,6 +489,7 @@ CONFIG_SCSI_WAIT_SCAN=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
+# CONFIG_SCSI_DH is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_MACINTOSH_DRIVERS is not set
@@ -533,8 +545,18 @@ CONFIG_USB_NET_MCS7830=m
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
# CONFIG_WAN is not set
-# CONFIG_PPP is not set
+CONFIG_PPP=m
+CONFIG_PPP_MULTILINK=y
+# CONFIG_PPP_FILTER is not set
+CONFIG_PPP_ASYNC=m
+# CONFIG_PPP_SYNC_TTY is not set
+CONFIG_PPP_DEFLATE=m
+# CONFIG_PPP_BSDCOMP is not set
+# CONFIG_PPP_MPPE is not set
+CONFIG_PPPOE=m
+# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
+CONFIG_SLHC=m
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
@@ -603,6 +625,7 @@ CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
@@ -618,23 +641,17 @@ CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
-CONFIG_GEN_RTC=y
-# CONFIG_GEN_RTC_X is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
-
-#
-# SPI support
-#
# CONFIG_SPI is not set
-# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
+# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
#
@@ -652,8 +669,17 @@ CONFIG_SSB_POSSIBLE=y
#
# Multimedia devices
#
+
+#
+# Multimedia core support
+#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
+# CONFIG_VIDEO_MEDIA is not set
+
+#
+# Multimedia drivers
+#
# CONFIG_DAB is not set
#
@@ -671,8 +697,8 @@ CONFIG_FB=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
+# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
-CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
@@ -712,18 +738,12 @@ CONFIG_FB_LOGO_EXTRA=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
-
-#
-# Sound
-#
CONFIG_SOUND=m
-
-#
-# Advanced Linux Sound Architecture
-#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
+CONFIG_SND_HWDEP=m
+CONFIG_SND_RAWMIDI=m
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
@@ -732,53 +752,20 @@ CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
-
-#
-# Generic devices
-#
-# CONFIG_SND_DUMMY is not set
-# CONFIG_SND_MTPAV is not set
-# CONFIG_SND_SERIAL_U16550 is not set
-# CONFIG_SND_MPU401 is not set
-
-#
-# ALSA PowerMac devices
-#
-
-#
-# ALSA PowerMac requires I2C
-#
-
-#
-# ALSA PowerPC devices
-#
+# CONFIG_SND_DRIVERS is not set
+CONFIG_SND_PPC=y
CONFIG_SND_PS3=m
CONFIG_SND_PS3_DEFAULT_START_DELAY=2000
-
-#
-# USB devices
-#
-# CONFIG_SND_USB_AUDIO is not set
+CONFIG_SND_USB=y
+CONFIG_SND_USB_AUDIO=m
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
-
-#
-# System on Chip audio support
-#
# CONFIG_SND_SOC is not set
-
-#
-# ALSA SoC audio for Freescale SOCs
-#
-
-#
-# Open Sound System
-#
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
-# CONFIG_HIDRAW is not set
+CONFIG_HIDRAW=y
#
# USB Input Devices
@@ -807,17 +794,20 @@ CONFIG_USB=m
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
+CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
+# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_EHCI_BIG_ENDIAN_MMIO=y
# CONFIG_USB_EHCI_HCD_PPC_OF is not set
# CONFIG_USB_ISP116X_HCD is not set
+# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_HCD_PPC_OF is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
@@ -831,6 +821,7 @@ CONFIG_USB_OHCI_LITTLE_ENDIAN=y
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
+# CONFIG_USB_WDM is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
@@ -890,12 +881,45 @@ CONFIG_USB_MON=y
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
+# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
+# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_LIB=m
+CONFIG_RTC_CLASS=m
+
+#
+# RTC interfaces
+#
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
+# CONFIG_RTC_DRV_TEST is not set
+
+#
+# SPI RTC drivers
+#
+
+#
+# Platform RTC drivers
+#
+# CONFIG_RTC_DRV_CMOS is not set
+# CONFIG_RTC_DRV_DS1511 is not set
+# CONFIG_RTC_DRV_DS1553 is not set
+# CONFIG_RTC_DRV_DS1742 is not set
+# CONFIG_RTC_DRV_STK17TA8 is not set
+# CONFIG_RTC_DRV_M48T86 is not set
+# CONFIG_RTC_DRV_M48T59 is not set
+# CONFIG_RTC_DRV_V3020 is not set
+
+#
+# on-CPU RTC drivers
+#
+CONFIG_RTC_DRV_PPC=m
# CONFIG_DMADEVICES is not set
# CONFIG_UIO is not set
@@ -911,6 +935,7 @@ CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
+# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
@@ -959,8 +984,8 @@ CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
-# CONFIG_HUGETLBFS is not set
-# CONFIG_HUGETLB_PAGE is not set
+CONFIG_HUGETLBFS=y
+CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
#
@@ -1059,12 +1084,15 @@ CONFIG_NLS_ISO8859_1=y
#
CONFIG_BITREVERSE=y
# CONFIG_GENERIC_FIND_FIRST_BIT is not set
-# CONFIG_CRC_CCITT is not set
+CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
+# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=m
+CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_PLIST=y
@@ -1082,7 +1110,7 @@ CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
-# CONFIG_DEBUG_FS is not set
+CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
@@ -1090,33 +1118,49 @@ CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
+# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
-# CONFIG_DEBUG_LOCK_ALLOC is not set
-# CONFIG_PROVE_LOCKING is not set
+CONFIG_DEBUG_LOCK_ALLOC=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
+CONFIG_DEBUG_LOCKDEP=y
+CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
-# CONFIG_DEBUG_WRITECOUNT is not set
+CONFIG_DEBUG_WRITECOUNT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
+CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
+# CONFIG_LATENCYTOP is not set
+CONFIG_HAVE_FTRACE=y
+CONFIG_HAVE_DYNAMIC_FTRACE=y
+# CONFIG_FTRACE is not set
+# CONFIG_IRQSOFF_TRACER is not set
+# CONFIG_SCHED_TRACER is not set
+# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_SAMPLES is not set
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUGGER is not set
+# CONFIG_CODE_PATCHING_SELFTEST is not set
+# CONFIG_FTR_FIXUP_SELFTEST is not set
CONFIG_IRQSTACKS=y
+# CONFIG_VIRQ_DEBUG is not set
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG is not set
@@ -1172,6 +1216,10 @@ CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
+# CONFIG_CRYPTO_RMD128 is not set
+# CONFIG_CRYPTO_RMD160 is not set
+# CONFIG_CRYPTO_RMD256 is not set
+# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
^ permalink raw reply
* [patch 1/2] powerpc/ps3: Add a sub-match id to ps3_system_bus
From: Geoff Levand @ 2008-07-16 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <487E654C.9030001@am.sony.com>
From: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Add sub match id for ps3 system bus so that two different system bus
devices can be connected to a shared device.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/device-init.c | 1 +
arch/powerpc/platforms/ps3/system-bus.c | 21 ++++++++++++++-------
drivers/video/ps3fb.c | 1 +
include/asm-powerpc/ps3.h | 7 +++++++
4 files changed, 23 insertions(+), 7 deletions(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -486,6 +486,7 @@ static int __init ps3_register_graphics_
return -ENOMEM;
p->dev.match_id = PS3_MATCH_ID_GRAPHICS;
+ p->dev.match_sub_id = PS3_MATCH_SUB_ID_FB;
p->dev.dev_type = PS3_DEVICE_TYPE_IOC0;
result = ps3_system_bus_device_register(&p->dev);
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -347,16 +347,23 @@ static int ps3_system_bus_match(struct d
struct ps3_system_bus_driver *drv = ps3_drv_to_system_bus_drv(_drv);
struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
- result = dev->match_id == drv->match_id;
+ if (!dev->match_sub_id)
+ result = dev->match_id == drv->match_id;
+ else
+ result = dev->match_sub_id == drv->match_sub_id &&
+ dev->match_id == drv->match_id;
if (result)
- pr_info("%s:%d: dev=%u(%s), drv=%u(%s): match\n", __func__,
- __LINE__, dev->match_id, dev->core.bus_id,
- drv->match_id, drv->core.name);
+ pr_info("%s:%d: dev=%u.%u(%s), drv=%u.%u(%s): match\n",
+ __func__, __LINE__,
+ dev->match_id, dev->match_sub_id, dev->core.bus_id,
+ drv->match_id, drv->match_sub_id, drv->core.name);
else
- pr_debug("%s:%d: dev=%u(%s), drv=%u(%s): miss\n", __func__,
- __LINE__, dev->match_id, dev->core.bus_id,
- drv->match_id, drv->core.name);
+ pr_debug("%s:%d: dev=%u.%u(%s), drv=%u.%u(%s): miss\n",
+ __func__, __LINE__,
+ dev->match_id, dev->match_sub_id, dev->core.bus_id,
+ drv->match_id, drv->match_sub_id, drv->core.name);
+
return result;
}
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -1297,6 +1297,7 @@ static int ps3fb_shutdown(struct ps3_sys
static struct ps3_system_bus_driver ps3fb_driver = {
.match_id = PS3_MATCH_ID_GRAPHICS,
+ .match_sub_id = PS3_MATCH_SUB_ID_FB,
.core.name = DEVICE_NAME,
.core.owner = THIS_MODULE,
.probe = ps3fb_probe,
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -337,12 +337,18 @@ enum ps3_system_bus_device_type {
PS3_DEVICE_TYPE_LPM,
};
+enum ps3_match_sub_id {
+ /* for PS3_MATCH_ID_GRAPHICS */
+ PS3_MATCH_SUB_ID_FB = 1,
+};
+
/**
* struct ps3_system_bus_device - a device on the system bus
*/
struct ps3_system_bus_device {
enum ps3_match_id match_id;
+ enum ps3_match_sub_id match_sub_id;
enum ps3_system_bus_device_type dev_type;
u64 bus_id; /* SB */
@@ -371,6 +377,7 @@ int ps3_close_hv_device(struct ps3_syste
struct ps3_system_bus_driver {
enum ps3_match_id match_id;
+ enum ps3_match_sub_id match_sub_id;
struct device_driver core;
int (*probe)(struct ps3_system_bus_device *);
int (*remove)(struct ps3_system_bus_device *);
^ permalink raw reply
* PS3 patches for 2.6.27
From: Geoff Levand @ 2008-07-16 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
Hi Ben,
Here are two more PS3 patches for 2.6.27. Please apply.
-Geoff
^ permalink raw reply
* [PATCH] powerpc: Fixes for CONFIG_PTE_64BIT for SMP support
From: Kumar Gala @ 2008-07-16 21:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
There are some minor issues with support 64-bit PTEs on a 32-bit processor
when dealing with SMP.
* We need to order the stores in set_pte_at to make sure the flag word
is set second.
* We want to ensure that set_pte_at is always called w/a pte that is not
valid. Change kunmap_atomic to always clear the pte.
* Change pte_clear to use pte_update so only the flag word is cleared
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Do we want to unconditionally change kunmap_atomic or not?
- k
include/asm-powerpc/highmem.h | 4 ++--
include/asm-powerpc/pgtable-ppc32.h | 14 ++++++++++----
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
index 5d99b64..7f101d1 100644
--- a/include/asm-powerpc/highmem.h
+++ b/include/asm-powerpc/highmem.h
@@ -97,7 +97,6 @@ static inline void *kmap_atomic(struct page *page, enum km_type type)
static inline void kunmap_atomic(void *kvaddr, enum km_type type)
{
-#ifdef CONFIG_DEBUG_HIGHMEM
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
@@ -106,7 +105,9 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type type)
return;
}
+#ifdef CONFIG_DEBUG_HIGHMEM
BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
+#endif
/*
* force other mappings to Oops if they'll try to access
@@ -114,7 +115,6 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type type)
*/
pte_clear(&init_mm, vaddr, kmap_pte-idx);
flush_tlb_page(NULL, vaddr);
-#endif
pagefault_enable();
}
diff --git a/include/asm-powerpc/pgtable-ppc32.h b/include/asm-powerpc/pgtable-ppc32.h
index 3a96d00..2436eab 100644
--- a/include/asm-powerpc/pgtable-ppc32.h
+++ b/include/asm-powerpc/pgtable-ppc32.h
@@ -502,7 +502,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#define pte_none(pte) ((pte_val(pte) & ~_PTE_NONE_MASK) == 0)
#define pte_present(pte) (pte_val(pte) & _PAGE_PRESENT)
-#define pte_clear(mm,addr,ptep) do { set_pte_at((mm), (addr), (ptep), __pte(0)); } while (0)
+#define pte_clear(mm,addr,ptep) do { pte_update(ptep, ~0, 0); } while (0)
#define pmd_none(pmd) (!pmd_val(pmd))
#define pmd_bad(pmd) (pmd_val(pmd) & _PMD_BAD)
@@ -593,9 +593,6 @@ static inline unsigned long pte_update(pte_t *p,
return old;
}
#else /* CONFIG_PTE_64BIT */
-/* TODO: Change that to only modify the low word and move set_pte_at()
- * out of line
- */
static inline unsigned long long pte_update(pte_t *p,
unsigned long clr,
unsigned long set)
@@ -639,8 +636,17 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
#if _PAGE_HASHPTE != 0
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
#else
+#if defined(CONFIG_PTE_64BIT) && defined(CONFIG_SMP)
+ __asm__ __volatile__("\
+ stw%U0%X0 %2,%0\n\
+ eieio\n\
+ stw%U0%X0 %L2,%1"
+ : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
+ : "r" (pte) : "memory");
+#else
*ptep = pte;
#endif
+#endif
}
/*
--
1.5.5.1
^ permalink raw reply related
* [PATCH] powerpc/fsl-booke: Fixup 64-bite PTE reading for SMP support
From: Kumar Gala @ 2008-07-16 21:24 UTC (permalink / raw)
To: linuxppc-dev
We need to create a false data dependency to ensure the loads of
the pte are done in the right order.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/head_fsl_booke.S | 24 ++++++++++++++++++++----
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 3cb52fa..fa39cce 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -579,13 +579,19 @@ interrupt_base:
FIND_PTE
andc. r13,r13,r11 /* Check permission */
- bne 2f /* Bail if permission mismach */
#ifdef CONFIG_PTE_64BIT
- lwz r13, 0(r12)
+#ifdef CONFIG_SMP
+ subf r10, r11, r12 /* create false data dep */
+ lwzx r13, r11, r10 /* Get upper pte bits */
+#else
+ lwz r13, 0(r12) /* Get upper pte bits */
#endif
+#endif
+
+ bne 2f /* Bail if permission/valid mismach */
- /* Jump to common tlb load */
+ /* Jump to common tlb load */
b finish_tlb_load
2:
/* The bailout. Restore registers to pre-exception conditions
@@ -640,6 +646,16 @@ interrupt_base:
FIND_PTE
andc. r13,r13,r11 /* Check permission */
+
+#ifdef CONFIG_PTE_64BIT
+#ifdef CONFIG_SMP
+ subf r10, r11, r12 /* create false data dep */
+ lwzx r13, r11, r10 /* Get upper pte bits */
+#else
+ lwz r13, 0(r12) /* Get upper pte bits */
+#endif
+#endif
+
bne 2f /* Bail if permission mismach */
#ifdef CONFIG_PTE_64BIT
@@ -702,7 +718,7 @@ interrupt_base:
/*
* Both the instruction and data TLB miss get to this
* point to load the TLB.
- * r10 - EA of fault
+ * r10 - available to use
* r11 - TLB (info from Linux PTE)
* r12 - available to use
* r13 - upper bits of PTE (if PTE_64BIT) or available to use
--
1.5.5.1
^ permalink raw reply related
* Re: SW TLB MMU rework and SMP issues (pte read/write)
From: Kumar Gala @ 2008-07-16 21:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <B2B96B0D-960F-4FB1-A5C1-6146EFB7E563@kernel.crashing.org>
On Jul 16, 2008, at 3:57 PM, Kumar Gala wrote:
>>> * 64-bit PTEs and reader vs writer hazards. How do we ensure that
>>> the
>>> TLB miss handler samples a consistent view of the pte. pte_updates
>>> seem ok since we only update the flag word. However set_pte_at
>>> seems
>>> like it could be problematic.
>>
>> eieio on the writer and a data dependency on the reader. segher
>> suggested a nice way to do it on the reader side, by doing a subf
>> of the
>> value from the pointer and then a lwxz using that value as an offset.
>>
>> ie. something like that, with r3 containing the PTE pointer:
>>
>> lwz r10,4(r3)
>> subf r4,r10,r3 <-- you can use r3,r10,r3 if clobber is safe
>> lwzx r11,r10,r4 <-- in which case you use r3 here too
>>
>> That ensures that the top half is loaded after the bottom half, which
>> is what you want if you do the set_pte_at() that way:
>>
>> stw r11,0(r3) <-- write top half first
>> eieio <-- maitain order to coherency domain
>> stw r10,4(r3) <-- write bottom half last
>>
>> In fact, in the reader case, while at it, you can interleave that
>> with
>> the testing of the present bit. Assuming _PAGE_PRESENT is in the low
>> bits and you can clobber r3, you get something like:
>>
>> lwz r10,4(r3)
>> <-- can't do much here unless you can do unrelated things -->
>> andi. r0,r10,_PAGE_PRESENT
>> subf r3,r10,r3
>> beq page_fault
>> lwzx r11,r10,r3
>
> This makes sense. I think we need to order the stores in set_pte_at
> regardless of CONFIG_SMP.
Ok, so I realized that we don't actually need to order the stores
since the sequential programming model will ensure the right things
happens.
- k
^ permalink raw reply
* RE: 82xx performance
From: Rune Torgersen @ 2008-07-16 21:08 UTC (permalink / raw)
To: Arnd Bergmann, Milton Miller, linuxppc-dev
In-Reply-To: <200807152150.35811.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 15 July 2008, Rune Torgersen wrote:
>> Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
>> test I did is almost identical (within 1%) of what the arch/powerpc
>> 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
>> (I'll see if I can find an exact version, as I think my ppc port can
>> be compiled for all versions from 2.6.18 to 25)
>=20
> You probably already know git-bisect, but if you don't, you should
> definitely give it a try. It's the best tool to find which patch
> exactly broke your performance.
Turns out the story is no so simple.
I redid the test wih all versions of arch/ppc from 2.6.18 to 2.6.26, and
also arch/powerpc (2.6.24 and 25, 26 doesn't compile because of binutil
issues)
This time I made very sure that the tests were performed the same way,
and I made a tabel showing relative performance:
kernel compile time rel context switch rel
v2.6.18 01:13:33.70 1.00 7.2 1.00
v2.6.19 01:13:29.21 1.00 7.1 0.99
v2.6.20 01:13:29.58 1.00 2.8 0.39
v2.6.21 01:13:24.91 1.00 8.1 1.13
v2.6.22 01:13:42.72 1.00 4.5 0.63
v2.6.23 01:15:16.43 1.02 17 2.36
v2.6.24 01:15:30.90 1.03 20 2.78
v2.6.25 01:14:51.21 1.02 21 2.92
v2.6.26 01:14:34.76 1.01 23.8 3.31
v2.6.24-powerpc 01:17:41.99 1.06 25.8 3.58
v2.6.25-powerpc 01:18:10.10 1.06 35.7 4.96
This shows that arch/ppc no matter versin is fairly consistent in speed.
Arch/powerpc is roughtly 6% worse.
The contect swith column is found running lat_ctx 2 from lmbench3, and
should be in microsecs.
^ permalink raw reply
* Re: SW TLB MMU rework and SMP issues (pte read/write)
From: Kumar Gala @ 2008-07-16 20:57 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216174045.7740.152.camel@pasglop>
>> * 64-bit PTEs and reader vs writer hazards. How do we ensure that
>> the
>> TLB miss handler samples a consistent view of the pte. pte_updates
>> seem ok since we only update the flag word. However set_pte_at seems
>> like it could be problematic.
>
> eieio on the writer and a data dependency on the reader. segher
> suggested a nice way to do it on the reader side, by doing a subf of
> the
> value from the pointer and then a lwxz using that value as an offset.
>
> ie. something like that, with r3 containing the PTE pointer:
>
> lwz r10,4(r3)
> subf r4,r10,r3 <-- you can use r3,r10,r3 if clobber is safe
> lwzx r11,r10,r4 <-- in which case you use r3 here too
>
> That ensures that the top half is loaded after the bottom half, which
> is what you want if you do the set_pte_at() that way:
>
> stw r11,0(r3) <-- write top half first
> eieio <-- maitain order to coherency domain
> stw r10,4(r3) <-- write bottom half last
>
> In fact, in the reader case, while at it, you can interleave that with
> the testing of the present bit. Assuming _PAGE_PRESENT is in the low
> bits and you can clobber r3, you get something like:
>
> lwz r10,4(r3)
> <-- can't do much here unless you can do unrelated things -->
> andi. r0,r10,_PAGE_PRESENT
> subf r3,r10,r3
> beq page_fault
> lwzx r11,r10,r3
This makes sense. I think we need to order the stores in set_pte_at
regardless of CONFIG_SMP. Also, I think we should change pte_clear to
use pte_update() so we only clear the low-order flag bits. Patch will
be sent shortly for review.
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc: fix ALSA options in Freescale 85xx and 86xx defconfigs
From: Timur Tabi @ 2008-07-16 20:41 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <1214346902-4363-1-git-send-email-timur@freescale.com>
Timur Tabi wrote:
> The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for some
> audio related options. In particular, OSS emulation should be enabled,
> and the old ALSA API should be disabled.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
Kumar, can you apply this patch, please?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: support for latencytop
From: Nathan Lynch @ 2008-07-16 20:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200807101608.18643.arnd@arndb.de>
Arnd Bergmann wrote:
> Implement save_stack_trace_tsk on powerpc, so that we can run with
> latencytop.
So I tried latencytop with linux-next and got the following oops, but
I didn't really look into it yet.
Unable to handle kernel paging request for data at address 0x00000008
Faulting instruction address: 0xc00000000002d114
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 pSeries
Modules linked in:
NIP: c00000000002d114 LR: c0000000005d3c68 CTR: 0000000000000000
REGS: c0000000e9137580 TRAP: 0300 Not tainted (2.6.26-next-20080716-08333-g49de20b)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000040 XER: 20000018
DAR: 0000000000000008, DSISR: 0000000040000000
TASK = c0000000e9138000[9] 'migration/2' THREAD: c0000000e9134000 CPU: 2
GPR00: c0000000005d3c68 c0000000e9137800 c000000000a54fc8 c0000000e91378f0
GPR04: c0000000e91378f0 c0000000e91e2750 0000000000000000 0000000000000002
GPR08: c0000000011154e0 0000000000000000 0000000000000400 c000000000a876c0
GPR12: 0000000044000042 c000000000a90800 00000000002146f4 0000000000214744
GPR16: 4000000002040000 0000000002903b58 c0000000e90bff10 00000000ffffffff
GPR20: c0000000010aec30 c000000000a95dc8 0000000000000010 0000000000000003
GPR24: 0000000000000001 c0000000011154a0 c0000000e91e2750 c000000000eedf68
GPR28: c0000000e9137908 0000000000000003 c0000000009c0c30 c0000000e9137800
NIP [c00000000002d114] .save_stack_trace_tsk+0x24/0x40
LR [c0000000005d3c68] .account_scheduler_latency+0xa4/0x2dc
Call Trace:
[c0000000e9137800] [c0000000e9137850] 0xc0000000e9137850 (unreliable)
[c0000000e9137880] [c0000000005d3c68] .account_scheduler_latency+0xa4/0x2dc
[c0000000e91379b0] [c0000000000794e8] .enqueue_task_fair+0x1e0/0x24c
[c0000000e9137a60] [c000000000074be4] .enqueue_task+0x80/0xb0
[c0000000e9137af0] [c000000000074c50] .activate_task+0x3c/0x64
[c0000000e9137b80] [c00000000007a5c8] .try_to_wake_up+0x2a0/0x384
[c0000000e9137c50] [c00000000007a6d0] .default_wake_function+0x24/0x38
[c0000000e9137cd0] [c00000000007438c] .__wake_up_common+0x74/0xec
[c0000000e9137d90] [c0000000000765c0] .complete+0x5c/0x8c
[c0000000e9137e30] [c00000000007eaa4] .migration_thread+0x2a4/0x33c
[c0000000e9137f00] [c0000000000a1da4] .kthread+0x84/0xd4
[c0000000e9137f90] [c000000000029ce4] .kernel_thread+0x4c/0x68
Instruction dump:
7c0803a6 7d808120 4e800020 7c0802a6 fbe1fff0 7c651b78 7c832378 38c00000
f8010010 f821ff81 e9250478 7c3f0b78 <e8890008> 4bfffef5 e8210000 e8010010
---[ end trace e35e4a6e751f309e ]---
^ permalink raw reply
* Re: [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Wolfgang Grandegger @ 2008-07-16 20:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, Linuxppc-dev
In-Reply-To: <20080716142436.GD24045@secretlab.ca>
Grant Likely wrote:
> On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
>> Currently, the I2C buses are probed for HWMON I2C devices, which might
>> not be acceptable in same cases. This patch makes device probing
>> configurable through the property "probe" of the FDT I2C device node:
>>
>> i2c@3000 {
>> ...
>> compatible = "fsl-i2c";
>> probe;
>> ...
>> };
>
> You need to add documentation to booting-without-of.txt about what the
> 'probe' property means. Also, 'probe' is a pretty generic term being
> used in an i2c specific context. Can you prefix it with i2c or
> something to protect the namespace? 'i2c-probe' perhaps?
Of course, no problem. I'm also aware of booting-without-of.txt but
first I wanted to bring up the problem-
>
>> Assuming that systems using fsl-i2c should have proper platform data,
>> probing is disabled by default. Unfortunately, that's not the case and
>> various DTS files would require to be updated.
>
> This comment doesn't seem to be correct.
Well, maybe it's due to my bad English. What I wanted to say is that by
default probing should be disabled. But that requires various DTS files
to be fixed.
>
>> ---
>> arch/powerpc/sysdev/fsl_soc.c | 4 ++++
>> drivers/i2c/busses/i2c-mpc.c | 17 ++++++++++++++---
>> include/linux/fsl_devices.h | 1 +
>
> This will need to be reworked for current top of tree. i2c-mpc
> dependence on fsl_soc.c has been removed.
I kown. Will prepare a new patch a.s.a.p.
Wolfgang.
^ permalink raw reply
* RE: linux boot sequence
From: Siva Prasad @ 2008-07-16 18:34 UTC (permalink / raw)
To: Rami WEHBI; +Cc: linuxppc-embedded
In-Reply-To: <D3C541E264C021479BFB60B3B790C0FB497182@etoilenoire.STARWARS.local>
Rami,
Please make sure to copy the list as well.
OF - Open firmware. I am not sure which version of Linux kernel you are =
using, and which boot loader. Lately it is all OF based, however it is =
supported in the form of device tree blob/structure. For more =
information read booting-without-of.txt in Documentation/powerpc.
U-Boot updates the detected memory in the dtb you loaded, so that when =
kernel reads it, correct information is provided.
There is no auto-detect option in kernel. You need to write your own =
code at the exact location it needs to identify the size of memory. =
Typically this is passed to the kernel either through DTB or kernel =
arguments.
Good Luck.
- Siva
-----Original Message-----
From: Rami WEHBI [mailto:rwehbi@wirecom-tech.com]=20
Sent: Monday, July 14, 2008 11:47 PM
To: Siva Prasad
Subject: RE: linux boot sequence
what is the OF dtb ??? And how does the bootloader update it ???
How can I do to set the autodetect option in the kernel ???
Best Regards,
Rami,
-----Message d'origine-----
De : Siva Prasad [mailto:sprasad@bivio.net]=20
Envoy=E9 : vendredi 11 juillet 2008 23:01
=C0 : Rami WEHBI
Cc : linuxppc-embedded@ozlabs.org
Objet : linux boot sequence
Well!... You can pass the size as part of the OF memory=3D<>.
Typically your boot loader should detect the amount of memory on the =
system and update the OF dtb to reflect the available memory.
You may also tweak the kernel yourself to autodetect, instead of reading =
from the OF. How ever, I would recommend the previous approach.
- Siva
Date: Fri, 11 Jul 2008 08:34:54 +0200
From: "Rami WEHBI" <rwehbi@wirecom-tech.com>
Subject: linux boot sequence
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
=09
<D3C541E264C021479BFB60B3B790C0FB497014@etoilenoire.STARWARS.local>
Content-Type: text/plain; charset=3D"iso-8859-1"
Hi all,
=20
I am using the ppc405 and I would like to know, how does linux on =
this architect detect the available memory size in details !!!
is it a parameter passed to linux at startup by the boot loader =
??
is it an automatic detection ?? what are the steps to accomplish =
this job then ???
=20
Best regards to all,
=20
Rami
=20
Rami WEHBI =09
Recherche & D?veloppement =09
T?l : +33 2 36 56 86 00=09
Fax : +33 2 36 56 86 01=09
www.wirecom-tech.com=09
<http://www.wirecom-tech.com> =09
WIRECOM Technologies
135, Rue Jacques Charles
45166 Olivet
=09
^ permalink raw reply
* [PATCH] dtc: supply a definition for YYRHSLOC if there isn't one
From: Paul Gortmaker @ 2008-07-16 17:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker, jdl, david
It seems that some machines, like a default RHEL4 install, will
not have a definition for YYRHSLOC, and that prevents building
dtc. This supplies what appears to be the standard definition
for it in the event that the host system does not have it defined.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
srcpos.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/srcpos.h b/srcpos.h
index e17c7c0..fa4d001 100644
--- a/srcpos.h
+++ b/srcpos.h
@@ -39,6 +39,10 @@ typedef struct YYLTYPE {
struct dtc_file *file;
} YYLTYPE;
+#if ! defined(YYRHSLOC)
+#define YYRHSLOC(Rhs, K) ((Rhs)[K])
+#endif
+
#define YYLTYPE_IS_DECLARED 1
#define YYLTYPE_IS_TRIVIAL 1
#endif
--
1.5.6.2
^ permalink raw reply related
* [HOW] binutils-2.17 breaks the 2.6.26 kernel
From: Milton Miller @ 2008-07-16 16:21 UTC (permalink / raw)
To: ppcdev; +Cc: Alan Modra
Hi.
I've been working with Debian bintuils 2.17-3 (which identifies
itself as 2.17) on my build box for some time.
When testing all-yes-config, I was getting warnings, but the
vmlinux was booting via kexec.
Since I was replicating the warnings from BFD about section lmas
overlapping in vmlinux.strip.$$, I was encouraged to actually try
booting the resulting stripped kernel. After a false start (getting
the old binary) I ended up replicating the fail-to-boot some people
have reported on linuxppc-dev.
Digging into the failure, we were trying to copy *way* too much data
in copy_and_flush from after_prom. I found the value loaded from
_klimit was something like 0x00002fea_00400000, not quite _end that
it was initialized.
I tracked this down to the .rodata and all sections following loosing
the inter-section alignment.
/DISCARD/ {
....
}
text: AT( .text - LOAD_OFFSET): {
....
}
. = ALIGN(0x1000) /* this align directive aparently gets lost
when stripping the file */
.rodata: AT (.rodata - LOAD_OFFSET): {
...
}
the effects of that align were dropped during strip, shifting all
following sections up in memory and the resulting failure.
I don't know if the fault is ld or strip.
The behavior came between 2.6.24 and -next-20080710, but others
have suggested their kernels don't boot in the 2.6.25 to 2.6.26
transition, and a likely candidate is the addition of AT(x) to
set the lma, although we also switched form TEXT_TEXT macro in
include/asm-generic.h to a hand-rolled .text section.
Can we come up with a workaround?
thanks,
milton
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Grant Likely @ 2008-07-16 15:46 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: fkan, linuxppc-dev, Victor Gallardo, linuxppc-embedded
In-Reply-To: <200807161646.02306.arnd@arndb.de>
On Wed, Jul 16, 2008 at 04:46:01PM +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Grant Likely wrote:
> >
> > >
> > > And then you don't need this file at all. Just add a
> > > "amcc,canyonlands" string to your root node compatible property.
> >
> > No! Don't do this because it is not true!
> >
> > Instead, add your board name to canyonlands.c in canyonlands_probe().
> > It's not the most scalable solution, but it keeps you from lying about
> > your hardware in the .dts file.
> >
> > I'm working on a more scalable solution for this, but for now just add
> > your specific board to canyonlands_probe().
>
> Shouldn't it be enough to have a common compatible value in each
> of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> specific type unless you need to do something special?
This is bad for the same reason that "amcc,44x-<blah>" compatible values
are bad in device nodes. The definition of '*-44x-*' changes over time as
new parts are added. Compatible values should always reflect an exact
part number.
g.
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Grant Likely @ 2008-07-16 15:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Victor Gallardo, fkan, linuxppc-embedded
In-Reply-To: <20080716103752.463e00cb@zod.rchland.ibm.com>
On Wed, Jul 16, 2008 at 10:37:52AM -0400, Josh Boyer wrote:
> On Wed, 16 Jul 2008 08:15:39 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
> > On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> > > And then you don't need this file at all. Just add a
> > > "amcc,canyonlands" string to your root node compatible property.
> >
> > No! Don't do this because it is not true!
>
> Meh. You're splitting hairs. It _is_ true from a kernel perspective.
... at this particular moment in time. It may not be true 6 months from
now.
g.
^ permalink raw reply
* Re: [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Timur Tabi @ 2008-07-16 15:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, Linuxppc-dev
In-Reply-To: <9e4733910807160742t7037c098k67dcbbadbac992fc@mail.gmail.com>
Jon Smirl wrote:
> Probing an i2c bus does not necessarily come to a good conclusion. The
> probes for some chips can alter the states in others. People have
> accidentally changed voltage settings and fried CPU chips. The process
> is not well defined.
I agree. We should not be implementing any feature that encourages I2C bus
probing.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Jochen Friedrich @ 2008-07-16 14:48 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, Linuxppc-dev
In-Reply-To: <20080716142436.GD24045@secretlab.ca>
Hi Grant,
> On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
>> Currently, the I2C buses are probed for HWMON I2C devices, which might
>> not be acceptable in same cases. This patch makes device probing
>> configurable through the property "probe" of the FDT I2C device node:
>>
>> i2c@3000 {
>> ...
>> compatible = "fsl-i2c";
>> probe;
>> ...
>> };
>
> You need to add documentation to booting-without-of.txt about what the
> 'probe' property means. Also, 'probe' is a pretty generic term being
> used in an i2c specific context. Can you prefix it with i2c or
> something to protect the namespace? 'i2c-probe' perhaps?
In i2c-cpm, I currently use the property "linux,i2c-class" to set the
i2c class directly as documented in dts-bindings/fsl/cpm_qe/cpm/i2c.txt.
We should agree on *one* method to set the i2c class.
Thanks,
Jochen
^ permalink raw reply
* Re: Booting ML405 (Kernel panic - not syncing: No init found)
From: Ron Sass @ 2008-07-16 14:47 UTC (permalink / raw)
To: Neeraj Garg; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <487C4326.9000000@cdac.in>
Hmmm... I think you've got a problem with your ramdisk. There are
a couple of issues but these alone don't explain your helloworld test.
1. busybox should be set to root not neeraj
2. you need to setuid busybox for some apps to run
(chmod 4775 bin/busybox so that it is srwxrwxr-x-r)
3. I would be wary of Yaghmour's text... it is a little dated
and if I remember correctly, he uses some regular expressions
to copy "just" the libraries you need to lib; but with
newer versions of gcc/glibc these regular expressions
don't catch everything
Two questions:
Can you tell me exactly what your cross-compile command-line looks
like? How are compiling helloworld?
How are you creating the ramdisk? How do you go from directory
structure to ramdisk.image.gz?
Ron
>
> Hi,
>
> --Ron,Permissions are -rwxrwxr-x for all and owner is neeraj itself. And
> shared libraries are present in lib/ . Now I have placed helloworld.elf
> (using printf to print helloworld, and linked with -static option) in
> bin/ and changed init=/bin/helloworld , again it says cannot execute
> /bin/helloworld.
>
> --John, we are using our custom hardware board, not exactly ML405 but
> its more or less similar to ML405, so I cannot use bit file provided for
> ML405. Till now we were using xilkernel, but now onward we are planning
> to use Linux. For serial console I have no option other than uartlite.
> This is how I compiled kernel :
>
> 1) make ARCH=ppc ml405_defconfig
> 2) patched kernel src with EDK(10.1) , so as to change xparameter.h, and
> later made some changed in arch/ppc/boot/simple/embed_config.c and
> xparameters.h file.
> 3) make ARCH=ppc menuconfig , and selected uartlite to be console and
> ramdisk as file system.
> 4) Created ramdisk (as per Building embedded linux, Karim Yaghmour,
> however major and minor number for device nodes is similar to ramdisk
> provided at git.xilinx.com)
> 5) I have placed this ramdisk in arch/ppc/boot/images
> 6) And then issued $make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu-
> zImge.initrd
>
>
> --I have downloaded ELDK4.1 and installed it. And when I compile
> simple helloworld.c using cross compiler, it says unresolved symbol
> 'printf' . Is there anything else to install with ELDK ?
>
>
> -------------------------------------------------------------------
> Neeraj Garg
>
>
>
> In addition to what John wrote, I would also investigate your ramdisk.
> I would be sure to check that you have the permissions/owner set correctly
> on bin/busybox. Also, I would double check that, if you compiled busybox
> with shared libraries, the shared libraries are in the right place
> on your ramdisk.
>
>
> Ron
>
> >
> > Hi,
> >
> > Yes I am using ARCH=ppc (actual line is $make ARCH=ppc
> > CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I have
> > placed ramdisk.image.gz in arch/ppc/boot/images. In case of ARCH=powerpc
> > I cannot find processor type 405 , in make menuconfig. Thats why i am
> > using ARCH=ppc.
> >
>
> --------------060307000300070002040802
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Hi,<br>
> <br>
> --Ron,Permissions are -rwxrwxr-x for all and owner is neeraj itself.
> And shared libraries are present in lib/ . Now I have placed
> helloworld.elf (using printf to print helloworld, and linked with
> -static option) in bin/ and changed init=/bin/helloworld , again it
> says cannot execute /bin/helloworld. <br>
> <br>
> --John, we are using our custom hardware board, not exactly ML405 but
> its more or less similar to ML405, so I cannot use bit file provided
> for ML405. Till now we were using xilkernel, but now onward we are
> planning to use Linux. For serial console I have no option other than
> uartlite. This is how I compiled kernel :<br>
> <br>
> 1) make ARCH=ppc ml405_defconfig<br>
> 2) patched kernel src with EDK(10.1) , so as to change xparameter.h,
> and later made some changed in arch/ppc/boot/simple/embed_config.c and
> xparameters.h file.<br>
> 3) make ARCH=ppc menuconfig , and selected uartlite to be console and
> ramdisk as file system.<br>
> 4) Created ramdisk (as per Building embedded linux, Karim Yaghmour,
> however major and minor number for device nodes is similar to ramdisk
> provided at git.xilinx.com)<br>
> 5) I have placed this ramdisk in arch/ppc/boot/images<br>
> 6) And then issued $make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu-
> zImge.initrd<br>
> <br>
> <br>
> --I have downloaded ELDK4.1 and installed it. And when I compile
> simple helloworld.c using cross compiler, it says unresolved symbol
> 'printf' . Is there anything else to install with ELDK ?<br>
> <br>
> <br>
> <div class="moz-signature">
> <pre>-------------------------------------------------------------------
> Neeraj Garg
> </pre>
> </div>
> <br>
> <br>
> In addition to what John wrote, I would also investigate your ramdisk.
> <br>
> I would be sure to check that you have the permissions/owner set
> correctly
> <br>
> on bin/busybox. Also, I would double check that, if you compiled
> busybox
> <br>
> with shared libraries, the shared libraries are in the right place
> <br>
> on your ramdisk.<br>
> <br>
> <br>
> Ron
> <br>
> <br>
> > <br>
> > Hi,
> <br>
> > <br>
> > Yes I am using ARCH=ppc (actual line is $make ARCH=ppc <br>
> > CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I
> have <br>
> > placed ramdisk.image.gz in arch/ppc/boot/images. In case of
> ARCH=powerpc <br>
> > I cannot find processor type 405 , in make menuconfig. Thats why i
> am <br>
> > using ARCH=ppc.
> <br>
> > <br>
> <font color="navy" face="Arial" size="2"><span
> style="font-size: 10pt; font-family: Arial; color: navy;"></span></font>
> </body>
> </html>
>
> --------------060307000300070002040802--
>
>
> --===============0970715627==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> --===============0970715627==--
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox